Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!usenet.blueworldhosting.com!feeder02.blueworldhosting.com!border4.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!news.iecc.com!.POSTED!nerds-end From: glen herrmannsfeldt Newsgroups: comp.compilers Subject: Re: invitation to discussion: code and protocol obfuscation techniques Date: Tue, 6 Aug 2013 19:09:05 +0000 (UTC) Organization: Aioe.org NNTP Server Lines: 46 Sender: johnl@iecc.com Approved: comp.compilers@iecc.com Message-ID: <13-08-008@comp.compilers> References: <13-08-002@comp.compilers> <13-08-006@comp.compilers> NNTP-Posting-Host: news.iecc.com X-Trace: leila.iecc.com 1375906400 76146 64.57.183.58 (7 Aug 2013 20:13:20 GMT) X-Complaints-To: abuse@iecc.com NNTP-Posting-Date: Wed, 7 Aug 2013 20:13:20 +0000 (UTC) Keywords: code Posted-Date: 07 Aug 2013 16:13: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:954 Gyll . wrote: > 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): One important thing to know is the approximate value of someone breaking the system. That affects how much human effort one might put into the attack. > 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: Some things you might read about are Diffie-Hellman key exchange and differential cryptanalysis. I am not so sure that Diffie-Hellman will help, but it is often used in client-server systems. It is, for example, how secure network connections are made. > 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 This is the case where differential cryptanalysis can come in. By comparing the differences, probably using a computer, one can determine statistically what matters and what doesn't. > 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) Consider that the attacker can use a program other than the one you supply to send in requests and process the replies. That allows one to determine more than you might hope about what the secret side is doing. -- glen