Code Protection

[Pete OHanlon]

Sorry - I should have clarified that I meant that a good test of ANY obfuscator is to try it in reflector.

Deja View - the feeling that you've seen this post before.

My blog | My articles

[Ravi Bhavnani]

Gotcha. OT: How are you? :) /ravi

My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com

[Jim Crafton]

Good! :)

¡El diablo está en mis pantalones! ¡Mire, mire! Real Mentats use only 100% pure, unfooled around with Sapho Juice(tm)! SELECT * FROM User WHERE Clue > 0 0 rows returned Save an Orange - Use the VCF! VCF Blog

[Giorgi Dalakishvili]

From my own experience Xenocode is better then Spices.Net I've seen some assemblies obfuscated with xenocode that couldn't be decompiled by .Net Reflector. It just said 'item obfuscated' instead of the code. (Not all of the code but some parts.)

Giorgi Dalakishvili #region signature my articles #endregion

[Michael Sync]

Jörgen Sigvardsson wrote:

Obfuscation is truly a waste of money.

Yes. I agree with you.. I'm not sure why ppl want to use those kinda "Code protection" program. I think it will make your program slow. .

Thanks and Regards, Michael Sync ( Blog: http://michaelsync.net)

[my4color]

.Net Reactor (Obfucation + code protection) Also provides Licensing.

[aptbid2002]

I've been happy with .Net Reactor. It's cheaper than most out there $179 per license or $279 for company. I've used it for the past six months and so far I've been happy with it. It has a NecroBit protection level which is propriatary to this software. I've tried all the de-obfuscators on my assemblies and none have been able to crack them. Check it out at http://www.eziriz.com/

[Vic D]

There are two ways to protect .NET code; obfuscation (string encryption, variable naming code flow) and code protection (prevents decompilers, code encryption, anti-debug stuff, and anti-tampering). This discussion thread seem to morph the two approaches. So I have attempted to compare the varous products mentioned in the threads (below). But first this is how I would define the two classes of protectors Code Protection - Products that employ anti-reverse engineering technology into the code and protect the code at runtime - Can include anti-decompiling capabilities, code encryption, anti-debug, anti-tamper, and runtime exection protection Code Obfuscators - Products that remove context from the code by obfuscating the IL. - Includes string encryption, changing code flow, variable renaming - Some may include anti-decompiler technology, but without protection of the code in memory its has little value Here is how would groups the different products mentioned Code Protection V.i. Labs CodeArmor - Encrypts IL code at assembly level and protects the decryption operation with a driver based technology. Continiously monitors for anti-debugging and other reverse engineer tools to deter analyzing the code in memory. The .NET binaries will appear as native unmanged code on disk. Microsoft SLPS - Tranforms and encrypts code into a per vendor proprietary format and implements a separate VM CLR to compile code. Can protect at method level, but have severe performance issues because of VM CLR component. XHEO CodeVeil - Encrypts IL code, has some obfuscation, some anti-debug, but code is accessible in memory and more exposed to dumpers. Salamander Protector - Not an available product, but can test by giving them code. I believe they encrypt the IL code and provide a library that hooks the CLR to decrypt JIT and limited exposure in memory. However, I do not believe that monitor the runtime environment for tools and protect against their stuff being hooked. Traditional Code Obfuscation Note: Should be able to combine obfuscation with some of the products above for really strong protection. Spices.NET Obfuscation .NET Reactor PreEmptive DotObfuscator

[Vic D]

NecroBit just sounds like they are wrapping as an unmanaged binary. So on disk it looks like unmanaged code and decompilers will fail, but when running the IL code is still exposed in memory. The way to test this is using .NET generic unpackerhttp://www.ntcore.com/utilities.php[^] This tool will produce unprotected code while app is running if no other countermeasures are deployed

[aptbid2002]

You're right however, I just tried it on one of my programs that is protected by .Net Reactor and I can see my form names as well as controls that I placed on the form. The problem comes when I try to view the code in my routines. .Net Reflector blows up and won't let me see anything, it just displays an error message. Now while this makes me feel better, I still don't like the fact that I can view my form names. It should be protected all the time and I will email .Net Reactor about this and see if they have a solution. Thanks for your input.

[Pero Matic]

I have personal experience with PreEmptive Solutions DotFuscator. With a price tag of around $2,000, it costs more than many of its competitors, however, it is top of the line when it comes to obfuscation. There are many advantages to obfuscation from a performance standpoint, the main one being that with obfuscation renaming you usually get a smaller file size and functions are addressed faster by the runtime due to smaller method names. Of course if you use string encryption/decryption, it may balance out the performance gain. Most professional obfuscation software will integrate into the Visual Studio build process so that you never have to leave the IDE (unless you want to). Obfuscation will prevent the large majority from attempting to tamper/reverse-engineer your code. It is not a fool-proof way of stopping it though. My opinion is that as long as you sell more of your product than the cost of obfuscation software, then it's worth the cost. It will stop the majority of those attempting to invade your code.

- Pero Matic -