Introduction
Very recently, I was developing a School Management System, using ASP.NET and C#. The software was to be packaged into an installer (containing prerequisites like MSSQL Server Express Database Engine and the .NET Framework) that would deploy the software to client computers and configure IIS automatically after installation. I really had a hard time finding a product that could meet this need; but eventually, I did. So, I got the core of my application ready, had my installer-builder on ground, and mapped-out a plan to handle license-registrations via a WCF Service I would deploy to an external server, and then…boom!
It dawned on me - With the myriad of .NET Reflectors (programs that can decompile .NET code and browse the classes therein) out there, I knew I needed a way to disguise my source-code, if I hoped to prevent pirates from taking a peek at it. I was pressed for time and (don't laugh) I needed money fast, so, I really wanted a solution that was automated and didn't require me to write any code to achieve the feat - I had been coding-up my app for months, and didn't want to spend more time tweaking or writing more code to protect its Source Code.
I quickly came-up with a list of requirements for my tool of choice:
- My topmost requirement was that tool must be FREE - yes, FREE. I didn't have money to spend on any commercial product. So, I wanted FREE!
- Secondly, the tool must be extremely easy to use; offering me the most protection for my code within the shortest possible time - basically, within 5 minutes or less.
- Finally, if the tool was an open-source project, I wanted one that was being actively developed.
Armed with the above list, I set-out to query the search engines. And to my greatest delight, after an extensive search on the Net, I found the tools I was looking for.
Now, in this article, I'll be showing you how to use the tools I found to completely protect your .NET code and make it impossible for even tools like Red Gate's Reflector to understand a thing about your code. My discussion will be done within the context of an ASP.NET website, but you could apply the ideas I present here to your Windows Forms, WPF, or even your Silverlight Out-Of-Browser (OOB) application projects.
So, let's get started.
First Things First - The Tools I Found
I know you've been itching to get to this point. So, here are the tools I found and of course, the tools we’ll be using:
- ILSpy - ILSpy is a powerful, free, and actively-developed open-source project. It's a .NET Class Browser and decompiler. This is not the tool we'll be using to protect our code, but we'll be using it to decompile our compiled .NET code and then browse through the source, so as to give us a glimpse of how easily a Reverse Engineer or pirate can gain access to our source-code, when not protected. We'll use this tool, both before and after protecting our code, so you can see the difference between a protected and unprotected code.
You can download ILSpy from the following URL: http://ilspy.net
- ConfuserEx - Yep! ConfuserEx is the tool we'll be using to apply protection to our code. It's also a free and open-source project. The latest release for this project was done on the 1st of July, 2016. Although the developer of this tool just stated (a few days ago) that he won't be releasing newer versions of the product, he has also clearly stated the he's not completely abandoning the project. He might occassionally release fixes for the app, but won't be making any major changes. That said, the developer encourages others who are interested in taking the project further to do so. So, if you're feeling inclined, give it a shot!
Here's the download link for ConfuserEx, on github: https://github.com/yck1509/ConfuserEx/releases
Both ILSpy and ConfuserEx don’t need any install – that means they are portable applications. Just download their respective zip files, and extract to desired locations on your hard drive. Browse to the locations on your hard drive, where you extracted the files, and double-click the appropriate files to launch the programs.
For ILSpy, the file needed to launch the program is highlighted in the image below:
For ConfuserEx, the target-file is highlighted in the image below:
Beginning The Process
Creating And Publishing Our Website
Alright! Now that we’ve made-ready the tools we’ll need, it’s time to get our sample website ready for protection. Follow the steps outlined below:
STEP 1: Go ahead and create a new ASP.NET Website.
STEP 2: Add a label to your Default.aspx page, and give it the ID "mylabel".
STEP 3: In the Page_Load Method of your Default.aspx’s code-behind file, type-up the following code, in your programming language of choice - I've used C#.
mylable.Text="Welcome To Code-Disguise Camp, dude!";
This is just a demo app, so, we could get away with putting our code directly in the code-behind file of our web page. In a real-world app however, we would extract most of our code into separate classes in the same project or into a separate Class Library Project. We’ll then reference and use the library in our main website project - this makes for good application design, promotes code re-use, and also makes protection of our .NET code more straightforward.
STEP 4: Now, we’ll publish our website by right-clicking our website-project (in Solution Explorer, in Visual Studio. I’m assuming you’re also using Visual Studio, like me), and selecting “Publish Website”, from the context-menu.
STEP 5: From the “Publish Website” dialog that appears, select the option to create a “Custom” publish profile, on the right pane of the dialog. Enter any name for the profile.
See image below:
STEP 6: Move on to the “Connection” Tab, on the left pane of the “Publish Website” dialog, and select the “File System” option from the “Publish Method” Dropdown List - we’re choosing this option because we’ll be publishing our website to a directory/folder on our local computer.
Also, pick a location on your system, where you’d want your site published. You do so by clicking the button with an ellipsis, to the right of a text-box that shows-up, as soon as you choose the “File System” Publish Method.
Don’t give-up on me now. Be determined! Move-on to the next step.
STEP 7: Select the “Settings” Tab from the left pane of the “Publish Website” dialog. Expand the “File Publish Options” section to the right, and then, check the “Precompile during publishing” checkbox. Also, click the “Configure” link beside this option, to display the “Advanced Precompile Settings” dialog, as shown in the image below:
From the “Advanced Precompile Settings” dialog (shown below), choose the “Merge all pages and control outputs to a single assembly” option. Type-in any name of your choice (I typed the word “Trial”), to be used for the assembly to be created.
Note: If you don't select the option to merge all pages and control outputs to a single assembly, ASP.NET will compile the code in the code-behind files of all your pages, and produce separate assemblies for each of them. If you've put some sensitive code in those code-behind files (which shouldn't be), you'll need to go through the processes outlined in the code-protection section of this article, to protect each of those assemblies - depending on how many pages you have in your entire website, the experience may not be an interesting one!
Click the "OK" button
Alright! What we’ve done in this 7th step is to instruct ASP.NET to compile our website before publishing it to the location we’ve designated on our local computer. This step also creates a single assembly (.dll file) with the name we specified in the “Advanced Precompile Settings” dialog.
If we had some code in external classes (in addition to the code we wrote in the code-behind file), those classes would have been added (automatically by ASP.NET) to an “App_Code” folder, all of whose content would have also been compiled into a separate “App_Code.dll” assembly - normally, this assembly would have also been a target for protection.
STEP 8: Publish the website, by clicking the “Publish” button.
This final step publishes our website to the target directory.
Seeing Our Code Through The Eyes Of A Pirate
Okay, now we’ve published our site, and pre-compiled (in the process) to produce a locked-in form of our code – an Assembly. All is well and good; at least, until you discover how easy it is for a pirate to get to your source-code, using a nifty tool like ILSpy.
To get a feel of what I’m talking about, do the following:
- Fire-up ILSpy, and Select “Open” from the “File” menu.
- Navigate to the directory where we published our site, and double-click the name of the assembly we created during the publish-process, to open it.
- From the left pane, expand the topmost node for our assembly
- Also, expand an inner node to reveal the “_Default” class, as shown in the image below:
What do you see?
Our code, just lying there – bare!
...
So…o…, wha…what do we do now?
Simple – we go to war!
Confusing The Adversary With ConfuserEx
We’ll be using ConfuserEx to throw the enemy into confusion. Go ahead and fire-up ConfuserEx, then follow the steps below:
STEP 1: Click the plus sign to the right, and navigate to the assembly we created during our Publish Process. Double-click the file, to open it in ConfuserEx, as shown in the image below:
STEP 2: Click the “Settings” tab. On the “Modules” pane, select our assembly. On the right side, click the “+” button – this will add a new rule (“true”) in the “Rules” pane.
STEP 3: Click the “edit rule” button (that’s the button under the “-“ button, highlighted in the image above) to edit the rule we just added. This opens-up the "Edit rule" dialog:
ConfuserEx offers 5 different levels of protection, one of which can be selected (during code protection) from the “Preset” Dropdown List.
For our walk-through, we’ll be using the “Aggressive” Protection Level - so, go-on and select this from the “Preset” Dropdown List.
Below the “Preset” list, you’ll find the “Protection” pane. ConfuserEx offers up to 10 different types of protection for our code, which includes:
- Anti IL disassembly protection (anti ildasm)
- Anti Tamper Protection (anti tamper)
- Constants Protection (constants)
- Control Flow Protection (ctrl flow)
- Anti Dump Protection (anti dump)
- Anti Debug Protection (anti debug)
- Invalid Metadata Protection (invalid metadata)
- Reference Proxy Protection (ref proxy)
- Resources Protection (resources)
- Name Protection (rename)
We’ll be applying all 10 protections to our code, for maximum protection – remember, I told you we were going to war!
To add the first type of protection, click the “+” button (to the right) – this adds the "anti ildasm" protection.
Click the “+” button again, to add the second Protection Type; but this time, select the next protection-type from the Dropdown List.
Repeat the process to add all 10 protections. Your screen should look like the image below:
Click the “Done” button, and move-on to the next step.
In essence, the statement we’ve made to ConfuserEx (between adding the rule “true” and editing the rule to define our protection-level and protection-type) is this:
“Yes (true). Apply an “Aggressive” protection (with the 10 protection-types specified) to the assembly we just selected”.
STEP 4: Click the “Protect!” tab. To the right of this tab, click the “Protect!” button. If all goes well (and it should, if you followed me carefully to this point), your screen should look like this:
Viola!
Our code is fully protected.
The neat thing about ConfuserEx is that, it doesn’t tamper with your original assembly. It simply makes a copy of your assembly, protects that copy, and then saves it in a folder it labels “Confused” – you’ll find this folder in the “bin” directory/folder of your published website.
You can then use the resulting (Confused) assembly in place of the original one, in a production environment/server.
Just to show you how much ConfuserEx has done for us, follow the steps as before, and open your confused-assembly in ILSpy. Try to locate the “_Default” class again.
What do you see now?
MOUTH = OPEN!
That’s the power of ConfuserEx
Something You Should Know
I think it’s important to state (at this point) that ConfuserEx protects your Source Code by manipulating it, using different algorithms in the process. As a result, you might notice a slight performance-lag when you run your application after protection. In my opinion, the lag in performance is so negligible; I consider it as nothing, compared to the level of protection I get for my Source Code.
Conclusion
Like I said earlier, you could use these tools to protect .NET code you write with other .NET APIs, like Win Forms, WPF, and Silverlight. To make protection with these technologies much more straightforward, you should push your business-logic away from the code-behind files of your application, and into (preferably) a separate Class Library Project, which you can constantly modify, build, and reference in your main project. When you’re done with development, you could then protect your library, before packaging your entire application into an installer.
So, there you have it...complete protection for your .NET Code – nice and easy!
Oh…and just in case you’re wondering what tool (I was speaking about at the beginning of this article) that helped me package my asp.net app into an installer, with MSSQL Server Express Database Engine and .NET Framework as prerequisites, while installing and configuring IIS automatically on the end-user’s computer – the tool is called “Advanced Installer”.
And, guess what – if you are a Microsoft MVP or a Microsoft Certified Trainer (MCT), or maybe you’re just working on an open-source project, you can get a free copy of Advanced Installer from the following URL: http://www.advancedinstaller.com/free-license.html
Well, what can I say now? Happy Code Protection!
