How to dismantle a Logic Bomb

Anni fa gli U2 pubblicarono un album, dal titolo "How to dismantle an Atomic bomb".
Era il 2004, ed all'epoca io ero molto impegnato a godermi la mia nuova moto...Ma questo non mi impediva certo di continuare a combinare le mie belle marachelle informatiche in casa. A dire il vero, questa che vi racconto oggi è una delle primissime sciocchezze che mi sia mai capitato di fare ed è strettissimamente collegata con il post precedente. Se nel 1982 i loop si facevano in BASIC, a partire dal 1991 cominciai a farli un po' più seri con Ms-DOS.
All'epoca ero fortunato possessore di un brillantissimo (all'epoca) 80386DX40, ovviamente affiancato dal coprocessore FPU 80387. In quegli anni i PC venivano anche chiamati "cloni", in quanto era appena partito alla grande il mercato del personal computing ed era pertanto facile trovare assemblatori ad ogni angolo delle strade. Più o meno chiunque avesse a disposizione quattro mura si metteva a comprare ed a mettere insieme motherboards, schede video, case, alimentatori per poi venderli. Il mio sistema usava un 80386 prodotto da AMD (quando ancora la AMD era una dittarella), saldato sulla scheda madre perchè, all'epoca, l'idea di bruciare una CPU non passava per l'anticamera del cervello di nessuno, ed i produttori di CPU si facevano pagare soldoni per confezionare i chip in voluminosi e complicati package flip chip dotati di centinaia di pin. Come conseguenza di ciò, anche le mainboard dotate di socket costavano betoniere di quattrini! All'epoca i processor socket erano ad incastro "semplice" e sulle mainboard normalmente non ce n'erano. C'era la CPU saldata sulla scheda e basta. Su quelle un po' più "sofisticate" se ne trovava solo uno idoneo al montaggio del famigerato coprocessore 80X87. Fino alla serie 486, infatti, non tutte le CPU erano dotate nativamente di una Floating Point Unit integrata. Effettuavano le operazioni in virgola mobile "emulando" le operazioni con una serie di istruzioni più elementari. Paradossalmente, ciò che all'epoca costava di più, in un computer, non era la CPU, nè la scheda video. Il vero capitale era la RAM. I sistemi impiegavano dei costosissimi moduli SIMM che venivano venduti a tagli da 256KB, 512KB, 1MB, 2MB e 4MB. I primi, ovviamente costavano relativamente poco, ma dato che le mainboard supportavano solo 8 slot (utilizzabili tassativamente a coppie), era logico che venissero usati tipicamente 8 moduli da 256KB per avere la bellezza di 2 MB di RAM. Io ero all'epoca un privilegiato, perchè comprai il computer fornito di 4 moduli da 1MB. pertanto potevo vantare la bellezza di 4 Mega di RAM. E vi lascio immaginare la mia gioia estrema quando un giorno, in ufficio da mio padre, trovai 2 moduli da 2MB che erano stati dismessi da una loro titolatrice CHYRON per far spazio a 2 moduli da 4 MB. Li portai a casa e li montai nel PC con la stessa cura ed attenzione che un neurochirurgo adopera quando ficca le mani in un cranio umano. Ora ero il fortunato possessore di un PC 386DX40 con coprocessore 387, 8 MB di RAM, scheda video VESA, Hard Disk da 40 MB, Ms-DOS 5.0 e Windows 3.0!
Credetemi, all'epoca era davvero un pezzo forte, che suscitava l'invidia di tutti i miei compagni di scuola. Vi basti sapere che ci potevo persino giocare a Wolf3D a tutto schermo!
Al tempo, Windows era per me sostanzialmente inutile. Di fatto non lo caricavo mai, dato che tutto quello che mi serviva fare lo potevo tranquillamente e molto più efficacemente fare rimanendo in DOS mode. L'unico vero limite del DOS mode era il fatto che la memoria "visibile" ai programmi era limitata a 640KB, perchè MS-DOS era un sistema a 16 bit. Era ovviamente disponibile un driver dos extended mode che permetteva di indirizzare la memoria a 32 bit tramite paging, ma dato che di norma nessun programma occupava più di 2MB di RAM, difficilmente si poteva sentirne l'esigenza. Ad ogni modo, in quegli anni io andavo a scuola e stavo imparando a programmare in Turbo Pascal. Il principale problema di MS-DOS era che non era affatto un sistema operativo multitasking, pertanto era impossibile sviluppare software che operasse tramite IPC (Inter Process Communication). Come si poteva ovviare a tutto ciò? Il modo più semplice (ed abusato) era quello di avviare i programmi tramite dei batch script (i famosi file con estensione .bat) e creando per quanto possibile dei moduli indipendenti che, tramite un menù ed il trasferimento dei dati via filesystem, permettesse di alternare l'elaborazione. Concettualmente semplice, praticamente un casino.
Fu proprio in occasione della produzione di un batch file per lanciare un set di 2 programmi che innescai la mia prima bomba logica.
A scuola ci insegnavano la programmazione Top-Down, dal macro al micro, dagli algoritmi in metalinguaggio al codice compilabile...
A casa si apriva l'IDE e si scriveva direttamente il codice, sviluppando per debug incrementale.
Produssi pertanto due exe: il primo, chiamato menu.exe, non faceva altro che disegnare un menù sullo schermo, raccogliere l'input, metterlo in un file ed uscire. Il secondo, chiamato elabora.exe, apriva il file, leggeva cosa c'era scritto, faceva una operazione in funzione di quanto aveva letto, cancellava il contenuto del file ed usciva. Il tutto veniva lanciato da un batch file, chiamato avvio.bat, che conteneva il seguente codice:

