D code obfuscator

[Cym13]

On Thursday, 14 June 2018 at 10:39:19 UTC, DigitalDesigns wrote:
> Wait? Are you sure you are not kidding? Do you want another 
> shot?

I won't say that obfuscation is entirely useless, if I have to 
choose I'll of course take the version with symbols for reverse 
engineering and there are specific cases where symbols carry way 
to much information for you to want it disclosed (most common 
being names of customers or projects etc).

But, as someone whose job is to find security issues with 
softwares
  (and other stuff) be it with or without source, I can say with 
professionnal certainty that things like changing all identifiers 
to single-letter ids don't slow me the slightest in my 
assignments. That's just the state of things, reversers deal with 
stripped stuff all the time, identifiers are just nice to have.

So instead, here's what would slow a reverse engineer:

- Remove strings. Make sure to remove as many as you can, 
especially debug statements. Hide the rest by encrypting in 
memory. Even if it is possible to decrypt it or read it at 
runtime it'll be way harder to correlate things together.

- Pack. Have your software decipher itself in memory at runtime, 
not all at once but only sections at once dynamically. Use random 
keys automatically generated at compile-time for that, that'll 
mess up binary diffs.

- Include binary tricks to mess up with disassemblers. There are 
many constructs that common disassemblers interpret badly.

- Mess with the structure. If you can remove all conditions and 
loops. A reverser can often just look at a function's logical 
graph and know what kind of work it is doing. The movfuscator is 
a good example.

- Add runtime checks based on time deltas between two points of 
the code in different functions. Generate other output based on 
that.

- Be sure to encrypt all communications of course.

In short, do what good malwares do.