Free Obfuscation .NET

[neowin_hipster]

Any mono, or free / open source obfuscation technologies exist? On windows all i have is sharpdevelop + free framework and also mono + monodevelop on *nix.

[smurfiness]

You'd probably have better luck writing one yourself. Although that's no trivial task, neither is finding a free (and good) .NET obfuscator. The quality of obfuscation programs generally is not so great, and the only truly free one (lots of companies shout "FREE!" and then tell you that that actually meant free-as-in-evaulation) that I've been able to find (Aspose) has enough bugs in it that I would not trust it to obfuscate assemblies I want actual people to use.

As for open source, I've seen one. It was an example in a book about obfuscation called Desaware QND Obfuscator (distributed under MPL 1.1). The last time I tried it, it was VERY limited and didn't do a terribly good job of obfuscation -- it only obfuscates private code and it doesn't do a great job on even that. But both of those things can be changed without really adding any code (except for mapping code if your project spans multiple assemblies), and the result is about the equal of anything you'll find for free (http://www.desaware.com).

[Farstrider]

I do not know to much about this, but have you tried RetroGuard and JODE Modules for Sun ONE Studio Mobile Edition

I do not know if this is what you are looking for but go to Sun's webpage. Perhaps this will help you!

And a small article that may also help!

Code Protection ? Prevent Assembly Decompilation.b>

Description:There are a couple of options to prevent the user from reverse-engineering your assembly. Let us discuss the following techniques.

1. Native Image generation

2. Strong-naming the assembly

3. Hiding the Implementation via a web service

4. Obfuscation.

Native Image Generationb>

One technique you may try is to create a native image of your assembly. This is done via the ngen tool that comes with .NET. This tool doesn't work with CIL source files; rather, it takes a .NET assembly and transforms it into a native assembly. For example, you can create a native image of AI.dll as follows:

ngen AI.dll

The tool creates a native image of the assembly, but it puts the result into the Native Image Cache (NIC). You can see what's in the cache by using the /show argument of ngen:

ngen /show

Unfortunately, the results aren't what you might expect. The problem is that you still need the original assembly for the client code to run properly. ngen essentially creates implementations of your methods, but the metadata is contained in the original assembly. If you try to run an assembly that uses AI.dll after you employed ngen on it and deleted (or renamed) the source AI.dll, the client will throw a FileNotFoundException.

The runtime will always load the CIL-based assembly, but it's smart enough to use the native implementations if they exist in the NIC. Therefore, you can't distribute a native image without the regular assembly. Someone will always be able to reengineer the code like I did before, and if you rename the resulting assembly and target the client to use this new assembly, you can prevent the runtime from using the native implementations.Strong-Naming the assemblyb>

The best you can do with strong-naming your assembly is that you can prevent others from reverse-engineering your code and putting your brand on it. It doesn't prevent others from at least being able to see the underlying code.Hiding the Implementation as Web Servicesb>

If your clients have high-speed Internet access, another option available is to make them Web services. Clients can access the assembly's functionality, but they can't get the physical assembly itself. Also, if a bug did occur in your assembly, fixing the offending code means that all clients get the fix at one time.

Of course, there may be situations where this is not feasible. For example, if you were writing a high-performance graphics engine to compete with DirectX, you probably don't want the method invocations to occur over HTTP. However, if you know that you must protect your resources, then keeping them off the client's machine may the safest way to do so.Obfuscationb>

This is basically a technique in which a tool will take input, like source code or a PE file, and create output that makes it very difficult for reverse-engineering tools to discover what the executable is doing. However, it will not change the expected behavior of the code, and it may make loading times quicker.

Out of all the options available, this one covers all of the bases, and I think it's the best measure you can take to protecting your investment. Remember, though, that obfuscation is not a guarantee. Someone with enough perseverance may figure out ways to get around an obfuscator in the future.