Technical solution to eliminate desync in single-player sessions

"

Sachiru wrote:

Wonder what's the difference between Console and PC for D3? Warden. Blizzard can be arrogant and do client-side damage calculations because it has this (spyware) software to prevent cheating, not through some magical serverside verification done via "deterministic seeds". Take away Warden and cheats abound, as we can see from the ton of console cheaters for D3.

"

.. reason why console version of D3 is hacked/cheated is because whole game and game logic is on your hard drive

"

LogoOnPoE wrote:

While I'm not saying you're wrong, all your sources discuss floating point calculations or conversion from floating point to integer, none of them discuss fixed point calculations as far as I can see.

"

symban wrote:

2. Mobility moves causing desynch:
The skill that is effected the most is whiling blades, to a degree that it is totally useless and unreliable. For all mobility skills insert "/oos" into the code of that skill. If mobility skills are prone to desynch, make sure client requests synch from server at the use of them.

"

Skogenik wrote:

"

symban wrote:

2. Mobility moves causing desynch:
The skill that is effected the most is whiling blades, to a degree that it is totally useless and unreliable. For all mobility skills insert "/oos" into the code of that skill. If mobility skills are prone to desynch, make sure client requests synch from server at the use of them.

Oh wow - no!

You don't know how labour intensive this is on the server and client; and in programming terms we call this 'Fixing the symptom and not the bug'.

I have no concrete evidence of course because I don't work for GGG, but I cannot imagine a good scenario if potentially every connected client spams /oos multiple times a minute.

Otherwise, good post and good thinking.

"

gonzaw wrote:

Lots of stuff about hashes...

Spoiler

"

genericacc wrote:

"

gonzaw wrote:

For instance, imagine GGG get a custom Linux distro made for themselves. They can twink ANYTHING they want, just to cater to PoE and how it handles the client.
Are you telling me there is no possible way GGG can twink their Linux distro, in a way no hacker can ever get full information about everything he needs to know to simulate the PoE client? If so, why?

The PoE client binary is sufficient information to simulate the PoE client binary, from a theoretical point of view. You have to install it somehow, so it could be reverse engineered.

Okay, how about this: Authentication based on a hash (SHA1 for example) of the PoE binaries

Basically, GGG releases the same game everywhere. This means the binaries are the same. Thus the security hash is the same everywhere. This means the PoE client can be "signed" with said hash, for verification purposes, right?

Now, we could assume the hackers would patch/hack the PoE.exe, and run their hacked version, right?
In this case, the hash created by the hacked client would differ from the actual poe hash. Why? 1) The hacked necessarily had to change something in the binaries to get some benefit from the hack. 2) The nature of hashes (at least SHA1 or whatever new one will come) means any small change will produce a completely new hash, and it's almost impossible to force collisions.

So, can't this new "PoE linux distro" do something with this to authenticate a "legit" PoE client?

For example:
1) User clicks Poe.exe/Poe.out/etc
2) The OS first computes the hash of the binaries executed
3) The OS gets the "official" hash that represents a legit PoE client stored somewhere in the system
4) The OS compares the stored hash with the computed one.
5) If the hashes are different, an error occurs, the PoE client is not legit and has suffered modifications, and the PoE client can't run
6) If the hashes are the same, the PoE client is legit and has suffered no modifications. The PoE client can now run.


