classic asp obfuscate

Question

Hi,

I have a small classic asp site and I am concerned that a client may stop paying me. The site is on their server, so I basically want an "off switch" in the event they stop paying me. I couldn't think of a good way to do this as they have a tech person who has access to the server, so any code I write to stop the site would be easily found and changed in the classic asp site (there aren't many pages).

So we had thought of maybe obfuscating the 2 main class pages so that they won't be able to edit the pages easily and we still have code to stop the site functioning. My questions are:

• What is the best option for obfuscating classic asp code (if anyone has done this before)?
• Is there another option that maybe we're not thinking of?

Thanks for any help you can provide!!

Answer 1

I'm pretty sure that programmers have gotten sued or even charged criminally for this sort of thing; the courts see it as "hacking" into a client's site and breaking it over a payment dispute. Be careful.

Answer 2

I believe the best way would be to simply have it call your own server for some critical piece of data. That way you can restrict that service if / when their subscription does not tally with your desired business model.

It does depend a lot on the site, but there will always be something you can return from your own server to keep the site active. Also this does give you the advantage you are not disabling their server but your own if it goes wrong.

hope that helps

Answer 3

There is a tool from Microsoft called Script encoder that encodes a script into garbage, though it's fairly easy to get the original back..

Answer 4

I think your energies are better placed on setting milestones in your project that are tied to payments. This ideally is done in increments so that neither party feels at a disadvantage with regards to the amount of work done / amount of money paid.

Obfuscation is easily removed and decoded, generally.

Remote checking for a security license opens a security hole for the application, and also can be defeated relatively easy.

Putting in code that "self destructs" if some action or code is not removed is also not great practice.

Licensed software is a little bit different in this regard. It sounds like you're building a bespoke system that you will simply hand over to the client at the end. If that's the case, putting in mechanisms to disable that system that only you control is not a great way to build trust. They may be violating trust if they fail to pay, but your disabling of the website actually gives them an additional incentive NOT to pay you, and consider you as a programmer willing to put in a Trojan Horse into the code.

The real problem to solve here is not in code, but in project management. A social not a programming problem.

This is a hard problem, and a great one for StackOverflow. I wish you well in sorting it out.

Answer 5

Why not put some of the business logic into a VB6 component? That's valid optimisation and obfuscation in one. They could decompile such a DLL, but it's a lot of hassle.

More importantly, you need to consider who owns the code, regardless of what you do at this point. The link below is a discussion on code ownership in freelance situations (without a contract), and I think that the accepted answer defines the issues rather well: http://stackoverflow.com/questions/111815/freelance-work-with-no-contract-who-owns-the-code

Answer 6

You're in Australia right? You have a small claims court system? If you've delivered what you were obligated to code for them, you shouldn't have a problem collecting.