Hello world!

Today we continue the “Trolling the Decompiler” series (first part here: Prevent Reflector from Decompiling) but now with a more serious approach - this one should work on any decompiler.

The point is: it is rather difficult to make .NET programs run with a key or license; since these can be reverted back to their sourcecode, anyone can alter it or just learn to create fake keys that will be seen as valid.

## Possible Solution

One way to make an application a little bit more difficult to crack would be to deliver it as a program that decrypts instructions, compiles and runs them only when needed. This way, if someone finds out where the sourcecode is stored, it will still be encrypted and without a key (or license) it is unusable.

We’re kinda writing polymorphic stuff here - AVs won’t be happy; actually…only 2/57 don’t like it, we’re good.

## 1. Making the Compiler

We’re not really going to reinvent the wheel here - .NET seems to allow us to use the original compiler to produce an Assembly. Just as always, we start with a CodeDomProvider, add a bunch of settings using CompilerParameters and a few sourcecodes.

If you look around, there’s also an article that provides a little bit more detail about how to compile code at runtime using CSharpCodeProvider and ICodeCompiler which are now considered obsolete, but the code is similar.

## 2. Running the Compiled Assembly

What we’re interested in is result.CompiledAssembly - in order to run it we have to create an instance of the method that serves as entrypoint and then invoking it.

Short note: if the assembly that you’re trying to run belongs to a Console Application and this program has the same project type, you might need to call FreeConsole() and then AllocConsole(). Without recreating the Console there seems to be no output from the compiled assembly.

This is how we can run the compiled code:

## 3. Encrypting & Attaching Sourcecodes

This is one of the tough parts - we take the sourcecodes of the files that we want to secure and encrypt them (I use AES with Rijndael’s algorithm) then attach the results at the end of the executable that we’ve been working on at the previous steps.

Here, the content of the executable and each sourcecode are separated by a sequence of 3 FS (File Separator Character). It’s not the clean way to handle this…don’t use it in serious projects; but for this tutorial it should be fine.

FS = 28(dec) = 1C(hex);

The method that I use looks like this:

I’ll not add EncryptMessage()’s code here since it’s not related to the actual subject - you can find it below, in the complete sourcecode.

## 4. Extracting & Decrypting Sourcecodes

Procedure that runs before the whole compile & run thingy - we look for any sequence of 3 FS characters, skip the executable’s content, take the encrypted sourcecode and run it through the decryption method - the result is pure C# code that will be given to the compiler.

Remember to replace the "abcdabcdabc..." decryption key with what the user inputs in order to use the program (like a license) - line 31.

## Final Notes & Complete Sourcecode

Below you’ll find the sourcecode I ended up with while writing this article. It’s more like a fast way to explain an idea - it needs some “patching”.

In order to actually use it you should split this into 2 programs - one for encrypting and attaching and the other to do the decryption, compilation & execution. You send only the latter one to the user - so he won’t get the encryption key - this or switch to an asymmetric algorithm. Also don’t forget to remove the hardcoded decryption key and ask the user for his own.

## Proof of concept

Short video, before people start saying it’s not working!!!.