«How to Crack» — Lezione 1: un approccio

1. Che cosa è il testo

Si presenta come «Lesson #1 — An approach» di «How to Crack — The +ORC Lessons». L’autore usa la sigla +ORC e firma l’esempio pratico con la data gennaio 1996. Il tono è volutamente provocatorio: polemizza con i programmatori «commerciali», con chi progetta le protezioni e con la società che, secondo lui, subordina tutto al denaro.

Va distinto ciò che è spiegazione tecnica da ciò che è presa di posizione. Quando l’autore sostiene che le protezioni non evolvono davvero, ma ripetono vecchi trucchi, formula una tesi che si può discutere; non è una verità tecnica dimostrata nel documento.

2. La tesi iniziale: partire da programmi vecchi

Il consiglio di apertura è pedagogico: per imparare, bisogna cominciare da applicazioni vecchie con protezioni vecchie. Il motivo è che le tecniche di base sono più leggibili: programmi piccoli, poche funzioni, meno livelli di astrazione. Imparate quelle, secondo l’autore, si riconoscono più facilmente anche gli schemi moderni, spesso variazioni di idee già note.

È il ragionamento di chi impara a suonare partendo da brani semplici: non perché siano più importanti, ma perché mostrano la struttura senza coprirla di complessità.

I quattro requisiti

• Una conoscenza almeno essenziale dell’assembler: senza leggere le istruzioni della CPU non si capisce che cosa un programma stia realmente facendo.
• Intuizione: capacità di scegliere dove guardare quando le possibilità sono moltissime.
• Aiuto di persone più esperte: il sapere circolava allora in comunità, newsgroup e archivi.
• Una «mente non mercantile»: è il requisito più ideologico; l’autore lo presenta come un atteggiamento verso la conoscenza, non come una competenza tecnica.

3. Le sette famiglie di protezione

Il testo classifica i programmi da studiare in sette categorie, dalla più semplice alla più elaborata. È una tassonomia utile perché separa che cosa viene controllato.

Nel resto della lezione l’autore usa soprattutto la seconda categoria: una demo che permette di giocare per due minuti.

4. Dove trovare «materiale di studio»

L’autore osserva che le riviste con CD-ROM allegati contenevano molte versioni dimostrative e che i giochi, per le loro dimensioni ridotte, mostrano protezioni relativamente sofisticate in file facili da esplorare. Il ragionamento è tecnico: cercare un controllo in un singolo eseguibile piccolo è più semplice che cercarlo in grandi collezioni di moduli.

Qui il testo diventa anche problematico. Parla di usare per sempre programmi in prova, di distribuirli e, più avanti, di applicare le stesse conoscenze a servizi remoti e perfino a sistemi bancari. Sono affermazioni che non vanno lette come raccomandazioni: l’elusione di una protezione, la distribuzione di copie o l’accesso non autorizzato a sistemi possono violare norme sul diritto d’autore o penali, secondo il caso e il Paese.

5. Il caso di studio: una demo a tempo limitato

L’esempio è una versione dimostrativa di un gioco di biliardo del 1994, distribuita su CD allegati a riviste nel 1995. Dopo circa due minuti compare una schermata che invita ad acquistare il programma completo. Il problema posto è: dove, nel codice, il programma decide che il tempo è scaduto?

5.1 Il metodo: confrontare fotografie della memoria

Invece di leggere subito migliaia di istruzioni, l’autore propone di osservare gli effetti. Si registra lo stato della memoria in momenti diversi, senza toccare il programma, e si confrontano le fotografie. Le celle che cambiano mentre il tempo passa sono candidate a essere contatori. È una strategia molto generale: ridurre un problema enorme alle poche posizioni che si comportano in modo coerente con l’ipotesi.

L’ambiente è quello di un debugger residente in DOS, che permette di fermare l’esecuzione, ispezionare memoria e registri, confrontare vettori di interruzione. Il testo ironizza con il momento «zen»: guardare i dati, aspettare che il disegno diventi riconoscibile.

5.2 Primo tentativo: la costante di ricarica

Il primo indizio è una posizione che viene ricaricata con il valore esadecimale 3C, cioè 60 in decimale, e poi decrementata fino a zero. L’autore la interpreta come il contatore dei «passi» che compongono un secondo: quando arriva a zero, il programma sottrae un secondo al tempo disponibile.

L’idea sembra ragionevole: aumentando il valore di ricarica, ogni «secondo» dovrebbe durare più a lungo. Il testo la presenta però come un esempio di ragionamento apparentemente corretto che non risolve il problema.

