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

"

Dao wrote:

"

ScrotieMcB wrote:

The only thing I'm not getting is the part where the client "faking" packets as lost opens up any room for hacks; I don't see how failure to acknowledge would open up hack opportunities, seems like the server would just log the client out eventually.

you just illustrated a case of it in your response to systemdown.

That case involves trusting the client. I'm not a big fan of trusting the client.

I think the appropriate server responses to missing ACKs is to resend, then if that isn't ACKd to log the account out. No exploitable gamestate manipulation there.

"

ScrotieMcB wrote:

"

Dao wrote:

"

ScrotieMcB wrote:

The only thing I'm not getting is the part where the client "faking" packets as lost opens up any room for hacks; I don't see how failure to acknowledge would open up hack opportunities, seems like the server would just log the client out eventually.

you just illustrated a case of it in your response to systemdown.

That case involves trusting the client. I'm not a big fan of trusting the client.

I think the appropriate server responses to missing ACKs is to resend, then if that isn't ACKd to log the account out. No exploitable gamestate manipulation there.

it was all discussed under the part where the client uses TCP only...

it was some of the reasoning i gave for the client to not use UDP, and "faking" lost packets was the packets sent by the client.

"

ScrotieMcB wrote:

"

gonzaw wrote:

You don't think client -> server should have UDP either at any point?

The server is the one with the gamestate, the client is the one that needs the gamestate streamed to it. The client has nothing to stream that the server wants; just specific commands.

I was talking more about syncing algorithms.
Maybe the client can tell the server with UDP every now and then the position of the player, so the server can go "oh wait, the positions are different so there's desync! Let me tell him the real position" or something like that

"

"

gonzaw wrote:

Now what happens when you (server) receive a new command (TCP) packet from the client?
Check the timestamp in it, and check your own timestamp.
After that, you rollback to the state NOW-(your time-client time), process the command, send back the UDP packet with the new stuff (damage done to monster, damage done to player, new position of the player/monster, loot dropped, etc)
After that set a new threshold (with the new difference in times you got from client/server), delete the states after the initial one, and keep going.

And now you are trusting the client to tell the server what time it is. Suddenly breaking GGG's encryption, as opposed to just going pixel-based, has an application. Hello, hacks.

Didn't we conclude that the server can 100% know if a packet is legit?
Like...if someone can break the encryption and change the time and stuff we break that assumption.

If assuming the client is telling the truth can eradicate desync then just try to implement the best security ever, instead of gimping solutions just because "you don't trust the client"

"

ScrotieMcB wrote:

The other problem with this is you're essentially asking the server to store many instances where it previously stored only one. If you didn't know, the reason why town portals close if you AFK too long is because the servers don't have the resources to have so many instances up simultaneously, so the server closes them and the portals that go to them. Say hello to 2-minute portals.

The "store instances" thing wouldn't be much of a problem if you just keep them open for 500ms or something.
But yeah it's just theoretical, maybe in practice that is expensive as fuck

"

But let's say that doesn't happen because GGG not only finds the money to properly redo netcode for UDP, but also lots of nice new servers. Let's say someone's at the top of the Onslaught ladder, and they die. Normally, the server would send information to the client to display the "You have died" screen, move the character to Standard, and mark "Dead" by their name on the website ladder. But wait! 762 milliseconds after the death was declared, the server gets a command from the player, dated 788 milliseconds ago, to hop in a Town Portal he created. So the server does one of two things:

• completes death actions immediately upon death, then implements undo commands to clear out the "you have died" screen, move characters from Standard to Default league, and remove Dead status from ladder rankings. In addition to being potentially exploitable commands, this opens up a whole can of worms as people realize that GGG has a command to resurrect dead hardcore characters.
• implements a waiting period before implementing certain responses, to see if a delayed command appears. This is kind of a slippery slope, and if GGG goes all the way down it, the delay before responding to anything you do would be about equal to the acceptable delay in your actions... which means you'd both be living an equal amount of time in the past, having zero effect for a shitload of coding. The less important it is (lack of death, lack of awesome item, etc.) the more likely it is not to suffer mutual delay, which runs counter to what we want the suggestion to do.

