Technical solution to eliminate desync in single-player sessions

"

genericacc wrote:

"

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

Hmm, okay. Sorry but I don't quite understand that Microsoft certifying process :P
My main question is: Can this only be done in Win8? Is it impossible to be done in a linux distro for example? Or some other OS?

"

gonzaw wrote:

"

genericacc wrote:

"

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

Hmm, okay. Sorry but I don't quite understand that Microsoft certifying process :P
My main question is: Can this only be done in Win8? Is it impossible to be done in a linux distro for example? Or some other OS?

Linux distributions that boot under UEFI Secure Boot either have their key added to the store or have their key signed by Microsoft (since MS key is in the keystore by default), usually the latter.

"

ScrotieMcB wrote:

"

gonzaw wrote:

Please know this is a purely theoretical discussion. I want to know if it is theoretically impossible or theoretically possible to do what I'm talking about or not.

At the end of the day, as far as the server can tell, the client is nothing more than a bunch of packets received over the Internet. Thus, it's not really about spoofing the OS; any OS information is just information on the packet, which can be spoofed by knowing what information to write down. What you are talking about is so theoretically impossible that it's actually irrelevant.

Hmm, yes I understand that. I think I might be able to go somewhere with this.

This is how I think it happens:

Red propositions are hypothesis. These are the ones that we "assume" true to reach our conclusions. If the logic is correct, then these are the ones we have to either prove true, or assume true as axioms in our theory
Yellow propositions are compound propositions, that use the previous hypothesis to derive new propositions we can work with

0) For the server, the "client" is just the bunch of packets he receives from a specific session.
1) If there is no hacking involved, the server always gets "correct" packets from a running PoE client (basically, there is no other external factor that fucks up that "stream" of packets)
2) Because of (1), the only way to "fuck" up the gameplay in the server, is to willingly "hack" some part of the process
3) Because of (0), for the hacker to "hack" the game (i.e fuck up the normal course of gameplay like described on (2) ), he has to manipulate the packets that are sent to the server
4) A hacker has 4 options for "modifying" the flow of packets from the client to the server, or basically 4 ways to "hack" PoE:
(Hack_1) Modifying the content that goes inside the packets that get sent to the server by the PoE client (deciphered content). Basically, getting the meaningful content from inside the packet and modifying it (for example, changing a timestamp, or changing a player position, etc)
(Hack_2) Modifying the flow of packets. I.e determining if a packet gets sent or not, resending packets, buffering packets, stopping packets from going to the server, etc.
(Hack_3) Creating packets of his own to send to the server (deciphered content). Basically, create his own meaningful packets (for example telling the server the player moved to position [x,y]), and then encrypting them and sending them to the server as if he was the PoE client.
(Hack_4) Modifying the content of the packets that get sent to the server by the PoE client (cyphered content). This means getting the encrypted data, WITHOUT knowing the meaning behind it (the hacker doesn't know whether the packet contains the player position, or damage, or the usage of a skill, etc), and just changing bits here and there and sending the modified packet to the server.
5) There exists an application protocol, that for any hacker that does ONLY (Hack_2) (but NOT Hack_1, Hack_3 or Hack_4), the server can determine when the flow of packets he receives are being manipulated by the hacker and when the packets he receives result from the normal flow from a "legit" PoE client
6) There exists an application protocol, that for any hacker that attempts to do (Hack_4), the server can detect when the packets the server receives have been tampered by said hack.
7) There exists an encryption mechanism for encrypting packets, that makes it (almost) impossible for a hacker to decipher packets without having the encryption key
8) Assuming (7) has some sort of public/private key algorithm, then the server keeps his private key and the hacker can't get it, and if the client finds a way to keep his private key without the hacker getting it, then there is no way for the hacker to decipher the packets sent between the PoE client and the server (again, based on 7)
9) There exists a methodology for the PoE client to have his private key in the encryption mechanism from (7) without the hacker from possibly getting it
10)Because of (9) and (8), there exists a way for the packets to be encrypted between the PoE client and server, so that the hacker can not decipher them at all.
11) Because of (10), in this "way" described, the hacker can't possible perform (Hack_1) (he can't decipher the packets being sent between server and client).
12) There exists a protocol, for the PoE client+server to follow, that allows the server to validate when he received a packet from that PoE client, and not one created from scratch by the hacker.
13) Because of (12), if the same protocol is followed, the hacker can't possibly use (Hack_3) on the server successfully
14) There exists an application protocol that can do both (5) and (6) and (12)
15) Using the methodology described in (9), and the application protocol (14), then the hacker can't possibly do (Hack_1), (Hack_3) or (Hack_4) (because of (11), (13) and (6) respectively).
16) Because of (15), it can't do the 1-3-4 hacks, thus it can ONLY do (Hack_2). Because it uses the protocol from (14), it uses the functionality from the protocol in (5). Therefore the server can determine when the flow of packets he receives are being manipulated by the hacker
17) Because of (16) and (4), the server will ALWAYS be able to determine when the hacker is trying to hack the game, manipulate packets, etc (the hacker can only possibly do 4 types of hacks, and all are accounted for and can be detected).
18) Because of (17) and (1), then if the methodology and protocols described by (15) are followed, then if the server receives packets he deems are "correct", it means there is no hacking going on at all
19) Because of (18), there exists a way for the server to know exactly then it's being hacked, therefore he can always detect hacks and can always trust clients when he doesn't detect anything abnormal. Therefore, the server can "trust the client".


