Technical solution to eliminate desync in single-player sessions

*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.

"

qwave wrote:

I have edited the main post. MeltingPoint, please pay attention to important things like timestamp generation. These are key points that prevent cheating.

Save for the fact that now the server is doing the loot roll, nothing I did in the 'hacking' section produced tainted timestamps, because the client produced them - I need to be really clear here - besides a small delay, the timestamps are in perfect order, and perfectly valid. Just because the Timestamp says the action was performed at 8:00:00, and arrived at the server at 8:00:01, doesn't make it an in valid timestamp/snapshot.

"

qwave wrote:

So wait, you're telling me that this 'seed' will ensure that a mob's AI works in the same manner on the client as on the server?

Yes, mob pathing occurs as a result of the deterministic seed being passed into the mob's artificial intelligence procedures.

I want to make sure we're clear here. Some definitions:

Seed = A value used to 'start' a Random Number Generator
Random Number = A value pulled from a Random Number Generator

In it's current incarnation, a Seed is sent once to start the Random Number Generator off. We are left with 2 possibilities for mob pathing/AI

1) All mobs use the Seed as their Pathing/AI generation.
2) All mobs use a Random Number as their Pathing/AI generation.

In 1) that would mean all mobs, or at the very least, all mobs of the same type/class, will behave the same. If you've found a way to use one Seed on the same mobs, and have a different outcome, you've essentially broken the point of the seed.

In 2) that would mean that each timestep/snapshot, a mob gets a new random number for it's pathfinding/AI, how can this result in fluid motion? How is it any different from coin flipping to determine movement?

Do you guys have Skype? I need to explain this verbally, because you guys don't seem to be understanding it.

Why are we arguing about security with a guy who obviously has no understanding of how security works?

"

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.

The client is never trusted. You can't spoof a packet because the timestamp has to match the seed / actions. I really really want you to understand this. If you have Skype I can explain in better detail. I am willing to take the time to talk to you because I think you are an influential member on this topic.

Anyone that wants a better explanation, I can discuss on Skype and show you exactly how it all works.

"

In 1) that would mean all mobs, or at the very least, all mobs of the same type/class, will behave the same. If you've found a way to use one Seed on the same mobs, and have a different outcome, you've essentially broken the point of the seed.

In 2) that would mean that each timestep/snapshot, a mob gets a new random number for it's pathfinding/AI, how can this result in fluid motion? How is it any different from coin flipping to determine movement?

The server is using this exact same system currently on the server. This is how AI works. My proposal enables the client to also simulate mob AI in the same way the server does.

"

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?)

The client does not have to prove he is a client. The only thing that's important is that the packet contains actions and a timestamp that are validatable by the server. The timestamp cannot be spoofed because it uses the seed generated by the actions at that exact time.

This means that the timestamp MUST match the actions which MUST match the seed which MUST be validatable. All must be true, otherwise the server can see that the packet is bogus.

This is the cutting edge on securing packet payloads / timestamps.

"

qwave wrote:

This means that the timestamp MUST match the actions which MUST match the seed which MUST be validatable. All must be true, otherwise the server can see that the packet is bogus.

I would LOVE to see some pseudo code on that.

"

qwave wrote:

Do you guys have Skype? I need to explain this verbally, because you guys don't seem to be understanding it.

It's not me you have to convince. I will say this, there is a vast difference between the amount and quality of information presented in that white paper you keep talking about, compared to that first post. If you expect GGG to take you seriously, you'll need to do better.

No hard feelings, thanks for your time.

"

deteego wrote:

Why are we arguing about security with a guy who obviously has no understanding of how security works?

It's people like you who are preventing this thread from moving forward. Just get out bro. If you haven't noticed yet, most of those who were originally against OP's ideas are now trying, I said trying, to move forward with him. While I don't understand pretty much anything they're saying, it seems accepted now that OP's idea has potential.

As long as there is a slight potential of desync moving toward getting fixed, no one should discourage such a discussion, even if it leads to nothing.

So, your words have no power here, just get out.

You know what? I'm going to write the code to prove it. I'm tired of trying to explain it. Lets see if you can argue when the code is in front of you. I'll even write a hacked version and prove that the server can validate it.

"

It's not me you have to convince. I will say this, there is a vast difference between the amount and quality of information presented in that white paper you keep talking about, compared to that first post. If you expect GGG to take you seriously, you'll need to do better.

No problem. Im writing the code now. Will paste it shortly as proof.