Obfuscating C-based binaries to avoid decompilation

Question

Is there some way to obfuscate C-based executables or libraries to prevent decompilation?

Answer 1

No. You can make it more difficult to decompile but you cannot prevent it. My advice is to stop wasting your time and instead concentrate on delivering a fantastic product with ever-improving features.

Then people will be willing to pay for it.

Your main problem is that the only way to make your code un-decipherable is to make it un-runnable. Anything that can be loaded into a PC can be cracked. The people that do reverse engineering for fun, profit or fame are generally very good at it and will really not be the least bit phased by anything you do to try and stop them.

They have access to tools that make the job of deciphering your code far easier than the job you will have obfuscating it :-) Far better to convince the world at large that your software is worth buying, and seeing piracy as an opportunity to possibly convert "thieves" to genuine users.

For example, find out why they're not paying for your software and try to fix that. You'll never convert 100% of the people, some will pirate your code just for the fun of it.

Check out the series of articles running over on techdirt concerning CwF+RtB (connect with fans plus reason to buy). I've found many of the points raised there could be applicable to the software industry.

Answer 2

The easy way: Buy a packer/cryptor/obfuscator product. Some are expensive and used in games, some are not. Google for them by buzzwords like "copy protection", etc.

The fast way: pack with UPX and then mangle the header somewhere so it will still be loaded in memory and run fine, but the upx utility will fail with an error (try the version field). 95% will give up if the upx utility fails.

The hard way: Write your own packer.

oh, I forgot:

The real easy way: Just ship it as it is. No really - whatever you do people can still reverse engineer your code. The amount of effort you put it in just restricts how many can reverse it.

Answer 3

compile with full optimization.

Answer 4

"obfuscated executables" makes no sense. The hardware has to be able to "understand" the code in able to to execute it, and it the hardware can understand it, a reverse engineering human can understand it. The most you can do will be make it more tedious to understand, but probably not by much, and at a cost.

Answer 5

To make it harder? Sure. Please don't do that.

To prevent it? No. Any system that's going to run your binary will need the software to decrypt whatever scheme you come up with. And they'll be able to decompile that and then see how your obscured binaries get interpreted.

Answer 6

I think if you speak about compiled binary there is not much you can do, (perhaps only apply UPX or related tool) which does not make a lot of sence since it can be reversed.

If you talk about writing new code, try Self Modyfing C Code which will probably be the hardest way to re engineer your application.

Answer 7

Compiling C code with an optimizing compiler makes it impossible to restore the original source code or anything that even remotely resembles it. It is far more secure than any of the Java or .NET obfuscators that are popular these days. Be sure to strip the executable if you want to make it smaller and hide any symbol names before release. However, notice that this also makes debugging (when the application crashes) pretty much impossible.

Even so, if someone really wants to hack your software, he will do so on assembly level, possibly with loader software or other trickery - no matter what you try and do to prevent him. Many companies have tried, yet none have succeeded. Using hacks like this only frustrate the end-user as they may crash the application or even crash the built-in debugger of Windows.

Quit wasting your time thinking about obfuscation while you should be improving the program instead.

Answer 8

Decompilation (No More Gotos) and both obfuscation practice (Flowtables) and theory (Indistinguishability Obfuscation) are active areas of research and therefore there are no solutions - only tools, techniques and expertise. If you really want your code to be impervious to decomplilation, create a web app, and put the sensitive code server side. But if you're stuck to the model of giving someone a binary, then you must wisely judge the trade-off you want to make between security and performance. Obfuscation comes at a cost, and still is never perfect. Some options

• Use a packer other than UPX (UPX comes installed in many linux distros). The performance cost is low and most people do not have the skills to manually unpack a binary for static analysis. But to experienced reversers, the cost of unpacking is immaterial
• Check out Tigress, a diversifying virtualizer/obfuscator with rich features for C source-to-source obfuscation. For better performance, rely on the supporting transformations, control flow flattening, function merging/splitting, literal encoding
• If you want even greater protection, check out Tigress's major transformations: virtualization, JITing, etc, but I'm fairly certain these are more expensive and your users may notice a slow down if you use these transformations.

Don't be discouraged by Barak et al's seminal work on the impossibility of black box obfuscation. He only proves the impossibility of black box obfuscators, not the impossibility of many practical and worthwhile obfuscations. (Black box obfuscation being the inner workings of the program are completely unintelligible) Also don't be discouraged by pirates. There's always people who make it a point to buy your product if it is good.

Answer 9

Why obfuscate the code if there's a commercial gain from it? To be honest, suppose the commercial code is optimized enough and obfuscated, and works, then the mother of a all embarrassing thing happened - a glitch....you are stuck imho, as the production binary code is obfuscated, making it harder to debug where the glitch is happening and difficult to replicate, it will be stuck on the BUGS list forever...

For instance, trying to find the stack trace, you'll end up with losing more hairs then ever trying to figure out the dis-assembled code to work out WTF is happening in there, endless reams of spaghetti loops. In short, don't!

You'll end up with losing money in trying to debug the glitch...either you have to be a brilliant assembler expert to read up the memory dumps and work it out from obfuscated code... Don't throw it away, just get your beautiful product working and sell it...Sure, there's plenty of people that have time on their hands to break it by reverse-engineering the code...

The secret to beating that is following the principle - release frequently, release often, make improvements as you release often, in that way the latest and greatest features would be more up-to-date then the time it takes for a cracker to disassemble it and work out! Look at the linux source code, the patches come in, then it gets released...if you keep that principle in mind, by releasing new version with more features at a far more faster pace then you're winning!

Answer 10

One way to make things slightly more difficult is to pack them. UPX will pack your binaries which makes it harder to decompile out of the box. Technically it's possible to unpack and then decompile but it will raise the bar a bit. Assuming you're running on a vanilla user operating system there isn't a whole lot you can do to prevent decompilation without using nasty tricks.

Answer 11

If you really want to jumble it up you need a separate program to do it. As a developer you write your code in the cleanest, and most readable form. Post compilation you run the separate application to do the obfuscation. You can buy such applications for about $100K.

If your intention is to stop the code from being reversed engineered that will probably work. If your intention is to stop someone from cracking the security then obfuscation alone won't stop a determined attacker. At some point there is a yes/no decision they don't need to understand the code to find that nor to circumvent it.

Answer 12

Tiny C compiler modified to produce obfuscated code: http://blogs.conus.info/node/58

Answer 13

To provide some theoretical support for the answers here: in 2001 Barak et. al. proved that program obfuscation is impossible in general.