Re: Making C compiler generate obfuscated code

Martin Ward <martin@gkc.org.uk> wrote:
(snip)


> FermaT's primary commercial application is migrating assembler to
> structured and maintainable C and COBOL, so the "deobfuscation"
> transformations are geared towards removing the "clever tricks"
> introduced by assembler programmers to save a byte here and a cycle
> there: or just because they were


One of the tricks I remember from the 8 bit microprocessor days was to
put an instruction in the two bytes of a load instruction instead of a
branch around the instruction.


I used to have a table driven disassembler for 8080, Z80, and then
later 6809 code that would follow along from the entry point, keeping
track of conditional branch destinations on a stack. When it reached
an unconditional branch it would take an entry off the stack. It
keeps flags for each byte as the first byte (opcode), absolute
address, relative address, or, if not part of any instruction, data.
I suppose one would eventually learn enough tricks though.


Along the line of such tricks, there are stories of Apple II ROM
cloners claiming that so many such tricks were used that the Apple
implementation was the only one possible in the available number of
bytes. Then, since it was the only one possible, it should not
protected against cloning.


-- glen

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