I believe hypothesis (0), (1) and (4) could be taken as axioms.
I believe, it could be possible for (5) to be true, but it may result to be a little tricky. Nonetheless, it may be a good area to focus and find a more technical solution, at least when all other hypothesis are proven to be true
For hypothesis (6), I think it may be possible. It could just use simple checksums and the like right? Or if you want use something more complex, but I doubt we'll get stuck in here
Hypothesis (7) I guess could be an axiom or not? I am no expert on cryptography so I am not really sure if this is true or not. Again, could be a subject to focus on later on to see if we can get it down.
I believe what I posted about the OS in my previous post makes hypothesis (9) true. Basically, the OS itself has this encryption key that it passes only to legit PoE clients he executes. Maybe I missed specifying the exact algorithm the OS should use to determine what a "PoE" client is, and how to pass the key to it. I think it won't be much trouble though..? If there are problems, again could be an area to focus on.
Hypothesis (12) is a problem. I think I may be able to work something out with the whole "OS has the private key" thing. I'll see if I can post something later
Hypothesis (14) I think is possible. Once we figure out exactly what the protocol would be like for (6), (5) and (12), we might have an easier time to put all of them into one. This seems more like a technical challenge though, not really a theoretical one.

So that's it. Those are the hypothesis, and they may become true, thus making it possible to "trust the client". Feel free to disagree on any of them, discuss, etc. That's what they are there for.

I think this could be a good exercise, we have a bunch of hypothesis we want to prove are either true or false. If we prove them wrong, then this whole thing falls apart. But that's good, it meant my solution was faulty, and it's good to find faults in solutions, because we can evolve better ones from them, or at least gain more knowledge (if we do theoretical exercises with proofs and the like). For instance, it'd be nice to know if it is theoretically impossible for a PoE server to trust a PoE client or any packets he receives. That'd be a huge advance (although a disappointing one :( )

We can modularize our efforts into proving those hypothesis right or wrong. Divide and Conquer.
So please, feel free to challenge those hypothesis, discuss, do anything you want.

However, if you find a fault with the reasoning itself (the syllogism itself and the logical derivation), please point it out because this whole Divide and Conquer methodology I am describing is based on the logic being correct.


EDIT: If we are getting REALLY serious about the above, then it should be possible to use first order logic or some similar way to prove the logic is right. Maybe use a proof assitant like I stated before. But we'd need to create the specification, create the proofs, etc. That's not light work, but it is possible.
Thus, if it causes too much confusion, or is the focus of a LOT of debate, the logical derivation itself can be proven true, or maybe proven false.

Okay, here's how I think hypothesis (12) might be solved.

First, we assume the OS the PoE client runs can't be tampered with or compromised. That was the hypothesis I've been working on, and it's basically the ONLY thing that makes this whole thing possible (if not it is exactly like Scrotie and other's said, there is no way to trust the client at all).

Now, this means the OS can have files and data protected by anyone. I.e no hacker can possibly access it, no matter what (this is shown with hypothesis (3.1) from my previous exercise ).

