Re: Encripted source as an ANDF

rf@mcc.comg (Ron Guilmette):
> worley@compass.com (Dale Worley) writes:
>>The most interesting ANDF-type work I've seen is the concept of
>>"shrouded source code", that is, compilable source that has been
>>deliberately uglified by removing comments, renaming variables, etc.
>
> Regarding "uglified" source code, it should be noted that "uglification"
> could really be a very intense process, going far beyond anything that
> you might at first think of.


> First, in the case of C (or C++) one of the best techniques for rapidly
> removing the mantainability from a piece of source code (that is assuming
> that there was any to being with) is to preprocess it with the C
> preprocessor.


> Another very effective uglifing transformation is to perform comprehensive
> de-structuring, i.e. the conversion of all loops and well structured if and
> switch/case statements into the most degenerative possible equivalent forms
> using GOTO statements.


> For C, other good "semantics preserving" one way transformations include
> the elimination of all typedef statements, and the elimination of all
> enum type declarations/definitions and enum type constants.


So as a general rule all "uglifications" must preserve semantics.


Ok, now lets make all temporaries explicit and break up expressions
into sequences of statements containing only binary or ternary
operations like "x op= y," "x = y op z," and "if(x)goto y."


Lets make all address arithmetic and dereferencing operations
explicit.


Now lets do some loop folding, move invariant code out of loops, and
common subexpression elimination.


Is that ugly enough for you?


Doesn't this process sound familiar? By the time you have the "source"
code in this uglified form you have done most of the work of compiling
it. If you are careful your uglifying transformations can not only
preserve the semantics of the original program, they can be machine
independent.


Mapping the partially compiled intermediate code, er... I must mean
uglified code, into machine code for a specific architecture without
messing up the semantics is hard. But then that has always been the
hard part of implementing standards compliant compilers.


Bob P.
[From bpendlet@esunix.uucp (Bob Pendleton)]
--

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