21 replies to this topic

[ObsidianSpectre]

Dreepa, on 20 February 2013 - 09:30 AM, said:

What is the difference between a hack that tells the server "I hit location X with gun A on mech B" or a hack that tells the server "Fire gun A on vector X/Y/Z"?

Hack B is harder to make, easier to detect, less reliable, and less stable.

With hack A, once you've figured out the client/server protocols, you're basically done. You don't really need to read memory or do anything clever unless you want to.

Hack B requires all the work of hack A, plus you need to figure out and decipher the memory layout of the game, and a bunch of math to figure out the proper firing solution. Then it requires run-time reading of the memory, which is itself detectable and less reliable. Since the game expects sole access, you can get race conditions. What if the hack is trying to read the memory while the game is writing to the same place? This could mean the hack is using half old data and half new data, and could even cause instability in both of the apps (the write could fail because of the read, or the read could fail because of the write). The resulting vector will also be predictable in some fashion, and much easier to distinguish from a human who happens to have good aim. Breaking predictability means lowering the advantage it gives over actually having good aim.

A lot of those problems with hack B can be solved, but it's harder to do, which means more time between waves of hacks, which in turn means the developers have more time to recognize and counter them. Hack A, on the other hand, is trivial and more difficult to detect.

[Dreepa]

ObsidianSpectre, on 20 February 2013 - 11:19 AM, said:

Hack B is harder to make, easier to detect, less reliable, and less stable.

With hack A, once you've figured out the client/server protocols, you're basically done. You don't really need to read memory or do anything clever unless you want to.

Hack B requires all the work of hack A, plus you need to figure out and decipher the memory layout of the game, and a bunch of math to figure out the proper firing solution. Then it requires run-time reading of the memory, which is itself detectable and less reliable. Since the game expects sole access, you can get race conditions. What if the hack is trying to read the memory while the game is writing to the same place? This could mean the hack is using half old data and half new data, and could even cause instability in both of the apps (the write could fail because of the read, or the read could fail because of the write). The resulting vector will also be predictable in some fashion, and much easier to distinguish from a human who happens to have good aim. Breaking predictability means lowering the advantage it gives over actually having good aim.

A lot of those problems with hack B can be solved, but it's harder to do, which means more time between waves of hacks, which in turn means the developers have more time to recognize and counter them. Hack A, on the other hand, is trivial and more difficult to detect.

Thanks for some solid info here. Finally some insight. I am a tech guy, but not that much into this stuff and coding.