Obfuscating C-based binaries to avoid decompilation

Question

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

Baranowski

write spaghetti code ;-) – Juna

I am not sure code can get much more obfuscated than naturally complied C. – Nystagmus

Compiled C binaries don't always decompile into the code they were compiled from - decompilation isn't gauranteed to give the exact same source code that was used to write the application. Inline functions, macros, compiler optimizations, etc... are all handled after you finish saving your source files. – Garrow

The software crackers have been reverse-engineering binaries for years. I myself can pretty much figure out C binary disassembly in my head, although C++ is far too obnoxious for me even in a source debugger if I go all the way through cout & friends. That's without practicing this as an end in itself for half my life. – Boggart

If you write spaghetti code, make sure to put meatballs in as well. – Wini

@Matthew C++ would have been more on the spot ;) – Handclasp

I think the missing question here is: Why obfuscate C executables to hinder (not prevent) decompilation? – Prod

People please, he's asking how to obfuscate code, not if he should. At least answer his question first before you turn it around – Handclasp

I like the spaghetti code option. – Accepted

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.

Thinskinned

What about anti-cheat software and the like? – Numerous

@tm1rbrt, it's almost a certainty that any automated anti-cheat software will have a anti-cheat-software-cracker tool in the serious cracker's arsenal :-) – Thinskinned

Anti-cheat software requires evil tricks to prevent active tampering, not necessarily anti-decompilation tricks (although they may be used too). The reason those things are evil is that they prevent you doing legitimate things on your own machine, despite the fact that they are necessary when not operating on a trusted platform. – Aeronaut

An excellent (and in my opinion correct) response. But you didn't answer his question. – Handclasp

@joveha: Good point. Is there a way? Yes. Will it prevent decompilation? No. There ya go :-) – Thinskinned

@Thinskinned Just because somebody out there might be able to doesn't make the effort fruitless :) It's about raising the bar. – Handclasp

@Thinskinned If the goal is to prevent decompiling, it might not be to prevent piracy. There are many other reasons to decompile something: to reverse engineer its functionality, or find security exploits. @joveha: I agree, an informed response that somehow fails to address any part of the question. – Accepted

Bods, I answered the question that way for the same reason I'd answer the question "How can I use bubble sort to order a 50-million-node linked list?" with "Don't do that!". There's ample precedent on SO for answers suggesting that there's either a better way, or no way, or that you shouldn't waste your time. I need to make it clear that there is no way to prevent decompilation. Like house security, you can make it harder to keep out the casual thief but a determined burglar will not be stopped. In my opinion, compilation itself is enough to keep out the casual types, no more is needed. – Thinskinned

Well in this case there is a way and there are many situations where it makes sense to obfuscate code. SO is supposed to contain The Answer rather than opinions. It's a worthy remark to make after you've answered the question. If SO answers simply "don't" to otherwise perfectly valid questions then we've lost something – Handclasp

It's not an opinion, this is The Answer. Don't waste your time doing things that will be broken anyway. – Thrust

And my answer, joveha, to the question "Is there some way to obfuscate 'C' language based executables or libraries to prevent decompilaton?" is "No, there isn't." You cannot prevent decompilation, you can only make it harder (and not much harder, in my opinion). – Thinskinned

@Lo'oris So you don't lock your front door either? It can be broken so why bother right? The fact is that the OP can buy a packer product for around $10 and then produce a binary most would give up on. He could do all that in 5 minutes. Locks prevent theft. – Handclasp

In my opinion, @joveha, the compilation itself is the locks in your metaphor, since that's the thing that keeps out the vast majority. In any case, locks do not prevent theft as evidenced by the fact someone can smash in your door with a sledgehammer. At best, they reduce the likelihood. – Thinskinned

@Thinskinned If codes are not secure so is it possible to have secure content on devices. I mean as u noticed sources can be reverse-engineered and also it is same for encrypted content which they access (e.g. content of an encrypted book inside an ebook-reader app). Am I right? – Sonny

@VSB: no, not really. If the content is at some point converted to some form unencrypted (and it has to be so you can read it), you can get at that data. Only if the device is so locked down that you can't do anything else, it may be relatively safe. And, to be honest, not even then, since you could rig up a camera and OCR reader on a separate device to "steal" said content straight from the display of the locked down device. – Thinskinned

