Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm interested in doing code obfuscation (native code, to make it clear what I mean by "native code": the actual machine code in x86/x64/arm executable files - PE, ELF, Macho and etc, not the sources) as a part of a build process. I can think of several ways of doing it:

  1. Writing a compiler plugin, that would get internal representation after all optimization phases, transform it and then send it to compiler's back-end. In this case, could you advise me some compilers that support plugins like that? Programming language doesn't really matter, but I would like to try out something other than C/C++ (I know that both GCC and Clang support plugins, but I could never get it working properly on Windows).

  2. Dump internal representation after all optimization phases to file, parse and process it with my obfuscation tool and pass it back to the compiler. I couldn't find how to do it with GCC (I successfully dumped different internal representations, but I couldn't find how to make compiler generate code from it). And I know that Clang is able to generate LLVM bitcode, that can be processed and compiled with LLVM compiler, but again I couldn't make it work properly on Windows. Do you know any compiler that allows doing such things?

  3. Currently I'm doing obfuscation by preprocessing sources, it works, but it takes too long to do it for a large code base. So I'm looking for alternative ways of doing it, and I want to read your opinions on what is the best way to do native code obfuscation.

PS Please bear in mind that I'm asking a concrete question. I'm not asking whether I need obfuscation on not. Obfuscation is done for a reason and I have a reason to do it. I'm not asking how to perform actual native code obfuscation or about algorithms of code obfuscation. I know how to do it and how to break it.

I'm asking about native code compilers that either have good support for plugins or can dump and recompile some low level internal representation like AST (abstract syntax tree), RTL (register transfer language), three-address code or something else.

share|improve this question

closed as off-topic by Bart van Ingen Schenau, Yusubov, mattnz, Michael Kohne, Kilian Foth Aug 29 '13 at 11:20

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Questions asking us to recommend a tool, library or favorite off-site resource are off-topic for Programmers as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it." – mattnz, Kilian Foth
If this question can be reworded to fit the rules in the help center, please edit the question.

Just outsource your development to unskilled programmers -- then nobody will understand the code ever. Seriously though optimized machine code seriously hard to understand, any obfustication process wouldn't make it much harder while drastically slowing down your execution. – James Anderson Aug 21 '13 at 8:02
You mean, you want your machine code to to become more obfuscated as it is already from an optimizing compiler? Because you believe it is still "too readable"? – Doc Brown Aug 21 '13 at 8:33
@JanHudec: What else? The code! I'm obfuscating the code. I'm generating trash code, encrypting strings, using antidisassembly tricks and all this is done by preprocessing source files. No symbols are left after the compilation to native code, what are you talking about? – user2102508 Aug 21 '13 at 9:12
@user2102508: That last answer should definitely go as question edit. When you ask a question, you must explain why you need it. Because for 99% of questions of the form "how do I use X to do Y" the correct answer is "use Z". I read the question carefully. But I am not going to answer it before I am certain there is no easier way. And so is not most other people here. – Jan Hudec Aug 21 '13 at 9:37
"asking about native code compilers" -- Questions asking us to recommend a tool, library or favorite off-site resource are off-topic for Programmers as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it. – gnat Aug 21 '13 at 9:49

Have a look at Stuxnet for a starting point. I realize you didn't imply or ask about malware technique, but it's the only example I can think of that will meet your requirements. Regardless of the political intent for Stuxnet, the technical structure is quite interesting.

Symantec's analysis provides a really good introduction to the structure of that malware. There's quite a few additional analyses available that go deeper into the code.

The heart of Stuxnet consists of a large .dll file that contains many different exports and resources. In addition to the large .dll file, Stuxnet also contains two encrypted configuration blocks.
The dropper component of Stuxnet is a wrapper program that contains all of the above components stored inside itself in a section name “stub”. This stub section is integral to the working of Stuxnet. When the threat is executed, the wrapper extracts the .dll file from the stub section, maps it into memory as a module, and calls one of the exports.

And I think the generalized approach would work for you. You'll have a stub or wrapper that hosts your application. Each separable component is encrypted and packed within the wrapper. An attacker would then need to decrypt the packed component(s) before they could read the machine code it contains.

