Re: invitation to discussion: code and protocol obfuscation techniques

@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

Return to the comp.compilers page.
Search the comp.compilers archives again.