Decisions in application architecture, class, method/function, IPC/RPC & other data-flow are fairly unique between coders. Also, very difficult to loose those characteristics with obfuscation routines.

The generation of equivalent functional code, and higher-level understanding of these concepts in code by the obfuscating engine would be required. That's not trivial.

Of course, if you are unskilled, that is, if you don't use 'patterns' at all - it is trivial to make you look like everyone else.

-Travis

On Thu, Dec 31, 2015 at 12:41 PM, Troy Benjegerdes <hozer@hozed.org> wrote:

On Thu, Dec 31, 2015 at 04:49:53AM -0800, coderman wrote:
> On 12/31/15, Georgi Guninski <guninski@guninski.com> wrote:
> > ...
> > Have they tried it on perl or assembler (or whitespace or brainfuck and
> > other esoteric languages)?
>
> yes, even intentionally obfuscated disasm resistant mungifications of
> compiled programs.
>
>
> > Obfuscated perl appears hard (in case it significantly different than
> > the preimage ;) )
>
> the key aspect is that it is well distinguished among obfuscated perl
> programs written by other coders, especially architecturally complex
> perl programs (of any variety)

Seems like if you have code that is both complex and has good performance
characteristics, then this leaves signals in the code that come from the
collective experience of the neural network(s) that created said code.

Obfuscation works by adding noise, and performance overhead.

Now the real question on my mind is how much of what I see in bitcoin's
main.cpp is obfuscation by Satoshi, or is someone going to run this
analysis on code running at banks and figure out who he really is?

Twitter | LinkedIn | GitHub | TravisBiehn.com | Google Plus