How to set a Linux Ditribution to self-destruct (to wipe everything from the system partition) via a script

Question

I shall be helping to facilitate a course that uses licensed software. The software is somewhat expensive and allows only a limited number of concurrent installations, so what I'll do is to install one instance on an encrypted Virtual Disk with Ubuntu (or some other flavor of linux) installed. Just to lessen the chance of any unnecessary pirating from occurring, I intend to schedule (using cron) a self-destruct script to run immediately after the last day of the course. (Or at the latest, during the first instance of boot up after the last day.)

As much as I love freeware and open-source projects (and crowd sourcing in general), I also have a healthy respect for commercial software and the time and effort that the developers have put into coming up with a good product - I don't want to end up inadvertently contributing to the piracy of their blood, sweat, and tears.

Would appreciate any idea on how to implement this self destruct script on a Linux machine.

Answer 1

As mentioned several times, deleting the encrypted image should be more than enough. Another approach would be to install the application on its own partition and wipe it afterwards with dd.

dd if=/dev/zero of=/dev/TARGETPARTITION bs=1M

This will overwrite everything with zero which is enough to delete the data beyond recovery.

Answer 2

To destroy everything seems to be a little overkill, how about to just remove/unstall your program.

rm -rf /path/to/your/program/ 

Or how about you implement a normal licensing server that the program must contact before it can start?

---

Update: As a open question, do you plan to destroy the users data as well as your program? Or are the users data stored elsewhere?

And maybe the user should get some kind of nagware notice that you plan destroy everything! Something like

-"This software will self destruct if you don't pay more money, you have X days left."

As a user I would be really upset if you just destroyed something in my computer without even telling me that this was about to happen (so I at least got some chance of affecting the outcome).

It is kind of bad for your company if all your paying costumers would end up hating you.

Answer 3

A bit old but ok. According to that setup, I would rather indeed just encrypt the VM filesystem, and during sessions (assuming they are networked) you would remotely login. If they would copy the VM they would have to bruteforce the password, hardly what your users should be up to :)

i.e. if you don't mind you can encrypt a mountpoint: Note: this protection system is illegal apparently in some countries/states? (well in US but you seem to be from England?):

Setting up an encrypted, passworded mount:

dd if=/dev/urandom of=/home/user/virtualfolder bs=16065b count=100  
modprobe loop  
modprobe cryptoloop  
modprobe aes  
losetup -e aes /dev/loop1 ./virtualfolder  
password: <enter your password here which you don't show to the users>  
mkreiserfs /dev/loop1  
mkdir /theprogram  
mount -o loop,encryption=aes,acl ./virtualdrive /theprogram  
password:<enter the same passy>

Now install/move your program into /theprogram

(Each time you want to access /theprogram again do):

mounting

mount -o loop,encryption=aes,acl ./virtualdrive /theprogram  
password:<enter the same passy>

unmounting

umount /theprogram  
losetup -d /dev/loop1  
rmmod aes  
rmmod cryptoloop  
rmmod loop 

When done, make the software folder look like just a file of random bytes.

You can also make sure the user accounts they use during the VM session do not have su rights in case they copy whole thing.

Answer 4

I don't know what your setup is, but if you can require your users to be on-line, then you might want to take a different tactic - try loading the software over a network connection whenever they run it. This is only viable, and it depends on you being able to issue some kind of id to the individual users. You'd have a stub on the VM, and the stub would auto-mount a remote server and run the binary from there. Nothing that they couldn't get around with a bit of work, but it would at least be harder than getting around the auto-destruct.

Alternately, you could have the remote server respond with keys, and keep an encrypted version of the program on disk - the stub queries the server for the keys, decrypts and runs the program, deleting the decrypted binary as appropriate. This would also be harder to get around, but again requires unique user ids (which may not be possible for you).