Preventing .NET DLL execution

Preventing .NET DLL execution

• Jeroen Vos

  If you wanted the safest solution you would also move the database off the server that is directly connected to the internet and into the internal network. I understand these things probably aren't an option to you due to current hardware, network, and skillset.

  As far as I know you're not going to be able to obfuscate the dll easily for your web service.

  Another option might be to use the web application project for addin for 2005. This way you end up with a single compiled assembly for your webservice and you can obfuscate the webservice dll and the dll you are concerned about together.

  Alan

  
  

• godfrank

  If you really would like to hide the functionality start from the beginning. Architect a solution that protects you starting on the network layer. Your publicly exposed web service sits in the unprotected DMZ, which causes security concerns. Setup another service that sits in your trusted internal network which is firewalled from your DMZ.

  Have your service in the DMZ call your service that is in your trusted internal network.

  Your service that is in the trusted internal network could be implemented as a webservice, for ease of communication through a firewall, or something quicker such as remoting over TCP.

  Now, mind you, I have assumed you're trying to hide this functionality from the internet.

  Let me know what you think.

  Alan

  
  

• Polo Gringo

  Well, I downloaded and installled the "support for Web Application Projects" and the Web Application Projects addin last night and installed them. I didn't test it until this morning. Upon first running VS, I got a message saying that there was a corrupted J# redistributable and some other message. I didn't have time to investigate, so I just did what I thought would not take any more actions and shut down. That's what scares me about "Alpha" releases. I've had more than my share of problems with the VS installations so I don't want to mess it up and I REALLY don't want to have to go through the installation again. It took multiple days on the phone with Microsoft to get it to install properly on a brand new machine.

  JT

  
  

• C3i

  Yeah, moving the database is not a possibility for me.

  Is there any reason that the DLL called by the web service could not be put with the database as well Would it need to be a web service

  I think I saw SOMEwhere on SOME forum or article a mention of something like a web application project addin, but I didn't pay much attention to it. I just went into VS and looked at the Addin Manager and saw nothing in the "available addins". I Googled it and wound up at http://msdn.microsoft.com/asp.net/reference/infrastructure/wap/default.aspx. According to the text there, it was released in May 2006. In Microsoft terms, that's like an Alpha release. Have you used this

  The lingering problem is that, being a web service, it was designed to be accessible to anyone and everyone. So an obfuscated web service would not only be a headache for me, but for anyone else who wanted to use it.

  Here's the obvious solution that I proposed to PreEmptive Solutions: There should be a map file that allows you to make a reference to the web service (essentially a translated WSDL file) so that you could at least create the program that referenced the obfuscated web service. I must be misunderstanding something because that seems like a no-brainer.

  So, I don't think I'm any closer to a solution yet, unless I just put my DLL with my database file and keep it out of sight for now. Any other thoughts

  JT

  
  

• D-Swat

  Yes, I'm trying to hide the code from Internet users. The code is in a web service because it needs to acces a database on the web server. I know as much about networking as I know about the human genome, so bear with me. On my web server (the host that I use), my database sits outside of my root web folder. The web service accesses it using a literal path. I don't know if that database's folder is considered to be outside the DMZ or not. It is only accessible via password-protected FTP. Is there any reason that the DLL called by the web service could not be put there as well Would it need to be a web service

  I'm taking the approach that NOTHING is safe on the Internet so I'm encrypting the database even though it's not readily accessible. It doesn't have very sensitive information, but I want to do my part to protect against anything that could eventually lead to identity theft. So if I put my DLL with the database, I'd probably still want to obfuscate it.

  So I guess I'm back to the original question. Can you obfuscate a DLL that is called by a web service If so, then how

  JT

  
  

• Guillaume JAY

  You should write a C dll which acts as a password verifier, and then write your code so it requires a password to run ( so the calling code passes in the password ).  Even then, unless you can move something core into your C dll, anyone can reverse engineer your code to remove the password check.
  
  This is the biggest problem with .NET, it's so easy to decompile, remove the bits you don't want, and compile again.
  
  
  

• jedediah

  That sounds like my best option. I appreciate the help. I've just started working with the dotfuscator today so it helps to have additional opinions and experience.

  Thanks Alan.

  JT

  
  

