In breve
La quarta lezione riguarda le protezioni a tempo: prove che scadono dopo un numero di giorni, a una data fissa, dopo alcuni minuti o dopo un numero di avvii. Il testo analizza due programmi shareware del 1995-1996, poi riporta il lavoro di studenti della +HCU su una versione a 16 bit e una a 32 bit dello stesso prodotto.
Questa pagina spiega come funzionano questi schemi, che cosa fa ogni caso e quali debolezze di progetto emergono. Il documento contiene anche ricette precise per aggirare i limiti: qui non le riporto, né come sequenze di byte né come passaggi da ripetere.
1. Le quattro famiglie
| Nome nel testo | Che cosa limita | Che cosa deve ricordare il programma |
|---|---|---|
| Cinderella | Un periodo (per esempio 30 giorni) dalla prima installazione | La data di inizio |
| Best before | Una data fissa | Quasi nulla: basta la data di scadenza |
| Countdown | Minuti o secondi per ogni avvio | Il tempo trascorso nella sessione |
| Quiver («faretra») | Un numero di utilizzi | Un contatore |
L'autore ammette che il contatore non dipende dal tempo, ma lo include perché la struttura è simile. Il punto comune è che un programma che deve ricordare quanto ha già concesso deve conservare uno stato tra un avvio e l'altro. Quello stato è la parte più delicata del sistema.
2. Primo caso: un database con due limiti
Il programma del 1995 si disattiva dopo 90 giorni o 25 sessioni, a seconda di quale limite arrivi prima. L'eseguibile è piccolo (8.912 byte) perché contiene soprattutto la protezione. L'applicazione vera sta in una DLL molto più grande, caricata solo se i controlli vengono superati.
Come viene letto
- Si cercano i testi. Parole come «demo», «expire» o «evaluation» portano ai messaggi mostrati alla scadenza.
- Si risale ai confronti. Ogni messaggio è preceduto da una condizione. Il programma non usa il numero 25 ma una coppia di valori: la differenza tra 0x66 (102) e 0x4D (77) è 25. Chi cerca soltanto 25 non lo trova.
- Si osserva dove cambia lo stato. Confrontando un file prima e dopo alcune esecuzioni si scopre che il contatore è un byte nascosto nella DLL, senza cambiare la data del file.
- Si separano i meccanismi. Contatore e confronto tra date sono due protezioni distinte e richiedono analisi distinte.
Il limite di 90 giorni
Il confronto usa un valore a 32 bit, diviso in due parole a 16 bit. La soglia è 0x0076A700, cioè 7.776.000: i secondi di 90 giorni (90 × 86.400). Il testo scrive «A700 = 42572», ma in decimale A700 vale 42.752: è un refuso. Il programma ricava le date dai servizi DOS e converte l'anno in giorni complessivi.
Il comportamento distruttivo
Dopo la scadenza il programma cancella la DLL principale senza avviso. Il testo lo presenta come curiosità. Per chi studia software sconosciuto è anche un avvertimento pratico: va eseguito in un ambiente isolato, perché può danneggiare dati.
3. Secondo caso: scadenza, funzioni ridotte e sblocco
Il secondo prodotto è una suite di tre strumenti diagnostici scritta nell'agosto 1996. Il testo lo descrive con quattro proprietà: scade dopo 21 giorni (0x15), ha funzioni disattivate, è «ridotto» e può essere sbloccato con una chiave elettronica ricevuta dopo la registrazione. In questo caso la protezione non è nell'eseguibile principale ma in due DLL di supporto.
Il problema dell'orologio
Un controllo del tipo «oggi è dopo la data iniziale più 21 giorni» si elude riportando indietro l'orologio. L'autore descrive la contromisura: una posizione che può solo crescere, come un diodo. Se il programma rileva una data oltre il limite, segna la scadenza come definitiva. Tornare alla data reale non la cancella.
Dove viene ricordato lo stato
Secondo il testo, il programma distribuisce informazioni in tre luoghi: un file nascosto nella cartella di Windows, una riga nel file di configurazione di sistema e una voce nel registro. I valori hanno la forma di identificativi con un numero centrale che cambia nel tempo. È una tecnica di ridondanza: reinstallare il programma non basta, perché i resti precedenti indicano che la prova è già stata usata.
Come si arriva alla funzione di sblocco
Le tracce più utili non sono nelle stringhe del codice ma nelle risorse delle finestre. Uno strumento per le risorse mostra le finestre di dialogo, i loro pulsanti e gli identificatori numerici. Cercando lo stesso numero nel disassemblato si arriva al codice che legge la chiave inserita e al messaggio di conferma. Lo stesso metodo individua due versioni della finestra «Informazioni»: una per gli utenti registrati e una per chi usa la prova.
4. Il lavoro degli studenti
Dopo la lezione di +ORC, il documento riporta contributi della +HCU. Qui conviene separare ciò che mostrano come metodo dalle modifiche applicate.
- Nascondere i nomi. Un file di sistema viene indicato un carattere per volta, così non appare come una stringa continua. Lo studente osserva che è una difesa debole: il nome compare comunque nel codice come sequenza di byte.
- Estensione dei file. Una seconda estensione suggerisce che esista un file diverso dopo la registrazione. È un'ipotesi che lo studente verifica con un esperimento: cambiando il nome, il programma si limita a scrivere il file con un altro nome.
- Confrontare prima e dopo. Salvare lo stato prima e dopo la scadenza rivela che il file di controllo contiene sia la data sia l'informazione «scaduto».
- Funzioni sulla data. Cercando le chiamate DOS che leggono la data si scopre che il programma usa direttamente i servizi di sistema invece di una sola funzione di libreria.
- Test sul tempo. Per verificare scenari futuri lo studente usa un piccolo programma che cambia la data per il solo avvio del bersaglio. Annota anche un dettaglio utile: l'orologio deve gestire il passaggio della mezzanotte.
L'esperimento sulla durata di 21 giorni non è del tutto concluso: gli studenti ammettono di non aver atteso tre settimane per essere certi di tutti i casi limite. È un'importante precisazione scientifica: un test breve con date simulate non dimostra ogni comportamento reale.
5. Il «punto cavo»: un'unica decisione
La parte più istruttiva è la conclusione dei due contributori. Dopo aver studiato file, registro e date, scoprono che molte strade convergono su un solo punto: una funzione restituisce un codice, e il programma decide se proseguire oppure mostrare un errore. Nel codice a 32 bit i valori diversi corrispondono a licenza scaduta, licenza modificata, copia senza licenza, versione vecchia o errore generico.
La struttura è efficace per chi progetta e per chi analizza:
- un unico confronto controlla un sistema complicato;
- i messaggi mostrano il significato dei codici interni;
- la stessa logica compare nella versione a 16 e in quella a 32 bit, quindi il metodo è trasferibile.
Per un autore di software la lezione è opposta: l'intera funzione di verifica dipende da una scelta locale sul computer dell'utente. Una scadenza è difficile da rendere affidabile se la decisione finale, i dati e il codice stanno tutti sulla macchina controllata da chi dovrebbe essere limitato.
Il testo dice che quel punto è stato individuato grazie al suggerimento di +ORC sulla seconda occorrenza del numero 0x15, cioè 21. Il valore compare più volte, ma una soltanto accompagna la preparazione e il controllo della verifica. La spiegazione non basta però a stabilire che tutte le versioni del prodotto si comportino allo stesso modo.
6. Un altro schema: date in secondi
Alla fine compare un frammento incompleto, che +ORC lascia senza spiegazione. Mostra una sezione di configurazione con tre valori numerici: installazione, scadenza e ultimo utilizzo.
| Valore | Interpretazione come data Unix (UTC) |
|---|---|
| 854824551 | 1 febbraio 1997 |
| 857416551 | 3 marzo 1997 |
| 854824717 | 1 febbraio 1997, 166 secondi dopo l'installazione |
La differenza tra scadenza e installazione è 2.592.000 secondi, cioè 30 giorni (86.400 secondi al giorno). La lettura come data Unix è un'interpretazione coerente con i numeri, ma il testo non la dichiara. Il frammento resta un indizio, non una dimostrazione. Mostra comunque un'alternativa più semplice agli schemi nascosti: tutto l'intervallo concesso in un'unica sezione leggibile.
7. Lettura critica
- Il tono. Il documento definisce gli autori «stupidi» e parla di software come cose che dovrebbero essere gratuite. Sono giudizi dell'autore, non argomenti tecnici. Un limite di prova è una scelta commerciale legittima del titolare, anche quando la protezione è debole.
- La distribuzione. Il testo suggerisce di procurarsi i programmi con ricerche FTP o con CD-ROM economici. Il fatto che una copia circoli non la rende autorizzata.
- Le ricette. Le sezioni che indicano che cosa modificare trasformano l'analisi in un uso concreto. Non le pubblico perché servirebbero a usare oltre i limiti concessi un software commerciale.
- Le prove mancanti. Le affermazioni sull'efficacia delle modifiche provengono dagli studenti. Non le ho eseguite e non posso confermarle.
- La fine del file. Il testo ricevuto termina nell'invito a scrivere a +ORC per ottenere le lezioni mancanti, interrotto a metà frase. Non posso dire se la copia originale continui.
8. Che cosa si impara per progettare meglio
- Lo stato di una prova non va nascosto in un solo file né affidato a una convenzione facile da riconoscere.
- I controlli sparsi in molti punti non bastano se tutti dipendono da una sola decisione finale.
- Il codice, la data e la memoria della prova sono tutti sotto il controllo dell'utente. Una verifica lato server o una licenza firmata digitalmente riduce il problema, senza eliminarlo.
- I messaggi d'errore descrivono la logica interna. Distinguere gli stati con codici diversi aiuta il supporto, ma aiuta anche chi osserva il programma dall'esterno.
- Un'esperienza utente chiara (limiti, funzioni disattivate, istruzioni di registrazione) è più importante di una protezione che punisce l'utente onesto.
Glossario
- Shareware
- Software distribuito per la prova, con acquisto o registrazione per l'uso completo.
- Cinderella
- Nome scherzoso per la scadenza dopo un periodo, come a mezzanotte nella fiaba.
- Quiver
- Protezione basata sul numero di utilizzi.
- DLL
- Libreria di codice caricata da un programma Windows.
- Registro di sistema
- Archivio di impostazioni di Windows.
- Dead listing
- Disassemblato letto su carta o a schermo senza eseguire il programma.
- Data Unix
- Secondi trascorsi dal 1 gennaio 1970 UTC.
Fonte e verifiche
Il testo è stato ricevuto in tre blocchi incollati dall'utente, non come file allegato; non è quindi disponibile come «ORC_4.DOC» nel mio archivio. Ho controllato i calcoli sulle soglie e sulle date. Non ho eseguito programmi né applicato modifiche.