di Carlo Concari

Chi si diletta con il retrocomputing sa bene che i supporti magnetici non durano per sempre. Negli anni ’80 e ’90 i produttori di floppy disk dichiaravano una vita utile di circa 10-15 anni, ma col tempo abbiamo scoperto che, tenuti lontani da fonti di calore e umidità e dai campi magnetici, i floppy disk possono trattenere i dati molto più a lungo, tant’è che molti di noi hanno dischetti ancora perfettamente funzionanti dopo oltre 35 anni di vita.

Purtroppo, col passare del tempo, tutti i supporti sono destinati inesorabilmente a deteriorarsi, il che rende particolarmente necessari tutti gli sforzi volti alla preservazione.

E’ così che un membro della nostra comunità ha trovato in vendita sul web una copia di “Avventure con le Tabelline” (Interdacta, 1986, Fig. 1), uno fra i titoli più rari fra quelli usciti per il PC128S, e, senza pensarci due volte, l’ha comprato. Una volta provato, però, ecco l’amara sorpresa: il gioco non partiva. Il compratore, quindi, ha creato con il suo fido Greaseweazle un’immagine del dischetto da 3.5” e me l’ha spedita per analizzarla.

Un primo sguardo

Dalla versione inglese del software, liberamente scaricabile dai siti dedicati al BBC Micro, si sa che il programma principale è scritto in BASIC; facendo il *CAT del dischetto, però, compare il solo file !BOOT, lungo appena 100 byte. Un rapido esame del contenuto di settori presi a campione con HxC Floppy Emulator, inoltre, rileva solo alcuni brevi spezzoni di codice BASIC immersi in un mare di byte apparentemente casuali. Ciò può significare una sola cosa: il programma è criptato e memorizzato su settori nascosti!

L’analisi con HxC mostra anche numerosi settori danneggiati, compresa l’intera traccia 1 (Fig. 2). Mentre i danni alla traccia 1 sono intenzionali e fanno parte della protezione anticopia di quasi tutti i titoli Interdacta, tutti gli altri danni sono stati causati dal tempo. Fortunatamente sembra che quasi tutti i settori danneggiati siano vuoti; più precisamente, tutti tranne uno. Data la rarità del titolo vale la pena provare a recuperarlo. Forse non tutto è perduto!

We need protection !

La protezione di Avventure con le Tabelline si è rivelata sorprendentemente complessa e articolata per un titolo non “di punta”. Ci sono file e dati nascosti su settori marcati come vuoti, dati criptati e tecniche anti-debug. Il programma principale, scritto in BASIC, è stato criptato due volte, in due passate successive. Il reverse engineering della protezione ha richiesto un paio di weekend di lavoro, e chi è interessato può trovare tutti i dettagli tecnici qui.

In breve, il file !BOOT legge dati grezzi da due settori del disco contenenti un programma in linguaggio macchina che, una volta eseguito, legge un’altra porzione di codice macchina da altri settori, e così via. Persino il logo a piramide Olivetti Prodest viene caricato in questo modo. Il procedimento continua con una catena di cinque passaggi fino al caricamento in memoria del programma principale, inizialmente in forma criptata, sempre mediante lettura di dati grezzi da specifici settori. Alla fine del procedimento il programma principale viene decrittato in RAM con un procedimento in due fasi, e viene inoltre installato del codice che intercetta le pressioni di BREAK e CTRL-BREAK impedendo al computer di resettarsi e rendendo impossibile il recupero del programma dalla memoria del computer. A questo punto, finalmente, il controllo passa al gioco.

Il programma di gioco principale criptato è memorizzato sui settori che vanno (in esadecimale) da &7F a &C6. Il settore &8C fa parte di questi ed è l’unico non vuoto fra quelli danneggiati; questo danno è la ragione per cui il gioco non parte.

Decrittiamolo

Per capire l’entità del problema e valutare le possibilità di recupero occorre estrarre dal disco la versione decrittata del programma in BASIC di Avventure con le Tabelline. Farlo usando il PC128S sarebbe piuttosto complesso, dati i numerosi passaggi che caratterizzano il caricamento del gioco in memoria. Per prima cosa occorrerebbe modificare i vari programmi in codice macchina direttamente sui settori nascosti del floppy su cui risiedono in modo da eliminare gran parte dei meccanismi di protezione messi in atto durante il caricamento, come la disattivazione del tasto ESCAPE e la disabilitazione del driver VDU. Occorrerebbe poi modificare la routine di caricamento finale in modo che, una volta decrittato il codice del gioco, invece di lanciarlo ritorni il controllo all’utente; a questo punto si potrebbe salvare direttamente il gioco decrittato dalla memoria RAM al disco.

