Traps against Hacker

Maybe you‘ve read my article “Software protection from a hacker‘s perspective“ in one of the last issues of KEYnote. In this article I described the difficulties of emulating a CodeMeter dongle. The encrypted communication between dongle and software may be no more than “state-of-the-art“ but the P-RID packets hidden in the data stream add a totally new level of quality protection to the software. The attack described in that article was based on dongle emulation. I‘ve mostly witnessed this kind of attack in Russia which is why I refer to it as the “Russian Hack.” CodeMeter knows how to defend itself against this hack but how does it cope with the “Chinese Hack?”

The Chinese Hack

Whereas the Russian Hack hardly makes any changes to the software, the Chinese Hack patches it i.e. replaces encrypted sections of software with unencrypted code. The time and effort, and the possible risks and side effects of this hack are of course much greater than those associated with its Russian counterpart.

Naturally the time and effort required for the “Chinese Hack” depends on whether the software is encrypted at all or whether it just makes API calls. If it’s encrypted, it of course makes a big difference whether one large block is encrypted with just one key, as is the case with most tools, or whether many small jigsaw pieces are encrypted with possibly different keys, as is the case with CodeMeter.

Here too CodeMeter has proven to be the “Best of Breed.” CodeMeter’s AxProtector and IxProtector tools divide the software into many small jigsaw pieces and dynamically reassemble them at runtime. Different keys are even used for the same license. But how well does it hold out against the “Chinese Hack?”

Dynamic vs. static

Basically there are two types of reverse engineering methods. The hacker either analyzes the software without executing it, i.e. by disassembling and manually decrypting it (static analysis), or he executes the software in a debugger and simultaneously observes and modifies it (dynamic analysis).

For “hello world” applications both methods are more or less trivial. During the dynamic analysis there’s always the chance anti-debugging mechanisms have been implemented in the protected software and that I, the hacker, will be caught by a debugger detector.

The situation is totally different though with a proper application. During static analysis I, the hacker, have to find all the pieces and fit them together. This is very time consuming so I naturally want to automate the process.

The dynamic analysis

I often hear young up-and-coming hackers say that for a dynamic hack “you only need to wait until all the encrypted methods have been executed and sit decrypted in memory.” I’ve been working in the areas of software development, software testing and reverse engineering since 1996, the year of the first Yellow Point and Yellow Star CDs (see below). Out of experience I can say with absolute certainty that if anyone manages to execute every line of code in a software application he hasn’t written himself, he’s found both the philosopher’s stone and the holy grail. This person would make so much money selling test tools, he would be able to sit under a sun umbrella on his privately-owned South Sea island sipping cocktails every day.

Let’s take MS Word as an example of a software application. Even power users never use more than 10% of its capabilities. If the software were accordingly protected, which hacker would ever manage to execute 100% of the code?

The situation can be summed up as follows: dynamic analysis of an application protected by IxProtector will not succeed, the only exception being applications whose complexity does not usually exceed that of a “hello world” program, or those with only rudimentarily implemented IxProtector protection.

A quick look back

Incidentally, the Yellow Point CD is an excellent example of how not to do things. A pure marketing firm commissioned a consulting engineering company (with no previous experience of software protection) to develop an activation CD. It was cracked in less than a week following its release. The flaw was due to a fatal implementation error which drastically shortened the length of the used key. If you are able to assume an exe file is stored at the beginning of each encrypted archive, as was the case for 95% of the products, you only had to look through a few keys to trigger on “MZ” (the first two bytes of an exe file). And that was it. The hack was complete. The decryption routines were even shipped with the software. Following this debacle a company with many years of experience in the sector was chosen to develop Yellow Point’s successor, Yellow Star. This CD was never cracked by the way. The company Yellow Point, who worked alone internally, soon disappeared from the market. The company behind Yellow Star, on the other hand, was successful for many years. Maybe because they were willing to buy know-how and solutions?

The static analysis

So, what’s the situation if I, the hacker, statically analyzes the application? I decrypt every single method separately and afterward put the application back together again. Like with the Yellow Point CD, the shipment includes the code to decrypt the application. I don’t even have to make the effort to write this routine, which wouldn’t be any problem for me anyway as the CodeMeter API is very easy to use.

Now I know the theory, I’m going to try it out in practice. And it doesn’t take long before I discover a big dirty trick of CodeMeter. It has set traps in the encrypted application for me to fall into during static analysis and within no time my license is deactivated, just like with the debugger detector during dynamic analysis.

I try to understand what’s going on. It seems the application contains code which is never executed and hence never decrypted. My static analysis of course discovers all the pieces of code which are encrypted, which is no easy task. If I decrypt all these pieces one after the other, I will inevitably end up decrypting a trap too. And as soon as I do this the CodeMeter dongle is automatically deactivated internally. There’s no way I can detect the traps in advance because CodeMeter uses so many different keys. I don’t notice until it’s too late and the license has been deactivated. The game is over. I can forget about trying the decrypt the rest of the code: Once locked, the license is locked forever.

This type of trap, which makes use of encrypted methods to automatically deactivate the license as soon as they are decrypted, is another quantum leap for CodeMeter and sets it apart from other protection and licensing systems.

Flow chart

I allow myself one more attempt. I decide to follow the program flow and start with the main function. I decrypt this and note the methods called from here (of course I’ve written a tool to help me do this). In other words I draw a flow chart for the software to find out which methods are called and which aren’t. By the way, the names of the methods don’t mean anything. The CodeMeter team are professionals down to the smallest detail.

When I’ve finished the flow chart I’ll know where all the good pieces of code are and hence be able to say where the pitfalls are. At least that’s what I thought. But even here CodeMeter has put obstacles in my way. Have I mentioned that as a hacker, CodeMeter makes me want to pull my hair out? Sometimes the methods are called using reflection (of course the names of these methods are encrypted too) and hence can’t automatically be recognized as good functions. And it gets worse: Some of the traps seem to have ended up in my flow chart. There are branches which are never executed according to the program logic but my analysis reports them as being “good” branches. Once again, I’ve been caught.

My conclusion

So, I have to say, I’m impressed with CodeMeter. It has answered all my questions. On the face of it, the difference between CodeMeter and other products is minimal: Almost all provide a wrapper. But when you look underneath the surface and examine the functions more closely, you soon realize why CodeMeter never fails to stay that one important step ahead of the hacker.

Of course, the level of protection provided by CodeMeter depends very much on how well it’s integrated into the software. CodeMeter can automatically insert traps but they don’t become fully effective until I, the software developer, neatly tuck them away behind my business logic. As a developer, I know a slope can never be steeper than 90%, that a pack of cards must have an even numbers of cards in it, that my car engine can’t do more than 19,000 rpm, that the highest tax rate can never exceed 100%. The hacker doesn’t normally know these things though and hence falls into a trap which deactivates his license. And a hacker without a license is like a warrior without a sword. Thank goodness for CodeMeter.     

Wibu-Systems Professional Services Team

Our team is happy to fulfill your requirements promptly and cost effectively. We provide services from concept development to implementation in order to speed up your time to market. Our knowledge and experience are made available to you. Share your plans with us: Tel. +49-(0)721/9317217

 

 

KEYnote 25 – Edition Spring 2013