Technical solution to eliminate desync in single-player sessions

"

How do you generate the packet buffer? You will need to use a cryptographic hash against the seed on every permutation in order to generate a packet buffer for the FUTURE. Do you have some sort of quantum processor at your disposal?

You can't just 'change' a packet without disrupting the entire snapshot. Any changes to any packets would require you to re-calculate the complete simulation.

I don't need to do that. My packets will come in absolutely natural order. I'll insert 5 second of waiting packets at start. One after each other, then I'll change the times of packets on each player action accordingly. One packet goes after each other. All cryptographic hashes will be correct with your seed send.

If at some time another seed is send, I'll just use that seed as in unchanged situation. Remember my packets are continuous, correct and in order!

IMPORTANTLY:
I'll not be changing the real network traffic packets but the messages client is sending by injecting the code to the client!

Filousov:

If I understand what you're saying, then you would be simulating the game client-side in memory, while telling the server that you are not actually moving/doing anything by injecting the packet buffer. Although this requires some incredible reverse engineering knowledge, lets assume that someone manages to accomplish it.

This can be solved by having the server generate the map/mobs. That way it requires you to actively play the game. Moreover, the server can be responsible for certain things that require you to stay in sync at all times.

"

qwave wrote:

Filousov: How do you generate the packet buffer? You will need to use a cryptographic hash against the seed on every permutation in order to generate a packet buffer for the FUTURE. Do you have some sort of quantum processor at your disposal?

You can't just 'change' a packet without disrupting the entire snapshot. Any changes to any packets would require you to re-calculate the complete simulation.

You're not getting it.

He's doing two seperate things:

1. A small modification to the game client so that whenever creates a timestamp it adds five seconds. Identifying where PoE's executable accesses the system clock and modifying to add 5 seconds to that does not require a quantum processor.

2. All Packets PoE creates now have 5 seconds added to them before encryption. After a packet has been encrypted but before it's send we stop it. We hold it. We don't do anything with it, we just delay it for five seconds so that when it arrives on server it seems as if it arrived at exactly the correct time.

Our client is now running 5 seconds into the future. If we detect we die we simply delete all the packets we're queuing and disconnect. The server will now repeat the previous 2-3 seconds of simulation in which we don't die and then log us off as we've been disconnected. We don't die.

I'll admit, Fulousov's hack proposals are even better and easier done than mine. Unlike me his method will actually provide a reliable 100% guarantee to avoid death hack.

"

qwave wrote:

ScrotieMcB, do you honestly believe that if they had 2% more bandwidth, they could eliminate desync? Your suggestions are really starting to move outside the realm of possibility now.

The point is that they should switch to partial UDP. And really, there's no such thing as eliminating desync, although there is such a thing as minimizing it to the point that it becomes unnoticeable. Even your so-called solution just pushes desync off of the client and onto the server.

Gobla: Yeah, I understand, he is playing the game while withholding a packet buffer that he created by sending tons of 'im not doing anything' packets. I think this can be resolved by making the server authoritative for certain actions, such as spawning mobs, generating loot, opening doors/chests/using doodads, generating the map, etc. I apologize for my misunderstanding.


ScrotieMcB: This solution eliminates desync completely. The server and client cannot 'desync' because the snapshot would be evaluated in it's entirety at the end of the instance/session.


I do think you guys are helping a lot with evolving this solution to a workable state.

"

qwave wrote:

Gobla: Yeah, I understand, he is playing the game while withholding a packet buffer that he created by sending tons of 'im not doing anything' packets. I think this can be resolved by making the server authoritative for certain actions, such as spawning mobs, generating loot, opening doors/chests/using doodads, generating the map, etc. I apologize for my misunderstanding.

You don't get it.

He's not sending tons of 'I'm not doing anything' packets.

He's simply playing the game as normal, adding 5 seconds to each packet's timestamp before encryption, and delaying all of them by 5 seconds.

The server will assume he spend those 5 seconds in a loading screen. He's now playing 5 seconds into the future.

It doesn't matter if the server is authoritative on all those things because they're irrelevant.

The only thing that matters is that he's sending completely legit and normally generated packets, except for the timestamp, in a continuous stream 5 seconds late. If he dies he interrupts the stream, including the 5 seconds of gameplay he's been caching.

The server takes over and simulates 2-3 seconds in which he doesn't die before logging him off.

He's immune to death.

A. If he's playing 5 seconds into the future, the server will not be able to perform the authoritative tasks that I listed, such as generating the map, spawning mobs, loot, chests, doors, etc.

B. The server could perform random sanity checks by providing a new seed, which would 'reset' his 'future progress'.

"

qwave wrote:

A. If he's playing 5 seconds into the future, the server will not be able to perform the authoritative tasks that I listed, such as generating the map, spawning mobs, loot, chests, doors, etc.

B. The server could perform random sanity checks by providing a new seed, which would 'reset' his 'future progress'.

All these things the servers has authority over require a loading period.

Client receives a map? It has to load it into memory, including all art assets.
Client receives mob spawns? Same story.

It'll simply appear as if he's running on a slow computer and loading all those assets takes him 5 seconds longer.

The random seed could help, true. But it wouldn't reduce the effectiveness of his hack to 0% and unless those checks are done every few seconds and don't allow much window for delayed packets of the old seed it's effectiveness will still be extremely high.

If the server does do them every few seconds and doesn't allow slightly late packets of the old seed then congratulations, you've now got desync again.

The server would reveal portions of the map, as it currently does. Therefore, he could not play seconds into the future. The sanity check would be there just to eliminate cases where this sort of cheating was present.

I do accept that the possibility exists that he could reduce his chance of death using these techniques. But again, I would rather eliminate desync/lag than worry than a random hacker is able to avoid death from time to time.

Actually, I believe ive found a solution. The random seed could require a hash of the system clock (milliseconds) in order to generate a random number. This means that every action you perform is 'signed' based on the time you performed the action. It would therefore be impossible to spoof snapshots/packets that have been generated at a time other than the current time. =)

There is actually a white paper that describes this technique:
http://www.cs.cuhk.hk/~cslui/PUBLICATION/ms2008.pdf

The theorem indicates that malicious packets can be bounded by single trip latency. It prevents timestamp exaggeration in this manner. Problem solved.

"In this paper, we presented a synchronization protocol for multi-player online games
that support dead-reckoning. Meanwhile, it is invulnerable to a very common type
of cheat called speed-hack. The general idea is that the server or peer players
can use the legal speed of an avatar to compute its position from a set of update
parameters. This eliminates the need to state the avatar’s position directly in the
update packets. Even if the cheater is able to modify the data in the update packets,
the cheater cannot spoof other players to render a faster moving avatar because the
displacement an avatar can travel is now bounded by the legal speed of the player
that is authorized by the server"