Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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.

share|improve this question
I am not sure why this was downvoted. It is a legitimate question with legitimate value. – BinaryMisfit Sep 14 '09 at 8:49
Nice question. Thanks for looking out for software developers. +1 – D'Arvit Sep 14 '09 at 9:43
I'm not sure this is going to really further your goals. If they plan to steal the software, they are probably going to grab a copy of the VM during the course. They they'll be able to screw with it at their leisure. They can always boot the VM off of a live-cd in order to examine the thing to figure out what you did. – Michael Kohne Sep 14 '09 at 13:28
Thanks to everybody who gave an answer, I'm grateful for the input. :) – techtechmo Sep 15 '09 at 0:53
up vote 3 down vote accepted

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.

share|improve this answer
So just to clarify, once the script executes the system will wipe itself from the (in this case virtual) partition, and there's no cancel? This sounds like what I intend to do. :) What if, for example I tell the virtual machine to power off just a few seconds the command executes? Although the system may be accessible, it would still theoretically be possible to mount the undeleted portions of the disk right? Perhaps the first step of the script should be removing the software first, and then running the self-destruct script? – techtechmo Sep 14 '09 at 12:29
Well, if the user is logged in as a user with appropriate permissions, AND if they know what's going on, then they could, in theory, kill the 'dd' command, but not before it does a lot of damage (the partition tables are near the front of the disk, for instance). – Michael Kohne Sep 14 '09 at 13:26

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.

share|improve this answer
As I had mentioned the software will be in a virtual drive specifically created just for the course. It's an isolated environment without any user files meant in particular to allow the participants some hands on training w/ a piece of software. One things I want to guard against is somebody copying that Virtual Drive onto, say, a USB Drive and ultimately pirating the software inside. Thus, I intentionally want to set the system to self destruct right after the course in order to minimize the chance of something like that from happening. Your concern is of course valid, thanks for sharing.:) – techtechmo Sep 14 '09 at 12:18
By the way they are not in any way buying a license of the software to be used. And considering how notorious piracy is in my part of the world I would rather make preparations assuming the worst, but working for the best. :) – techtechmo Sep 14 '09 at 12:27

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):


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


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.

share|improve this answer

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).

share|improve this answer
Nice idea, but I think something like this would require some experience and comfort with implementing the system that you have described - unfortunately I don't have that luxury. :) The hands-on with the software will be done in the room where I will be facilitating, however I do not want to have to keep looking over my shoulder. Your comment in the question is precisely what I'm anticipating - even if they grab a copy of the VM, the next time they boot it up the VM should wipe itself clean of everything. (I shall of course not even mention the existence of the wipe everything script.) – techtechmo Sep 14 '09 at 15:13
The problem is that once they see the VM destroy itself, they'll just get another copy off their USB stick, boot the VM from a live CD and start poking around until they find out what it does to kill itself. As long as you are comfortable with the fact that a sufficiently motivated user can get around it, then you're golden. Then all you have to do is to update the VM image before each class... – Michael Kohne Sep 14 '09 at 20:21
I'll be encrypting the VM filesystem on install (hopefully - it'll be my first attempt t do such), so that's another means of dissuading would-be thieves. As I had said, all of this trouble would likely be overkill - the average user may not think that it's worth the trouble to keep poking around. But I really would rather assume the worst anyway - piracy is the norm here. The software I'll be using is native to Windows: good thing it works on Linux through Wine. And I'd rather prepare everything on Linux because honestly it'll be much harder to pirate the software from there. Thanks again! – techtechmo Sep 15 '09 at 0:51

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .