Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!news.glorb.com!border3.nntp.dca.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!news.iecc.com!.POSTED!nerds-end From: "Gyll ." Newsgroups: comp.compilers Subject: invitation to discussion: code and protocol obfuscation techniques Date: Thu, 1 Aug 2013 14:49:02 +0300 Organization: Compilers Central Lines: 15 Sender: johnl@iecc.com Approved: comp.compilers@iecc.com Message-ID: <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 1375562811 9586 64.57.183.58 (3 Aug 2013 20:46:51 GMT) X-Complaints-To: abuse@iecc.com NNTP-Posting-Date: Sat, 3 Aug 2013 20:46:51 +0000 (UTC) Keywords: code, question Posted-Date: 03 Aug 2013 16:46: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:948 I'd like to get some info on the subject of code obfuscation, particularly source code-level obfuscation methods that will not get rendered [totally] useless by code optimizers, program flow graph extractors, and other program analysis tools. More specifically, i need to build an obfuscator source code preprocessor for a P2P client such that the obfuscator automatically introduces additional protocol states to the base protocol in the client code (a "protocol state" is state in the client algorithm state machine where a [set of] messages are exchanged between two P2P clients). The obfuscator-introduced protocol validation messages should be as well obfuscated as possible, in order to make it difficult for an attacker which has the original source code of the client to determine which new protocol states have been introduced (and where inside the code) by the obfuscator.