Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!news.glorb.com!npeer01.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!nx02.iad01.newshosting.com!newshosting.com!216.196.98.142.MISMATCH!border3.nntp.dca.giganews.com!border1.nntp.dca.giganews.com!border4.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!news.iecc.com!.POSTED!nerds-end
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Newsgroups: comp.compilers
Subject: Re: invitation to discussion: code and protocol obfuscation techniques
Date: Sun, 4 Aug 2013 03:41:38 +0000 (UTC)
Organization: Aioe.org NNTP Server
Lines: 39
Sender: johnl@iecc.com
Approved: comp.compilers@iecc.com
Message-ID: <13-08-004@comp.compilers>
References: <13-08-002@comp.compilers>
NNTP-Posting-Host: news.iecc.com
X-Trace: leila.iecc.com 1375794841 6877 64.57.183.58 (6 Aug 2013 13:14:01 GMT)
X-Complaints-To: abuse@iecc.com
NNTP-Posting-Date: Tue, 6 Aug 2013 13:14:01 +0000 (UTC)
Keywords: code, tools
Posted-Date: 06 Aug 2013 09:14:00 EDT
X-submission-address: compilers@iecc.com
X-moderator-address: compilers-request@iecc.com
X-FAQ-and-archives: http://compilers.iecc.com
X-Received-Bytes: 2946
Xref: csiph.com comp.compilers:950

Gyll . <isiisorisiaint@gmail.com> wrote:
> I'd like to get some info on the subject of code obfuscation,
> particularly source code-level obfuscation methods that will not get
> rendered [totally] useless by code optimizers, program flow graph
> extractors, and other program analysis tools.

As far as I know, the usual obfuscator generates a program with the
exact same function, flow, etc, (as seen by a compiler) but harder to
read by humans.

> More specifically, i need to build an obfuscator source code
> preprocessor for a P2P client such that the obfuscator automatically
> introduces additional protocol states to the base protocol in the
> client code (a "protocol state" is state in the client algorithm
> state machine where a [set of] messages are exchanged between
> two P2P clients).

Seems to me that this would require the obfuscator to know much more
about the algorithm than is usual. First of all, it has to recognize
that it is a state machine. It is not so unusual for verilog reading
tools to recognize and optimize state machines, but, as far as I know,
unusual for other languages. Even so, they expect a fairly specific
way of writing the state machine.

> The obfuscator-introduced protocol validation messages
> should be as well obfuscated as possible, in order to make it
> difficult for an attacker which has the original source code
> of the client to determine which new protocol states have
> been introduced (and where inside the code) by the obfuscator.

As usual, how well that can be done depends on how determined the
attacker is. What the value (in actual money) would be to an attacker,
and what tools would be available.

You might, for example, have an obfuscator that makes the code hard
for a human, but a program could determine that the added states
didn't make logical sense, and remove them.

-- glen