Come implementare “l’autodistruzione” di un software shareware?

Come implementare “l’autodistruzione” di un software shareware?

countdown photo

In questo articolo affronteremo una delle curiosità più interessanti mai dibattute nella storia dell’informatica, e che riguardano la possibilità per un programmatore di creare software “a scadenza”.

Lo scenario è il seguente: un utente crea un software che vorrebbe mettere online in “periodo di prova”, cioè seguendo essenzialmente la definizione dei programmi shareware diffusi negli ultimi anni. Come fare ad implementare una caratteristica del genere? Secondo alcuni, di fatto, si tratta di un qualcosa di impossibile, su cui molte case produttrici hanno speso anni senza riuscire a trovare una soluzione realmente robusta: di sicuro una soluzione autocontenuta, ovvero un’installazione in locale, non è adatta al caso. Il software potrà sempre essere reinstallato, emulato su una Virtual Machine, resettato ed utilizzato in questo modo teoricamente all’infinito. Diventa allora necessario ricorrere all’autenticazione su un server remoto: in prima istanza ciò corrisponde a fare un check di credenziali di accesso sul server della casa produttrice, ad esempio. Se lo stesso fosse ad esempio irraggiungibile o in downtime, tuttavia, si porrebbe un serio problema di discontinuità nell’uso da parte degli utenti che l’hanno acquistato, senza contare che legare l’utilizzo ad una connessione ad internet può risultare fastidioso, oltre che dallo scarso appeal commerciale, per moltissimi utenti.

Del resto, rimane comunque il problema dei crack: qualsiasi funzione che controlli se l’utente è autorizzato ad usare il software si riconduce, in prima approssimazione, alla restituzione di un valore 0/1 oppure true/false. Chiunque, presto o tardi, potrebbe riuscire a manipolare il valore restituito da questa funzione di autenticazione ed aggirare così il controllo, permettendo a chiunque di usare il software senza pagarlo.

In linea di massima, comunque, per garantire l’autenticità di un software commerciale si ricorre al confronto delle date, memorizzate in forma preferibilmente criptata all’interno del registro del sistema operativo. Si cerca anche di fronteggiare il fatto che l’utente potrebbe retrodatare il sistema al fine di utilizzare la versione pirata del software, mentre si cerca sempre di memorizzare la data attuale, quella di prima esecuzione del software e quella di scadenza cercando di verificare che la prima sia compresa tra le altre due. Tecniche molto utilizzate sui programmi proprietari di Microsoft ed Adobe, ma che in qualche modo si riescono – l’informatica insegna – quasi sempre ad aggirare con diversi gradi di difficoltà. Un’ulteriore opzione di autenticazione, inoltre, richiede la presenza di chiavi fisiche (USB) da associare al programma creato: in questo modo l’utente sarà vincolato dal possedere una chiave per utilizzare quel software, per quanto poi – anche qui – sia possibile emulare il comportamento di qualsiasi chiave di crittografia mediante un software artigianale (crack, generatore di seriali e così via).

La soluzione definitiva a questo problema, quindi, sembra non esistere: possono essere architettati al più sistemi per rallentare il processo, ma non – soprattutto – per costringere seriamente un utente a spendere soldi che non spenderebbe comunque. (Tratto liberamente da arstechnica)

Photo by DLR_de

Ti piace questo articolo?

0 voti

Su Trovalost.it puntiamo sulla qualità dei contenuti da quando siamo nati: la tua sincera valutazione può aiutarci a migliorare ogni giorno.

Ti potrebbero interessare (FAQ Hosting & Dintorni):

Cerca altro nel sito

Clicca sul box, e scegli la sezione per vederne i contenuti.