How can I protect my ASP.Net Source Code From My Developers

Question

This seems like a weird position to be in, but let me ask the question anyway.

I have created some DLLs that do some magical mumbo-jumbo that is needed to display the content for the website I am making right now in ASP.Net. I've got a small team of developers who can help me with this, but I am afraid that they will steal my code (the DLL) and use it in projects when they leave my company. In a software I can probably prove that they are using my DLL to generate the content, but on a server where the DLLs are not available to public I can't.

So in spite of having a team I've been working on this all alone.

My question is. Is there any way you can think of using which I can protect my DLL (which goes into the bin folder) so that my coders can't steal it, or it becomes unusable if stolen.

I just want to protect whatever goes into the bin folder.

Answer 1

You could have the dll check its environment and fail to work (I suggest you make it give wrong results rather than break) if the environment does not feel like home. You will also have to obfuscate the code to hamper efforts to remove the protection.

Edit: you could use an environment variable, registry key, existence of a performance counter, an obscure setting in machine.config, etc., and make it look like a genuine setting, then obfuscate and sign with a strong name.

Answer 2

This may not be appropriate to your situation but you could provide them with a proxy DLL which doesn't perform the calculations but instead calls your DLL.

You then keep your DLL on another server that only you have access to and the proxy DLL calls it via some sort of remoting protocol.

Answer 3

That is a weird position to be in... my condolences.

At the .Net level, the best you can do is obfuscate your code when you build it. Strongly signing your assembly will let you know if tampering is going on as well.

Another approach that some people have taken is to write the really sensitive code in C++ and compile it to an unmanaged .dll, and call into it from .net using interop. C++ bytecode is much harder to read than IL, and this throws up a lot more barriers to easy reverse-engineering.

Edit: based on comments from the OP, here is an updated answer.

If you're simply worried about them stealing the DLL that you place in the bin folder on your web server, simply publish it to a subfolder of \bin, lock the folder down using windows permissions, so there is no way they can get into it, and change your web.config to probe it.

<runtime>
   <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <probing privatePath="bin;bin\mysubfolder;" />
   </assemblyBinding>
</runtime>

Definitely make sure to strongly name the .dll, and keep your private key file somewhere safe. That makes your .dll uniquely identifiable and tampering can be detected if they do get at it.

Answer 4

Related: https://stackoverflow.com/questions/181991/suggest-a-good-obfuscator-for-net-closed.
You might want to obfuscate your code selectively(keep public API's as is)

Answer 5

You could have the dll talk to a trusted third party (which would probably be a server you would have control of) to do a little hand-shaking to make sure it's supposed to run.

Something along the lines of

A. Hey, I'm sitting at [hostname->taken from env vars], can i do my job?
B. (checks records of registered hosts)  Yes you can.
A. Thanks.  (does what it does best)

edit: Of coarse, if someone else knows you're doing this, they could bind the remote address to a machine of their choosing... at which point you haven't really fixed your original problem.

Answer 6

I don't know much about the legal system in India, but make sure you get them to sign some form of NDA, and make it clear to them that you take it serious and will sue them if they violate it.

And if possible only expose your DLL through a Windows Service or out-of-process COM server so that you can isolate your DLL where they cannot access it directly.

If they have physical access to your DLL, and they're halfway competent developers, then there probably isn't much that you can really do from a technology standpoint to actually prevent them from using it. You can slow them down a bit, but inevitably they will get what they want if they have access to the binary. Denying them access to the binary is the only effective way to prevent it.

However, if the DLL processes user input in any way and provides content to display as a result, then you can put in some kind of "Easter Egg" that will output a distinct signature of some kind based upon some obscure but specific input. Depending on the legal system that may be good enough to open an investigation and force them to grant access to investigators to prove that they're not stealing your tech. Unless they know it's there they probably won't look for it and disable it before you have a chance to invoke it.

Answer 7

I would create a web service on a secured server that would expose the functions of your dll. Once development is done you could change the parts of the code that call the web service to call the dll directly.

Answer 8

I concur with LachlanG's strategy to distribute a proxy DLL instead of giving your developers access to the production one that could easily be cracked and reversed engineered.

Another option you can explore is to "dongle" protect your DLL. I stumbled with your question while researching a solution to my problem. I am exploring this option since I am in the same spot but with even more vulnerable PHP based solution.

I found that Keylok offers a competitive product at an affordable price that I am strongly considering. It's yet to be seen how to protect the API calls in PHP which code is not binary nor obfuscated. I dont foresee any problem with a DLL.

I was a project manager for a company that protected their SAP integration software with these kind of dongles. The final product was a CD with the code, the installation manual, the dongle and a license bill for $200k. Sweeet!!! It was 10 years ago, and I have not heard of any piracy or copyright infringement stories from them yet!

I hope this helps.