protection from .NET Decompiler?

P

pnp

Hi all,
I ran into this decompiler http://www.remotesoft.com/salamander/
yesterday and I tested it on some of my apps that I've created with C#
and it could decompile them all back into source code!!! Give it a try
and see. They have an online decompiler as well. Is there any way to
protect my exe and dlls from this?? What can we do generaly speaking for
protection from decompilers??

thanks in advance,
pnp
 
C

cody

You could use an obfuscator which can "encrypt" non public identifiers and
twist the code a bit to make the disassembled code harder to read.
 
C

Carlos J. Quintero [.NET MVP]

There are at least a dozen of .NET Obfuscators on the web (Dotfuscator,
Xenocode, etc.). Obfuscators make it difficult to copy your source to create
a new app because the identifiers are meaningless (you can not reconstruct
"PayInvoice()" from "a()", but if you need to protect something very
sensitive (an algorithm, etc.), create a native Win32 DLL and call it from
your .NET app.

--

Carlos J. Quintero

MZ-Tools 4.0: Productivity add-ins for Visual Studio .NET
You can code, design and document much faster.
http://www.mztools.com
 
J

JohnnyAppleseed

Do not distribute your applications to the public or implment the
presentation tier as web forms.
 
C

cody

There are at least a dozen of .NET Obfuscators on the web (Dotfuscator,
Xenocode, etc.). Obfuscators make it difficult to copy your source to create
a new app because the identifiers are meaningless (you can not reconstruct
"PayInvoice()" from "a()", but if you need to protect something very
sensitive (an algorithm, etc.), create a native Win32 DLL and call it from
your .NET app.

In my opinion over 99% of the code in business apps are not worth it to
protect it since the business logic heavyly is bonded to this specific
application, database structure and so on which makes it nearly impossible
to use it in another application.
 
P

pnp

So we cannot really protect our code from decompilation... The only
thing that can be done is obfuscate the compiled assembly and rely on
the renamed methods, atts ..?
 
J

JohnnyAppleseed

Never let be said that Microsoft doesn't support open source software ...
 
C

Carlos J. Quintero [.NET MVP]

Yes, that's is. With .NET and Java you can not prevent decompilation, you
can only make the decompiled code (much) more difficult to understand.

--

Carlos J. Quintero

MZ-Tools 4.0: Productivity add-ins for Visual Studio .NET
You can code, design and document much faster.
http://www.mztools.com
 
I

Indie Pop

Carlos said:
Yes, that's is. With .NET and Java you can not prevent decompilation, you
can only make the decompiled code (much) more difficult to understand.

So, basically, .NET is Open Source ;D
 
H

Helge Jensen

pnp said:
So we cannot really protect our code from decompilation... The only
thing that can be done is obfuscate the compiled assembly and rely on
the renamed methods, atts ..?

Working decompilers can be found for binary code too. Protecting your
code from professionals out to steal it is impossible.

Protecting it from "average joe" is quite possibly a waste of time and
generally makes debugging and error-reporting a nightmare, piling onto
the support burden.

If your code is badly written though, I can understand why you would
want to use an obfuscator on it, since you can always claim that the
obfuscation produced the bad code :)
 
J

Jon Skeet [C# MVP]

Indie said:
So, basically, .NET is Open Source ;D

No. I've seen that flip comment in various places now, and it's
completely inaccurate. The idea that "Open Source" is the same as "you
can reverse engineer it to get code which you can then compile" is
ridiculous.

I know you put a winky there, but it's still a huge misrepresentation :(

Jon
 
A

Alvin Bruney [MVP]

No. I've seen that flip comment in various places now, and it's completely
inaccurate
Sounds like you are on a crusade of sorts? good luck.

--
Regards,
Alvin Bruney [Microsoft MVP ASP.NET]

[Shameless Author plug]
The Microsoft Office Web Components Black Book with .NET
Now Available @ http://www.lulu.com/owc
 
J

Jon Skeet [C# MVP]

Sounds like you are on a crusade of sorts? good luck.

Well, I don't know whether it's really a "crusade", but it does
irritate me to see the phrase "open source" used so carelessly.
 
C

clu

Take a look at the FCL assemblies.
Try run Reflector (or the decompiler of your choice) over them.
Voila: you can actually inspect some Mircosoft code after a
decompilation !

Two things are worth notice about this, IMHO.
First: MS did not obfuscate its own managed code !
Second: you cannot actually see everything. Take a look at the
InternalCall flag applied to a lot of methods.

So I believe Carlos is completely right: sensitive algorithms should be
implemented in unmanaged code (which is very, very, very harder to
decompile, although native decompilation is possible).

Claudio Brotto
 
S

Sean Hederman

Include a section banning reverse engineering in your EULA. Note that if you
sell your software in a box to the the consumer, a California court ruled
that the EULA is not 100% applicable, since you only agree to if after
purchase:
http://codingsanity.blogspot.com/2004/12/no-nasty-surprises-redux.html
Therefore you'd need a summary of the EULA on the outside of the box. Also
if you're going the EULA route, please please make it nice, and not the
"screw my customers" EULA that most companies use:
http://codingsanity.blogspot.com/2004/11/no-nasty-surprises.html

Anyway, if you ban reverse engineering, then they're not allowed to
decompile your code. How you're going to prove that they did is the tricky
bit though...
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top