:inizio
menu.exe
elabora.exe
goto inizio
:end

Ovviamente il tutto, messo così, non darebbe alcun problema se non fosse che, come è facile immaginare, si tratta di un loop infinito. Manca la condizione di uscita. Certo, sarebbe bastato un semplice IF nel file batch. Il problema è che io volevo che la condizione d'uscita fosse selezionabile nel menù del programma e non dipendente dallo script di avvio.
Introdussi quindi nel codice di elabora.exe una routine che, nella mia mente di programmatore ragazzino, avrebbe dovuto risolvere il problema. Avrei aperto il file batch dall'interno dell'eseguibile ed avrei modificato la riga del goto cambiando la label, da "inizio" a "end". Stavo per addentrarmi nel terreno inesplorato del polimorfismo...
Feci un po' di prove e sembrava che tutto funzionasse bene...decisi quindi di impaccare il tutto e di lanciare il mio batch
_______________________

C:\Programma> Avvio.bat

                                    MENU'
   Digita un numero per selezionare l'opzione desiderata, quindi premi invio:

                              1) Opzione 1
                              2) Esci dal programma

Scelta> 2

Mi aspettavo che il programma sarebbe uscito al prompt, invece tornò al menù...
Mi venne pertanto il dubbio che non avesse modificato come desiderato il file batch, pertanto mi domandai come fosse possibile cambiare il programma durante l'esecuzione.
Ve la faccio breve: non riuscivo a capire che il file batch che chiamava gli eseguibili rimaneva "bloccato" dal sistema, rendendone impossibile la modifica. Cercate di capire una cosa: all'epoca non c'era Internet in casa, pertanto trovare la soluzione al mio problema "online" non era una opzione praticabile. Tutto il supporto che potevo avere era quello fornitomi da un manuale di Ms-DOS.
Lì dentro trovai la fatidica risposta ai miei quesiti: la funzione "CALL".
la funzione Call permette ad un batch di richiamare un altro batch, eseguirlo, quindi ripassare l'esecuzione al batch chiamante.
Ecco allora l'idea: il batch di avvio chiama il programma del menù tramite una call ad un batch che chiama menù.exe
Quindi menù.exe oltre a scrivere il file contenente l'opzione per elabora.exe, scrive anche il batch che lo chiama, in maniera tale che se l'opzione scelta non è quella di uscita, allora il batch conterrà una call al batch che lancia il menù.
Tralascio ogni considerazione sul fatto che, come è evidente, un programmatore motivato è sempre capace di trovare una soluzione che aggira i limiti imposti dal sistema. Sta di fatto che avevo creato un loop potenzialmente devastante.
Ed infatti alla prima esecuzione il sistema non fece una piega, salvo cominciare a dare un po' i numeri dopo una trentina di volte che rieseguivo il ciclo senza uscire dal programma...
Avevo creato una bomba logica che dopo un certo numero di cicli saturava la memoria del computer.
La cosa paradossale è che ancora oggi il problema delle bombe logiche non è affatto risolto.
Se non ci credete, provate voi stessi, con il seguente semplicissimo batch file.

!!!!ATTENZIONE!!!!

Il codice qui sotto è una VERA bomba logica. Se lo lanciate ben difficilmente sarete in grado di fermare il computer dal saturarsi e l'unico modo che avrete per interrompere il loop sarà quello di spegnere fisicamente il computer. Pertanto accertatevi di avere salvato tutto e di aver creato un punto di ripristino, dato che lo spegnimento "brutale" del sistema, per quanto completamente innocuo nel 99.99% dei casi, ha sempre uno 0.01% di probabilità di rovinare il filesystem da qualche parte.

aprite un command prompt e digitate il comando:

echo start bomb.bat > bomb.bat

A questo punto vi è sufficiente lanciare bomb.bat per far partire una cascata di finestre di CMD che in breve tempo renderanno il computer inutilizzabile.

Le bombe logiche, nelle loro più disparate varianti, sono tecnicamente da ascrivere alla categoria dei Denial of Service (DoS).