Vista - Given a C#.NET assembly, what information can you get?

I'm developing a proprietary system in C#.NET. The assembly is in a
folder accessible by outside people.

Since it's critical that others don't know what it's about and how
it's implemented, I want to know what information anyone can get by
examining the assembly.

On Jul 28, 12:21 pm, Curious <fir5tsi...@xxxxxx> wrote:Download a program called Reflector and then open your assembly with
it and you will see what can be gleaned from your assembly.

http://www.aisto.com/roeder/dotnet/

Chris

> I'm developing a proprietary system in C#.NET. The assembly is in aIf you just compile the source code into an assembly and do nothing else
any reasonably competent user can reverse engineer it to functionaly equivalent
source code with just a freeware program and a few mouse clicks.

See: .NET Reflector at http://www.aisto.com/roeder/dotnet/

For a quick lesson (10 minutes) on how easy it is to get the source code
of .NET assemblies see: http://www.dimecasts.net/Casts/CastDetails/28

If you are serious about protecting your code there are a number of options
available, do a search on "obfuscation" for a number of resources on the
ways to protect managed code assemblies from decompilation. Also Microsoft
(and some other companies) provide the possiblity to make it even more difficult
to decompile managed code, see: http://www.microsoft.com/slps/ for information
on Microsoft's offering.

Disclaimer: The company I work for (PreEmptive Solutions) makes a product
(Dotfuscator) to raise the bar on the ease of reverese engineering .NET assemblies.
We include a community version of our product in Visual Studio 2003 and
higher that provides basic renaming functionality and our Professional version
provides many more features, in addition to integration with SLPS.

Hi Chris,

Thanks for the advice! I downloaded this tool and was able to see all
of the names of the methods and classes in the assembly.

On the download web page, it said:

Reflector is the class browser, explorer, analyzer and documentation
viewer for .NET. Reflector allows to easily view, navigate, search,
decompile and analyze .NET assemblies in C#, Visual Basic and IL.

What does "decompile" mean? Does it reverse the assembly back to the
source code in C#.NET? Do you believe that Reflector can go that far?

Hi Joe,
How can I reverse it back to source code with Reflector?
I took a look at the web page, but couldn't find the lesson. Could you
further advise?

in reflector - right click on the assembly , select export
it will export code, resources and even create a project file with assembly
info etc

it is not 100% but its a big step in that direction


"Curious" <fir5tsight@xxxxxx> wrote in message
news:e7a86f1a-ac2e-4a12-be24-1cd21c52d7ce@xxxxxx

Joe Kuemerle wrote:If you're serious about protecting your code, don't provide the object
code to your adversaries!

Against an adversary who can run your code in a debugger, I'm yet to see
an obfuscator that is worth bothering with the debugging pain.

Alun Harford

Hi Joe,

Thanks for the recommendation of the Microsoft SLPS! I'll give them a
call.

I never intended to provide my .dll to anyone. But I'm put in this
client-server type of environment where I am a client. Although
my .dll file is on my location machine, when I run it against a server
that belongs to another company and located remotely in their office,
I believe that they are able to see my .dll.

One more question for you gurus: Do you believe that they can get
my .dll file when I run it against their server database ? Could
anyone explain how can they get my .dll through the server?
What do you mean by saying this? Please explain.

Curious wrote:In that case, you need to either trust them with the code (because you
think they're not an adversary; because its not in their interest to
attack you; because you'll go to court and win lots of money; because
they're not clever enough to reverse engineer your code, etc...) or
don't give them the code.
If you're just connecting to their database server, they shouldn't be
able to see your code.
It's trivial to reverse engineer any realistic class. Lets take
something kind-of-like System.Drawing.Color as an example (simply
because it's self-contained).

This is 'obfuscated' code I've written manually and does not represent
any particular product:

namespace System.Drawing
{
public struct Color
{
public byte R{get;private set;}
public byte G{get;private set;}
public byte B{get;private set;}

public static Color Black = FromArgb(0,0,0);
public static Color White = FromArgb(0,0,0);
public static Color FromArgb(int a, int b, int c)
{
A(a, "red");
A(b, "green");
A(c, "blue");
return new Color(){R = a, G = b, B = c};
}
private static void A(int a, string b)
{
if(a < 0 || a > 255)
{
throw new ArgumentException(b + " value is out of range");
}
}
}
}

I've removed all non-public names, and thrown away as much information
as I can while still maintaining the same interface. It's still easy to
understand.

There are a few more silly tricks. For example, we could make 3
functions that evaluate to "red", "green" and "blue" so we don't have to
put those literals in the code, but anybody with a debugger is just
going to put a watch on the result of those functions and see what the
result is. Another silly trick is to change all variables to have the
same or similar names (because this is supposedly harder to read - you
can write a tool to parse the code and change them back to a,b,c,... in
less than 2 minutes with Mono Cecil).

And for this 'security', you've lost the information from your stack
trace so it's not clear (if an exception were thrown) that the exception
happened in the CheckByte function (called A here). You've also probably
added some extra bugs from the obfuscation layer. Reflection doesn't
always work any more either, because you might have thrown away the name
of what you're looking for.

Alun Harford