Re: invitation to discussion: code and protocol obfuscation techniques

Gyll . <isiisorisiaint@gmail.com> wrote:
> 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):


One important thing to know is the approximate value of someone
breaking the system. That affects how much human effort one might put
into the attack.


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


Some things you might read about are Diffie-Hellman key exchange and
differential cryptanalysis. I am not so sure that Diffie-Hellman will
help, but it is often used in client-server systems. It is, for
example, how secure network connections are made.


> 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


This is the case where differential cryptanalysis can come in. By
comparing the differences, probably using a computer, one can
determine statistically what matters and what doesn't.


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


Consider that the attacker can use a program other than the one you
supply to send in requests and process the replies. That allows one
to determine more than you might hope about what the secret side is
doing.


-- glen

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