Una delle cose positive di vivere nel 21esimo secolo è la disponibilità di computer che, rispetto a quelli a 8 bit del passato, sono milioni di volte più potenti e possono far girare gli emulatori. Uno degli emulatori più evoluti del PC128S è B-Em, che dispone anche di un primitivo ma potente debugger in grado di bloccare l’esecuzione quando vengono incontrate specifiche istruzioni e salvare il contenuto della memoria su un file (Fig. 3).

Per prima cosa ho creato un’immagine del disco compatibile con B-Em, che non è in grado di gestire direttamente le immagini nei formati .scp e .hfe create da Greaseweazle. Per farlo ho convertito con HxC l’immagine .scp in un’immagine grezza (raw) contenente i soli dati dei settori, senza header e sincronismi vari. Successivamente, utilizzando un editor esadecimale, ho inserito nell’immagine raw la quantità esatta di byte che mancano nella traccia 1 (ricordate che è volutamente danneggiata) in modo da ricostruire un’immagine della dimensione corretta, in questo caso 163840 byte (40 tracce da 16 settori da 256 byte ciascuno). In questo modo l’emulatore si ritrova i dati delle tracce successive alla 1 nelle posizioni corrette.

Con il debugger di B-Em è una questione di minuti impostare un break point su una delle ultime istruzioni eseguite prima di passare il controllo al gioco, quando quest’ultimo è già presente in RAM in chiaro, e salvare il contenuto della RAM su un file, da cui si può finalmente estrarre il programma in BASIC.

Ricostruiamolo

Un volta decrittato ed estratto il programma in BASIC è possibile esaminarlo e confrontarlo con la versione inglese (Fig. 4). Si constata subito come i due programmi siano molto simili; le uniche differenze riguardano i testi che sono stati tradotti in italiano, ma la struttura e persino i numeri di riga sono rimasti identici.

Esaminando con HxC il contenuto del settore &8C si nota che la parte danneggiata, evidenziata da stanghette verticali rosse nella parte superiore, si limita alla parte finale del settore (Fig. 5). Dal listato appare subito evidente che il settore danneggiato sul dischetto ha modificato le righe di codice che vanno da 2670 a 2800, confermando che il danno ha un’estensione limitata a poche decine di byte. Fortunatamente, il danno sembra coinvolgere parti di codice prive di testo e, quindi, probabilmente identiche fra le versioni in inglese e in italiano. Si può tentare una ricostruzione binaria sovrapponendo il programma in inglese a quello in italiano e sostituendo i byte danneggiati.

Sovrapponendo i byte dei due programmi a partire dalla riga 2660 mediante un editor esadecimale si nota una sequenza di byte coincidenti interrotta da una cinquantina di byte che differiscono, corrispondenti alla parte danneggiata fra le righe 2670 e 2800. Sostituendo i byte diversi del file italiano con quelli nelle posizioni corrispondenti del file inglese, ho ricostruito il programma BASIC in italiano, che risulta perfettamente funzionante. Qui trovate la versione sbloccata e ricostruita, pronta per girare su emulatore o sul PC128S, tramite Gotek o floppy fisico.

Con il programma originale ricostruito, l’impresa potrebbe dirsi terminata qui. Tuttavia, per noi puristi, una versione sbloccata del solo programma principale non rappresenta un software nella sua interezza. Va bene per giocarci velocemente sugli emulatori e per archiviare il programma BASIC in una compilation, ma preservare completamente un software originale significa ricostruire un’immagine il più fedele possibile del prodotto, comprese le tecniche anticopia che incorpora. Grazie al Greaseweazle, oggi è possibile creare immagini a basso livello che descrivono fedelmente l’andamento del campo magnetico sulla superficie del disco. Avendo ricostruito il programma originale, è possibile ricreare un’immagine fedele del floppy originale riparando gli errori? Vediamo!

Preserviamolo

HxC Floppy Emulator è uno strumento eccezionale per esaminare immagini di floppy disk a basso livello, ma la sua vera potenza risiede nel fatto di poterle anche modificare.

Usando la funzione di zoom nella modalità “Track view”, la schermata passa da una visione d’insieme alla visualizzazione diretta dei singoli impulsi magnetici (Fig. 6). Ogni impulso corrisponde a un’inversione di polarità del segnale magnetico registrato sul disco. La codifica MFM DD usata dal PC128S prevede uno “slot” ogni 2 milionesimi di secondo, in ogni slot può esserci o non esserci un impulso. E’ proprio la sequenza degli impulsi in questi slot a codificare le informazioni. Attivando la funzione “editing” di HxC è possibile inserire o cancellare gli impulsi uno a uno, semplicemente cliccando sul relativo slot. Se uno sa quello che fa, può modificare i dati sul disco!

