.NET Obfuscation

Does anyone have any hands-on experience with using a .NET assembly obfuscation product, or just hacking MSIL using a hex editor? I'm interested in C# and VB.NET coding techniques that can help hide data in a compiled assembly without the need for using an obfuscater, or to help an obfuscater do a better job hiding the details of code and data. A common example is representing string data as integers so the string can't be obviously identified by using a hex editor on the assembly's compiled code.

I am interested if anyone else has been working on these types of problems in .NET using commercial tools or their own coding techniques.

Here's a nice tutorial on .NET obfuscation: http://www.howtoselectguides.com/dotnet/obfuscators/

Find more posts tagged with

Comments

bcairns

The biggest issue I have with reverse engineering in general is how easy it is !!!

(( a bit of a rant so the newer guys know what we are talking about ))

For example, you make an application that asks for a password or serial number - in your code you have this as a string

if UserInput = Password then unlock the application

That string gets dumped as a resource in your exe.... anyone can do a string **** of your resource and spot potential passwords and serials.

Other methods get a bit more indepth like creating code that takes a GUID and compairs it to a list of allowable GUIDs - like Microsoft Windows Serial number.

Those are just as easy to bypass as you can use a dissassembler and good debugger (like blackice) to make the ASM code jump right past the function that checks to see if there needs to be a serial number at all.

Now on to your question...

Of the products I have tried...the edition that comes with .net is pure crap.
It does not even encrypt the strings in the exe and has a predictible variable renaming pattern.

Check out this URL
http://www.xheo.com/products/enterprise/codeveil/comparison.aspx

XenoCode and CodeVeil are probably the best ones out there but they do leave markers in the code they modify which means an engineering cracker could figure out which application you used and begin toying with that.

The one thing that bugs me about .Net Java and other "script" languages is there is an abundance of decompilers on the internet.

I remember showing a friend how fast and easy it was to decompile his Java and VB apps - got everything back the way it was, (even his code comments in the Java app).

Obfunsicating makes it harder to read the code after it has been decompiled.

//Before
String myString = "hello";

//After
String sh12A = "hello";

//After with string encryption
String sh12A = "dhjasdjhkjsad=";

But as you can see...the code is harder to read but still readable.

One thought is to Obfunsicate and then use a good PE Shrinker like ASPack.

PE Shrinkers were popular before broadband came out.
They take your EXE and DLL files and compress them, in the process they are encoded and in some cases encrypted.

So after Obfunsicating and Shrinking an EXE, 99% of the time a decompiler will generate junk as it can't decode the code.

But nothing thus far stops a cracker from loading up blackice or windsm and making the ASM code branch past your security checks.

Thats when it becomes a mind game... make timers in memory and randomly check to see if the application has been purchased.

Thats why there is such a rise in startup registrations.... the application contacts a web service and the web service says if the application can run or not.

JDMurray

bcairns wrote:

That string gets dumped as a resource in your exe.... anyone can do a string **** of your resource and spot potential passwords and serials.

Yup. Unless you use special coding tricks to hide strings as other types of data, a simple hex editor will reveal passwords, file names, URIs, etc. Throw in a diff tool to show changes made to data and config files and you can pretty much expose the data in an insecure program. This is what I'm trying to avoid in .NET apps.

bcairns wrote:

Those are just as easy to bypass as you can use a dissassembler and good debugger (like blackice) to make the ASM code jump right past the function that checks to see if there needs to be a serial number at all.

There is no way to defend against this type of attack for apps that run on insecure operating systems (like Microsoft Windows) and don't use security hardware devices, like dongles and TPM. My hope is to prevent my apps from being hacked by all the other people who don't know how to use these types of tools.

bcairns wrote:

Of the products I have tried...the edition that comes with .net is pure crap. It does not even encrypt the strings in the exe and has a predictible variable renaming pattern.

Yes, that's Dotfuscator Lite Edition. I, too, was disappointed that it didn't obfuscate string data. If it had, I'm sure the encryption used would have been easy to break ("upgrade to our Pro edition for stronger string encryption!"

bcairns wrote:

XenoCode and CodeVeil are probably the best ones out there but they do leave markers in the code they modify which means an engineering cracker could figure out which application you used and begin toying with that.

Yes, I'm sure that professional .NET software crackers have a subscription to all commercial obfuscation tools, recognize their signatures, and carefully track the changes in each update. These guys are also the ones using SoftIce, so there's not a lot I can do to defend against them.

bcairns wrote:

Obfunsicating makes it harder to read the code after it has been decompiled.

One thing I'm interested in is an Obfuscator that doesn't break Reflection code. Obfuscators that change the app's code structure can also cause problems in certain .NET mechanisms, like Reflection. The solution is probably just to turn off the code obfuscation features until a patch fixing the problem is released.

bcairns wrote:

Thats why there is such a rise in startup registrations.... the application contacts a web service and the web service says if the application can run or not.

Yes, but unless the app itself requires Internet access to work, this can make the app a real pain for user without Internet access to use. Until wireless Internet coverage becomes common and inexpensive, I don't think that I'll go this route for normal app usage.

Thanks for your advice.