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: glen herrmannsfeldt Newsgroups: comp.compilers Subject: Re: invitation to discussion: code and protocol obfuscation techniques Date: Thu, 8 Aug 2013 14:41:00 +0000 (UTC) Organization: Aioe.org NNTP Server Lines: 87 Sender: johnl@iecc.com Approved: comp.compilers@iecc.com Message-ID: <13-08-011@comp.compilers> References: <13-08-002@comp.compilers> <13-08-006@comp.compilers> <13-08-008@comp.compilers> <13-08-010@comp.compilers> NNTP-Posting-Host: news.iecc.com X-Trace: leila.iecc.com 1375974592 67890 64.57.183.58 (8 Aug 2013 15:09:52 GMT) X-Complaints-To: abuse@iecc.com NNTP-Posting-Date: Thu, 8 Aug 2013 15:09:52 +0000 (UTC) Keywords: code Posted-Date: 08 Aug 2013 11:09:51 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:957 isiisorisiaint@gmail.com wrote: > @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, (snip) >>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) Seems like something similar might be useful in ordinary source obfuscation. Giving hints to the obfuscator... >>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. Yes, that is why I mentioned differential cryptanalysis. After that post, I read the wikipedia page, which I had forgotten about. It seems that the beginning of the pubic discussion on it included noting that DES was unusually resistant to differential analysis, that is, much more than would have been expected. It seems that IBM knew about it at the time, designed for it, but didn't talk about it. In your case, I am considering the possibility that the humans trying to break it start using computers to help. If you don't design for it, it might be too easy. Well, consider one example. Say you distribute programs with magic constants in them. It would normally be difficult for someone to find such constants. But say someone gets two different copies, with two different constants. In that case, a byte comparison will easily flag them. It is much less obvious in the case of states of a state machine, but again, it might be possible for a program to extract them, compare them, and figure out the obfuscation. Reminds me that one time I had a web page where I could select the value of some parameters from a menu, but I wanted a value that wasn't one of the choices. I downloaded the page (saved the html source) edited the source, loaded it into a browser, and selected the new value. The server didn't verify that only specific values were used. Also, note that this problem seems not so different from the license validation keys used by many software protection systems. >> Some things you might read about are Diffie-Hellman key >> exchange and differential cryptanalysis. -- glen