Re: invitation to discussion: code and protocol obfuscation techniques

"Gyll ." <isiisorisiaint@gmail.com>
Mon, 5 Aug 2013 15:44:50 +0300

          From comp.compilers

Related articles
invitation to discussion: code and protocol obfuscation techniques isiisorisiaint@gmail.com (Gyll .) (2013-08-01)
Re: invitation to discussion: code and protocol obfuscation techniques gah@ugcs.caltech.edu (glen herrmannsfeldt) (2013-08-04)
Re: invitation to discussion: code and protocol obfuscation techniques isiisorisiaint@gmail.com (Gyll .) (2013-08-05)
Re: invitation to discussion: code and protocol obfuscation techniques isiisorisiaint@gmail.com (Gyll .) (2013-08-05)
Re: invitation to discussion: code and protocol obfuscation techniques gah@ugcs.caltech.edu (glen herrmannsfeldt) (2013-08-06)
Re: invitation to discussion: code and protocol obfuscation techniques isiisorisiaint@gmail.com (2013-08-08)
Re: invitation to discussion: code and protocol obfuscation techniques gah@ugcs.caltech.edu (glen herrmannsfeldt) (2013-08-08)
Re: invitation to discussion: code and protocol obfuscation techniques isiisorisiaint@gmail.com (2013-08-14)
Re: invitation to discussion: code and protocol obfuscation techniques genew@telus.net (Gene Wirchenko) (2013-08-20)
| List of all articles for this month |

From: "Gyll ." <isiisorisiaint@gmail.com>
Newsgroups: comp.compilers
Date: Mon, 5 Aug 2013 15:44:50 +0300
Organization: Compilers Central
References: 13-08-002 <B5FEE00B53CF054AA8439027E8FE17751EFB7508@IMCMBX04.MITRE.ORG>
Keywords: analysis, code
Posted-Date: 06 Aug 2013 09:15:58 EDT

Allow me to [try to] kickstart the discussion with an idea (dependent
on, and thus characteristic to) the the split-program structure that i
described (i.e. half trusted, half not, and communicating with
each-other via a communication protocol):


an obfuscated version of the protocol can allow, apart from
introducing new protocol stages and modifying the message format (in
order to render older versions of a program inoperable), also to
introduce *new dependencies in the program*, thus apparently (to me)
having the potential to completely change the program's abstract
syntax tree (AST) beyond recognition; namely:
a) new variables can be introduced, where said variables are
initialized from values coming in messages from the trusted half of
the program (the server in my case); then these variables can be
pollute the program by embedding them in opaque expressions
b) various [known only to the trusted half] relationships between the
newly-introduce variables can exist, thus enabling the creation of
opaque predicates, which in turn can be used to cloak both the program
flow, and to cloak the statistics of a code block (thus making harder
the identification of a code block that performs a given function)
* of course, the above techniques must be assisted by variable codecs
(e.g. variable merging and the likes) in order to hide the
dependencies of an expression on a given (set of) variable(s)


Note that both of the above techniques only work against static
analysis, but i'd be very interested in ideas of how to use my
specific setting (two-half program with half trusted and half not) to
harden dynamic analysis
A suggestion for a starting point: identify various computing
resources that your typical computer has (e.g. multi-threading,
multi-stasking, local loop, etc), and try to figure out how to make
best use of them for obfuscation purposes


Post a followup to this message

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