Remotesoft Protector Runtime Error – yet to handle multiple .NET framework runtime

One other symptom of this was that .exe files would just blow chunks.  I’ve finally figured out what was causing this!  Most of our products are protected during the nightly builds.  This error however is specific to assemblies protected using the the Remotesoft .NET Explorer UI.  When using this application for the protect or obfuscate functionality it is really just a front end around the protector.exe/obfuscator.exe.  The UI is building the following command line string and tonight it finally dawned on me:

Command: C:\Program Files (x86)\Remotesoft\Protector\bin\protector.exe -neutral -resource -string -cctor -clrversion v2.0.50727 "C:\temp\SmartInk for Kahua\SmartInk.UI.exe"

The UI was forcing the clr version to .NET 2.0 – when my assemblies are all built against .NET 4.0.  Oops…

After a bit of digging I found that you can set the CLR version in .NET Explorer from the Action / CLR Version menu item.  Unfortunately it has not been updated to support .NET 4.0 – and so has been rendered pretty much useless as a front end for protector.

The Fix

The only solution is to use the command line to execute your protection.   The updated command line ended up looking pretty similar:

"C:\Program Files (x86)\Remotesoft\Protector\bin\protector.exe" -neutral -resource -string  -clrversion v4.0.30319 "C:\temp\SmartInk for Kahua\SmartInk.UI.exe"

There you have it – I can’t believe I missed that…

Obfuscation was one of my first answers to this problem.  An obfuscator ships with Visual Studio Pro, free and there are many available on the market.  Obfuscation just didn’t do it for me.  I once helped a customer troubleshoot problems with one of their software solutions from an unnamed vendor using Reflector and walking through the obfuscated code.  This was really a painful experience, it does make it harder to figure out what is going on – but a friend of mine suggested a product that takes code protection one step further.

Hello Remotesoft Protector.  This product is pretty cool.  If you purchase the protector product you will receive three components.  Salamander .NET Decompiler, .NET Obfuscator, and .NET Protector.  Initially I was processing my assemblies with both the obfuscator and the protector.   Now a days, I pretty much only run my assemblies through the protector.

Once you’ve processed an assembly with the protector and you open it up in reflector things are going to look a little different.  Here is a little before and after action for you:

Now lets take a look at the same code, but after being protected:

That’s it.  Protector has made all your code go bye bye =)  What’s happened here?  As I understand it, Protector compiles all your managed .NET code into native code.  So, yes, is it possible to disassemble native binaries.  The difference here is the height of the bar – with plain .NET assemblies even my grand mother could get my code.  Reverse engineering a native assembly is a different story.  If someone with the skill to do that wants your code – well you must be writing some damn fine code.  It would probably be easier for that kind of person to write it from scratch =)

I’ve been working on increasing my Joel Test score lately.  One of my biggies is the one step build for RADE.  That sentence really doesn’t do the task justice.  The first step I’m tackling in the one step build is automating the process of protecting my .NET assemblies.  I could not find any resources on doing with with MSBuild.  Once I get it working, I’ll post some code.

All that said, I highly recommend you check out Protector if code protection is your thing.  The price is a little bit steep at 1899$ for 1-5 developers – but how much money have you invested in that one little DLL or EXE file?