Using .NET Reflector to read .NET Assemblies
By David Connell, January 27th, 2012
(or, "How to Check if Production Code is Obfuscated" - with a little help from Dom Smith, Jason Crease, Clive Tong, and Chris Massey)
David Connell, back again, and still a software developer at Red Gate. Here at Red Gate we are careful to obfuscate released software in order to help protect our intellectual property, and the obfuscation is performed by one of our other products, SmartAssembly, which should be run by our build system automatically. If you recall, I’ve been looking at a way to use .NET Reflector to automatically check whether our products are obfuscated, and I’ve made the full source code for the solution available at the bottom of this post.
To recap, a while ago, one of our testers, Robin Hellen, said that he wanted his automated tests to check that files were definitely being obfuscated. I quickly realised that I could use the .NET Reflector API to solve this challenge (Having already had some experience with it).
The easist way for me to solve this was to produce a WinForms application that:
- scans a folder looking for assemblies
- loads the assemblies
- displays whether or not the assemblies are obfuscated
- attempts to work out which features of SmartAssembly were used when the assemblies were built
Before I go on too much further I must explain that here at Red Gate we typically split our desktop applications into 2 tiers. A UI front end and a back end that actually does the work. The back end is typically called the engine as it caries out the actual work. This “Engine” has no UI and can normally be at least easily Integration tested, if not Unit tested.
However, in this case, because the engine is interfacing with .NET Reflector it has to have some UI components. This is because the fact that Reflector is a Windows application is currently hardwired into the code, and the usual pattern of separation isn’t there, and so the engine really wants to be able to create windows. Thankfully, it can be fairly easily used by Robin for his automated testing, where the UI front end can display the information that the engine produces.
At this stage, I must also thank Jason Crease (tester on SmartAssembly) and Ryan Haney (UX designer on .NET Reflector) for their assistance with the final steps in getting this tool working.
Creating the application was mainly a process of using the Microsoft Visual Studio debugger, Intellisense, and JetBrains Resharper to find the methods in the Reflector API that were useful for achieving the application’s aims.
The back end/engine code for this tool was pretty much covered in my previous blog post, so it’s worth taking a look at that to refresh your memory. Since then, I have made some minor changes to the backend, mainly to clean up the API and remove any idiosyncrasies. In addition, having teamed up with the previously mentioned Jason & Ryan, we came up with a quick and clean UI for the tool:
You can filter by company and sort by single column, and users can also double-click a given line to get more details about the application and how it’s obfuscated.
All this functionality is wrapped up in the Engine code and, as I mentioned, the UI is a simple visualization over the top. This is another way of saying that the menu items at the top of the tool window are not currently wired up to anything – they came with the stock UI. I may get around to cleaning them up at a later stage.
On a somewhat related note, SmartAssembly has recently rolled-out a new type of obfuscation called "Method Parent Obfuscation", and I have not yet investigated supporting this – I can certainly take a look if there’s a need. My currently implementation is not extensible, but I’d like to refactor it at a later date to improve the base code.
Anyway, please play with the code, change it to your needs, and most of all have fun programming and using the.NET Reflector API.