Obfuscating ASP.Net dll breaks web application.

Question

I wouldn't usually bother to obfuscate a web application DLL but right now I have to share some server space with someone who might have a conflict of interest and might be tempted to steal the deal and decompile it. Not an ideal solution I know but hey.

So I am using VS 2005, a web deployment project (which compiles into a single DLL) and Dotfuscator community edition. When I obfuscate the DLL the web application breaks and I get some message like

Could not load type 'Browse' from assembly MyAssembly

So I searched around and found that if I disable renaming then it should fix it. Which it does. But now when I look at the DLL using .Net reflector I can see everything again. So this seems kind of pointless.

Is there a way to get this to work? Is there a better way to protect my DLL from someone I have to share a server with?

UPDATE:

I figured out my problem. All the classnames have changed but now all my

<%@ Page Language="C#" AutoEventWireup="true" CodeFile="mycode.aspx.cs" Inherits="mycode" %>

is incorrect because mycode no longer exists. It is now aef or something. Is there any tool out there that will also change the names of the Codefile and Inherits tags?

Answer 1

You're close to the solution. In your situation I don't know in which context 'Browse' is used, but are you referencing it somewhere as a string?

There are some things which simply can't be obfuscated when you're using it in a certain way.

For example, when you have custom objects which is bound to a control. Those properties which you've specified as a displaymember of valuemember cannot be obfuscated. This is because the properties are defined as a string. So at designtime there's no connection between the control and the actual property, but at runtime there is. I don't know how to explain it better; but here's some code:

// custom object
Public Class MyObject
{
    string Test() { get; set; }
}

// here the object is bound to a combobox

MyCombo.ValueMember = "Test";  // The Test property cannot be obfuscated because of this 'indirect' reference.
MyCombo.DisplayMember = "Test";
MyCombo.DataSource = lstListOfMyObjects;

Hopefully it addresses your problem. If not, let me know.

Answer 2

I have never used the Dotfuscator community edition, but try to see if you can rename only the Private types, variables. That should make it more difficult to see. IMO most of the Obfuscators have issues, and when you find a bug they want you to send your code so they can fix the problem. I have found issues with most of commercial versions, but maybe they have gotten better in the last couple of years...

Answer 3

For asp.net I don't know of a quick way out. The quickest way I've found is Secure Team's code protection functionality. It leaves the interface but encrypts all the il and makes it hard for someone to reverse it.

Asp.net is tricky due to all the dynamic resolving and reflection used once you start changing the names of things it becomes fragile and in the need of a whole other round of testing to make sure everything loads and nothing breaks.

Answer 4

We needed something like that and tried bitHelmet. It provides predefined exclusions for certain objects which are known to be accessed by name by the framework, for instance Web.UI.Page Descendants. It works perfectly with web aplications.