I just finished my brief analysis on this protection and I have a very macro view about it and how to break it. If my gut is correct (if you have read Blink! you will trust your gut most of the times, if not go read it since it’s a great book) I can decrypt and run any game so I will not publish any detailed information about it.
The protection is based on a keyfile that is sent to you after you register online. This keyfile has two checksums and a encryption key. The encryption key will be used to decrypt the main binary, since the unencrypted part is just responsible for verifying if licence file is correct, launch the registration program if not and decrypt if there is a valid key. After the binary is decrypted, it is launched via what seems to be dynamic loading via the linker (sort of something like this). If the bytes are wrong then you get a beautiful crash. The only anti-debug I found was our ubiquous PT_DENY_ATTACH with a small obfuscation. There is some little more obfuscation (I would be tempted to call it pseudo-obfuscation) for some used syscalls that it’s very easy to solve and eliminate with the useful rename function in IDA. It’s very easy to understand the algorithm for the licence file name, but there’s no big interest here since each product will have an unique but single name for everyone. There is some suspicious int 3 in the code where I lost some time but it doesn’t seem to play anything significant.
In terms of flaws that helped me to understand what was happening we have:
It is very easy to find which hash algorithm is used. My first macro analysis flagged that routine as generating some checksum and today a more detailed analysis allowed to understand it. The problem is that the algorithm magic value isn’t protected or obfuscated, so it was very easy to use Google to find the algorithm name. Many people told this and I will repeate, never leave keys or magic values in clear because that will make things much easier.
The same mistake happens with the decryption algorithm. I have a strong hint about which one is it because there are some magic values left in clear.
After having the correct key, I think it’s very easy to finish the job. I don’t think the encrypted part is packed so it would be just a matter of decrypt and replace and nop the keyfile routines (I doubt entrypoint could be changed because the way that code is called). If there is a single decryption key then every product can be unpacked and it’s game over :-). If the company was careful then each product would have a single key, making things a bit more annoying. I’m not sure how easy it would be to bruteforce the key – that would require some deeper analysis, but there is an even easier way to get the key. Games cost around 20 euros so it’s a cheap attack, especially if there is a single decryption key. So in economic terms the protection has a very low barrier to entry rendering it ineffective. I’m not sure if the keyfile is personalized since there is some magic in between, but I doubt it is because of the decryption. So with more or less effort and a few less euros I can declare this as game over 😄 (unless my analysis is soooooo wrong, which of course it could happen hehehe). It was fun but it doesn’t seem to have much more juice to give. If you manage to complete the job, please don’t distribute it and keep it for yourself.
And that’s it for now. I’m a little bored with the amount of work that is required to write an hex editor (more specific a mach-o editor) and so I think I’m going to read something about business strategy to prepare the new MBA term (I really need a code slave to implement my ideas!).
P.S: Two interesting links:
http://blog.reversinglabs.com/ – interesting stuff although Windows centered but you can always learn from it (and Titan Engine seems cool!!!)
http://www.bureau14.fr/blogea/2010/01/security-through-deception/ – deception in copy protection designs (there are already articles and recommendations about this and software that uses it, just a note for any one interested in implementing copy protections)