Question

I recently had a negative experience, where client bailed from the bill, but my middle-man already uploaded our software and design to the clients server. Client turned out be a known criminal, and of course he changed all possible passwords of the server.

However, I can still access the admin-panel of the CMS. Sadly it turns out, that my software is very secure.. Tried to SQL-injection, fake the image-upload etc etc. However, I cannot hack my own software.. Anyways, I preparing to sue this person, so that is not the problem.. I'm just thinking now, that maybe there should be some backend selfdestruct-method. So, if similar case occur, I have the option to kill the software.

My own idea is to hide some function in the core files. Encode it with base64, so it wouldn't be obvious. So something like this:

eval(base64_decode('ZWNobyAnSGVsbG8gd29ybGQhJzs=')); // echo 'Hello world!';

And basically make a small script, that takes all the software's files, chmod's them to be sure and then deletes them.
My newer versions of the CMS, all have filemanagers that I could use for easier hacking. But what if the access to the admin-panel is limited.

To be very clear, this is meant only for the development-stage software's, in my personal server or the clients server (last part being the ethically questionable.) So if my client should steal my software.. This wont be included inside a commercial-software.
And to be even more clear, we are talking about those rare freelance jobs. I think its fairly logical, that contract-work doesn't need such methods. So we are talking about those jumprisk-clients, only in development mode -- when the project is ready, then obviously this would be a very very unethical backdoor to have inside your software.

  1. Ethically is this a good idea? (Keeping in mind, that obviously I will remove it, when project has been 100% and everything is paid for)
  2. Have you guys ever had to hack your own software, because of similar issues with the client(s)?
  3. Any recommendations on this idea, code and method wise?
  4. What may be the possible drawbacks or repercussions of selfdestruct-scripts?

My conclusion on this

Is a little bit sad, that all answers were targeted on the contracted cases. It was my fault really, that I didn't make it more clear in my question.. just thought, that it is fairly clear, that there is no point in the kill-switch.. when you are protected by the contract.
However, if you are doing a contract work.. then this should be stated in the contract -- this makes it legal, even inside the clients own server. However, having kill-switches inside my own personal server is really nobodies business (this is what I really wanted to know.)

I decided to make the kill-switch script for my CMS. Mainly, because it seems an interesting challenge. But also, that I could use this for my non-contracted works where the client is a friend of a friend of a friend.. I probably wont use this on the clients server, but..for the cases, where the client or some middlemen have access to my server .. And my software gets stolen, or "moved without my knowledge", then I don't get paid and they cut the access to the software.

I have read trough alot of topics here, where they recommend to send a warning and then take down the page. Well, I saw a problem in it, as when Im dealing with a person.. who will just copy it to somewhere else (maybe re-brand it and sell it) and tells me, that it has been taken down. And also, I wouldn't "turn the site off", but delete it. Though, I guess its still illegal to access my clients server and to delete it. Or at-least, access it trough backend and not from the FTP. For this I thank all of you, who answered.

No correct solution

Licensed under: CC-BY-SA with attribution
scroll top