For additional obfuscation, use separate encryption keys for each component. Keep in mind that an attacker will still have access to the keys since you have to include them for the wrapper to decrypt the components. However, if you are distributing based upon a licensing model then you don't have to distribute all the keys. Likewise, you could setup keys on a per-client distribution so if a copy of your code escapes to the wild, you could potentially track down the source of the escape.

Alternatively, take a look at what mainframe programmers of old used to do with code that would overwrite itself.

A conditional would jump to another location which would insert instructions in the area that just executed. The code then jumps back to the beginning of the modified area. It was "useful" when hotfix patches needed to be applied to a system. It was also frequently perilous to the application's health, so be cautious with this technique.

The obfuscation comes into play because the program has to run and write over the existing instructions before the "actual" program can operate. I don't think this would scale for a larger project

share|improve this answer
Hmm, interesting I hope it is a co-incidence that this is a good example and that the OP isn't writing malware ;) – Dave Hillier Aug 21 '13 at 11:54
@DaveHillier - I pondered a bit about that one too. However, I thought it was fairly unlikely that a malware author would seek advice in a public forum and the details about stuxnet are already pretty commonly known in those circles anyway. Most malware authors who are writing the kits that get sold are reasonably intelligent and stay on top of events like that. – GlenH7 Aug 21 '13 at 13:45
Problem with self-rewriting code is that current operating systems greatly limit it. You can generate code on heap and run it (virtual machines need that), but you can't write over code loaded from the binary file. – Jan Hudec Aug 22 '13 at 8:47

You seem to be confused.

Code obfuscation is a (weak) method of protecting your source code from being understood by others if they get their hands on it. It can be a superficial barrier to amateur when variable names, formatting etc. are distorted to be "unreadable", but the attackers you should worry about - hackers and crackers - aren't fazed by such cosmetic changes. They will just normalize the code automatically and read it with little difficulty.

Obfuscating native code makes even less sense. There are only so many ways you can add two numbers, and if your program needs additions, it will have to use one of them. Assembler code is never printed in anything but normalized one-op-per-line format, and it rarely uses long, meaningful identifiers in the first place. In other words, obfuscated native code looks just like normal native code. (And yes, professional software thieves can read machine code like they read the newspaper.) While it is possible to make the actual operations performed by the program more obscure and needlessly complicated, this carries a heavy risk of introducing errors and inefficiency. Is this really worth the perceived additional safety against code thieves?

In short, I suggest you reconsider what exactly your threat model is and what measures make sense to defend yourself.

share|improve this answer
I'm not confused and I'm not asking whether I need obfuscation or not. I'm asking a concrete question about native compilers. And by the way there are a lot of ways to perform native code obfuscation actually, some of them may be very complex, like control flow flattening for example. People write dissertations on this topic, and you are saying that it doesn't make sense... – user2102508 Aug 21 '13 at 7:57
-1. Not because of the angry comment by asker that it's not what he wanted, but because it's answer before you knew. – Jan Hudec Aug 21 '13 at 9:45
This is not true. Code obfuscation can go way beyond things like symbol names, and can obscure things like how a program comes up with a certain number. Look up white-box cryptography for an extreme case. It's difficult, it makes debugging all but impossible, it doesn't protect against copying the program unless you do it right for this purpose, all in all it's a huge increase in development costs that almost always goes way beyond any additional revenue that it might bring, but it is possible. – Gilles Aug 21 '13 at 10:06
@Gilles: Yes, it makes debugging impossible, but you don't really need to debug obfuscated code (you just disable obfuscation when you are developing, and enable it when you build release version), unless the obfuscation itself introduces some bugs to your code, which is unacceptable. – user2102508 Aug 21 '13 at 10:17
@Nisk: Of course you can obfuscate native code without crypto. For example, this Automated x86 instruction obfuscation post. Obfuscating native code just means translating into code which has the same semantics but different, more difficult (if only marginally so) to understand instructions. Whether such obfuscations are of value from a cost-benefit analysis is a separate question. – Brian Aug 21 '13 at 17:15

Not the answer you're looking for? Browse other questions tagged or ask your own question.