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.

Anishaaniso

Before you raise the trust heckles. I've been shiv'd before by a dev who stole my code and went to a competitor. Once bitten, forever shy. – Anishaaniso

I must confess... I have pondered over this question as well. +1 – Biennial

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.

Ensphere

There are a couple of viable approaches here. But I finally picked yours cause it's the most evil. I am adding some compiler flags to my DLL that will mess up the calculations if true. Now I must only remember to replace the test dll with my production dll before uploading. Thanks – Anishaaniso

This will slow them down, but ultimately will be crackable - somewhere there is a boolean flag in memory that just needs altering to make the check pass. – Winne

It's a compiler constant. So technically I believe the DLL should have only the incorrect code compiled. – Anishaaniso

"Most evil" + 1 for that! Loved it. – Ascospore

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.

Elegit

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.

Winne

That doesn't answer my question. It's not reverse-engineering I am worried about. – Anishaaniso

+1 Your updated answer is very interesting, but I already changed the DLL to display wrong results (which was easiest to implement). I will try your method as soon as I can and tell if you there are any security worries. Thanks – Anishaaniso

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)

Christiniachristis

Obfuscation is not my problem. I am not worried about someone de-compiling my code. I am worried about someone taking that dll, putting it in their bin folder and using it to make a website similar to mine. (It a DLL that does some special calculations). How do I stop them? How do I prove they are using my DLL on their server if that happens? – Anishaaniso

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.

Swanhilda

That kind of thing begs for a crack. Would still slow them down though. – Winne

Could also slow the app down if the tubes are a little sluggish. – Swanhilda

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.

Redoubt

Yes they have signed an NDA. But a legal suit in India takes decade(s) to settle. I would have adopted the easter-egg approach but the DLL is made for use in ASP.Net. If they put it online on a server, I can't do anything to call the functions from it. It will reside in bin. I think my best bet is to not let them get access to the correct DLL. – Anishaaniso

Yeah, what I meant was if the DLL did any processing of user input from the site. Without knowing the actual nature of the code it's hard to know if it makes sense, but if, for instance, the input to the DLL is based upon form data that a user inputs, that could be your conduit to invoke the Easter Egg, if the output of the DLL is then displayed to the user. But if legal suits take that long it's probably a moot point anyway, and I agree that not giving them access to the correct DLL is probably your best bet. – Redoubt

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.

Textile

Sounds like a viable strategy, but that would increase the lag time for mmy developers. I did the fake dll (dll gives wrong results), so my devs never know they're working with a placebo and they will get a nasty surprise if ever someone tries to put it in production. – Anishaaniso

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.

Beilul