All in all, a lot of work for something that's desync treatment, not desync prevention.

How would you propose that someone at the top of the Onslaught ladder is prevented from dying because of that desync, when he successfully sent a command to the server that would have saved him?

I'd even say that with stuff like death in hardcore leagues you should be even MORE careful with desync, and have more planification to erase it completely, than for instance in normal combat when you have full health.

If that "planification" involves undoing the death (i.e "resurrecting" him), then I'm all for it.
Of course there can be better ideas that just don't involve "Do X, but if you fuck up rollback EVERYTHING".
I don't see anything wrong with the 2nd choice basically. If the player died "freeze" the game, and wait a little bit (the "threshold" amount of time I described earlier).
If he gets a command by then, analyze it and go back to the previous state and execute it (it might have saved the guy)
If he doesn't get a command, then continue. The guy died so "living in the past" won't matter to him.

"

gonzaw wrote:

Didn't we conclude that the server can 100% know if a packet is legit?

We concluded that the path of least resistance -- much less resistance -- for hackers would be to hack some other way; not quite the same thing as saying 100% legit. The assumed legitimacy rests on the premise that breaking the encryption does not give the hacker any features that pixel-based hacks would not.

"

gonzaw wrote:

How would you propose that someone at the top of the Onslaught ladder is prevented from dying because of that desync, when he successfully sent a command to the server that would have saved him?

By the desync never existing in the first place. Which is the idea behind improving the netcode. An ounce of prevention is worth a pound of cure.

"

HeavyMetalGear wrote:

There is also significant information I quoted and critiqued (to be more Developer-friendly) that elaborates more about Desync and what GGG should focus on for a possible Fix.

"

"

ScrotieMcB wrote:

2. True Packet Information Entropy (both brevity and compression)
Right now I doubt GGG has taken efforts to make Packets compact, and is instead focusing on making them readable by humans, which greatly increases bandwidth consumption.

This isn't exactly non-standard for the industry; for example, the standard HTTP header* that comes attached to web pages you view looks something like this (which would be shrunk about 15% with lossless compression):

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

Read this: Entropy, Compression, and Information Content.
Reducing the size of Packets using these methods would help with bandwidth issues (both for GGG and the players who have them) and also help ease the Packet flow issues between TCP and UDP that where mentioned by the author in the TCP vs. UDP article.

* Although I've run Packet Capture on PoE before (to determine that PoE is 100% TCP), I haven't decrypted the Packet Contents, so I'm using this as a blind example. It's very hard to tell what GGG is doing on this front.

"

"

Dao wrote:

I highly doubt GGG made a Protocol similar to http, and I highly doubt that in the Multiplayer Gaming Industry it is standard or common. Then again, I am not a Game Designer.

"

ScrotieMcB wrote:

In my experience, the emphasis is on debugging clarity, which leads to very human-readable data. It's rare to see a strong emphasis on compactness, and instead to see a focus on understanding how the client misinterpreted a received communication.

this part is highly speculative, quite irrelevant to his suggestion, and highly contested by me without having any concrete answers short of what you quoted (though you seem to have quoted only our statements, not the important part of this discussion). no debugging advantages to it, only further complications from the programming stand point. and thus has no reason to actually go in that form in the packets. go through the relevant parts of my posts - especially the more recent ones - for explanations.

if you want this thread to be sticky, i would advice to remove that part, at least until it can be properly answered, and even then mark it as speculation at the end of the thread, or something like that. and any action that would lead to it being not speculation (meaning verified or disproved) would be illegal anyhow.

"

ScrotieMcB wrote:

"

gonzaw wrote:

Didn't we conclude that the server can 100% know if a packet is legit?

We concluded that the path of least resistance -- much less resistance -- for hackers would be to hack some other way; not quite the same thing as saying 100% legit. The assumed legitimacy rests on the premise that breaking the encryption does not give the hacker any features that pixel-based hacks would not.