Okay, so this is what we have:
The OS has a special private key stored in this "protected data store" of his, only he can access

Even more: The server has this private key as well
Why? Because GGG would manually create this private key. GGG would manually create it, and store it both on the server and on every OS they release/sell.
Thus, the private key is both on the OS and on the server.

This private key is the one used to decipher messages the server sends to the client. The OS "passes" the private key to the PoE client (for example, the code in the client could be "String privateKey = System.privateKey();"...ignore the type and declaration, is just an example). The PoE client uses that private key to decipher any packet he receives from the server, parses it and does whatever is appropiate (drop loot, execute combat skill, deal damage, etc).

Now, the key part is that this private key is also on the server. This means the private key is known to every single party except the hacker
The OS and therefore PoE client know the private key, but the hacker can't because:
-He can't hack into the OS (hypothesis 3.1)
-He can't hack a PoE client and run it in the OS to obtain it (conclusion of the previous exercise)
The Server knows the private key as well. We should assume the hacker can't hack the PoE server, but I think this is a fair assumption, considering nobody mentioned this as a problem at all before.

So everybody except the hacker knows this key. This is important and is what will make the server able to validate a packet sent by the PoE client and not one created from scratch (and then encrypted using the server's public key and then sending it to the server) by the hacker.

Anyways, from here on now, it's very easy: Every single packet sent to the server must have a field with this private key in it

So, every packet would have a "auth_key" field, where it puts the private key in it.

What does this accomplish? Well let's look at a flow from both the PoE client and from the hacker's point of view:

PoE client's point of view:
-Client gets the private key from the OS: String/long/etc key = System.getPrivateKey()
-Client creates packet: Packet packet = new Packet()
-Client sets key: packet.setAuthKey(key)
-Client encrypts packet using servers public key: EncryptedPacket enc_pkt = Encryption.encrypt(packet,serverPublicKey)
-Client sends packet: Network.sendPacket(enc_pkt,server)

-Server receives encrypted packet: EncryptedPacket enc_pkt = Network.receivePacket()
-Server deciphers packet using his own private key: Packet packet = Encryption.decipher(enc_pkt,serverPrivateKey)
-Server gets the "private key" from his database: String/long/etc key = Database.getPrivateKey()
-Server gets the authkey from the packet: String/long/etc packet_key = packet.getAuthKey()
-Server checks if both are the same or not: if (packet_key == key) print("Ok!") else print("Hacked!")
-The keys are equal, so it prints "Ok"

Hacker's point of view:
-Hacker knows exactly the code from the PoE client, it knows it calls String/long/etc key = System.getPrivateKey()
-However, hacker can't execute that piece of code since he can't run a hacked PoE client, so he can only simulate a key String/long/etc simulated_key = Simulate.getSimulatedKey()
-He has the same code as PoE client, so it does the same thing:
Packet packet = new Packet(); EncryptedPacket enc_pkt = Encryption.encrypt(packet,serverPublicKey);Network.sendPacket(enc_pkt,server)
-(let's assume he put a packet.setPlayerAttack(Attack.Crit); code in there so he tells the server he always crits ;) )

-Server receives packet in the same fashion as before, until he arrives here:
if (packet_key == key) print("Ok!") else print("Hacked!")
-The hacker simulated the key, and because of hypothesis (7) from the 2nd exercise, he won't be able to guess the key correctly.
-Thus, the server prints "Hacked".

With this, assuming the specified hypothesis come true, then hypothesis (12) is true.


Again, this can only work because both the OS and the server have common information the hacker doesn't have, and this information can't be "guessed" or simulated by the hacker.
If the OS could be "hacked" or compromised by the hacker, this could not happen, since the hacker could obtain the private key by calling that "System.getPrivateKey()" method or doing any other hacking stuff.

*yawn*

0) True.
1) Sort of. Keep in mind that, due to desync, the client can believe some fucked up shit, and thus some very weird packets can be legitimately sent. So I guess this depends on what you mean by "correct."
2) Also sort of, because it relies on #1.
3) In terms of modifying the core gamestate, true. In terms of viewing parts of the gamestate which are normally concealed, false. Examples: maphack, zoomhack; these are both examples of the server providing information in packets for use by the client program which is viewed prematurely by malicious players. But you mean modifying the core gamestate, so overall true.
4) Hack 1 isn't explained very well. In practice, modifying packet content en route is silly, borderline impossible; instead, you use Hack 2 (blocking the flow) plus capturing the packet (essentially copy-pasting it to something the hack can work with). Once you've captured it, you use that information For Hack 3. Nice inclusion of Hack 4 by the way, a lot of people would miss that one. However, you forgot a key one: capturing incoming packets. This means any data sent from the server to the client can be used by the hack.
5) False. Even with my limited coding, I could make a hack which captures information from outgoing packets from the legitimate client, blocks them, then creates new packets which are exact duplicates, which are then sent to the server. (This hack wouldn't give me any in-game advantage, just prove that I can manipulate the concept you're talking about.) The server would never know the difference, except that I would appear to have slightly higher latency (but it can't punish me for that).
6) Sort of. Checking the route which the packet followed will often reveal hacking in this case, forcing the hacker to gain root access on some very well-defended systems in order to execute such a hack, meaning that security is as good as the weakest link along the packet's route of travel. (This explanation makes no sense unless you understand the answer to 10 first.)
7) Sort of. The real question is: how will you stop the hack from intercepting the key? Thus the importance of "Hack 5;" you need to assume the hack has same keys the legitimate client has.
8) Really big assumption: getting the key to the client without interception seems impossible. Keep in mind that hacks can attempt to monitor current system processes as well, in addition to incoming packets. Technically true, if you were able to pull off such a miracle; false in practice.
9) False.
10) False. The value of encryption is to prevent a hacker between the client and the server from decyphering the data (presuming he wasn't there to intercept the very first key, because the second key would be encrypted using the first). Encryption cannot protect the client from processes on the same computer.
11) False.
12) False.
13) False.
14) False.
15) False.
16) False.
17) False.
18) False.
19) False.