5.3 Secondo tentativo: le posizioni gemelle

La modifica non produce alcun effetto perché la ricerca trova due posizioni con la stessa sequenza di byte. Secondo l’interpretazione proposta dall’autore, la seconda funge da controllo o specchio e può correggere la prima; il documento non fornisce però un’analisi completa che dimostri tale rapporto. L’autore lo usa per ricordare che una ricerca con più risultati va letta per intero, non fermandosi al primo.

Quando entrambe sono cambiate, il gioco sembra più lento — e proprio qui arriva la lezione più importante.

5.4 Il vero errore: confondere l’indicatore con la causa

Dopo la modifica, il tempo mostrato sullo schermo scorre più lentamente. Ma la schermata di fine prova compare comunque, dopo circa 28 secondi di tempo visibile. Il contatore modificato governava ciò che l’utente vede, non la condizione che decide la scadenza. Il programma conosceva il tempo reale in un altro modo.

È una distinzione che vale ben oltre il cracking: nel debugging, nelle misure fisiche e nell’analisi dei dati, cambiare un indicatore non equivale a cambiare il fenomeno che esso rappresenta.

6. L’interruzione del timer, spiegata

Per capire il passaggio successivo servono alcune nozioni dell’architettura dei PC DOS.

• Timer hardware. Un chip temporizzatore, della famiglia 8253/8254, genera un segnale periodico. Il BIOS lo programma in modo da produrre circa 18,2 interruzioni al secondo, cioè una ogni 55 millisecondi. Approfondimento sul timer.
• IRQ0 e INT 08h. Il segnale arriva al controllore delle interruzioni come IRQ0 e provoca l’esecuzione del gestore associato all’interruzione 08h. Il gestore del BIOS aggiorna l’orologio di sistema. Documentazione tecnica.
• INT 1Ch. Alla fine del gestore, il BIOS richiama l’interruzione software 1Ch, normalmente priva di effetti. Serve a offrire ai programmi un punto semplice dove agganciarsi a ogni tick senza sostituire il gestore principale. Documentazione tecnica.
• EOI. Un gestore personalizzato deve comunicare al controllore che l’interruzione è terminata, altrimenti le successive potrebbero non essere servite. Il testo lo riconosce nel gestore sostituito dal programma.

Il programma di prova aveva «agganciato» direttamente INT 08h, non INT 1Ch. L’autore ne conclude, con ragione, che quel punto fosse un buon sospettato: se un software intercetta il timer, può contare il tempo con una propria routine.

Una parentesi: disattivare il timer

Il testo spiega anche che è possibile mascherare l’interruzione del timer scrivendo in una porta del controllore, fermando l’avanzamento dell’orologio DOS. È un esperimento didattico che mostra come l’hardware possa essere governato direttamente. L’autore avverte però che con il timer fermo altri componenti si comportano male: per esempio il motore del floppy può restare acceso.

Nel caso della demo la tecnica non basta, perché il programma non dipende soltanto dal tick standard. La parentesi serve quindi a due scopi: insegnare un meccanismo e mostrare che una tecnica interessante non è necessariamente quella giusta per il problema.

7. La soluzione trovata e il suo significato

Dopo aver cercato a lungo nei gestori delle interruzioni senza trovare la protezione, l’autore torna ai dati raccolti. Nota due posizioni in cui un valore cambia lentamente, mentre quello vicino percorre rapidamente l’intero ciclo: l’autore li interpreta come i byte basso e alto di un unico contatore a 16 bit. Non viene riprodotta una traccia completa che permetta di verificare ogni passaggio di questa identificazione.

Il calcolo che gli permette di prevedere il valore limite è semplice: 60 passi al secondo per 120 secondi dà 7200, cioè 1C20 in esadecimale. Cercando quel numero nel codice trova un confronto seguito da un salto condizionale: se il contatore è inferiore al limite, il gioco continua; altrimenti viene richiamata la routine della schermata di scadenza.

La lezione è che il valore giusto non si indovina soltanto guardando i dati: si deduce da ciò che già si è capito del sistema. Quando i numeri tornano, l’ipotesi diventa molto più credibile.

Perché «effetti» e non «protezione»

Il primo principio enunciato è: se puoi eliminare gli effetti di una protezione, non cercare oltre. Ha senso per chi lavora con un obiettivo pratico; meno se si studia il meccanismo per capirlo. L’autore lo contraddice parzialmente nel suo stesso esempio, perché senza la comprensione del vero controllo la prima correzione non funzionava.

Una modifica «debole» e una «radicale»

