Re: Making C compiler generate obfuscated code

Hans-Peter Diettrich <DrDiettrich1@aol.com>
Thu, 16 Dec 2010 15:07:36 +0100

          From comp.compilers

Related articles
[4 earlier articles]
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)
Re: Making C compiler generate obfuscated code gneuner2@comcast.net (George Neuner) (2010-12-21)
Re: Making C compiler generate obfuscated code walter@bytecraft.com (Walter Banks) (2010-12-21)
Re: Making C compiler generate obfuscated code gah@ugcs.caltech.edu (glen herrmannsfeldt) (2010-12-21)
Re: Making C compiler generate obfuscated code martin@gkc.org.uk (Martin Ward) (2010-12-22)
[4 later articles]
| List of all articles for this month |

From: Hans-Peter Diettrich <DrDiettrich1@aol.com>
Newsgroups: comp.compilers
Date: Thu, 16 Dec 2010 15:07:36 +0100
Organization: Compilers Central
References: 10-12-017 10-12-019 10-12-023
Keywords: C, code
Posted-Date: 19 Dec 2010 15:11:09 EST

Torben Fgidius Mogensen schrieb:


> 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.


Best obfuscation can be found in (older) Windows system code. Short
jumps have been replaced by dummy instructions (CMP), with other jumps
going to the argument of that instruction. What assembly code should a
disassembler generate from such ambiguous constructs?


Also nice are vararg-type subroutine parameters inlined after the call
statement, so that the location of the next statement after the call
is unknown. Even worse when multiple possible return adresses (jump
tables) are part of these parameters. Such obfuscation requires to
decode and emulate the called subroutine, before the location of the
next statement is known.


In practice such interruptions of the control flow make automatic
disassembling almost impossible. Instead a good *interactive*
disassembler is required (as I was writing when I came across above
tricks), and time consuming manual intervention and analysis is
required with almost every break in the control flow. The mix of data
and instructions not only makes it impossible to generate an assembler
listing, but also hides the use of memory locations (variables or
constants), with pointers embedded in the inlined parameter
blocks. Now tell me how a decompiler or other analysis tool should
deal with such constructs, when already the automatic separation of
code and data is impossible.


DoDi



Post a followup to this message

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