protecting .NET code against decompilation

[VIeditorlover]

Hi everybody,

I'd like to ask you if there are some ways how to protect .NET exe and dlls against decompilation. I am not interested in any form of obfuscation, only methods based on (or equivalent to) compiling traditional compilers to machine language. There doesn't matter if commercial or open source, portability is not an issue - the only goal is strong protection.

Thank you for any reasonable tips.

Regards,

VIeditorlover

[sknake]

Sign your assemblies and don't distribute your application. The .NET assemblies are in MSIL so they can always be decompiled.

[VIeditorlover]

Well, I am looking forward to some tool which woukld work like NGEN.exe and convert managed s..t into true machine code ???

[Narue]

>the only goal is strong protection.
Why does your code need to be protected? Usually when someone asks for this, they're under the false impression that not being able to (easily) reverse engineer the code somehow makes the application more secure.

[ddanbe]

Way back in the previous century there was a saying that code that was TOP SECRET so that nobody could view it, was mostly code that was so badly written that it was a shame to show it to other people...

[kplcjl]

There has never EVER been a way to stop decompiling code. (You can ALWAYS get the assembler code.)
Strong naming or using Authenticode on a strong named assembly WON'T protect you from someone decompiling your code. The only thing both will do is authenticate your modified stolen code didn't come from you. All you need is someone who cares enough to verify this. (Good luck on that!)
Sorry, Scott, if you don't distribute your software, you don't need to strong name it. (There are other very good reasons why you would want to do so.)
I can think of two ways to not distribute your software. Web Service, or ASP.Net. (or it's cgi equivalent.)
PS I loved the last few comments.

[kplcjl]

Well, I am looking forward to some tool which woukld work like NGEN.exe and convert managed s..t into true machine code ???

As I said before you still haven't stopped anyone from decompiling your code.
My nephew has written an assembler routine that turbo-charges C# code. I don't know how it works and I haven't talked to him directly about it. I assumed that it converts C# into assembler and bypasses the overhead involved in running the MSIL code.

[__avd]

>how to protect .NET exe and dlls against decompilation?.
Some kind of decompilation will always be possible using reflection and similar tools. (Consider, if it were impossible, the processor/runtime couldn't understand it either.)

>portability is not an issue - the only goal is strong protection.
Try to precompile assemblies into native code as a part of the installation process.

Take a look at software protection tool - http://www.arxan.com/software-protection-products/microsoft-NET-GuardIt/index.php

[ghimangi]

Some protection is better than no protection. Obfuscation of .Net code is a very good obstacle which a hacker will need to overcome. Some obfuscators such as Crypto Obfuscator ( http://www.ssware.com/cryptoobfuscator/obfuscator-net.htm ) use multiple levels of protection like symbol renaming, string encryption, control flow, resource protection/encryption, etc which confer reasonable protection to your app.

[NetDeveloper]

You can try ILProtector
ILProtector protects your .NET code against reverse engineering, decompiling and modifying. ILProtector transforms Intermediate Language (MSIL) code into a Virtual Machine ("VM") specific form that is not recognized by disassemblers and decompilers such as IL DASM or .NET Reflector.

[jbennet]

Just obsfucate. Dotsfucator comes free with VS pro.

[skatamatic]

The only way to prevent someone from reverse engineering your code is to not give them your program.

This might sound like an oxymoron, but it really isn't. Think about client/server apps - the client only knows its inputs and outputs and not how the inputs got transformed into the outputs. That part is the server's job, and the client has no access to that process. Using this architecture also allows for the added benefit of generating server subscription revenue AND initial license revenue.

But if this won't work for you then you may need to look into embedded systems. Writing your code to hardware (FPGA or otherwise) makes it much more difficult for someone to reverse engineer it (albeit not impossible). It wouldn't suprise me if there exists a device out there that will flash-clear an FPGA when a tamper is detected :P (enclose the fpga in a case with a battery, if the case reed switch is opened the battery fries the chip). But that's probably getting a bit rediculous for your application.

If none of that will work for you, obfuscation and finger crossing are your best bet.

[thines01]

Making it web-only also creates some distance between the user/hacker and the source code.