5

I have a ASP .NET application that we give to our clients for them to deploy it in their web server and use it. My concern is that all of my ASPX pages source code is open and our clients can open the ASPX/CS file and see the code in it.

I want to protect my code something like a Windows application by implementing some 15-20 days trial limitations. Also on the other hand the source code must have some third party dll so that whenever they try to deploy the fresh build, it will be available for limited period only.

The payment terms with our client is, First Source Code and then Payment. So I am thinking some in between way that the faith at both side remain as it is. How can I do this?

durron597
  • 31,968
  • 17
  • 99
  • 158
  • 2
    Next time, provide the application in compiled DLL's and then provide the source code when full payment is received. – Robert Harvey Apr 17 '13 at 18:43
  • @RobertHarvey Compiled Dll is other aspect. Published files are already running at their end. Now project is almost over and they need source code first, then they release the payment. –  Apr 17 '13 at 18:44
  • 4
    If you are giving them the source code (even before they buy it), what would stop them from deactivating the trial? Anyone could just go into the source code and remove the check. Granted, they would have to re-compile, but this sounds strange. – gunr2171 Apr 17 '13 at 18:48
  • 2
    There are no tools to add trial limitations in a situation you have. You are required to provide them the source to the project. If they want they can simple modify the project and remove ANY method you implement. The only solution is to provide only the compile DLL since you can't do that there isn't a solution to your problem. – Security Hound Apr 17 '13 at 19:01
  • 2
    DLL compilation is by no means a complete solution either. .NET assemblies are particularly easy to decompile, it will only stop the most casual of "hackers". If you need to protect source code, then obfuscation is what you need. – Snixtor Apr 17 '13 at 22:20

3 Answers3

2

Publish your web application so that all the code behind files are compiled into a dll. This way they cannot easy see your code. They will however be able to use reflection to see the code using tools such as jetBrains dotPeeek.

Best Option Host the site yourself but as this doesnt answer your question here are some other options

1st Option

If the client insists on hosting the site as they are concerted about owning the data then allow them to host the site and database but pull in the functionality from a centrally hosted site that you are in control of. You can even provide an api.

You provide the client with a hash code in the web.config and this gets validated against your site. The hash gets made up from:

  • presalt
  • the web service address
  • the expiry date
  • client uniqueidentifier
  • any other info you want
  • postsalt

Encrypt the request and response of the web service and send via ssl.

The client hash will be sent in the request. Build a new hash with the same fields and validate this against the hash you received from the client. if it is not valid you don't provide the functionality.

Google maps requires that you register and get a hash code as they can then terminate your usage of the google maps api if you misuse it.

2nd Option

Another option would be to setup a web service call to a site that you host.

The deployed compiled web application would then build a hash using the response from your web service and match the generated hash with the hash you sent over in the response.

This means that if the client block traffic to your web service or tried to fake the response then the application will stop working.

Also add some logic to alert you if they have tried to fake the response. This obviously wont work if they block the call to your web service.

You wouldn't include the salts here as the client could read them if they decompiled your code.

3rd Option Add two fields to your web.config:

  • the hash code which you have generated for the client
  • an expiry date.

If the client changes the expiry date to allow them more time then it will not validate and they will be locked out.

Opion 2 and 3 would allow the client to reverse engineer the hashcode if they really wanted to.

=====================================

I don't really see the need for it but if you want you can use some obsfucation tools like mentioned in the other post to make it harder for the client to read your code. But even if they can read your code they should not be able to create a valid hash code on their own.

skyfoot
  • 20,629
  • 8
  • 49
  • 71
  • Note that in this system you don't break it by providing a new hash, you break it by modifying the code to remove the check against the hash. It's not particularly difficult. Obfuscating the code can make it a bit harder, but in this case the code that needs to be modified is simple enough that compromising it is quite easy. Obfuscating code is more to ensure that the entire project cannot be effectively reverse engineered and then significantly modified. Small modification of narrow aspects, (particularly just disabling them entirely) is much more practical. – Servy Apr 18 '13 at 16:41
  • If the web application is compiled the client would need to create a new application and reflect the code and copy it all over to the new application. No I don't see many client's doing this. I – skyfoot Apr 19 '13 at 08:25
  • Well, you don't need every single client to do that, you just need one client to do that and then begin re-distributing your own product for a fraction of the price (or for free). If you have a tiny client base that can be a problem, but as the client base grows more and more protection needs to be added as the value of cracking your program increases. – Servy Apr 19 '13 at 13:19
  • @ Servy If there is such a massive concern then host the application yourself or have a small site which pulls in the functionality from a central site you host but the client is able to own the DB and therefore the data – skyfoot Apr 19 '13 at 13:26
  • That is what you *have* to do to ensure that your code cannot be stolen. Any option in which you give the code to the client, no matter what protections you add, can be broken. It's simply a question of whether you can add enough protection that nobody will be bothered to try to crack your program. For a small product, that's probably fairly easy. For mainstream commercial products, it's very hard. – Servy Apr 19 '13 at 13:28
1

I suggest you check out .NET Reactor and Intellilock. .NET Reactor will prevent decompilation of compiled code, however with aspx I'm not sure how this will work since it would need to be pre-compiled. Intellilock will provide the ability to set an expiration time. I've used both with standard executables but never ASPX so I'm not sure if they'll help.

Link: http://www.eziriz.com/

Pete Garafano
  • 4,863
  • 1
  • 23
  • 40
0

DotFuscator Community Edition is a possibility, but it's probably too basic for your needs.

I suggest you look at the commercial obfuscators on the market. Here's a list of some I found with a simple Google search. (This is not a recommendation of any of these tools.)

Community
  • 1
  • 1
Robert Bratton
  • 435
  • 1
  • 5
  • 12