"

genericacc wrote:

Linux distributions that boot under UEFI Secure Boot either have their key added to the store or have their key signed by Microsoft (since MS key is in the keystore by default), usually the latter.

So what does it mean their key is "added to the store"?
This means a linux distribution can boot unther UEFI Secure Boot, without the need for Microsofr to sign it? And since Microsoft wants you to "enter custom mode or turn off secureboot ", then you can boot under "secure boot" all you want without problems?
Also, what does "enter custom mode" entail?

I assume, that this "UEFI Secure Boot" prevents the OS from being compromised by a malicious user right? How does it do it? Or well...rather, does it do it and does it do it correctly?

You mentioned that you had to control the hardware yourself, but you mention that just by having a linux distro you can already boot into UEFI Secure Boot with the key added to the store. Doesn't this mean you DON'T need the hardware? (or maybe the OEM certification)

If I got something wrong excuse me, this is new for me :P
You may want to explain things slowly and step by step :P

"

gonzaw wrote:

So what does it mean their key is "added to the store"?

Only bootloaders signed by a trusted key will be loaded.

"

This means a linux distribution can boot unther UEFI Secure Boot, without the need for Microsofr to sign it? And since Microsoft wants you to "enter custom mode or turn off secureboot ", then you can boot under "secure boot" all you want without problems?

Yeah if you turn it off or add your key to the store you can boot whatever/sign anything respectively.

"

Also, what does "enter custom mode" entail?

BIOS setting

"

I assume, that this "UEFI Secure Boot" prevents the OS from being compromised by a malicious user right? How does it do it? Or well...rather, does it do it and does it do it correctly?

Verifies that the bootloader is signed. That's it. OS security is its own problem once it's booted.

"

You mentioned that you had to control the hardware yourself, but you mention that just by having a linux distro you can already boot into UEFI Secure Boot with the key added to the store. Doesn't this mean you DON'T need the hardware? (or maybe the OEM certification)

The requirements for the certification specify that you must be able to enter custom mode or turn it off for non-ARM. The hardware isn't necessary, you can boot just fine without it. You just won't have secure boot.

"

If I got something wrong excuse me, this is new for me :P
You may want to explain things slowly and step by step :P

go read http://lwn.net/Articles/447381/

"

ScrotieMcB wrote:

1) Sort of. Keep in mind that, due to desync, the client can believe some fucked up shit, and thus some very weird packets can be legitimately sent. So I guess this depends on what you mean by "correct."

