On Thursday, 14 June 2018 at 08:54:16 UTC, Shachar Shemesh wrote:
> So, no, I was not kidding. Not even close.

I've had some experience on both sides of this... so, I think I can say with some certainty that debugging symbols make reverse-engineering MUCH easier (many hunts to find the relevant code can be reduced to a keyword search), so I think it's a valid concern.

That D leaks identifiers and other bits from the source code is a real issue preventing some real-world use cases. E.g., there might be legal obligations in place where leaking source code identifiers could be considered a breach of NDA etc. In one case, we needed to write an RTTI patcher for C++ (MSVC) after updating/reconfiguring the build toolchain, as the compiler would otherwise place the class names of some classes in the binary.

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.

On 06/14/2018 04:33 AM, DigitalDesigns wrote:

> 3 strikes and
> your out!

That was your third. :/

Ali