Re: invitation to discussion: code and protocol obfuscation techniques

@Roger: thank you for the pointer. i tried to walk through the article
PDF http://eprint.iacr.org/2013/451.pdf trying to figure out what
exactly the practical results are, and from what i've managed to
understand there's not very much of those yet, but i'll definitely
keep an eye on the subject.


Now, let me explain *my specific problem* a bit more in detail:


What I want to have is a two-halves program which are linked together
via a communication protocol, where one half of the program resides on
a trusted server and the other half is a client that is distributed in
the wild (to make things more clear, in my specific case the trusted
half will be a login server - but which can also do other stuff than
validating logins should it be needed, and the untrusted half that
needs to be protected is a messaging client)


What I am actually interested in is "code obfuscation-based moving
target defense", I.E. the client code (that needs to be protected) *is
allowed to be [periodically] re-obfuscated* by the server and
re-distributed (in the newly-obfuscated form) in order to achieve [a
very high level of] protection.


So the protection scheme looks something like this:


periodically_repeat: {
      new_obfuscation_method=pick_
at_random(set_of_obfuscation_methods);
      new_server_code:=obfuscate(new_obfuscation_method, original_server_code);
      new_client_code:=obfuscate(new_obfuscation_method, original_client_code);
      distribute(new_client_code);
}


and this brings me to following [code obfuscation-based moving target
defense] mechanism that i would like to have a discussion about:


1) each new version of the program introduces *new states* in the
communication protocol between the server-side and the client-side
halves of the program: this will make any not-updated version of a
client unfunctional (it will neither be able to log in on the server,
nor will it be able to comminicate with other clients (because the
clinet-to-client protocol also changes))
1.a) the protocol changes will consist *only* of adding protocol
validation messages, e.g. a new stage in the communication protocol
might have the server ask "tell me what is 1+1" and the client must
both understand the [newly-introduced] question, and (correctly) reply
to the question
2) each new version of the program is [heavily] obfuscated in a
different way, such that when comparing any two obfuscated program
versions it must be very hard to identify which code blocks in one
program version corresponds to which block in the other program
version
2.a) for an attacker who already knows exactly what code blocks *of
the original non-obfuscated program* he wants to change (i.e. in order
to implement a given malicious behavior into the *original* program),
it must be very hard for him to find (and then modify) the
corresponding code blocks *in the obfuscated program*: in this way the
attacker is delayed in introducing into the obfuscated program the
changes he wants to make, although he knows exactly how, and where, to
implement those changes in the original program code
2.b) alternatively, an attacker (who we assume has already crafted a
[malicious] patch to the source code *for the original program and
protocol*) must also have a hard time in understanding *exactly what
protocol changes have been made* in [each] new version of the client:
in this way, the attacker will be delayed in implementing any new
protocol changes into his already-maliciously-modified version *of the
original program* (until he first understands exactly what those
changes are)


So the input I'd be very much interested in is comments/ideas related
to this generic question: how can we leverage protocol obfuscation in
a split program where one part is trusted and the other is not, using
the moving target defense class of solutions based on code *and
protocol* obfuscation


I've been looking on the net for something along the lines described
in my previous post but came up empty handed, so, apart from any
original input on the topic, I'd also very much appreciate if anyone
can provide any pointers to some [published] work related to [a
similar method to] what I described

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