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

"

ScrotieMcB wrote:

Each TCP transmission comes in order; a transmission normally consists of several packets. The transmissions themselves must be ordered. The process is somewhat similar to when you try to send a really long SMS message; imagine ensuring that part 1 of 4 always arrived before part 2 of 4, but having no guarantee that the long multipart message would arrive before a very short message sent a few seconds later.

But there is a TCP connection while those 4 packets are going round the world trying to reach the server, how can the other "very short message" ever connect to the server from the same process?

You can't have 2 exact TCP connections going on at the same time (or can you?....I forgot about that already lol).

Server gets connection from the client, recognizes the port and shit. Any other TCP connection from the same host but different port he'll take as another client, not the same one (or as an error if the port is not supported).

The 2nd message would have to wait until AFTER the 1st one (all 4 parts) finished (and TCP connection closes, or he uses the same TCP connection to send that message)

Routers do this thing called routing. Network traffic does not necessarily take the same path from point A to point B; BGP takes congestion and other factors into consideration. It's much like how, due to extreme traffic, your friend might arrive at a destination before you, even though you left the same place earlier than him (and you both obeyed all speed limits).

I know I make it sound super simple when I describe all the TCP vs UDP stuff, but there's a lot of stuff that isn't directly relevant that I just didn't feel like writing a book about. As a result, you're probably feeling very frustrated right now. Good questions, though.

Yeah I know that

My point is that if you send those "fake" packets in the same TCP connection, they arrive in-order with the real ones
If you don't send them in the same TCP connection while those packets are flying around, the server would (or should) ignore them
If you send them AFTER the original command was sent to the server (TCP connection open, data send, TCP connection close), then again you send the "fake" packet after the real command...again in order.

So if a packet with timestamp X is going to the server, and you send one with timestamp X-1, you HAVE to send it before the TCP connection between client and server is created for that "timestamp X" one, if not the server would (or should) ignore it.

So basically you have to send every "fake" time actually "in order" with the actual commands being sent to the server by the real client.
In combat this is fast as hell and I doubt you'll stay still not issuing any click or anything at all while in combat, thus those commands are sent over and over with successive timestamps (X+1, X+2, X+3, X+4, etc).
Then you can only "fake" a time that should come right after the last one sent, which in this case most likely is just a couple of miliseconds, thus would basically have no importance at all (if you die at time X, you basically die at time X-10 miliseconds as well no matter what you do).

today i was in lower level map like 20 levels below... got stuck in a corner by mobs, so i passed through, walked like "50 meters" and then got teleported back in the corner: but i didnt released the mouse button, and then again... again... i made 6x rollbacks xD

edit: less funny story was today against the smith in dunes map: this boss is already OP so have to move in the fight. Was a nice fail lost 15% in some horrible 3 seconds lag/RESYNC: completely unfair got an instantly "you are dead" screen.

"

gonzaw wrote:

My point is that if you send those "fake" packets in the same TCP connection, they arrive in-order with the real ones

Sorry to jump in on this discussion again, but this isn't quite right. TCP guarantees data transport integrity (e.g. resending lost bits), but due to congestion and routing factors as ScrotieMcB outlined, the order of your data "packets" (distinct from transport layer "packets" or data chunking) is not guaranteed to be received in the order that you sent them.

"

If you send them AFTER the original command was sent to the server (TCP connection open, data send, TCP connection close), then again you send the "fake" packet after the real command...again in order.

We're not creating a new connection for each transmission. We're just pushing or pulling from the (single) open connection as required.

"

systemdown wrote:

"

gonzaw wrote:

My point is that if you send those "fake" packets in the same TCP connection, they arrive in-order with the real ones

Sorry to jump in on this discussion again, but this isn't quite right. TCP guarantees data transport integrity (e.g. resending lost bits), but due to congestion and routing factors as ScrotieMcB outlined, the order of your data "packets" (distinct from transport layer "packets" or data chunking) is not guaranteed to be received in the order that you sent them.

....isn't it?

My memory is a little bit rusty, but I think I remember that if you do "TCP.Send(X)" then "TCP.Send(Y)" no matter what the other guy will receive X first THEN Y.