"Then people will be willing to pay for it." Your faith in humanity is astounding - other than the fact that you did not answer the question. – Taite

@CTZStef: re not answering the question, see my comment starting "Bods". (Feb 16, 2010). It may not be an answer you wanted but apparently the OP and 44 other people considered it useful. In any case, my first paragraph is very much answering the question (with "no, you cannot prevent it, you can only make it harder"). – Thinskinned

@CTZStef: and I know from experience people will pay for good products, I both buy and sell them. As I stated, you'll probably never convert the sociopaths who demand everything for free while not offering their own services/products at a similar cost. But they're probably not the people you should be targeting. – Thinskinned

@Thinskinned "... people will pay for good products." This might be true in some countries, but I strongly doubt - and actually know for sure - it is not the case in many other countries, for various reasons such as software prices being too high. I don't know in which world you are living. Matlab or Microsoft could tell you about it. So, even if binary obfuscation can only slow down piracy a little, that's already a gain. – Taite

Alas @Thinskinned as you may already know you turned out to be wrong (see garbled circuits). Though at the time you wrote the answer they were not discovered (at least not the more viable candidates). (Of course garbled circuits are not a practical tool but it does make you theoretically wrong - you CAN write code which can be cryptographically guaranteed not to be reversible) – Terryterrye

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.

Handclasp

"can" do does not guarantee a practical solution. Alghouth VM packer can be reversed from this academic papers' perspective, I still think it is robust enough to resist disassemble tools normal people can find online. – Barneybarnhart

The fast way is not compatible with UPX's license. In theory it forces you to disclose source code of obfuscated program. – Hurl

Answer 3

compile with full optimization.

Mcgehee

Why SDReyes? If you don't rely on any undefined behavior, optimization should not do anything to your program... – Stupefaction

@BillyONeal Some of the more aggressive optimizations do change the meaning of the code in subtle, yet not standard conform ways. Changing the evaluation order of floating point arithmetics, for instance, will change the rounding errors, and consequently the results, even though no undefined behaviour is exploited. – Soutor

@cmaster: The standard does not define anything about floating point behavior, so relying on that order is in fact relying on undefined behavior. – Stupefaction

@BillyONeal: I'm sorry, I messed up the C standard with the IEEE 754-2008 standart which requests languages to provide reproducibility; and reproducibility means defined evaluation order because of the rounding errors. It's with this standard that those compiler optimizations are in conflict with. Yet, any well behaved floating point unit will provide IEEE 754 numbers and arithmetic, and compilers should strive to pass the standard's guarantees on to the language level. So, yes, technically it's implementation defined behaviour, but we should be able to expect conformance to IEEE 754. – Soutor

@cmaster: C does not require that an implementation use IEEE 754. And in fact, many common implementations (e.g. x86) do not follow that standard. IEEE 754 is a standard for processor manufacturers, not programming languages. – Stupefaction

Answer 4

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.

Papagena

Answer 5

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.

Virginity

Bear in mind that spending time on highly risky obfuscation is going to make your product less desirable in the marketplace. – Prod

You guys are keep telling each other that obfuscation is a waste of time while this is not a question at all. The OP asked the question precisely and got an appropriate answer. – Virginity

Answer 6

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.

Bumgarner

So do your debugging on a debug version, assuming of course you don't run into bugs that only occur in release builds, which is easily possible in any pre-processor-enabled language like C(++) – Shf

The assembler code generally becomes easier to read with some optimization applied, because all the obfuscating noop stuff gets thrown out first. However, some more advanced optimizations do obfuscate the code (loop unrolling and inlining, to name a few). To get the most readable assembler, use -Os. – Soutor

Answer 7

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.

Hearn

Answer 8

"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.

Ton

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!

Takeo

This is not really applicable to the question at all. – Accepted

@cazlab: I am pointing out that obfuscating and putting in code protection is a waste of time!! – Takeo

so what about DRM on android devices? I mean is it possible to access encrypted content that some application got access to it? – Sonny

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.

Aeronaut

UPX is able to uncompress executables compressed with it itself. It provides absolutely no protection. – Stupefaction

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.

Forgather

Answer 12

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

Combined

Answer 13

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

Go