I was considering adding obfuscation to a major project I was about to publish when I was offered the chance to review Crypto Obfuscator for .Net. I’ve used .Net Reactor in the past, but it had been a lot of work to integrate into an automated build and certain features simply hadn’t worked in some situations. Before I opened my wallet for another year’s subscription, I wanted to look around.

First, let me state that I’m not an expert in the current state of all obfuscators. I went through a few several years ago when I first required one for a project. There are a surprising number out there and they all have the same basic features: symbol renaming, some protection against decompilers, string / constant / resource encryption, and often integration with some sort of separate licensing product.

Secondly, my experience with obfuscation is mainly in producing an obfuscated application install, not just a library or a naked exe. As such, it’s very important to me to be able to seamlessly integrate it into the build process as well as have a relatively easy way to tinker with the settings.

VS Project Integration Wizard

This tool is a great usability feature. It will create a new obfuscation project for your solution file. You can select which projects to obfuscate and which build configurations. It then inserts MS Build tasks into your project files to execute the newly-created obfuscation project during build.

Last page of project integrator wizard.

Build tasks added to library.

Build tasks added to main exe.

I’ll confess I had some issues up front. My project configurations/platforms don’t always match the solution configuration and CO couldn’t process that. I had to modify my build configuration to get it to work, but I should have had a specific configuration just for obfuscation. I’ve found that makes debugging release binaries much easier.

Also, when selecting only two of the projects for obfuscation, it had a hard time finding the other projects and my NuGet packages when searching for dependencies. I ended up having to manually add my packages root folder and the obj folder for each of the project outputs.

But the build tasks that were inserted work perfectly and you can even see its output in the Build Output window.

Symbol Renaming

I was quite pleased with the “Fake But Believable” option that CO provides in addition to the common modes of unprintable, cryptographic, and the normal A, B, C, etc. style. For me, this form of renaming adds much more confusion to trying to read disassembled code and is a killer feature when used alongside the method encryption.

Though very effective, I did notice one internal method that wasn’t renamed as it should have been. Not sure why, but not a big issue for me.

Generated names look real and are nice and confusing.

Found a number of internal members that aren’t renamed. Why not?

Method Encryption

The other great feature is the method encryption where the IL code is actually encrypted and a single call to the decryptor / executor replaces your entire method body. I thought this was one of the most effective features.

I was a bit worried about its effect on performance, but because I was able to target only those portions of my assembly that are sensitive, I really didn’t notice any difference.

Conclusion

For the competition, .Net Reactor has a very low price but also difficult to integrate. Dotfuscator, of which a free (and useless) edition ships with Visual Studio, is very easy to use but also in the thousands of dollars. CO falls in between these two. You get good build integration, features that are relatively easy to use, and the price range is still reasonable for an individual developer.

Even with a couple of issues, I will use it as my obfuscation platform of choice going forward and would certainly recommend this to others.