Is there some way to obfuscate 'C' language based executables or libraries to prevent decompilaton?
+3
A:
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.
profjim
2010-02-16 14:40:53
A:
I don't think obfuscating at the source code level will help. The compiler (if it's good) will automagically do it for you.
John Smith
2010-02-16 14:42:42
+2
A:
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.
AlexKR
2010-02-16 14:42:54
Bear in mind that spending time on highly risky obfuscation is going to make your product less desirable in the marketplace.
David Thornley
2010-02-16 16:33:16
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.
AlexKR
2010-02-17 09:34:32
-1 "use UPX" would be an appropriate answer? rotfl?
Lo'oris
2010-05-12 08:35:24
A:
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.
Colin Newell
2010-02-16 14:43:56
UPX is able to uncompress executables compressed with it itself. It provides absolutely no protection.
Billy ONeal
2010-02-16 15:26:50
+22
A:
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.
paxdiablo
2010-02-16 14:46:56
@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 :-)
paxdiablo
2010-02-16 14:53:02
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.
Colin Newell
2010-02-16 14:53:27
An excellent (and in my opinion correct) response. But you didn't answer his question.
joveha
2010-02-16 15:14:18
@joveha: Good point. Is there a way? Yes. Will it prevent decompilation? No. There ya go :-)
paxdiablo
2010-02-16 15:16:16
@paxdiablo Just because somebody out there might be able to doesn't make the effort fruitless :) It's about raising the bar.
joveha
2010-02-16 17:15:51
@paxdiablo 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.
cazlab
2010-02-16 17:49:36
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.
paxdiablo
2010-02-16 23:27:21
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
joveha
2010-02-17 09:06:46
It's not an opinion, this *is* The Answer. Don't waste your time doing things that will be broken anyway.
Lo'oris
2010-05-12 08:34:12
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).
paxdiablo
2010-05-12 08:43:15
@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.
joveha
2010-05-16 22:57:18
Why SDReyes? If you don't rely on any undefined behavior, optimization should not do anything to your program...
Billy ONeal
2010-02-16 15:26:11
+2
A:
"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.
mickeyf
2010-02-16 14:53:29
A:
SDReyes
2010-02-16 14:58:48
Interesting link. But can it also pack? It might be gibberish for us but the compiler will understand it fine.
joveha
2010-02-16 15:27:24
+1
A:
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.
joveha
2010-02-16 15:06:39
+2
A:
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.
Tronic
2010-02-16 15:08:00
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(++)
John
2010-02-16 15:37:27
A:
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!
Hope this helps, Best regards, Tom.
tommieb75
2010-02-16 15:14:04
A:
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.
lilburne
2010-02-16 16:12:38