Re: invitation to discussion: code and protocol obfuscation techniques

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

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