Now, this is what I think these points bring to security and how they could/couldn't be hacked:
0.1) Hackers that change the binaries, change the hash of it.
0.2) A legit PoE client will always have a hash equal to the "official" one.
0.3) A PoE client is either legit or hacked
0.4) Because of (0.1), (0.2) and (0.3), if you compute the hash of a PoE client, and it gives you different than the "official" one, it's a hacked PoE client. Conversely, if the hash gives you equal to the "official" one, it's a legit PoE client.
1) This is a process that happens normally, there is no "hack" that can be done here (executing the .exe or whatever that means)
2.1) The hackers wouldn't be able to access and modify the kernel of the OS
2.2) Because of (2.1) the hackers can't change how the OS computes the hash, or how it access the binaries. Therefore the computed hash is legit and can't be tampered with
3.1) The hackers wouldn't be able to access the space in the disk drive that has stored the hash
3.2) The hackers wouldn't be able to modify the OS so that this lookup is done differently.
3.3) Because of (3.1) and (3.2), the lookup to get the stored hash is legit and can't be tampered with
4.1) The hackers wouldn't be able to modify the OS to change how this comparison is made
4.2) Because of (4.1), the comparison is always legit, given any 2 inputs
5.1) Because of (2.2), the computed hash is legit. Because of (3.3), the lookup of the stored hash is legit (it's the "official" one). Because of (4.2), the comparison of hashes is a legit operation. Therefore, the comparison of the 2 hashes, will return a legit result.
5.2) Because of (0.1), a "hacked PoE client" has a different computed hash if the computation is legit. Because of (2.2), this computation is legit. Therefore the computation of a non-legit PoE client is a legit hash different than the "official" hash.
5.3) Because of (0.2), a legit PoE client has the computed hash equal to the "official" hash. Because of (2.2) this computation is legit. Therefore the computation of a legit PoE client is a legit hash equal to the "official" hash.
5.4 Because of (0.4), if the hash is different than the "official", it's a hacked PoE client. Because of (5.1), the comparison of the computed hash and the stored hash will return a legit result, which is true if the hash is equal to the "official" one, and false otherwise. Therefore, if the comparison of the computed hash and the stored hash returns false, the PoE client is a hacked client.
5.5) Because of (5.4), a hacked PoE client will never be able to run/execute.
6.1) Because of (0.4), if the hash is equal to the "official", it's a legit PoE client. Because of (5.1), the comparison of the computed hash and the stored hash will return a legit result, which is true if the hash is equal to the "official" one, and false otherwise. Therefore, if the comparison of the ocmputed hash and the stored hash retuns true, the PoE client is a legit client.
6.2) Because of (6.1), a legit PoE client will always be able to run
7) Because of (5.5) and (6.2), only legit PoE clients will be able to run, and hacked PoE clients won't. Therefore any PoE client that runs is legit and can be trusted.


Sorry if the derivation is difficult to understand (with "legit" thrown around a lot), but if it's necessary I can make it clearer. I wanted to put the numerals the same as the "algorithm" above, to know which logical proposition equates to which step of the procedure.

So, based on this, if the axioms are true (the axioms are the underlined ones), then this would be a sure-fire way to determine if a PoE client is hacked or not, and to determine when to ONLY execute a trusted legit PoE client, and to reject modified clients or hacked ones.

If you find problems, then they can happen in 2 places:
1)One or more of the axioms are wrong: Then please point out which axiom you don't believe can happen. Remember, this is theoretical, I'm basing this on a theoretical custom OS that, if possible, will fulfill all those axioms. You have to prove, that for the axiom you believe is false, there exists NO possible OS or methodology to make that axiom come true.
2)The logical derivation is wrong: Then I fucked up at some point. Please point it out.

But if the axioms are right, and the logical derivation is right....then this solves the problem of "hacked" PoE clients right?
Wouldn't that solve most of the "we can't trust the client" problems?

Of course, the other problem of hacking is one where the hacker has Wireshark or something, intercepts packets from and to the client/server, and modifies them. However, this falls under the "runtime Environment" solution I mentioned. In this "magical" OS, the authentication is done on the PoE client that is running. For example, when the PoE client is running, the runtime environment provides it with an encryption key, in which case the hacker can't know what key that is (because the hacker has processes and programs NOT running in that same runtime environment), thus the legit PoE client and server can encrypt their packets so the hacker can't do anything with them, other than stopping them or letting them pass (but he has no way of knowing their content, thus with a sufficient communications protocol between the client and server, you could prevent ANYTHING the hacker might do to try and breach security).

Well...that may actually be another discussion, so let's go step by step (this all makes sense in my head, but I think this wall of text may seem like garbled gibberish to you guys haha).

If I have time, and you guys are interested and don't find uber noob mistakes I made, I could make this whole thing clearer, and indicate each specific problem and solution, its reach, its objective, etc.

"

"

Or no matter how "lower" you get in the architectural level, there is always a way the hacker can "hack" your programs/OS/etc at that level to be able to "hack" PoE?
...what about quantum computers? I bet hackers can't "hack" quantum superposition can they? :P

Quantum computers still use algorithms, they're just quantum algorithms >_>

Yeah it was kind of a joke

"

Shagsbeard wrote:

Good thinking except for that he's totally wrong. Movement doesn't "cause" desync. You notice desync when you move. You can be just as out of sync standing still. Inserting /oos after any move would increase costs to the point where GGG wouldn't be able to run PoE on our good will.

"

LogoOnPoE wrote:

Overall I really liked this thread and the articles that were linked. Thanks to everyone who provided constructive discussion.