Reverse Engineering Tools are Awesome—Except When You Don’t Want Them To Be

Earlier this month, I came across Scott Hanselman’s excellent blog post, What’s better than ILDasm? ILSpy and dnSpy are tools to Decompile .NET Code, where he shared his insights on the strengths and limitations of a laundry list of reverse engineering and debugging tools. In the following comments, someone had asked for an obfuscation recommendation for when a developer wants to protect their code against reverse-engineering (a reasonable question to be sure).

Unfortunately, comments had been disabled by that point, so I emailed Scott, mapping Dotfuscator’s anti-reverse-engineering/tamper/debugging capabilities to the collection of developer tools he had covered. 

It seemed like an excellent opportunity—not to self-promote our work (which we are very proud of) but to call out one of our most labor-intensive aspects: tracking and responding to real-world app-monitoring/tampering developments. 

In the same way that antivirus software vendors update their products in response to shifting real-world threats, we always update our “in-app protection” and code obfuscation tools to counter evolving reverse-engineering, debugging, and monitoring tool capabilities. 

…and soon after, Scott made an excellent suggestion: that we turn those notes into a generally available blog. Thanks, Scott! 

This is a snapshot! 

By the time you read this, we will have already released another version of Dotfuscator, so the table below may well be outdated. We have another comparable table for PreEmptive Protection / Obfuscation for Android and Java (DashO) and, coming soon, PreEmptive Protection / Obfuscation for JavaScript. 

Regardless, there are a few points that persist across versions and product lines: 

• If you are evaluating in-app protection tools (obfuscation, encryption and root, debug, tamper detection, etc.), satisfy yourself that the vendor regularly publishes updates (would you run a 2-year-old version of your anti-virus software?). 
• If you HAVE our tools (or a competitor’s), keep your software up-to-date! (same reason)
• Don’t lose sight of WHY you’re securing your code – this is also a key requirement driver.

Use cases for “in-app protection” are multiplying, and so are requirements. Are you trying to protect Intellectual Property? (a traditional use case) Or do you need to meet a PCI Compliance requirement to secure the data flowing through a Xamarin.Android app (or any of a dozen other data privacy/security requirements)? Are there audit requirements? Incident detection and/or response requirements?

Thanks to Azure, business logic and sensitive data are migrating from the desktop to the relative safety of the cloud. However, Xamarin, .NET Core, and (soon) client-side Blazor each push code and data in the opposite direction—onto unknown devices and often beyond any kind of trusted control. 

Developers increasingly have to translate abstract directives like “security by design and by default” into concrete controls and processes. 

With all of this in mind, here’s a table based on the tools referenced in Scott’s post. I would encourage every organization to validate its own tool list. 

The following snapshot table shows to what extent these development tools can (and mostly cannot) overcome (in this case) Dotfuscator’s obfuscation, encryption, hardening, and shielding transforms.

Impressive? We think so, but don’t take out word for it. You can always evaluate the latest version of any of our products HERE.