Re: invitation to discussion: code and protocol obfuscation techniques

From	glen herrmannsfeldt <gah@ugcs.caltech.edu>
Newsgroups	comp.compilers
Subject	Re: invitation to discussion: code and protocol obfuscation techniques
Date	2013-08-04 03:41 +0000
Organization	Aioe.org NNTP Server
Message-ID	<13-08-004@comp.compilers> (permalink)
References	<13-08-002@comp.compilers>

Show all headers | View raw

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

Thread

invitation to discussion: code and protocol obfuscation techniques "Gyll ." <isiisorisiaint@gmail.com> - 2013-08-01 14:49 +0300
  RE: invitation to discussion: code and protocol obfuscation techniques "Costello, Roger L." <costello@mitre.org> - 2013-08-03 20:58 +0000
  Re: invitation to discussion: code and protocol obfuscation techniques glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-08-04 03:41 +0000
  Re: invitation to discussion: code and protocol obfuscation techniques "Gyll ." <isiisorisiaint@gmail.com> - 2013-08-05 13:42 +0300
  Re: invitation to discussion: code and protocol obfuscation techniques "Gyll ." <isiisorisiaint@gmail.com> - 2013-08-05 15:44 +0300
    Re: invitation to discussion: code and protocol obfuscation techniques glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-08-06 19:09 +0000
      Re: invitation to discussion: code and protocol obfuscation techniques isiisorisiaint@gmail.com - 2013-08-08 03:24 -0700
        Re: invitation to discussion: code and protocol obfuscation techniques glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-08-08 14:41 +0000
          Re: invitation to discussion: code and protocol obfuscation techniques isiisorisiaint@gmail.com - 2013-08-14 08:20 -0700
          Re: invitation to discussion: code and protocol obfuscation techniques Gene Wirchenko <genew@telus.net> - 2013-08-20 19:05 -0700

csiph-web