• John Cheng

  Unless I'm mistaken, and I could be, the .cs file resides on the web server along with the .asmx file, thus making it as "plain as day" to anyone who wants to see the code. This is why I'm investigating a different method. I'm trying something similar to what you're describing. I am putting sensitive code into a separate DLL and creating a web service that does nothing more than create an instance of the class in the DLL and mimicking the methods. For instance, the Utils DLL would contain:

  class Utils

  {

  public string DoSomething(string Orig)

  {

  return Orig.Substring(3);

  }

  }// end of class Utils

  My web service ExposedUtils woud contain:

  [Web Method]

  public string DoSomething(string Orig)

  {

  Utils.Utils Stuff = new Utils.Utils();

  return Stuff.DoSomething(Orig);

  }

  I apologize for code errors. This is just for explanation. Now my problem is, I want to obfuscate this with the included "dotfuscator" in VS 2005. The web service is not compiled into a DLL, and thus cannot be obfuscated. The web service refers to the Utils DLL using the original method names. If I obfuscate Utils, my web service stops working unless I go through the painstaking process of trying to use the newly mapped symbols, and if the enhanced overload induction is used, there are potentially overloads with just the return value being different. (I don't think that's allowed in source code.)

  I have not started doing any "StrongNaming" so I don't currently understand that suggestion. Have you done what I'm trying to do or run into this situation Is my approach implausible

  Thanks!

  
  

• medhat__1

  I think your best bet is to try the web application project. We are using for development at my company with no complaints so far. If you feel it doesn't work for you then you can uninstall it.

  When you obfuscate the two dlls together you can tell the obfuscator what to obfuscate and what not to obfuscate.

  There are options in Dotfuscator to ignore certain namespaces or types. With this you can have your logic in your important dll obfuscated but leave the "interface" of your web service intact.

  In my opinion putting the the dll and the database in a different directory is no safer than locking down permissions on your virtual directory. This is because the account that the ASPNet worker process runs under must also have rights to this other directory to load the dll or to open the DB.

  I'm hoping someone else will chime in with some different ideas as well. Good luck.

  Alan

  
  

• briankaiser

  What I would do for the very best protection is:

  1. In C# 2.0 (this is a new feature) is make as many members in your assembly internal, so no outside DLL can call it. If you have Assembly's that need to access that member, an outside Assembly can call an internal member of a referenced assembly provided that the internal member specifies which outside assembly's can see it, defined by the calling assembly's name and Public Key when signed with a strong key. You can do this with the InternalsVisibleToAttribute Attribute. This is called "Friend Assemblies".  The advantage of this is the StrongNameIdentityPermissionAttribute only applies to individual members, while InternalsVisibleToAttribute can be set at the assembly level.
  2. Obfuscate your assembly with a 3rd party tool, i.e. the Dotfuscator. This program will re-write your assembly's MSIL into an extremely hard form to read. Although, this is not a gaurenteed way to protect code. This just makes it very difficult to read.

  Keep in mind that no matter what you do, if someone is determined enough to reverse engineer your code, it will be done. Even with unmanaged code. It is always possible to view the x86 assembly code of an unmanaged C/C++ library, and with enough effort, you can reverse engineer a standard C library. The 100% best way to fix this is don't give your assemblies to anyone, is write it as a web service, if possible.

  
  
  

• Xaz

  If the option is available to you, you can move your sensitive code to a server and provide it as a web service. This way, the inner workings are not visible to the user.
  
  

• ImBroken

  There's really no foolproof method of protecting any binary from reverse engineering, .NET or native.

  A Web Service would be the most secure because people would not have access to the binaries.  If you deploy a compiled web service no source files will reside on the server.

  StrongNameIdentityPermissionAttribute will basically be ignored by any FullTrust caller.

  Obfuscation really only makes the IL harder to read; it doesn't protect the binary.  A sample application called deprotector from RemoteSoft will actually deprotect any obfuscated assembly that can't be disassembled, into an assembly that can.  They also offer a product that will convert your assembly from IL to native code; which would give you the same level of protection as native DLLs.

  You also have the option of selectively making certain methods compile to native instead of IL.  You can do this with the MethodImplAttribute.  If I remember the syntax correctly you would do something like this:

  using System.Runtime.CompilerServices; //... [MethodImpl(MethodImplOptions.Unmanaged, MethodCodeType=MethodCodeType.Native), SuppressUnmanagedCodeSecurity]void MyMethod() { // Do something useful here that can't be seen by ILDASM or Reflector. }

  I've only tried this in FullTrust environments, I would not be surprised if it causes problems in a low-trust environment.

  That attribute will not work with all methods; anything that the CLR reflects upon normally will cause an exception (like event handlers, delegates, etc. can't have that attribute).

  
  
  
• Preventing .NET DLL execution