There are numerous books, articles, and blog posts on how to better protect your code. Some of them are even useful and practical; however, most of them are dedicated to certain third-party tools or combinations thereof. We are not going to review any of those, neither books nor tools. Instead, we are about to see what we are able to do ourselves with the tools we already have.

First of all, we have to assimilate the fact that there is no such thing as 100% protection for our code. No matter what we do, the more valuable our code is, the higher is the possibility that it will be reverse engineered. We may use packers, protectors, and whatever other tools we may come up with, but at the end, they are all well known and will be bypassed one way or another. Thus, the final frontier is the code itself. To put it correctly, it is the way the code appears to a potential attacker. This is where the obfuscation comes into play.

The dictionary definition of the word obfuscation is the action of making something obscure, unclear, or unintelligible. It may be quite a powerful technique, whether in conjunction with other approaches or alone. I once had a chance to reverse engineer a program that used encryption extensively. This program was not protected with any third-party tool, instead there was a very nice and unclear (at first glance) game of bits and I have to admit--it was much more difficult to reverse engineer than it could have been if any tool like Themida was in place.

In this part of the chapter, we will see a primitive example of what obfuscation may look like by slightly enhancing the patch we made for our Windows-based executable with gets(). As obfuscation is not the primary topic of the book; we will not dive into much detail, but show how simple and tiny changes may make it a bit harder to understand the underlying logic of the code without dynamically watching it in a debugger.