Well, perhaps you are right. But I think this hypothesis might even be removed altogether.
The only proposition that depends on (1) is (2), and as you can see it's not used anywhere except (3). However, I think (3) is true by itself, so you don't need (2), and therefore you don't need (1).

That problem of desync is internal to the game, wouldn't have much to do with this problem per se. I don't think it influences it though

"

2) Also sort of, because it relies on #1.

Idem, it might not be needed.

"

3) In terms of modifying the core gamestate, true. In terms of viewing parts of the gamestate which are normally concealed, false. Examples: maphack, zoomhack. But you mean modifying the core gamestate, so overall true.

I forgot to add another hypothesis as well. Or rather, another proposition

20)The hacker can't "view" the game state no matter what

This follows from (15). The hacker can't do any of the 4 hacks, which are basically the only ones he can do AT ALL. The hacker can only use these hacks to "view" the game state, so without being able to use these hacks he can't do anything.

"

4) Hack 1 isn't explained very well. In practice, modifying packet content en route is silly, borderline impossible; instead, you use Hack 2 (blocking the flow) plus capturing the packet (essentially copy-pasting it to something the hack can work with). Once you've captured it, you use that information For Hack 3. Nice inclusion of Hack 4 by the way, a lot of people would miss that one. However, you forgot a key one: capturing incoming packets. This means any data sent from the server to the client can be used by the hack.

About (Hack_1). Well, I put it there just for completion. It's different than (Hack_3), because in (Hack_3) he creates the packet from scratch (didn't receive ANY packet from the client to do so), while in (Hack_1) he receives the packet from the client, and modifies that one. So yeah, basically what you say is (Hack_3) I called it (Hack_1) here.

Hmm...I initially thought about adding that last Hack (let's call it Hack_5), but thought "We are talking about the validation on the server here, not about client validation". But hmm...yeah it may be tricky and lead to some situations where bad shit can happen.
So yeah. let's add (Hack_5):

4)...
(Hack_5) The Hacker can use Hack 1-4 on the client as well.
(Hack_5.1) Modify the content of packets the server sent to the client.
(Hack_5.2) Block/etc the flow of packets from the server to the client
(Hack_5.3) Create a new packet from scratch and send it to the client
(Hack_5.4) Modify bits from packets sent by the server to the client.

However, this is already entailed in other propositions. We'll just add this:
5) There exists an application protocol, that for any hacker that does ONLY (Hack_2) or (Hack_5.2)(but NOT Hack_1, Hack_3 or Hack_4 or Hack_5.1,3,4), the server and client can determine when the flow of packets he receives are being manipulated by the hacker and when the packets he receives result from the normal flow from a "legit" PoE client/server
6) There exists an application protocol, that for any hacker that attempts to do (Hack_4) or (Hack_5.4), the server and client can detect when the packets the server/client receives have been tampered by said hack.
11) Because of (10), in this "way" described, the hacker can't possible perform (Hack_1) or (Hack_5.1) (he can't decipher the packets being sent between server and client).
12) There exists a protocol, for the PoE client+server to follow, that allows the server/client to validate when he received a packet from that PoE client/server, and not one created from scratch by the hacker.
13) Because of (12), if the same protocol is followed, the hacker can't possibly use (Hack_3) or (Hack_5.3) on the server/client successfully.
15) Using the methodology described in (9), and the application protocol (14), then the hacker can't possibly do (Hack_1), (Hack_3) or (Hack_4) or (Hack_5.1,3,4)(because of (11), (13) and (6) respectively).
16) Because of (15), it can't do the 1-3-4-(5.1,3,4) hacks, thus it can ONLY do (Hack_2) or (Hack_5.2). Because it uses the protocol from (14), it uses the functionality from the protocol in (5). Therefore the server/client can determine when the flow of packets he receives are being manipulated by the hacker

Goes the same from there.

It is symetrical because the protocol is done in both the server and client. The key is that both share the same common info the hacker doesn't, which is the one I mentioned in the proof of hypothesis (12). With that private key, the client can validate packets sent by the server. The server has to do the same exact thing but in reverse: Put "packet.setAuthKey(key)" from the key he has in the database, and the PoE client validates it with the key from the OS.
Thus every solution for hacks 1,2,3 and 4 are mirrored and can be solved for hacks (Hack_5.1,2,3,4).
It may make the proof of hypothesis (5) more difficult though (since we have to include the client there).

