Technical solution to eliminate desync in single-player sessions

"

gonzaw wrote:

"

ScrotieMcB wrote:

*yawn*

"

qwave wrote:

But hackers can just modify the timestamp to any value that they want! Therefore the server has to believe whatever the client tells them

The server can detect modified timestamps because the timestamp is encrypted using the current deterministic seed random number based on the state of the game. This is called 'signing' the packet. The timestamp and seed is used as a signature.

In other words, the server will only be able to read the packet if it can decrypt that packet using the exact deterministic seed that your client had at the time of creation.

So basically, if your character attacks a Rhoa and then raises some skeletons, the deterministic seed will be at a specific value at that exact time.

Therefore, it is impossible for the client to forge the timestamp, because it uses the deterministic seed to 'sign' the timestamp.

The hack also has the seed, and can track uses of it (both alleged and real) to know precisely which number to encrypt with.

Let me break this down for you real slow.

Starting from before the Path of Exile client even launches, and ending after the client closes, a hack can view any and every network communication the client receives, send any message to the server which it wishes, prevent any outgoing message from the client, or perform essentially any process which the client could (encryption, decryption, iteration). Therefore, no form of encryption can ever secure the client against local (e.g. not man-in-the-middle) hacks. Any keys which the client has, a hack can also have; same with any seed, any counting process, any analysis of data.

The ability of a local hack to spoof the client is limitless. In fact, the client can't even prove that it is the client. (Do you really believe that the ability to solve captcha proves you are human?)

You say to forget what we know. You say the client can be trusted. Sorry, but no. We can't even trust that what we think is the client, is actually the client. Nothing will ever solve this, ever; even token-based authentication can be spoofed.

While you've actually kind of converted me in terms of deterministic simulations, you have not, nor will ever, convince me that trusting the client is a good thing. Because it really, really isn't.

Physical control of a system is total control of a system.

I am not sure if this could be possible, but I'll give it a try.

So, what is this client, you ask? Well, abstractly speaking, I would say it is the pair <program,player> that occurs when the player executes the PoE.exe .
But "hacks", have total access to the physical data of PoE, and can simulate any interaction a player can have with the process and code. If a player moves the mouse and clicks the screen, there exists hacks that simulate that mouse move and click. If a player types a key, there are hacks that simulate that key press.
In terms of the program, the hacks can get access to the source code, and any configuration file. We can assume that will happen (at least after some time, the hacker has to decrypt files, figure out protocols, etc). Thus, the hacker has access to all the code, knows exactly how everything works in the client, and how the client-server relationship works, at least from the point of view of the client. He can also make tests and know exactly what each client network request/response does to the game.
So basically, any hacker can create a new pair <simulated_program,simulated_player>, therefore the hacker can simulate the client, or what the server thinks of the client.

Up until this point, I have to agree. The conclusion of this is indeed never trust the client at all, since ANYTHING that the server can consider comes from a client, can come from a simulated one.

But this depends on the server recognizing the client as that <program,player> pair. Maybe if we could define it in some other way, this could be averted?

There's one example that crosses my mind: runtime environment.
The "client" executes in a process in the machine, but does so in a specific runtime environment. This could be native code running normally (is stored in memory, is executed by CPU), or it could be bytecode running in some virtual machine like JVM, etc.
Now this could add a new dimension to the previous "definition" of a client. Perhaps, it could be possible to define a runtime environment where PoE runs, so that no "hack" can run in the same environment as this one. Or perhaps, this runtime environment could be defined in a way that the PoE program can be uniquely identified, and the "hacks" are identified in a different manner. Let's say this identification is an "RTE_id" number.
Now, we can say that, PoE, running in a specific runtime environment, by a specific player, defines a tuple <RTE_id,program,player>. This new tuple is the one that defines the client. The server knows this tuple identifies the client. Now, can it be simulated by hacks? Well, we know the "program" and "player" parts can be simulated, but because the hacks can't manipulate the runtime environment they are running in, and they are identified by a "RTE_hack_id" number, then any hack will be, at most, identified as a <RTE_hack_id,simulated_program,simulated_player> tuple.
The program can be simulated, the player can be simulated, but not the runtime environment authentication. Thus, the client is not simulated, thus with the proper authentication, the server can trust the client.


I know this seems too abstract and maybe nonsensical, but that's because it HAS to be vague, without introducing other technical aspects (like network, etc), since that would just complicate things.

Basically, define a lower-level entity that acts as the "trust advisor", that can define if the client can be trusted or not. The hacks or hacker won't be able to manipulate this lower-level entity (won't have sufficient OS permissions, etc), so he can't access anything about it, or manipulate it into "simulating" the client.

I kind of think this may be impossible...but I'm not an expert on this subject. Could something like this be possible to do? In some operative system, in some computer architectural pattern, in any way? If it can be done in at least one way, that's a start. Obviously if it's something complicated (like maybe creating an OS from scratch just for PoE :P ) it won't be viable at all and GGG obviously won't be able to do it, but at least theoretically it could be done, and with time and effort...who knows? Maybe we could get there.