Well let them try break the encryption then, just use a super secure one and you are set.

I entrust SSL with the encryption of my password and stuff for most of internet shit, why shouldn't you trust GGG's encrypted package (which might as well use SSL as well)?.

Like...does it have any glaring vulnerability or something I'm missing? If GGG encrypts the packets, and also uses a "non-conventional" protocol, then there shouldn't be glaring ones, right?
Basically don't use HTTP and send ASCII chars, use streams of bytes just like TCP/IP do, and the protocol is only known by GGG.
If a hacker somehow DOES manage to decypher the packet, he'll just be welcomed with 0110010110101011000110110111010100 and he won't know shit what to do (different than getting a "Hi this is a packet with super hidden info X" if it were sent like HTTP for instance).

Use RSA if you want maybe, or whatever as well, or a higher sophisticated encryption method (I don't know many).

You telling me hackers may still be able to bypass all of this...just to be able to change the timestamp thing I mentioned? (like, it's not even to insta-cheat and get 100000 exalteds in 1 minute or something like that)

"

"

gonzaw wrote:

How would you propose that someone at the top of the Onslaught ladder is prevented from dying because of that desync, when he successfully sent a command to the server that would have saved him?

By the desync never existing in the first place. Which is the idea behind improving the netcode. An ounce of prevention is worth a pound of cure.

Well, I'm going by what GGG said that "desync will never be gone and we have to deal with it oh" and that stuff. Basically I'm assuming desync IS and WILL be a thing and we have to come up with a way to counter it.

"

gonzaw wrote:

You telling me hackers may still be able to bypass all of this...just to be able to change the timestamp thing I mentioned? (like, it's not even to insta-cheat and get 100000 exalteds in 1 minute or something like that)

With timestamp fraud, it would allow hardcore players to Alt+F4 after it's too late to Alt+F4. Just toss in some deliberate lag generation during non-key times, and it would see some use.

Assuming, of course, that they could break the encryption. And that might be tricky indeed. So I don't mean to be all Chicken Little and pretend that you do one thing like this and the next day the servers are on fire. But it is a vulnerability, and when you're dealing with something that you want to be secure, "why is there a door there?" is a totally valid question, even if it's guarded.

"

ScrotieMcB wrote:

"

gonzaw wrote:

You telling me hackers may still be able to bypass all of this...just to be able to change the timestamp thing I mentioned? (like, it's not even to insta-cheat and get 100000 exalteds in 1 minute or something like that)

With timestamp fraud, it would allow hardcore players to Alt+F4 after it's too late to Alt+F4. Just toss in some deliberate lag generation during non-key times, and it would see some use.

Assuming, of course, that they could break the encryption. And that might be tricky indeed. So I don't mean to be all Chicken Little and pretend that you do one thing like this and the next day the servers are on fire. But it is a vulnerability, and when you're dealing with something that you want to be secure, "why is there a door there?" is a totally valid question, even if it's guarded.

How would they do that?

Remember it's TCP, packets come in order. It wouldnt' make sense for the server to get a packet at time X, then a packet at time X-1.
If that happens I'd assume the server could indeed ignore the 2nd packet.

They have to be very lucky that they didn't send ANY packet after the supposed "fake time" they alt'ed.

If they sent a packet at time X that said "I attack this monster", then if they died at X+1, they can't do anything at all, unless they send a packet with fake time X+0.5 that somehow prevents them from dying (which most likely won't).


Also I assume they'll have a process ready to send these fake packets for them?


Even then.....avoiding death in 7% of the situations is a "good" tradeoff for "solving" desync (yeah it's a stretch, but it may solve it somehow if more work is put on that idea).
Like, I dgaf if a guy cheated to avoid death 1 time. I would care if he got 10000 exalts, or if he got insta-loot of his choice, or if some other stuff.

Again, people Alt+f4 in real life and nobody cares, this is just a slightly more sophisticated Alt+f4


Is there any other vulnerability?

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.