Technical solution to eliminate desync in single-player sessions

"

And as I tell you, because the delta is just a series of bits in memory, I can change the delta to whatever the hell I want. It's simply a matter of computing the optimal delta, then WAITING. Delta is time elapsed, so simply WAIT UNTIL THE TIME ELAPSES for your time to match.

If you wait, then the seed changes. You can change the timestamp to whatever you want, but it has to match the actions when the server simulates it. How are you not understanding this?

Run the code, see for yourself.

Some people are missing the fact the the code posted contains just an example, the server checks would, in reality happen on the server, not the client.

"

qwave wrote:

"

As far as I can tell, this just stops some sort of man-in-the-middle attack from happening. Does this code have a purpose beyond that?

The signature is an example of how to sign a packet. Technically you should probably sign the packet using the seed + timestamp + serialized packet. But I am just trying to illustrate how it's done.

Are you saying it's not possible for a hacked client to sign a packet in the same way that the unhacked client does?

If that's true, I was unaware that can be guaranteed. How so?

If not, then what is the purpose of the signature?

"

qwave wrote:

"

And as I tell you, because the delta is just a series of bits in memory, I can change the delta to whatever the hell I want. It's simply a matter of computing the optimal delta, then WAITING. Delta is time elapsed, so simply WAIT UNTIL THE TIME ELAPSES for your time to match.

If you wait, then the seed changes. You can change the timestamp to whatever you want, but it has to match the actions when the server simulates it. How are you not understanding this?

Run the code, see for yourself.

Wait and the seed magically changes? Every how many seconds? Even if you say that it changes every 10 ms, which would be ridiculous since you would need to send a seed every 10 ms, I can do

y=Attack(clientSeed, mob, x);

for(x=timestamp, x< timestamp +9ms; x+1ms) {
if (Attack.AttackDamage > y){
y = Attack(clientSeed, mob, x);
}
}

This in itself is already a damage optimizer, because it calculates optimal attack in between updates. You may live in some sort of universe that somehow magically sends updated seeds instantaneously without regard for the laws of physics and the speed of light, but we don't. And as long as there's a gap between updates, I can compute within that gap and cheat.


And what would your system do if you fail to receive the seed in time? It would desync. This does not solve desync, it adds another cause for it.

"

Wait and the seed magically changes?

We are approaching the point at which I feel that you are trolling. The seed changes when any other actor in the environment, or the simulation itself, rerolls the seed. This is up to GGG, not me.



Anyway, im working on this signature/security portion, because it seems it is causing a lot of confusion. It looks like I need to make a full example.

"

MeltingPoint wrote:

Some people are missing the fact the the code posted contains just an example, the server checks would, in reality happen on the server, not the client.

This code sucks as an example.

It's not indicative IN ANY WAY about what's actually happening on the server. It's indicative only of what's happening in his head.

This supposed 12-year-industry-veteran is making noobie changes, saying that hackers will at most only change three variables and stop there, probably out of some sort of misguided notion of fair play. Memory injection, packet buffering and reordering, speedhacks and synchronization problems aren't even addressed here.

For instance, where's the code to keep the server in sync? Even if you send the packet containing the seed the moment it's generated, it has to travel through wires, and will automatically be LATE when it arrives at the client.

Latency also isn't constant, you don't somehow have only 80 ms ping for the next three hours, it fluctuates. What would you then do, check delta? So if ping spiked to 160 ms, what do you do, desync? Oh right, this is somehow a desync solution, right?

Sachiru: Seriously, read the damn code. ALL of these things are handled. Hackers can change every single line of code on the client, the server will STILL VALIDATE THE OUTPUT.


Tell me how you would make your client attack a creature that is far away with the code I posted. Seriously. Speed hack and everything is accounted for.

You can fake the timestamps all you want, the server will still prevent you from attacking distant creatures based on movespeed.

"

For instance, where's the code to keep the server in sync? Even if you send the packet containing the seed the moment it's generated, it has to travel through wires, and will automatically be LATE when it arrives at the client.

You are trolling. You have to be trolling.

"

qwave wrote:

"

Wait and the seed magically changes?

We are approaching the point at which I feel that you are trolling. The seed changes when any other actor in the environment, or the simulation itself, rerolls the seed. This is up to GGG, not me.



Anyway, im working on this signature/security portion, because it seems it is causing a lot of confusion. It looks like I need to make a full example.

So tell me, oh expert, how often do you send a seed change? Merely standing still already causes a lot of changes. One mob even just looks another way, seed change. One mob moves, seed change. Someone in Global Chat says "SEED CHANGE!", seed change.

That would mean that you update seeds every moment in time, realtime. How would this

a) Prevent packet loss and therefore missing seeds
b) Prevent desync from flood of too many packets
c) Be somehow better from what GGG is doing right now

In the real world, the world we actually live in, sending seeds every time something changes is NOT PRACTICAL. Change is always there even if you are doing fucking nothing. Making the entire ENGINE re-initialize every time you so much as look at a monster funny would be laggy as hell for both the server and the client.

"

qwave wrote:

"

Wait and the seed magically changes?

We are approaching the point at which I feel that you are trolling. The seed changes when any other actor in the environment, or the simulation itself, rerolls the seed. This is up to GGG, not me.



Anyway, im working on this signature/security portion, because it seems it is causing a lot of confusion. It looks like I need to make a full example.

Why is a seed value changing? A seed initializes (hence the term "seed") a PRNG, it doesn't change unless you are instantiating a new PRNG.

I think you mean "state" and not "seed."

Why does serverValidate() instantiate a new PRNG every time it is asked to validate a packet? That can't be right, unless a new shared seed is generated each time and transmitted to the client (not shown in the latest version of the code I have seen).

I think it would be good to have a clearly defined space of code we are allowed to modify to try to "break" your code, and that the main() function (or whichever you'd like) should output whether or not our packet was accepted.

"

qwave wrote:

Sachiru: Seriously, read the damn code. ALL of these things are handled. Hackers can change every single line of code on the client, the server will STILL VALIDATE THE OUTPUT.


Tell me how you would make your client attack a creature that is far away with the code I posted. Seriously. Speed hack and everything is accounted for.

You can fake the timestamps all you want, the server will still prevent you from attacking distant creatures based on movespeed.

"

For instance, where's the code to keep the server in sync? Even if you send the packet containing the seed the moment it's generated, it has to travel through wires, and will automatically be LATE when it arrives at the client.

You are trolling. You have to be trolling.

Can't counter, can't explain, so call the guy a troll. Right.