"

5) False. Even with my limited coding, I could make a hack which captures information from outgoing packets from the legitimate client, blocks them, then creates new packets which are exact duplicates, which are then sent to the server. (This hack wouldn't give me any in-game advantage, just prove that I can manipulate the concept you're talking about.) The server would never know the difference, except that I would appear to have slightly higher latency (but it can't punish me for that).

Hmm, interesting. Yes, it won't do any "in-game" hack. It would make the server/client believe he has higher latency...
...but two questions:
1)How is this any different than me ACTUALLY having higher latency? There is no difference in you (hacker) "delaying" my packet by 30ms, and the network adding 30ms of RTT to the packet.
2)How could this "break" the game, or possibly "hack" it?

This hypothesis might pose a problem yes.

"

6) False, although checking the route which the packet followed will often reveal hacking in this case, forcing the hacker to gain root access on some very well-defended systems in order to execute such a hack. See 10.

Couldn't a simple checksum solve it?
Basically the hacker would play the "change bits" game that usually happen in the network itself. If the packet contains a checksum, it can detect these errors. The server either gets an error parsing the packet itself, or it gets a checksum error. In both cases it will not let the packet pass as valid.

"

7) Sort of. The real question is: how will you stop the hack from intercepting the key? Thus the importance of "Hack 5;" you need to assume the hack has same keys the legitimate client has.

Yes this was what I wanted to avert with the whole "magic OS". In this case the hacker does not have access to the same key the legitimate client has.

"

8) Really big assumption: getting the key to the client without interception seems impossible. Keep in mind that hacks can attempt to monitor current system processes as well, in addition to incoming packets. Technically true, if you were able to pull off such a miracle; false in practice.

The key is shipped with the OS on the OS installation (outside of the scope of PoE-hacking). The OS would have the key, the Server would have the key. The hacker can't intercept it.

A hacker can monitor the memory space of another process? Maybe in Windows :P
I am working on the assumption this "magic OS" is implemented well with good security and the like (it's part of the hypothesis) :P
Unless...again...it is theoretically impossible for an OS to prevent ANY hack from monitoring other processes memory.

"

9) False.

True based on my previous exercise (the "hash PoE client one"). The discussion of the veracity of this hypothesis should go into the other exercise.

"

10) False. The value of encryption is to prevent a hacker between the client and the server from decyphering the data (presuming he wasn't there to intercept the very first key, because the second key would be encrypted using the first). Encryption cannot protect the client from processes on the same computer.

This is new to me. I'd like some more explanation on how this happens, and if there is no way to prevent it.

"

11) False.

Is the logic false, or just the conclusion false (based on you believing (10) is false)?

"

12) False.

Just made a post about that one

"

13) False.
14) False.
15) False.
16) False.
17) False.
18) False.
19) False.

Again, problem in logic, or just problem in the previous hypothesis they use?


Okay, we are making progress.
Based on this, the "problematic" hypothesis (and maybe false ones :O ) are:
(5): If the hacker delays packets, then sends and exact duplicate (exact bits and all), then it might pose a problem to how the server-client communication unfolds. I don't really have enough info to analyze this, don't really know how much it will impact it...although it does seem it can impact it big-time a priori (but without enough info and trying workarounds that fix it I would not know).
(8)-(10) There's the problem that processes are not safe in the client. From what I got from Scrotie, the hacker can monitor the memory of the PoE client process, and get the private key from there. However I'd like more info on how this happens, and more importantly how it can be prevented and if it can't why.
(9) The previous exercise hasn't been analyzed yet (except for that facepalm from Scrotie), it might pose some other problems or issues to discuss further.
The OS one Basically the one we are in discussion with genericacc, on whether it is possible or not for the OS to not be compromised by any user. I.e so no hacker can possibly "hack" the OS, and access specific data, or change specific computations, etc.

"

gonzaw wrote:

(8)-(10) There's the problem that processes are not safe in the client. From what I got from Scrotie, the hacker can monitor the memory of the PoE client process, and get the private key from there. However I'd like more info on how this happens, and more importantly how it can be prevented and if it can't why.

