By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
455,467 Members | 1,605 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 455,467 IT Pros & Developers. It's quick & easy.

Protecting Assembly against disassembling...

P: n/a
Hi,
how can i protect a assembly against disassembling with ILDASM and
other products like that. i have a dll with some encryption methods
implemented and i dont want them to be exposed, to the outside of
the world. of cource there are restrictions like modifiers and misc.
but i dont want the assembly "disassembled" from someone with
"bad intentions"...

How can i protect it efficiently...?

Thanks in advance
Kerem Gmrkc
Nov 16 '05 #1
Share this Question
Share on Google+
5 Replies


P: n/a
I've got two ideas in my mind.

1. There is a product out there that converts .NET IL into native IL, which
is a lot more difficult to disassemble. I don't remember the exact name of
the software, but I will do some research and post the result if I have
success.

2. I've once seen a cool thing. The actual implementation was stored as a
resource and this .resources file was encrypted. Then he wrote some kind of
starter Application that decrypts the resources file and launches the
resulting Type.

Hope I could give you some new ideas.

Regards Alexander

"Kerem Gümrükcü" wrote:
Hi,
how can i protect a assembly against disassembling with ILDASM and
other products like that. i have a dll with some encryption methods
implemented and i dont want them to be exposed, to the outside of
the world. of cource there are restrictions like modifiers and misc.
but i dont want the assembly "disassembled" from someone with
"bad intentions"...

How can i protect it efficiently...?

Thanks in advance
Kerem Gümrükcü

Nov 16 '05 #2

P: n/a
- If your code have some secret (such as a proprietary algorithm), you
should put it in a native Win32 DLL. x86 instructions can be disassembled
too, but it is much more difficult to understand.

- For the rest of purposes, obfuscation (renaming identifiers) should be
enough, since it makes the code difficult to read.

--

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
"Kerem Gmrkc" <ka*******@hotmail.com> escribi en el mensaje
news:up**************@TK2MSFTNGP09.phx.gbl...
Hi,
how can i protect a assembly against disassembling with ILDASM and
other products like that. i have a dll with some encryption methods
implemented and i dont want them to be exposed, to the outside of
the world. of cource there are restrictions like modifiers and misc.
but i dont want the assembly "disassembled" from someone with
"bad intentions"...

How can i protect it efficiently...?

Thanks in advance
Kerem Gmrkc

Nov 16 '05 #3

P: n/a

Try Spices.Net Obfuscator (http://spices.9rays.net ) with antiILDASM=true or
antiILDASM=Complete , stops some of the decompilers and full dissassembling
with ILDASM. Also you can use Naming scheme with non-printable chars to
prevent correct displaying of names in the ILDASM.
--
Best regards,
Al Ponomarev
9Rays.Net

Nov 16 '05 #4

P: n/a
The only approach that is currently available is obfuscation. There
are many .NET Obfuscation products currently available, and for the
most part, they tend to integrate directly into Visual Studio, so it's
not hard to use them as a part of your build process.

While obfuscation is hardly bulletproof, it is the only real
alternative. There are some serious limitations. For instance, an
obfuscator cannot change the names of calls to .NEt Framework classes,
so if your encryption methods use the System.Security.Cryptography
namesapce, a hacker using a disassembler could easily see where your
code calls those classes.

If you are trying to write security to a "serious" application, I'd
advise that you take a look at the incomperable and essential book,
"Writing Secure Code" by Michael Howard and David LeBlanc. It covers
all of the issues more completely than any other source of information.

Regards,

Adam

Nov 16 '05 #5

P: n/a
Thank you for the hints.

But i still do rewrite the Code to C++ and i think this
is the only way to protect the critical parts due the code
is native, and the best thing is, that i can (easily) port it
to any other platform using a cpp compiler. the code is
widely written on the ansi standards, thats why i say portable...

i think some core parts will be written in assembler, but this
makes the thing incompatiple with other platforms. my
colleague insisted...

I already know the book, it is one of the best available...
i can recommend it to anyone who wants to know more
about security internals....and how to break up a application...
Thank you...
Best Regards
Kerem Gmrkc
Nov 16 '05 #6

This discussion thread is closed

Replies have been disabled for this discussion.