I met with Gabriel Torok and Sebastian Holst of PreEmptive Solutions, the other day. PreEmptive makes obfuscator products, including the Dotfuscator that comes with Visual Studio. Gabriel founded PreEmptive more than 10 years ago, and it was originally a code optimization company (The dual focus on performance and security resonates with me).
I was familiar with obfuscation and its limitations. I wasn’t as familiar with some of the internals of specific obfuscation techniques, such as identifier renaming, control flow obfuscation, metadata removal, and string encryption, or how you can tweak or tune these. One surprise for me was that obfuscation for some scenarios could yield a 30-40% reduction in size (the result of shortening identifier names and “pruning” libraries that are never called.)
Gabriel’s interested in creating obfuscation guidance for the community. I gave him my wish list:
- Scenarios. Illustrate how obfuscation fits in, including high level, when to use or not to use, as well as lower-level choices among obfuscation techniques.
- Anatomy of obfuscation. From a developer mindset, this means knowing how things work. Walk me through the bits and pieces and the execution flow.
- Impact and surprises. If I introduce obfuscation, tell me things I might run into. For example, is there impact to my build process? What about servicing my codebase? Is there a difference between obfuscationg with ASP.NET using dynamic compilation vs. pre-compilation? What if you need to GAC? What if you sign your code with a 509 cert?
- Performance considerations. Take me through trade-offs and scenarios where performance can be improved or degraded. Give me insight into how to influence or tweak my obfuscation approach.
Sebastion and I exchanged some metaphors. In reference to the limits of obfuscation, I said that just because door-locks don’t prevent car thieves, that doesn’t mean cars should come without locks. Sebastion related it to smoke alarms. In the grand schema of things, smoke alarms play a key role in saving lives and limiting damage, but to the individual, there’s not a lot of value until a fire occurs. The fact that smoke alarms are low cost and simple helps justify their common use. He added, risk varies by context, so the value to hotels or restaurants may be more obvious.
It was an interesting and insightful meeting and I look forward to Gabriel’s whitepaper.