What Is a Program Transformation?

Level 3 showed how tools stop seeing your text and start seeing structure. This level is about what they do with that structure: rewrite it. A program transformation takes a program in and produces a different program out, with one iron rule. The new program must behave exactly like the old one.

Everything in this family works the same way, whatever its motive. An optimizing compiler rewrites your code to be faster. A formatter rewrites it to be prettier. An obfuscator rewrites it to be unreadable. Same machinery, three different goals.

The pipeline: parse, rewrite, regenerate

A transformation never edits text with find and replace. It parses the source into a tree, walks the tree making precise structural edits, then prints the modified tree back out as fresh source code. Working on structure instead of text is what makes the iron rule keepable: the tool knows a variable from a string from a keyword, so it cannot accidentally rewrite the wrong thing.

• Parse: build the syntax tree, exactly as in Level 3.
• Rewrite: apply a pass, a focused rule like rename every variable or fold constant arithmetic, to the tree.
• Regenerate: print the new tree as ordinary source code that any interpreter will happily run.

This is a live rename pass over a real syntax tree. Drag the slider to apply it one change at a time and watch meaning drain out of the program while its behaviour stays untouched.

The end state, side by side. Every occurrence of each name was replaced consistently, definitions and uses together, which is exactly the kind of coordinated edit that is trivial on a tree and dangerous on raw text.

price = 12
tax = price * 2
total = price + tax
print "total:", total

v1 = 12
v2 = v1 * 2
v3 = v1 + v2
print "total:", v3

Passes compose

Think of a car wash with stations: soap, rinse, wax, dry. Each station takes whatever car rolls in and hands a working car to the next station. Transformation passes line up the same way: rename hands its output to constant folding, which hands its output to dead code removal. Because every station keeps the car a car, the whole line does too, no matter how many stations you add.

Real tools rarely run one pass. They run pipelines: rename, then fold constants, then remove dead code, each pass taking the previous pass's output as its input. Because every pass preserves behaviour, any chain of them preserves behaviour too. That composability is why obfuscators can layer many transforms and still ship working code.

Here is a second pass to compare against rename: constant folding, which computes fixed arithmetic ahead of time. Notice it is the same parse, rewrite, regenerate shape with a different rewrite rule, and notice that a compiler runs it to make code faster while an obfuscator runs its inverse, splitting constants apart, to make code stranger. Every transformation in Level 6 has a neutral compiler twin like this.

One rule governs this whole field: the output must behave identically to the input, always, for every input. A transform that is 99 percent correct is not an obfuscator, it is a bug generator. Judge every protection tool first by whether your code still works.

Frequently asked questions