Re: Making a partial C compiler (VBDis)
20 Jun 2003 00:07:41 -0400

          From comp.compilers

Related articles
[7 earlier articles]
Re: Making a partial C compiler (2003-06-03)
Re: Making a partial C compiler (Ivan Boldyrev) (2003-06-03)
Re: Making a partial C compiler (2003-06-03)
Re: Making a partial C compiler (2003-06-05)
Re: Making a partial C compiler (John Eskie) (2003-06-08)
Re: Making a partial C compiler (John Eskie) (2003-06-08)
Re: Making a partial C compiler (2003-06-20)
| List of all articles for this month |

From: (VBDis)
Newsgroups: comp.compilers
Date: 20 Jun 2003 00:07:41 -0400
Organization: AOL Bertelsmann Online GmbH & Co. KG
References: 03-06-062
Keywords: C
Posted-Date: 20 Jun 2003 00:07:41 EDT

"John Eskie" <> schreibt:

> I wonder what alternatives there exist for making control flow
> obfuscation.

You hardly can obfuscate "immediate" control flow, i.e. the immediate
conditional and unconditional jumps in the code. But you can obfuscate
the targets by using indirect jumps and calls, using tables and/or
pointers, and subroutines which provide the actual table indices.

In the MS Windows system I found a very strange technique, where
numerical information and pointers were placed immediately after a
subroutine call. The subroutine evaluated that information and used
one of the pointers as the return address. When the inserted
information (between the pointers) is of variable size, then a hacker
has to decode the algorithm for the evaluation of the whole table, in
order to only separate the pointers from the other
information. Without such an analysis even the size of the tables is
unknown, so that a disassembler must stop after every call to such a
subroutine, or it will erroneously try to interpret the table data as
instructions. Now you may understand what I mean with "immediate"
control flow ;-)

Another technique, also used in MS-DOS and Windows code, are jumps
into instructions. In this case the constant arguments of some
(compare...) operation are instructions themselves, the compare
instruction is some kind of "skip" over these instructions, when
reached by linear execution.

Needless to say that such modifications require special compilers, or
modifications to the compiler-created assembly code.

BTW, a modification of self-modifying code are compressed or encrypted
programs, which are uncompressed only at runtime. Such compressor
tools are readily available, and can be used to both compress and
obfuscate existing executables at the same time. In the resulting
executable only the code of the uncompressor is visible, whereas the
whole main program is garbled into bytes with no obvious meaning. Of
course there also exist tools to uncompress such executables, so that
the compression should use some inobvious algorithm, and/or user
defined parameters.


Post a followup to this message

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