Per iniziare a prendere confidenza con lo strumento sono partito da uno dei settori danneggiati vuoti. Un settore vuoto formattato dal PC128S contiene una sequenza di 256 byte identici, tutti di valore &5A. Il settore &270 è vuoto e contiene, nella parte finale, un piccolo errore, correttamente indicato anche da HxC mediante una stanghetta rossa verticale (Fig. 6). In questo caso è facile “indovinare” la sequenza giusta degli impulsi: dato che tutti i byte sono uguali, basta ricondurre il byte incriminato alla stessa configurazione di quelli adiacenti. Qui, in particolare, c’è un impulso che va spostato indietro di 2 microsecondi, cioè di uno slot. Effettuando tale modifica il settore diviene verde, segno che la riparazione è stata risolutiva e il CRC risulta corretto. Il byte danneggiato passa dal valore sbagliato &58 a quello corretto, &5A (Fig. 7).

Durante le analoghe riparazioni negli altri settori danneggiati vuoti ho scoperto che HxC ha anche una funzione di “autoriparazione”, che prova “a forza bruta” tutte le possibili configurazioni di impulsi in un intervallo ristretto fino a trovare quella corretta.

Effettuate le riparazioni più facili e, purtroppo, anche meno utili, dato che interessavano settori vuoti, mi sono concentrato sul settore &8C. Zoomando verso la fine del settore compaiono numerose stanghette verticali, che indicano un danno piuttosto esteso e consistente. La funzione “autoriparazione” non sembra in grado di trovare una configurazione corretta, il che può significare due cose: o il danno è più esteso, oppure il floppy drive, durante la lettura, ha perso il sincronismo aggiungendo o eliminando slot dalla sequenza.

In ogni caso, avendo ricostruito il programma, conosco la sequenza corretta dei byte. Ma… un momento! Il programma ricostruito è quello in chiaro, mentre la versione memorizzata sul floppy è quella criptata, ricordate? Occorre quindi rigenerare la versione criptata del programma in BASIC. Per fortuna i due passaggi che lo schema di protezione usa per decrittare il gioco sono facilmente reversibili, il che significa che posso adattare gli stessi programmi in linguaggio macchina che effettuano la decodifica in modo da criptare invece che decrittare. Semplice, no?

Sono quindi tornato all’emulatore e ho caricato in memoria il programma in BASIC ricostruito e quello in linguaggio macchina che esegue la decodifica. Grazie al debugger ho modificato quest’ultimo in modo che effettui una cifratura opposta alla decodifica per cui è stato scritto (Fig. 8). In pratica, così facendo, ho ricreato la routine che gli sviluppatori di Interdacta hanno usato 36 anni fa per criptare il gioco !

Una volta eseguita la routine di cifratura ho salvato il contenuto della RAM in un file, dal quale ho recuperato il programma in BASIC criptato.

Un confronto byte per byte del file criptato con il contenuto dei settori  da &7F a &C6 del disco, che contengono il programma criptato 36 anni fa da Interdacta, mostra una perfetta corrispondenza tranne nella parte finale del settore &8C, quello danneggiato; ora che conosco anche i valori corretti dei byte da scrivere in quel settore posso riparare il danno! Il fatto che tutti gli ultimi byte del settore differiscano da quelli corretti significa con tutta probabilità che ci sono impulsi non solo errati, ma anche aggiunti o mancanti. Ecco perché la correzione “a forza bruta” non ha funzionato.

HxC non permette di modificare il contenuto di un settore semplicemente scrivendo i nuovi byte in esadecimale: occorre necessariamente agire a livello degli impulsi magnetici. Ciò significa che occorre tradurre i byte corretti in codifica MFM! La codifica MFM non è complicata; per ogni bit in ingresso ne escono due calcolati con un algoritmo a partire dal valore del bit attuale e di quello precedente. Farlo a mano su decine di byte, tuttavia, è un’operazione estremamente tediosa e soggetta a errori. Pertanto, ho scritto un semplice programmino in MATLAB per convertire i dati da esadecimale a MFM (Fig. 9).

In codifica MFM un “1” indica la presenza di un impulso in uno slot, “0” ne indica l’assenza. Verificato che il codice MATLAB funzionasse correttamente, confrontando il suo output con la visualizzazione degli stessi dati mediante HxC (Fig. 10), ho convertito i dati errati e quelli corretti e confrontato le due sequenze MFM fra loro, trovando che la sequenza errata non differiva  molto da quella corretta. A parte una manciata di impulsi da modificare, c’erano due punti in cui mancavano rispettivamente uno e tre impulsi. Una volta inseriti gli impulsi mancanti e sistemati quelli errati, il settore è diventato verde e i byte memorizzati sono diventati uguali a quelli corretti. Vittoria !

A questo punto non rimaneva che salvare l’immagine corretta, scriverla su un floppy con Greaseweazle, e provare il disco sul 128 S. Il disco è partito regolarmente: missione compiuta !