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.
