Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!news.glorb.com!news-out.readnews.com!news-xxxfer.readnews.com!news.misty.com!news.iecc.com!.POSTED!nerds-end From: "Gyll ." Newsgroups: comp.compilers Subject: Re: invitation to discussion: code and protocol obfuscation techniques Date: Mon, 5 Aug 2013 13:42:18 +0300 Organization: Compilers Central Lines: 79 Sender: johnl@iecc.com Approved: comp.compilers@iecc.com Message-ID: <13-08-005@comp.compilers> References: <13-08-002@comp.compilers> NNTP-Posting-Host: news.iecc.com Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-Trace: leila.iecc.com 1375794920 7481 64.57.183.58 (6 Aug 2013 13:15:20 GMT) X-Complaints-To: abuse@iecc.com NNTP-Posting-Date: Tue, 6 Aug 2013 13:15:20 +0000 (UTC) Keywords: code, tools Posted-Date: 06 Aug 2013 09:15:20 EDT X-submission-address: compilers@iecc.com X-moderator-address: compilers-request@iecc.com X-FAQ-and-archives: http://compilers.iecc.com Xref: csiph.com comp.compilers:951 @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