Like that's the point, the transport layer "packet" actually arrive out-of-order (well can arrive out-of-order), but TCP makes it sure to put them in order so the application-layer-packet arrives in order

"

"

If you send them AFTER the original command was sent to the server (TCP connection open, data send, TCP connection close), then again you send the "fake" packet after the real command...again in order.

We're not creating a new connection for each transmission. We're just pushing or pulling from the (single) open connection as required.

I don't know how GGG does it. But no matter how they do it then I think it still works like what I said

"

gonzaw wrote:

Like that's the point, the transport layer "packet" actually arrive out-of-order (well can arrive out-of-order), but TCP makes it sure to put them in order so the application-layer-packet arrives in order

Yes, the transport layer packets are presented to the application layer in order by TCP so the single transmission is received whole and intact. I think there's been some confusion around terminology - maybe we can use "packet" to mean transport layer (i.e. a timestamped TCP packet) and a "transmission" to be the application level message we're sending.

So what is the stuff that arrives out-of-order in my example?

My point is:
With a proper protocol between client+server, you can make it so that EVEN IF hackers decypher the POE packets, they CAN'T send "fake" packets with "fake" timestamps with time before the time of a packet that was already sent by the client to the server (before he sent the fake packet)

Is this wrong or not?
If not, then that "vulnerability" about my "solution" is not a concern (there can be other vulnerabilities maybe though...but you have to find them first! :D )

"

ScrotieMcB wrote:

Example HTTP header

GET /tutorials/other/top-20-mysql-best-practices/ HTTP/1.1
Host: net.tutsplus.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5 (.NET CLR 3.5.30729)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Cookie: PHPSESSID=r2t5uvjq435r4q7ib3vtdjq120
Pragma: no-cache
Cache-Control: no-cache

However, if we convert it to this, it's 32% smaller, through brevity alone, loses zero meaning, and further compressible to 39% smaller:

Brief HTTP header

GT /tutorials/other/top-20-mysql-best-practices/ H/1.1
Ho: net.tutsplus.com
UA: Mo5.0 (Win; U; WinNT 6.1; en-US; rv:1.9.1.5) Gko/20091102 FF/3.5.5 (.NET CLR 3.5.30729)
At: t/html,a/xhtml+xml,a/xml;q=0.9,*/*;q=0.8
AL: en-us,en;q=0.5
AE: gz,def
AC: ISO-8859-1,utf-8;q=0.7,*;q=0.7
KA: 300
Cn: k-alv
Ck: PHPSESSID=r2t5uvjq435r4q7ib3vtdjq120
Pr: no-c
CC: no

Not sure why you're going into HTTP Headers, and the fact that you're not using binary / hex for the header is confusing...

Random enters for formating.


Would be a header.


Would be the REAL header, and yes that's a TCP header but the point is still the same.

0000000001010000 is still port 80 no matter how it's displayed on your capture program. If it wasn't your internet wouldn't work.

"

gonzaw wrote:

I'm talking about an application-level protocol

I'm going to assume you mean transport layer.

"

ScrotieMcB wrote:

Each TCP transmission comes in order;

Sent in order, received... not all the time, that's why we have 4 bytes for the sequence number.

gonzaw,

any protocol must be public, or have a a program that uses it, otherwise it is useless. if there is a program that uses it, then it might as well be public, because there are people who can learn what the protocol does. trying to hide the protocol, or the method of encryption, or anything else for that matter, will not work.

as for encryption, it doesn't matter at all. it is only relevant in man in the middle attacks. what you and ScrotieMcB are talking about is the player cheating - keeping himself alive. the program, the game client, is the one encrypting the data before sending, and that is in the hands of the player. anything about the protocol or the encryption is irrelevant to this topic because the hacker has the client, can find out how everything is done, and modify it to do things a bit differently.

theoretically, one could keep everything the client does regarding encryption as is, but modify the netcode to use raw sockets, which would just generate the same traffic most of the time, but send some "odd" packets when needed. you don't need to control the encryption if you control what goes in to be encrypted, and the packet headers that route the encrypted data back to the server.