Reasons Why Desync Happens (Thoroughly Explained /w Cited Commentary On Fixes & Focuses Info)

gonzaw:

how the process works all the time:

with X being right now, server receives packets usually with the timestamp [X-250] while client receives packets with the timestamp [X-100].

server sends with timestamp [X] as a normal trustworthy server, and client sends with timestamp [X-150], faking a delay of 150

how the process works at death:

right now in the server game simulation the client died. server sends packet with information about the death to the client

server point of view, with X being right now:
death was at [X], and sent to the client with timestamp [X]
last packet from client was with the timestamp [X-250]

client point of view, with X1=X+100 right now:
death was received at X1 with timestamp [X1-100]
new packet with alt+f4 sent with timestamp [X1-150]

server point of view, with X2=X+200 right now:
death was at [X2-200]
last packet from client was with timestamp [X2-450]
new packet with alt+f4 received with timestamp [X2-250]
so alt+f4 was at time 50 before death so server resurrects client

conclusion:

your suggestion has a vulnerability, and let's leave it at that. i will not explain further, short of reiterating an important point - the server game state is the important one. it does not go back in time because the client did something. the server cannot sync with the client, only the client with the server.

gonzaw:

i know little about any subject, and less about cryptography. but if you mention a public key, then a term called private key comes to mind. in that particular mechanism you are thinking of, there is some voodoo (read: mathematical) way that a private key is derived privately - as i said, generated each time a connection is established.

of course this is an age old memory, and i could be wrong. used to have some references regarding cryptography, wasn't ever motivated enough to dive into it. probably, once you decide what encryption method you are talking about, google could be of use and explain the process

EDIT:
irrelevant to the topic, as i said many times. so lets just forget cryptography and focus on the fact that the server cannot, under any circumstances, be the one syncing with the client.

"

Dao wrote:

gonzaw:

i know little about any subject, and less about cryptography. but if you mention a public key, then a term called private key comes to mind. in that particular mechanism you are thinking of, there is some voodoo (read: mathematical) way that a private key is derived privately - as i said, generated each time a connection is established.

of course this is an age old memory, and i could be wrong. used to have some references regarding cryptography, wasn't ever motivated enough to dive into it. probably, once you decide what encryption method you are talking about, google could be of use and explain the process

EDIT:
irrelevant to the topic, as i said many times. so lets just forget cryptography and focus on the fact that the server cannot, under any circumstances, be the one syncing with the client.

Well yeah let's forget about the cryptography thing, but one last thing:
the "private" key is private to each end-point. Server would have 1 private key, client would have another private key
The hacker could get the private key of the client, but that ONLY serves to decode packets that the server sends to him.
Without the private key of the server, and without the original message, the hacker wouldn't be able to decode packets sent by the client (he could encrypt new packets though)
Dunno if these get generated with each connection or not, but doesn't really matter.

...yeah I dunno what we were discussing this anyways lol

I'll get to that other post in a few minutes (after I try to understand it lol)

Oh, I get what you are saying...but hmm a couple of things:

1)I was mostly talking about "normal" kind of play, not death (since it is indeed an "important" subject and would require more thought behind it). I'll think more about it, it is indeed possible when the server realizes the player died a new procedure is put in motion (to prevent death by desync, but not have these vulnerabilities)

2)I don't think it's important the server sends a timestamp to the client. The client isn't the one "rolling back", the client just does things as he does now.
If the server sends the timestamp, then yes the client knows exactly when the player died so he can fake the timestamp.
If the server doesn't send the timestamp, then the wouldn't be able to know when he actually die and precisely fake a packet (unless the actual TCP/IP packets have a timestamp of their own? I forgot if they do).

But even then, this does follow my "You can't change the past" idea, where the client can't "undo" an action, he can just send a different action after one he already sent.
I dunno if being able to make the server rollback to "resurrect" the toon 50ms before would even matter at all if the dude will die 50ms later anyways

I don't know if there's a client command that can prevent you from dying in 50ms...?
Basically is the "alt+f4" thing a real command (sent via TCP in a POE-packet with TS and everything? Or is it just a FYN packet to end the tcp connection?
If it just ends the tcp connection then it doesn't matter (the dude already died in the server, the connection ends, but the server doesn't "rollback" anything since he didn't receive any POE-packet)

Dunno about "openinng a portal" stuff either, can it be done with a single poe-command that instantly tells the server the player is out of combat?


Depending on the answers to that, I'll have to think a little bit better about it.
It does seem that "player death" is one of the "extreme cases" to analyze and improve (maybe), but would you say that in "normal" play there is a vulnerability that can be exploited to change the game to a great advantage to the player?

"

gonzaw wrote:

2)I don't think it's important the server sends a timestamp to the client. The client isn't the one "rolling back", the client just does things as he does now.
If the server sends the timestamp, then yes the client knows exactly when the player died so he can fake the timestamp.
If the server doesn't send the timestamp, then the wouldn't be able to know when he actually die and precisely fake a packet (unless the actual TCP/IP packets have a timestamp of their own? I forgot if they do).

Timestamps prevent the client from receiving information, then receiving older information, then applying the older information. I don't see why one wouldn't use them; and for the UDP portion, it's all but required.

You're forgetting the principles from the first couple pages already.

"

ScrotieMcB wrote:

"

gonzaw wrote:

2)I don't think it's important the server sends a timestamp to the client. The client isn't the one "rolling back", the client just does things as he does now.
If the server sends the timestamp, then yes the client knows exactly when the player died so he can fake the timestamp.
If the server doesn't send the timestamp, then the wouldn't be able to know when he actually die and precisely fake a packet (unless the actual TCP/IP packets have a timestamp of their own? I forgot if they do).

