Ajudarei a facilitar um curso que use software licenciado. O software é um pouco caro e permite apenas um número limitado de instalações simultâneas; portanto, o que farei é instalar uma instância em um disco virtual criptografado com o Ubuntu (ou algum outro tipo de linux) instalado. Apenas para diminuir a chance de ocorrência de pirataria desnecessária, pretendo agendar (usando o cron) um script de autodestruição para ser executado imediatamente após o último dia do curso. (Ou, o mais tardar, durante a primeira instância de inicialização após o último dia.)

Por mais que eu goste de projetos de software livre e de código aberto (e de crowdsourcing em geral), também tenho um respeito saudável pelo software comercial e pelo tempo e esforço que os desenvolvedores dedicaram para criar um bom produto - eu não querem acabar inadvertidamente contribuindo para a pirataria de sangue, suor e lágrimas.

Gostaria de ter alguma idéia de como implementar esse script de autodestruição em uma máquina Linux.

Como mencionado várias vezes, a exclusão da imagem criptografada deve ser mais do que suficiente. Outra abordagem seria instalar o aplicativo em sua própria partição e limpá-lo posteriormente com o dd.

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

Isso substituirá tudo com zero, o que é suficiente para excluir os dados além da recuperação.

Destruir tudo parece ser um pouco exagerado, que tal remover / desinstalar seu programa?

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

Ou você implementa um servidor de licenciamento normal com o qual o programa deve entrar em contato antes de iniciar?

Atualização : Como uma pergunta em aberto, você planeja destruir os dados dos usuários e seu programa? Ou os dados dos usuários são armazenados em outro lugar?

E talvez o usuário deva receber algum tipo de aviso de que você planeja destruir tudo! Algo como

- "Este software se autodestruirá se você não pagar mais dinheiro, você tem X dias restantes."

Como usuário, eu ficaria muito chateado se você destruísse algo no meu computador sem nem me dizer que isso estava prestes a acontecer (então eu pelo menos tive alguma chance de afetar o resultado).

É meio ruim para a sua empresa se todos os seus clientes pagantes acabassem odiando você.

Um pouco velho, mas ok. De acordo com essa configuração, eu preferiria apenas criptografar o sistema de arquivos da VM e, durante as sessões (supondo que elas estejam em rede), você faria o login remotamente. Se eles copiassem a VM, teriam que forçar a senha com força bruta, dificilmente o que seus usuários deveriam fazer :)

ou seja, se você não se importa, pode criptografar um ponto de montagem: Nota: esse sistema de proteção é ilegal aparentemente em alguns países / estados? (bem nos EUA, mas você parece ser da Inglaterra?):

Configurando uma montagem criptografada e com senha:

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>

Agora instale / mova seu programa para / theprogram

(Sempre que desejar acessar / o programa novamente):

montagem

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

desmontando

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

Quando terminar, faça com que a pasta do software pareça apenas um arquivo de bytes aleatórios.

Você também pode garantir que as contas de usuário que eles usam durante a sessão da VM não tenham sudireitos, caso copiem tudo.

Não sei qual é a sua configuração, mas se você pode exigir que seus usuários estejam on-line, convém adotar uma tática diferente - tente carregar o software por uma conexão de rede sempre que executá-la. Isso só é viável e depende de você poder emitir algum tipo de ID para usuários individuais. Você teria um stub na VM e o stub montaria automaticamente um servidor remoto e executaria o binário a partir daí. Nada que eles não pudessem dar a volta com um pouco de trabalho, mas seria pelo menos mais difícil do que contornar a autodestruição.

Como alternativa, o servidor remoto pode responder com chaves e manter em disco uma versão criptografada do programa - o stub consulta as chaves do servidor, descriptografa e executa o programa, excluindo o binário descriptografado conforme apropriado. Isso também seria mais difícil de contornar, mas novamente exige IDs de usuário exclusivos (o que talvez não seja possível para você).