protection from .NET Decompiler?

[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

[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.

"pnp" <pnp.@.softlab.ntua.gr> schrieb im Newsbeitrag
news:eN**************@TK2MSFTNGP12.phx.gbl...

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

[perspolis]

I tried it..really it works well..
any other suggestion to protect it?
"pnp" <pnp.@.softlab.ntua.gr> wrote in message
news:eN**************@TK2MSFTNGP12.phx.gbl...

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

[cody]

> any other suggestion to protect it?

Do not use .NET then :)

[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
"perspolis" <re*****@hotmail.com> escribió en el mensaje
news:uk**************@TK2MSFTNGP12.phx.gbl...

I tried it..really it works well..
any other suggestion to protect it?

[JohnnyAppleseed]

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

"pnp" <pnp.@.softlab.ntua.gr> wrote in message
news:eN**************@TK2MSFTNGP12.phx.gbl...

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

[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.

[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 ..?

[JohnnyAppleseed]

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

"pnp" <pnp.@.softlab.ntua.gr> wrote in message
news:uI**************@TK2MSFTNGP09.phx.gbl...

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 ..?

[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
"pnp" <pnp.@.softlab.ntua.gr> escribió en el mensaje
news:uI**************@TK2MSFTNGP09.phx.gbl...

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 ..?

[Indie Pop]

Carlos J. Quintero [.NET MVP] wrote:

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

--
Texeme
http://texeme.com

[Helge Jensen]

pnp wrote:

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 :)

--
Helge

[Jon Skeet [C# MVP]]

Indie Pop wrote:

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

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

[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
----------------------------------------------------------
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:ug**************@tk2msftngp13.phx.gbl... Indie Pop wrote:

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

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

[Jon Skeet [C# MVP]]

<"Alvin Bruney [MVP]" <vapor at steaming post office>> wrote:

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.

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.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[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

[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/200...ses-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/200...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...

"perspolis" <re*****@hotmail.com> wrote in message
news:uk**************@TK2MSFTNGP12.phx.gbl...

I tried it..really it works well..
any other suggestion to protect it?
"pnp" <pnp.@.softlab.ntua.gr> wrote in message
news:eN**************@TK2MSFTNGP12.phx.gbl...

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