Because the hardware is controlled by the attacker. It could be as trivial as a raw memory dump or attaching a debugger to retrieve the key. Sure it could be obfuscated but it will always just be a matter of time.

"

gonzaw wrote:

(9) The previous exercise hasn't been analyzed yet (except for that facepalm from Scrotie), it might pose some other problems or issues to discuss further.
The OS one Basically the one we are in discussion with genericacc, on whether it is possible or not for the OS to not be compromised by any user. I.e so no hacker can possibly "hack" the OS, and access specific data, or change specific computations, etc.

It's also pretty trivial to hijack system calls.

NEVER trust the client!

"

tropane wrote:

Because the hardware is controlled by the attacker. It could be as trivial as a raw memory dump or attaching a debugger to retrieve the key. Sure it could be obfuscated but it will always just be a matter of time.

He is assuming the existence of a magical black box which cannot be examined by any means whatsoever iirc

"

NEVER trust the client!

If you do not trust the client whatsoever, most games give unacceptable performance. As you might note from the length of this thread, this is not excluded. >_>

A reasonable compromise is generally struck between people who hate the devs because they got shot through a crate and people who hate the devs because they need to wait 100ms to see anything after turning a corner, to make an analogy to FPSes

"

gonzaw wrote:

20)The hacker can't "view" the game state no matter what

This follows from (15). The hacker can't do any of the 4 hacks, which are basically the only ones he can do AT ALL. The hacker can only use these hacks to "view" the game state, so without being able to use these hacks he can't do anything.

In practice this is useless because:
1) The hacker can alter the hardware
2) The software running on the hardware is a subset of the capabilities of the hardware
3) (e: programs) are software

"

4) Hack 1 isn't explained very well. In practice, modifying packet content en route is silly, borderline impossible

Why do you think this is borderline impossible?

"

6) There exists an application protocol, that for any hacker that attempts to do (Hack_4) or (Hack_5.4), the server and client can detect when the packets the server/client receives have been tampered by said hack.

This premise is incorrect unless there exists a shared secret which can't be extracted by the hacker, where one of the parties sharing the secret is ... also the hacker. You can work around this by the assumption that the hacker can't examine the system, which has absolutely no bearing in reality.

"

It is symetrical because the protocol is done in both the server and client. The key is that both share the same common info the hacker doesn't, which is the one I mentioned in the proof of hypothesis (12). With that private key, the client can validate packets sent by the server. The server has to do the same exact thing but in reverse: Put "packet.setAuthKey(key)" from the key he has in the database, and the PoE client validates it with the key from the OS.

1) That's asymmetric cryptography, not symmetric. Symmetric would be more of a Diffie-Hellman-like scheme.
2) This is not generally done for time-sensitive applications because it adds a significant amount of overhead, to the extent that there's dedicated hardware.

"

Hmm, interesting. Yes, it won't do any "in-game" hack. It would make the server/client believe he has higher latency...
...but two questions:
1)How is this any different than me ACTUALLY having higher latency? There is no difference in you (hacker) "delaying" my packet by 30ms, and the network adding 30ms of RTT to the packet.
2)How could this "break" the game, or possibly "hack" it?

There were aimbots for Quake implemented using this method, actually. Packets are an encoding of data and you can change the data before resending.

"

6) False, although checking the route which the packet followed will often reveal hacking in this case, forcing the hacker to gain root access on some very well-defended systems in order to execute such a hack. See 10.

You do not know the route along which a packet was sent. Traceroute works by sending ICMP packets with increasing TTL, and we're assuming packets can be altered by the hacker (they can be)

"

Couldn't a simple checksum solve it?
Basically the hacker would play the "change bits" game that usually happen in the network itself. If the packet contains a checksum, it can detect these errors. The server either gets an error parsing the packet itself, or it gets a checksum error. In both cases it will not let the packet pass as valid.

The checksum is part of the packet.

"

Yes this was what I wanted to avert with the whole "magic OS". In this case the hacker does not have access to the same key the legitimate client has.

It is so magic that this is a thought experiment about as practical as Maxwell's Demon. "Perfect security" does not exist.

While you clearly have an interest in security, please read basic material before inventing an engine that assumes a perpetual motion machine exists, this conversation is getting quite tedious due to the length of your replies and the assumptions that bear no relation to actual practice.