Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!news.glorb.com!news-out.readnews.com!news-xxxfer.readnews.com!border4.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.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 15:44:50 +0300 Organization: Compilers Central Lines: 32 Sender: johnl@iecc.com Approved: comp.compilers@iecc.com Message-ID: <13-08-006@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 1375794958 7892 64.57.183.58 (6 Aug 2013 13:15:58 GMT) X-Complaints-To: abuse@iecc.com NNTP-Posting-Date: Tue, 6 Aug 2013 13:15:58 +0000 (UTC) Keywords: analysis, code Posted-Date: 06 Aug 2013 09:15:58 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:952 Allow me to [try to] kickstart the discussion with an idea (dependent on, and thus characteristic to) the the split-program structure that i described (i.e. half trusted, half not, and communicating with each-other via a communication protocol): an obfuscated version of the protocol can allow, apart from introducing new protocol stages and modifying the message format (in order to render older versions of a program inoperable), also to introduce *new dependencies in the program*, thus apparently (to me) having the potential to completely change the program's abstract syntax tree (AST) beyond recognition; namely: a) new variables can be introduced, where said variables are initialized from values coming in messages from the trusted half of the program (the server in my case); then these variables can be pollute the program by embedding them in opaque expressions b) various [known only to the trusted half] relationships between the newly-introduce variables can exist, thus enabling the creation of opaque predicates, which in turn can be used to cloak both the program flow, and to cloak the statistics of a code block (thus making harder the identification of a code block that performs a given function) * of course, the above techniques must be assisted by variable codecs (e.g. variable merging and the likes) in order to hide the dependencies of an expression on a given (set of) variable(s) Note that both of the above techniques only work against static analysis, but i'd be very interested in ideas of how to use my specific setting (two-half program with half trusted and half not) to harden dynamic analysis A suggestion for a starting point: identify various computing resources that your typical computer has (e.g. multi-threading, multi-stasking, local loop, etc), and try to figure out how to make best use of them for obfuscation purposes