Re: Making a partial C compiler and obfuscator

John Eskie wrote:


>>Optimizing compiler (for example, gcc with -O1) will re-arrange these
>>blocks back. Do you agree to distribute slow unoptimized code?
>>
>>
>
>Yes I know it will become slower and it's ok for what I need. If it
>takes 1 or 2 seconds longer to run the processed code it's acceptable.
>
>I wonder what alternatives there exist for making control flow
>obfuscation. I've read lots of reports on advanced analysis and
>restructuring of C code in some university reports published on
>various websites but it seems there are no practical implementations
>of it. Often there is alot distance from theory to get it to work.


I am unsure if it will ever work. There is a company, Cloakware, that
purports to do this "right", but I haven't gone snooping at their
patents to see what I thought of them. If you assume that your
adversary can get his/her hands on a machine (or a virtual machine)
executing your code, then you had better assume the worst. Especially
assume the worst if your adversary has deep pockets, and more so if
the adversary can obtain the services of someone who's worked on
optimizing compilers (remember, the damn things must be debugged, so
you get experience reverse-engineering code that doesn't even work
right).


Obfuscators for Java bytecodes are not at all good; I've worked on a
bytecode-to-native compiler, and the first thing that you do is
untangle all the obfuscation so that you can verify the code.
Deobfuscators don't even work that hard, and they usually do a pretty
good job. The obfuscators that "work well" have typically just
discovered a new trick, that has not yet had a recognizer written in
the deobfuscators. And, again, the compilers are out in front -- if
they must make sense of the code, they must undo the obfuscation.


There was a paper, I do not recall where, that did describe a theory
for doing this. I don't recall understanding it, except that it was
not trivial (imagine imposing a lot of log-N overheads for operations
that were previously constant -- that sort of thing).


David Chase

Return to the comp.compilers page.
Search the comp.compilers archives again.