Il testo distingue fra l’alterare il limite, che concede più tempo, e l’annullare la condizione del confronto, che elimina la scadenza. Raccomanda per i limiti temporali un intervento delicato, rimandando la ragione a una lezione successiva che non è presente nel documento. Questa parte è quindi incompleta: l’affermazione viene dichiarata, ma non giustificata.

8. Osservazioni sulla precisione del testo

Una lettura attenta mostra alcune imprecisioni nei numeri. Non cambiano il metodo, ma è importante non copiarle come fatti.

• EE al posto di 3C. Il valore di ricarica passa da 60 a 238: il rapporto è circa 3,97, quindi quasi quattro volte. Il testo parla prima di «quattro volte» e poi di arrivare a 12 minuti; con una durata iniziale di due minuti, il risultato atteso sarebbe invece circa otto.
• Il limite 4C20. L’autore lo presenta come un tempo di quattro minuti. Assumendo, come fa il testo, che il contatore avanzi di 60 unità al secondo, 4C20 corrisponde a 19.488 unità, cioè circa 325 secondi: poco più di cinque minuti e venti secondi. Quattro minuti avrebbero richiesto 14.400 unità, cioè 3840 in esadecimale.
• Le 60 unità al secondo. Non coincidono con i 18,2 tick standard del BIOS. Il testo non spiega come il programma ottenga la propria scansione temporale; è plausibile che usi un timer riprogrammato o una routine propria, ma questa è un’inferenza, non un’affermazione dell’autore.

9. Il secondo percorso: guardare all’indietro

L’autore descrive un metodo alternativo: osservare le istruzioni eseguite subito prima della schermata di scadenza. In una fase ripetitiva, lo stesso schema compare molte volte; poi, quando scatta il limite, l’esecuzione prende una strada diversa. Il punto in cui la sequenza cambia indica dove la decisione viene presa.

Lo giudica però instabile: dipende dal momento in cui si ferma il programma e dalla distanza fra controllo e schermata. È un buon esempio di compromesso fra metodo rapido e metodo affidabile.

10. Quando non serve fare nulla

La parte finale ricorda il caso di una demo che conteneva, nei fatti, componenti della versione completa. L’autore vuole mostrare che talvolta la limitazione è fragile non per una tecnica brillante, ma per superficialità del produttore.

Il passaggio ha un significato più ampio: prima di decidere che un sistema richiede analisi sofisticata, conviene verificare quali risorse siano già disponibili e a quali condizioni funziona davvero.

11. Il contesto storico e legale

Il documento nasce nell’epoca delle comunità sotterranee di reverse engineering, dei newsgroup e dei remailer anonimi. L’indirizzo anon.penet.fi, citato per ricevere le lezioni mancanti, era un servizio finlandese di posta pseudonima: venne chiuso nell’agosto 1996 dopo pressioni giudiziarie. Cronaca del 31 agosto 1996.

Questa pagina è un commento storico e didattico, non un’autorizzazione a eludere licenze, distribuire copie o accedere a sistemi altrui. Gli eventuali esperimenti vanno limitati a software proprio o a esercizi predisposti e autorizzati. La disponibilità di una demo non equivale, da sola, al permesso di modificarla o redistribuirla.

12. Che cosa può imparare oggi un lettore

• Dal fenomeno alla causa. Un valore che cambia sullo schermo può essere solo un riflesso di un meccanismo nascosto.
• Verificare con un secondo punto di vista. Il metodo del confronto e quello a ritroso producono risultati diversi, e la loro coerenza rafforza la conclusione.
• Usare la matematica per controllare un’ipotesi. La coincidenza fra 60 per 120 e 1C20 è ciò che rende credibile il ritrovamento.
• Documentare gli errori. L’esempio è efficace perché non nasconde le false piste.
• Distinguere cultura tecnica e responsabilità d’uso. Capire come funziona una protezione non autorizza a ogni utilizzo di quella conoscenza.

Glossario essenziale

Debugger

Strumento che permette di fermare un programma, osservarne memoria e registri e seguirne l’esecuzione.

Esadecimale

Sistema numerico in base 16, molto usato nei calcolatori. 3C vale 60 e 1C20 vale 7200.

Interruzione

Evento che sospende temporaneamente il programma e trasferisce il controllo a una routine specifica.

Gestore o ISR

La routine che risponde a una interruzione.

Hook

Aggancio con cui un programma sostituisce o affianca un punto di controllo del sistema.

Nag screen

Schermata che invita insistentemente ad acquistare il programma o a registrarlo.

Salto condizionale

Istruzione che sceglie quale percorso seguire in base al risultato di un confronto.