Re: Making C compiler generate obfuscated code

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.


> Some of the least readable code I have seen has been code where every
> trick in the book was used to make it as short as possible, so using
> extreme optimisaton tricks is probably a much better obfuscator than
> inserting random code -- even random control-structure code.


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.


> Some common optimisations do, indeed, make the code less readable:
> Strength reduction, loop scheduling, array blocking, common
> subexpression elimination and so on. So using these aggressively
> would work well. But there will be code where such optimsations do
> not apply. Here, you could use some of the following tricks:


If they are predictable, though, it should be possible to write
a program to undo them. Easier if the obfuscator is open source.


> - Split a variable x into two variables p and q, such that x=p+q.
> Modifications to x are made into modifications of p _or_ q. Uses of
> x (except those for self-modification such as x=x+1) are replaced by
> uses of p+q. This will make the code somewhat larger and slower, but
> not by much. Common subexpression elimination can remove some of the
> p+q additions without increasing readability.


Even better if you can find natural rearrangements of variables
that satisfy this goal.


> - Replace two otherwise unrelated variables x and y by p and q such
> that p=x+y and q=x-y (so x==(p+q)/2 and y==(p-q)/2).


Probably not so bad for integers, but not good for floating point.


-- glen

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