[jonjojr]

"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.

[bitexploder]

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".

[mikekchar]

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...

[slavik81]

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

[unknownid]

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

[mikekchar]

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

[bitexploder]

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 :)

[iancarroll]

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.

[tangent128]

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.

[matheusmoreira]

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.

[throwaway2048]

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