Path: csiph.com!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!news.misty.com!news.iecc.com!.POSTED!nerds-end From: isiisorisiaint@gmail.com Newsgroups: comp.compilers Subject: Re: invitation to discussion: code and protocol obfuscation techniques Date: Thu, 8 Aug 2013 03:24:38 -0700 (PDT) Organization: Compilers Central Lines: 53 Sender: johnl@iecc.com Approved: comp.compilers@iecc.com Message-ID: <13-08-010@comp.compilers> References: <13-08-002@comp.compilers> <13-08-006@comp.compilers> <13-08-008@comp.compilers> NNTP-Posting-Host: news.iecc.com Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: leila.iecc.com 1375970336 50689 64.57.183.58 (8 Aug 2013 13:58:56 GMT) X-Complaints-To: abuse@iecc.com NNTP-Posting-Date: Thu, 8 Aug 2013 13:58:56 +0000 (UTC) Keywords: code Posted-Date: 08 Aug 2013 09:58:56 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:956 @glen >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. Yes, this is pretty much the standard definition, but what i want to have is a *protocol* obfuscator (no "standard definition" for this one as far as i know) which, just like code obfuscation tries to hide code, protocol obfuscation tries to hide protocol (modifications) by polluting a "source protocol" with extra messages/stages (and also by scrambling the format of the source protocol messages); in this context, code obfuscation is only meant to obfuscate the code which implements the obfuscated protocol, such that finding correspondences between the code that implements the original protocol and the code that implements the obfuscated protocol are made hare to identify (and then change). >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. Yes, but I FORGOT TO MENTION SOMETHING IMPORTANT IN THE ORIGINAL POST: i am allowed to include obfuscator directives in the original source code, e.g. [...] //OBFUSCATOR_DIRECTIVE:insert_protocol_validation_message else if (state==STATE1) { [...] (also, apart from generic obfuscation methods which the obfuscator can pick at random and insert anywhere it pleases in the code, i can use directives to force it to introduce obfuscation in specific places where i want obfuscation to always be introduced) >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 My biggest problem is to have an algorithm that requires *human intervention*, and it would of course be nice to require as much human intervention as possible, but as i said in a later post i don't need one particular version of obfuscated code to be unbreakable since the obfuscated code will be constantly updated. What i *do* need is to have an automated algorithm which can produce such a high variety of obfuscated code that each new code version will require human intervention. >Some things you might read about are Diffie-Hellman key exchange and >differential cryptanalysis. I am familiar with these notions (actually i'm using public key crypto in my program), but only at the protocol level, i.e. i am not a mathematician eating groups for breakfast, so there's no way i can make an informed decision all by myself as to if and how all kinds of crypto analysis methods can be used against code obfuscation techniques. I did read quite a lot of articles on code obfuscation, and, fwiw, i didn't find anything related to crypto analysis-based de-obfuscation