Timestamps prevent the client from receiving information, then receiving older information, then applying the older information. I don't see why one wouldn't use them; and for the UDP portion, it's all but required.

You're forgetting the principles from the first couple pages already.

Okay, then what if it's done like it is today and the server sends the client info through TCP (instead of UDP)?

Well, fine, server sends timestamps, I can live with that.
So let's see if I can figure something out to solve the death thingy vulnerability (I'd like some answer on the alt+f4 thing though)

gonzaw:

1) cryptography:

first, let me remind you that the terms hacker, player and client are all interchangeable (except client also refers to the program). they are one and the same.

with that in mind, as you said, the hacker can decode messages by the server, and encode new messages. why would the client/hacker/player would ever want to decode his own messages? he is the one encoding them...

forget this topic. the fact of the matter is that client=hacker=player so any discussion about cryptography is irrelevant, because you cannot hide something that is already known!

2) the vulnerability:

the client does not need to know _anything_ ! with your design, the server is vulnerable. death was just an example, though the best one i could think of.

* very important - there is no "normal play"! what you should be most concerned about, as a programmer, designer, or whatever other thing you want to do with computers, is the not-normal cases, the extreme cases.

now, as for the example, the client doesn't need to know anything, not even the timestamp. review the example and you will see that it is the server keeping track while the client just does a simple operation - detect death and send with the usual faked delay. what the client needs to do is just fake a delay, then there is nothing to "undo" - the delay is faked so the everything the client sends, including the exploitation of your vulnerability, appears in perfect sequence. from the perspective of the server, nothing is "undone", because all appears in sequence.

you cannot try to solve this particular problem because other will surface that i cannot think of right now. fact of the matter is that your design is flawed, as this one example tries to show. you cannot fix just the death case and hope it is over, because this is a general vulnerability that is exploitable.

rules that you should adhere to: the server doesn't not, under any circumstances, revert back the game state. it is a continuous game simulation, and it is the client that should be synchronizing with the server.

1)But how would he play the game?

Like the POE application is the one showing you the monsters and animations and swings and moving your char, etc.
Do you expect the hacker to send EVERY poe-packet ever? How is he going to play the game?

By "client" I mean the real POE application that does stuff as usual
By "hacker" I mean the mean player that can send fake packets, prevent the real POE application from getting/sending packets, etc (well, "hacker" can also be someone that is interacting with ANOTHER player and wants to harm him or something thus hacks stuff between that player's client and the server maybe)

"

it is a continuous game simulation, and it is the client that should be synchronizing with the server.

But that leaves with shitty gameplay where YOU (in the client, that shows you stuff in the screen you believe is happening in real life) do stuff and think some stuff happens but it actually didn't because it arrived with a delay to the server and stuff.

I don't think desync can be fully "solvable" unless the server syncs with the client.
Or rather, unless there's a more thorough interaction between the two of them.


Anyways I think you are too "paranoid" about the hacker/client.
Surely there must be a way the hacker can't know 100% everything the client does (encryption keys, code, etc).
"Assuming" that will happen seems too over-the top to me. It'd be like saying "Oh, when planning the defense of a terrorist attack, you have to assume the terrorists have already infiltrated the White House and are in the President's bedroom RIGHT NOW!" or something.
Seems unrealistic to me, if there can be ways to prevent it you just ignore because this hacker is magical and can hack everything in the universe and there is simply no way to stop him or something

I'd like a more thorough explanation of why stuff like that is possible (why there can't be ANY security in the client itself regarding this stuff). Prove it to me, that way I can stop trying to find ways to counter-act it (i.e make the hacker NOT know everything the client does and has)

Also, again I ask: Does the "alt+f4" command include a POE-command, or is it just breaking the connection?
It seems to me it's just breaking the connection, if your OS just stops the client and he can't send any more ACKs (thus he wouldn't be able to "send" a "hey stop me from dying" packet back to the server)

Without the "alt+f4" thing I don't really see anything else this "fake packet before death" thing can really do to help that player/hacker (except maybe using a town portal instantly or something but I dunno how that works).


If you can somehow prove all that to me, then I guess I'll stop with the "server syncs with client" stuff, but then I ask: so how would you solve it?

@Dao: Server-to-client needs the timestamp, to properly toss out UDP packets if they're older than those already received. Client-to-server does not need the timestamp, because it doesn't care what time the client says it is.

Just nitpicking though; most of what you're telling gonzaw is dead-on.

@gonzaw: to be brutally honest, I lost interest in your client-trusting time-rewinding scheme pages ago and I'm just waiting for you to drop it.

gonzaw:

how does the hacker do it? seriously? it is a part of the code, if A happens then do B. it is patched into the client and it's done. the hacker/player doesn't even give it a second thought after that.

too paranoid? any piece of code (EDIT: by code i mean binary) that is available might as well be considered known. this is not paranoia, it is a fact. maphack? trainers? all the other plagues of diablo2? this is how it is done!

what changed since diablo2? more people inhabit the online world, and more people know how to do these things. i am not inventing anything new. it has all been done before and will all be done again.

one of the basic ideas behind writing a server is assuming that the client is unreliable and malicious and trying to protect yourself against it.

your solution also cannot work with more than 1 player, on top of everything. would the server synchronize with every player?

and forget alt+f4 and the death example. instead try to think how you fix the problem with the client faking a delay. at the bare minimum, the server will keep reverting back, and it will give the client advantages - more reaction time. with this in mind, it is no longer just a simple vulnerability, it is a major flaw!