Technical solution to eliminate desync in single-player sessions

For all the goofs who still defend desynch:


What can be done? We all know desynch exists, and cant be fixed, but can be masked better to impact gameplay less. So lets look at the instances where players suffer the most from desynch:

1. Finding yourself in 2 rooms away:
This happens because your client predicts a mob coming your way from 2 rooms away. You click on the mob and on server side your char starts walking towards the real position of the mob.

To me it seems there are couple of fixes for that:
1. Client mob action predict code: It is obviously faulty in this case. Fixing this predict code would remove this problem %100
2. Changing "clicking on monster = moving to that monster's position on server to attack" to "clicking on monster = moving to monster's position on client at the moment of attack, to attack". That way in worst case char would attack empty space where his client shows that there is a monster, instead of charing 2 rooms away to suicide

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.

3. Mobs that actually come to you in server side, not showing on client:
Again this is a similar problem to #1, where mob action predict code is not working properly. Improving client mob action predict code would ease that greatly.

4. Getting stunned when walking is almost always desynch:
I have no idea how this can be fixed at all. You either have to be stun immune or never attempt to disengage from pack of mobs.. Maybe someone will have ideas.

5. Getting close to obstacles causing desynch:
I dont know how many times I died to Brutus, my client showing I am behind that damn wall; meanwhile serverside I am not. Just give the client control over movement. What is the worst thing hackers can do? teleporting? Let them do it, who gives a fuck as long as we can play smoothly. It is not like they can use client's movement ability to duplicate items.

"

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

"

gonzaw wrote:

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.

"

ScrotieMcB wrote:

Spoiler

Hack easily has access to official version of PoE to create hash, and can run hacked version separately.

The point is that PoE would ONLY be able to be run in this "magical" OS, and this OS would be able to determine when the PoE's binaries were hacked or not. So the hacker wouldn't be able to run the hacked version "separately".
Granted, that's an hypothesis I missed to specify (that PoE would only be able to be run in this OS)

EDIT: Also, I don't see what's "facepalm" worthy. Try to be a little less of a dick Scrotie, thanks.

"

gonzaw wrote:

"

ScrotieMcB wrote:

Spoiler

Hack easily has access to official version of PoE to create hash, and can run hacked version separately.

The point is that PoE would ONLY be able to be run in this "magical" OS, and this OS would be able to determine when the PoE's binaries were hacked or not. So the hacker wouldn't be able to run the hacked version "separately".
Granted, that's an hypothesis I missed to specify (that PoE would only be able to be run in this OS)

Why are you assuming the OS can't be compromised >_>

"

genericacc wrote:

"

gonzaw wrote:

"

ScrotieMcB wrote:

Spoiler

Hack easily has access to official version of PoE to create hash, and can run hacked version separately.

The point is that PoE would ONLY be able to be run in this "magical" OS, and this OS would be able to determine when the PoE's binaries were hacked or not. So the hacker wouldn't be able to run the hacked version "separately".
Granted, that's an hypothesis I missed to specify (that PoE would only be able to be run in this OS)

Why are you assuming the OS can't be compromised >_>

Those are the hypothesis. This is the theoretical problem I want to know if it can be solved or not: DOES there exist a way, for the OS to NOT be compromised, so all the hypothesis I described above become true in this OS?


EDIT: The rest of my post is an attempt to say: "The problem of determining whether or not the client should be trusted, can be DIRECTLY reduced to the problem of whether or not the OS can be compromised, or whether or not the hypothesis I described above can be true in some scenario".
This reduces the problem to more specific one, reducing complexity, allowing us to focus better on what we can solve, how to do it, how to organize us to do it, bla bla bla.

"

gonzaw wrote:

Those are the hypothesis. This is the theoretical problem I want to know if it can be solved or not: DOES there exist a way, for the OS to NOT be compromised, so all the hypothesis I described above become true in this OS?

Not on consumer PCs. If you control hardware too you can do a version of UEFI Secure Boot with locked keys like they do on ARM, then hope that there are no exploits in the system stack itself

"

genericacc wrote:

"

gonzaw wrote:

Those are the hypothesis. This is the theoretical problem I want to know if it can be solved or not: DOES there exist a way, for the OS to NOT be compromised, so all the hypothesis I described above become true in this OS?

Not on consumer PCs. If you control hardware too you can do a version of UEFI Secure Boot with locked keys like they do on ARM, then hope that there are no exploits in the system stack itself

Hmm, interesting. Why is it that it doesn't work on consumer PCs?

"

gonzaw wrote:

Hmm, interesting. Why is it that it doesn't work on consumer PCs?

Microsoft won't certify PCs for Win8 unless they can enter custom mode or turn off secureboot so you don't have a chain of trust to your bootloader. Since most OEMs want certification, there you go

I read this daily now. Someone should compile this into block buster movie. The name of the movie, would be Code warriors of Wraeclast universe ^^.


I really meant it and i love these discussions, cause i learned something so far from this thread. So thank you for the 4th time now :P.