My question is pretty straightforward: You are an executable file that outputs ‘Access granted’ or ‘Access denied’ and evil persons try to understand your algorithm or patch your innards in order to make you say ‘Access granted’ all the time.
After this introduction, you might be heavily wondering what I am doing. Is he going to crack Diablo3 once it is out? I can pacify your worries, I am not one of those crackers. My goal are crackmes.
Crackmes can be found on – for example – http://www.crackmes.de. A Crackme is a little executable that (most of the time) contains a little algorithm to verify a serial and output ‘Access granted’ or ‘Access denied’ depending on the serial. The goal is to make this executable output ‘Access granted’ all the time. The methods you are allowed to use might be restricted by the author – no patching, no disassembling – or involve anything you can do with a binary, objdump and a hex editor. Cracking crackmes is one part of the fun, definately, however, as a programmer, I am wondering how you can create crackmes that are difficult.
Basically, I think the crackme consists of two major parts: a certain serial verification and the surrounding code.
Making the serial verification hard to track just using assembly is very possible, for example, I have the idea to take the serial as an input for a simulated microprocessor that must end up in a certain state in order to get the serial accepted. On the other hand, one might grow cheap and learn more about cryptographically strong ways to secure this part. Thus, making this hard enough to make the attacker try to patch the executable should not be tha t hard.
However, the more difficult part is securing the binary. Let us assume a perfectly secure serial verification that cannot be reversed somehow (of course I know it can be reversed, in doubt, you rip parts out of the binary you try to crack and throw random serials at it until it accepts). How can we prevent an attacker from just overriding jumps in the binary in order to make our binary accept anything?
I have been searching on this topic a bit, but most results on binary security, self verifying binaries and such things end up in articles that try to prevent attacks on an operating system using compromised binaries. by signing certain binaries and validate those signatures with the kernel.
My thoughts currently consist of:
- checking explicit locations in the binary to be jumps.
- checksumming parts of the binary and compare checksums computed at runtime with those.
- have positive and negative runtime-checks for your functions in the code. With side-effects on the serial verification. 🙂
Are you able to think of more ways to annoy a possible attacker longer? (of course, you cannot keep him away forever, somewhen, all checks will be broken, unless you managed to break a checksum-generator by being able to embed the correct checksum for a program in the program itself, hehe)
You’re getting into ‘Anti-reversing techniques’. And it’s an art basically. Worse is that even if you stomp newbies, there are ‘anti-anti reversing plugins’ for olly and IDA Pro that they can download and bypass much of your countermeasures.
Counter measures include debugger detection by trap Debugger APIs, or detecting ‘single stepping’. You can insert code that after detecting a debugger breakin, continues to function, but starts acting up at random times much later in the program. It’s really a cat and mouse game and the crackers have a significant upper hand.
Check out… http://www.openrce.org/reference_library/anti_reversing – Some of what’s out there.
http://www.amazon.com/Reversing-Secrets-Engineering-Eldad-Eilam/dp/0764574817/ – This book has a really good anti-reversing info and steps through the techniques. Great place to start if you’re getting int reversing in general.