Re: Making C compiler generate obfuscated code

Joshua Cranmer <Pidgeot18@gmail.com>
Thu, 16 Dec 2010 19:45:40 -0500

          From comp.compilers

Related articles
Making C compiler generate obfuscated code dennis.yurichev@gmail.com (Dennis Yurichev) (2010-12-07)
Re: Making C compiler generate obfuscated code paul.biggar@gmail.com (Paul Biggar) (2010-12-09)
Re: Making C compiler generate obfuscated code Pidgeot18@gmail.com (Joshua Cranmer) (2010-12-09)
Re: Making C compiler generate obfuscated code torbenm@diku.dk (2010-12-15)
Re: Making C compiler generate obfuscated code gah@ugcs.caltech.edu (glen herrmannsfeldt) (2010-12-16)
Re: Making C compiler generate obfuscated code Pidgeot18@gmail.com (Joshua Cranmer) (2010-12-16)
Re: Making C compiler generate obfuscated code Pidgeot18@gmail.com (Joshua Cranmer) (2010-12-16)
Re: Making C compiler generate obfuscated code martin@gkc.org.uk (Martin Ward) (2010-12-17)
Re: Making C compiler generate obfuscated code gah@ugcs.caltech.edu (glen herrmannsfeldt) (2010-12-18)
Re: Making C compiler generate obfuscated code rpw3@rpw3.org (2010-12-18)
Re: Making C compiler generate obfuscated code DrDiettrich1@aol.com (Hans-Peter Diettrich) (2010-12-16)
Re: Making C compiler generate obfuscated code torbenm@diku.dk (2010-12-20)
Re: Making C compiler generate obfuscated code gneuner2@comcast.net (George Neuner) (2010-12-21)
[8 later articles]
| List of all articles for this month |

From: Joshua Cranmer <Pidgeot18@gmail.com>
Newsgroups: comp.compilers
Date: Thu, 16 Dec 2010 19:45:40 -0500
Organization: Georgia Institute of Technology
References: 10-12-017 10-12-019 10-12-023 10-12-024
Keywords: C, code
Posted-Date: 17 Dec 2010 22:15:06 EST

On 12/16/2010 03:52 AM, glen herrmannsfeldt wrote:
> Torben Fgidius Mogensen<torbenm@diku.dk> wrote:
> (snip on object code obfuscating compilers)
>
>> Indeed. I wsa not impressed by the approach: It made the code a lot
>> larger and a lot slower and the obfuscation was easy to remove.
>> Ideally, obfuscated code should only be marginally larger and slower
>> than "normal" code, but extremely difficult to reverse-engineer.
>
> It would seem that one could divide the code into blocks at
> unconditional branches, and then move the blocks around randomly.
> Though again, it might not be hard to unobfuscate. I do remember
> stories about compilers with optimization algorithms based on
> random numbers and the natural difficulty with reverse engineering.


My decompiler worked by turning the disassembled code into a graph
(also removing unconditional jumps in the process), so the actual
location of hunks did not make when whit of difference.


> That is, assuming such tricks are allowed. As I understand it
> (possibly incorrectly) the exception model in Java makes it
> difficult to do many optimizations that traditionally would have
> been done. Moving statements outside of loops, for one.


Java does make guarantees about apparent execution order, but to the
degree that you know that statements are not going to cause "side
effects", you can reorder stuff.


--
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth



Post a followup to this message

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