Hacker News Reader

If you restrict the machine code it makes it that much easier for me to write an emulator to execute your machine code and return the result. It might even be trivial. It is a never ending Ouroboros. You build a more clever mouse trap, I will design a more clever mouse. If I have all your code and am running it on my computer it will be a matter of time before I can back out whatever obfuscation or technique you are doing and undo it. You may have some hope in network delivery of graphics only. If I am not running the game client code, and just streaming the game from one of your servers, you have a chance at keeping your client safe.

> emulator to execute your machine code

I think you missed a part. Namely that "It is allowed to read from anywhere". If it can't write anywhere but the sandbox, that just means it can't modify the game dynamically, just read its state. Which is plenty to verify whether the client has been hacked anywhere. You can read spans of .text to check whether code has been modified, you can read heap locations to check whether the state of the game is valid, and you can take all of that and hash it with a random seed included in the packet to set a high bar on the speed of any emulator. Your emulator would have to dynamically check every access to make sure it doesn't touch anything that has been tampered with, and change the reads to read from un-modified sections, while allowing it to view everything else accurately. Seems like a high level of effort for the cheater, for a low investment from the developer.

I see. The problem is the server needs to know all of the values it expects. And if the server knows the values a cheat can figure them out too. For example, a cheat could hook OS functions and report on values in certain memory regions (e.g . the games loaded .text as some cached values). Same with reading heap locations, hook the memory read functions. Computing a hash doesn't have to be emulated, though, right? A cheat can just compute it with whatever data /should/ be there for the game state. This also means the questions the server can ask of the client are ones it can somehow model. So, this is imposing potentially restrictive requirements on any server software if it needs a non trivial mapping of the client's memory. I have chased down a lot of really bizzare and non-deterministic packers and cheat software like this and ultimately you can only make things so difficult due to Rice's theorem. To truly detect cheating you would practically have to run all the computations my computer is running, at which point you might as well just stream the game to me instead of letting me install it and run it on my computer. These sort of "check for a known good state" things can almost always defeated by appropriate function hooking. Ultimately, my computer is a hostile environment for your game and I have complete control of it. The traps a client running can only be so elaborate. I do agree things like this will take some time and increase the skill required to take them apart, but you would be surprised at how much harder some CTF competition reversing problems are compared to a scheme like this, I think.

I think what you are getting at is that it's impossible to 100% fully prevent cheating. This is true, but I don't think that's the goal; the goal is to make it difficult enough that it's not worth the effort. The value gained from cheating in a video game is low enough that the vast majority of people would not be willing to go through such lengths to do so.

The average user doesn't have to go to such lengths, they just subscribe to a cheat company that does. That's literally how it works today. Cheats are big business.

Okay, but my comment still stands: You don't need to make it impossible, just hard enough that it's not worth the effort. This applies whether we're talking about individuals or companies.

As an aside, I don't know anything about the market for game cheats. Do people really pay a significant amount of money for that?

People are diligent enough to crack Denuvo's wall-of-VMs approach for free, even though it takes 6-12 months of work to do it. How much effort do you think people will put into it when there's money on the line?

People pay enough money for cheats that cheat makers have their own pretty intense DRM set up to make sure they get paid. You're probably looking at $10/month for something entry level, going up to $50 or $100/mo for something exclusive (that will take longer to get you banned).

> The value gained from cheating in a video game is low enough

Many people made serious money botting MMORPGs and selling gold. It's so prevalent it accelerates the inflation of the in-game currency.

If people make it too difficult to hook into the client, cheat developers can always reverse engineer the network protocol and make their own custom client. This bypasses all client-side annoyances. They might even create a headless client that can be run on servers.

A sandbox can be a virtual machine, for all practical purposes indistinguishable from any "normal" computers ordinary players use. Of course this will lead to the never ending Ouroboros of more sophisticated detectors and more sophisticated virtualization, ad infinitum.

I've heard there are cheats that use hypervisors to stand above the operating systems and avoid kernel-level anti-cheats. I wouldn't be too surprised to learn about cheats that sit on a bus and use DMA to peek into anything they please (subject to the memory protections of IOMMU - again, this war doesn't seem to have an end) - they're probably impractical but not something that couldn't exist.

I never claimed that this would be perfect. All security, especially the kind we're talking about here and the kind mentioned in the fine article is about the relative effort that the developer and cheater has to do to create the obsfucation and work around it, respectively. Making debugging harder doesn't make debugging impossible, it makes it more difficult and take more time. Adding random cheat checks on every rebuild doesn't make it impossible to find and remove them, just takes more effort and time. I.e. how much time investment do the developers have to put into making the workaround vs how much effort it takes the cheater.

I'm just saying this could be a relatively low effort on the part of the developers to create and a relatively huge effort on the part of cheaters to work around.

I really want to believe all this effort better be spent into fixing cheating. Either by tweaking game mechanics so cheating provides no meaningful gain (and just gets boring) or by tweaking other participating nodes (servers or other clients) into not accepting situations that should be impossible.

I don't know anything about LoL, though.

The article goes over all of these things, and LoL already goes to many lengths to invalidate as much cheating as possible. Their servers already don't trust data sent over the network and verify it independently, they already don't send information to a client that it doesn't currently require to render the frame, like the hidden locations of enemies, they're simply not sent so "map hacking" is literally impossible. The article has lots more details, I would recommend it.

Hah. Are you me? That is what I always call the cat and mouse of cheat / anti cheat. (An Ouroboros) :-D

I've just read your comment above and then quoted you without the proper credit ;) Liked the naming.

Ahh, well thanks :)

