Prevent debugging and other security measures?

  • Thread starter Thread starter Christoph Wienands
  • Start date Start date
C

Christoph Wienands

Hello everybody,

I have a couple of questions about "intellectual property security" in
DotNet. It is very easy to disassemble DotNet assemblies and the generated
code looks very pretty :-)

However, currently we are very concerned about our intellectual property
stored in the algorithms as well as passwords that we might need to ship
with the application. So I wanted to know if people here have gained some
experience with security measures. Here is what I was thinking about so far:

-Code obfuscating: VS.Net 2003 comes with one, we'll definitely use this. It
makes it hard to understand algorithms.

-Prevent debugging: Back in the DOS times you could do a couple of tricks
(hook into interrupts, etc.) which would crash most of the debuggers (except
for some really sophisticated ones). Does anybody know of tricks like that
for DotNet?

-Prevent use of our assemblies through other applications: Is there a way to
secure our libraries/assemblies so that only our applications will be able
to use them? I know you can give a strong name with a public/private key to
an assembly but I have no clue how this can help here. And I don't want to
store the assemblies encrypted in the application and decrypt and create
them on runtime.

-Secure passwords in assemblies: Assume our application needed to make a
connection to our server and we need to make sure that first this request
comes from our application, second, our application is unaltered. Any idea?

I know that these are quite some big questions and I don't expect complete
solutions ;-) But if anybody could give me some hints for one or the other
issues, I'd be very thankful.

Take care, Christoph
 
Hi Christoph,

Thanks for your post. I'd like to share the following information with you:

1. For obfuscation tool for .NET, I recommend you the following MSDN
documentation on Dotfuscator.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dotfuscator
/dotf3e5x.asp?frame=true

2. To protect your intellectual property, .NET Framework has built-in
licensing scheme. With .NET licensing, we are able to create licensed
classes, Windows Forms controls, etc. There are two modes of consumption
for licensed classes, design time and runtime. If you want to pretect your
library from being used by other applications, you can use design time
license. Please refer to the following articles:

..NET Licensing
http://windowsforms.net/articles/Licensing.aspx

Licensing Components and Controls
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/htm
l/cpconlicensingcomponentscontrols.asp

3. Based on my experience, I am afraid that we are not able to prevent a
..NET application from debugging.

4. Regarding "Secure passwords in assemblies", I suggest that you can use
connection-oriented protocal (say, TCP) to connect your application to your
server application. Once the connection is established, you client
application should send some "shake-hands" data first for the server to
identify the client. The following KB article demonstrates socket
programming in .NET:

HOW TO: Program the Microsoft Windows Sockets Interface and the Network
Connections in Microsoft Visual Basic .NET
http://support.microsoft.com/?id=821768

Please feel free to let me know if you have any problems or concerns.

Have a nice day!

Regards,

HuangTM
Microsoft Online Partner Support
MCSE/MCSD

Get Secure! -- www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.
 
Hello Tian,
1. For obfuscation tool for .NET, I recommend you the following MSDN
documentation on Dotfuscator.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dotfuscator
/dotf3e5x.asp?frame=true

2. To protect your intellectual property, .NET Framework has built-in
licensing scheme. With .NET licensing, we are able to create licensed
classes, Windows Forms controls, etc. There are two modes of consumption
for licensed classes, design time and runtime. If you want to pretect your
library from being used by other applications, you can use design time
license. Please refer to the following articles:

3. Based on my experience, I am afraid that we are not able to prevent a
NET application from debugging.

4. Regarding "Secure passwords in assemblies", I suggest that you can use
connection-oriented protocal (say, TCP) to connect your application to your
server application. Once the connection is established, you client
application should send some "shake-hands" data first for the server to
identify the client. The following KB article demonstrates socket
programming in .NET:
Click to expand...

Thanks a lot for your suggestions. I think, the Obfuscator + Licensing
(which I didn't know of before) will relieve a big part of our concerns.
Bottom line is that we only have to make it so difficult that the costs for
reverse engineering are at least as high as to develop it from the scratch.

Thanks a lot,

Christoph
 
Back
Top