|Making a partial C compiler email@example.com (John Eskie) (2003-05-18)|
|Re: Making a partial C compiler firstname.lastname@example.org (John Eskie) (2003-05-29)|
|Re: Making a partial C compiler email@example.com (Ivan Boldyrev) (2003-06-03)|
|Re: Making a partial C compiler firstname.lastname@example.org (John Eskie) (2003-06-08)|
|Re: Making a partial C compiler and obfuscator email@example.com (David Chase) (2003-06-08)|
|From:||David Chase <firstname.lastname@example.org>|
|Date:||8 Jun 2003 23:06:21 -0400|
|Organization:||Incompetent Software Hucksters|
|References:||03-05-139 03-05-202 03-06-017 03-06-062|
|Posted-Date:||08 Jun 2003 23:06:20 EDT|
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
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).
Return to the
Search the comp.compilers archives again.