UPDATE: I no longer recommend using Confusor (or any other obsfucator tool) after I have discovered that many anti-virus programs detect obsfucated assemblies as false-positives. If that is a deal-breaker for you (as it is for me) then it seems there is no good way to secure (ok, make it slightly more difficult to reverse engineer) a .Net app. Which sucks.
Recently I had to obsfucate a .Net (C# WPF) project that was a license generator, and after researching it seems that the best free tool to use for this is Confuser. It comes in both a GUI and console version, so you can try it, and then integrate it as a post-build step if you’re happy. And I was. IlSpy showed pretty much everything was replaced with foreign / non-printable characters. FYI the console version (Confusor.console.exe) takes a crproj file, which you is created by first running the GUI app and then pressing save on that tool. Then it’s a simple matter of adding a post-build step to call the console version passing the path to the crproj file and you will have your obsfucated assembly created in a subfolder called ‘Confused’.
- The generated CRPROJ file contains absolute paths, which of course need to be replaced (manually) with relative paths. Remember that the current directory will be the build output directory. My CRPROJ file looks like this:
<?xml version="1.0" encoding="utf-8"?> <project outputDir=".\Confused" snKey="" preset="normal" xmlns="http://confuser.codeplex.com"> <assembly path=".\LicenceGenerator.exe" isMain="true" /> </project>
- The generated CRPROJ file contains the path to the executable to obsfucate, which usually includes a debug / release identifier. To fix this issue, you can simply conditionally call the post-build step by doing this:
if $(ConfigurationName) == Release $(SolutionDir)Confuser\Confuser.Console.exe $(SolutionDir)$(SolutionName).Confusor.crproj
Note that this post build step needs to be all on one line in your project properties field in Visual Studio.
Happy with that!