"If I have all your code and am running it on my computer it will be a matter of time before I can back out whatever obfuscation or technique you are doing and undo it."

sure try to undo a block-chain and see what happens.

The code will be encrypted with a unique key that will need to be registered on the server with your account. Change that code and it invalidates your entire build along with your account. case closed.

I think you are missing my point. This concept in client computing security basically chains back to the halting problem. You can't /know/ what I am doing with my computer. You can build a very elaborate trap / obfuscation and it might be hard, really hard, to defeat it or circumvent it, but it is a certainty that I can. The block-chain has absolutely nothing to do with client code security because it has a network enforced mechanism. What the grandparent was suggesting was running some nugget of code in a little VM (or actually on my machine), computing a result, and then returning the result to the server to make a security decision. The problem is I control that machine performing that computation and your security decision as the server is based solely on the computation performed on my computer. A skilled reverse engineer will just hook your code in the right place, intercept that security check and have it return the right bytes back to your server, while still doing whatever client side cheats they wanted to do.

https://en.wikipedia.org/wiki/Rice%27s_theorem <--- this is all about program behavior and did the user actually run the code you sent them. Block chain is about "did I possess certain data" (such as a private key to sign a transaction) and not about "did I run certain code".

You are absolutely correct, but it occurs to me that CPU designers could actually implement a kind of RSA style memory fetch instruction. The CPU would generate a public/private key pair, where the private key is not accessible by any means. The client would send the public key to the server, which would in turn encrypt the memory location(s) that it wishes to inspect. There would then be an instruction on client's CPU which would accept that encrypted memory location and return the contents, without divulging location. The CPU could regenerate the public/private key values for each request. I can't imagine defeating that kind of scheme without hardware hacks. The more that I think about it, the more I wonder why no-one has done it before, because it seems useful. Probably there is something I'm missing...

You're on your way towards reinventing "trusted computing". https://en.wikipedia.org/wiki/Trusted_Computing

How do you prevent the cheat doing a MITM attack and changing keys?

Yes, you are right. That's what I was missing :-)

The answer, and it has dark implications, to me, is Trusted Computing. Never let the user have full control. Do this key exchange on a base OS or some other VM the user can never touch (e.g. Knox / TrustZone). Still, we can exploit our way to this trusted OS and MiTM there, but it takes much more skill. With Trusted Computing the base OS can more simply install a "spy" to keep track of a games memory / code to ensure it is only ever loaded and executed from memory that is essentially made read only after the program is loaded but before it executes. The trusted OS verifies the program code, the OS, etc, and if it all checks out, let's the code run. Of course it goes back to the halting problem, but if the programs memory is unexecutable and modern exploit mitigation is applied the game is now in a considerably sturdier mouse trap :)

Blockchains are not a solution here. This comment doesn't make much sense; your proposed solution is missing a lot of details.

If there was a simple solution to this problem there would not be insanely complicated packers that basically try to make their own instruction set.

If the player controls the CPU the code is running on, there is fundamentally no way to enforce they are actually running the code provided.

A server can't validate the integrity of the game remotely. A program on the user's computer must do that for you. You're trusting that the program will do what you expect it to do.

All one needs to do is modify the program to make it always tell your server the build is valid. Problem solved.

This is a very bad analogy, and you have misunderstood the problem to a huge degree.

What you describe is very similar to "Warden", Blizzard's anti-cheat system. I'm not sure how up to date this article is but it talks about how it works and approaches to working around it https://hackmag.com/uncategorized/deceiving-blizzard-warden/

It's pretty tricky to build a machine code validator to only be able to write and execute on certain areas... in x86, you have to take care of 'jumping in the middle of an instruction', that not only writes but also jumps are limited to your small area (because otherwise you will end up with something similar to ROP), etc.. I think Google Native Client did something like this, but it doesn't seem trivial.

On the other hand, a way to bypass it could be that, when you detect one of those "executable code packets" has to be run, you undo all the injection/hooks in the game (so that you are really running a 100% unmodified process), and let the executable code packet run. After it finishes (you could detect this by a timer, page fault, etc. which can be handled by a different process in a different address space), you inject all the hooks again.

So as a cheater you intercept those snippets, lets them do their magic in a dedicated address space that has the same client code loaded?

So you're saying the cheater would have to run a duplicate, unmodified, instance of the game in parallel with the hacked version that the cheater is actually using, while correctly teeing networking traffic and mouse/keyboard inputs, and dynamically inserting the snippet results from the legit copy over top of the results of the hacked copy. That seems like a huge increase in level of effort from cheaters for a relatively small measure from riot. Seems worth it to me.

You are going to kick players off for a missed packet? Network connections have packet loss and game protocols are usually udp.

Nope, just like any other game state that will eventually have to be synced to the server the results can be synced later. But you can't just run it any time because it reads the state of the game as soon as it arrives.