Friday, 14 March 2014

An uncrackable executable

Most of my Ideas come when I'm at one of two places: bed, or shower; and this one was no exception.
For some reason people tend to also have many ideas while in the toilet... Well, I guess crappy ideas must come from somewhere!

Last night before going to sleep, my mind drift away in weird and marvellous thoughts about preventing piracy. This is a summary of those thoughts, a brainstorm with myself.
If you want real tips on how to make your software more protected from tampering, you should checkout this post and research about how to solve your specific problem.

The initial idea: To have an application (let's call it an exe) which is not possible to be modified by a third party (a software cracker). Yeah, obfuscation is nice, but it is just another barrier for a cracker to overcome.
I'll jump to the final conclusions: The best I could come up with was an extra barrier, arguably not much better than simple obfuscation. I did not said it was a good idea, just an idea! Still better than nothing for a dozen of minutes of "trying to sleep", right?

Lets break it down:

1 - Well, why not authenticate it (RSA) with our private key and distribute it with the public key?
No use at all: anyone could retrieve the original exe, so the crack would just not be authenticated, as long as the final user is OK with that (and of course he is, after all he wants a cracked application).

2 - So let's remove the ability of the user to run unsigned applications!
Not that simple. First of all, that would need to be an feature build deep in the Operating System, of course. And even so, what would prevent anyone from retrieving the original exe, cracking it, and then signing it with his own private key and distributing the cracked application signed by himself?

3 - A trusted authority! VeriSign or whatever! That's how the Internet works after all!
Yeah, except that "Internet" does not force a website to be secure. And by the way, it's also pretty easy to make a copy of a secure site, ever heard of phishing?

(at this point I'm just arguing with my brain)
4 - Sure, but an OS could in theory force all applications to be signed by a verified entity prior to running them...
Really brain? You wanna go down that road? Sure, in theory it could. But you (me) are a developer... What about testing an app in that OS? You would first need to register yourself as an "entity" in that trusted authority (and everybody knows how cheap it is NOT to have a verified certificate).
And besides, everyone would know where any application would come from, so if a "bad" application was caught, you automatically would know.... Wait, what? Oh... Yeah, I guess that would not be such a bad thing after all... And it would be in itself a way to also prevent viruses, and all "bad" applications instantly - OK, not prevent, but at least to allow the culprit to be found immediately.
But anyway, as a developer, I'm not fond of the idea of having to pay just to develop and test a simple application.
And an OS that would force all it's applications to be verified? That's not going to happen soon... I think...

5 - OK, so back to the beginning... How about this:
5.1 - We cypher the application with the private key (the same as authenticating it);
5.2 - Embed the ciphered data in another application (a wrapper);
5.3 - The wrapper would  have the public key hidden inside and would use it to decipher the data;
5.4 - The deciphered data (corresponding to the original exe) would then be loaded into memory as executable data, and its main entry point would then be used to start the original application.
This is indeed a feasible approach, yet it does not achieve the proposed goal:
The original program would always be recoverable, either by analysing the wrapper's assembly code and figuring out the private key and ciphered data, or by analysing the runtime memory and extracting the deciphered data... But at least, there would be an extra step for the cracker to have fun with!
And strength would be as strong as the public key is hidden in the wrapper (and by the way, this approach doesn't seem to need asymmetric cryptography for this), as well as the the ciphered data (for example, in addition to a strong cryptographic algorithm you could XOR every Nth byte with a simple constant, and then revert it, prior to the decipher process).

OK brain, you've had your fun, now is time to go to sleep.
Fine. But I promise you that this is better than it looks like and it would give crackers a hell of a work to get the original application and I'll implement a simple program that will take an exe, cipher it and embed it in a wrapper and it will work, and... and... zzz... zzzzzz......

No comments:

Post a Comment