Woah, Nellie.NET!

From my simple mind to… mine…

Lutz’s Reflector

with 4 comments

I had the need to reverse engineer a library so I could figure out where a constructor call was crashing. The problem was that I didn’t have the original source for this library.

Utilizing Lutz’s Reflector, I decompiled the library. Then I generated a C# project, included that project in my solution and directly stepped into the code with the Visual Studio debugger.

The simplicity of the whole thing was shocking and led me to think about what steps can be taken to prevent such reverse engineering. Is obfuscation enough? I don’t know. Let me know if you do.

The problem was a missing configuration section in my web.config. Wow…

Advertisements

Written by Nelson

February 23, 2007 at 5:00 am

Posted in .NET

4 Responses

Subscribe to comments with RSS.

  1. Using dotfuscator will make it secure. Including obfuscation in your continuous integration is easy also with the dotfuscator executable.

    Jason

    February 23, 2007 at 1:39 pm

  2. I guess it depends on whether you are using the intellectual property model or the service model. Very little of the code I write today is so advanced that it requires obfuscation. I look at my development as a service. And with the increase in OSS, this seems to be the trend of the industry – away from obfuscation and IP and more towards the service model.

    That said, tools like Reflector do allow you to decompile commercial software into source files (using FileDisassembler), take out the bits that cause it to expire, and recompile and use. Software for sale should definitely be obfuscated for that reason.

    chris

    February 23, 2007 at 3:12 pm

  3. While obfuscation has it’s place. I don’t really recommend it.

    The problem you run into is binary compatibility. Not like in the COM days but it is the easiest parallel I can find.

    Let’s say you have a project with 4 different assemblies and you obfuscate them all. When you deploy them everything will be fine. Now let’s update one of the assemblies and add a new class, build the project and run the same obfuscation routine on the one assembly. Easy enough let’s make a quick update and deploy it. Not that you would really do this without testing it of course. If you were to do this with any other project it would work because the JIT compiler with recompile the new assembly with the old ones. The problem occurs because of the obfuscation that ALL assemblies must be obfuscated together in order to get them to work.

    OK enough about that, the real question you should ask your self is what is defined as intellectual property? What are you protecting? Are you protecting your awesome code and a new pattern that saved your precious milliseconds off of a call? Are you protecting a new algorithm that is able to forecast the financial viability of a company’s stock 4 years from now? The latter questions probably warrants obfuscation because of the intellectual property rights that are surrounding the technology. While the former simply demonstrates an efficiency in ones code.

    An easy demonstration of this argument can be control libraries. Infragistic supplies source code with their controls? Why? I mean their whole business model and intellectual property is coupled with these controls. Why not simply obsfuscate them to protect their property? The answer is they could but it would cause all sorts of compatibility issues later on and why increase the support calls. Besides anyone can create controls it is just that Infragistics does a dam good job at it and if you run into problems you can call their support. Their code is no different then what you or I would do if we had to build it, they just concentrated on doing it well and making money off of it.

    I know this is rather lengthy comment but I hope I have given you greater incite on why and why not obfuscate.

    Joe

    February 23, 2007 at 5:17 pm

  4. Joe, you make an interesting point that I hadn’t considered, that being run-time compatability issues. However, if you only obfuscate the private (and maybe protected) implementation of your classes, while leaving the runtime signatures of your public interfaces legible, I believe that allows you to have your cake and eat it too. I do agree with you that obfuscation is usually ill-advised.

    chris

    February 23, 2007 at 10:40 pm


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: