Il Significato di Hack

La parola hack non ha 69 significati come si dice, in accordo con l'hacker Phil Agre dell'MIT. Infatti, hack ha solo un significato, estremamente sottile e profondo tale da non poter esser confuso. Questa connotazione è tacita secondo l'uso di altre parole simili che ne contengono una definizione univoca. Stesse annotazioni valgono anche per altre parole hacker, la cui più nota è random.

L'hacking dev'esser caratteristico come un applicazione ingenua. Qualora il risultato sia un veloce groviglio di lavori o un attento lavoro artistico, devi ammirarne l'abilità che c'è dietro.

Un importante significato secondario di hack è la creazione di applicazioni scherzose. Questo tipo di hack è più semplice da spiegare ai non-hacker del tipo di programma. Di certo, alcuni hack hanno entrambe le nature; controlla il dizionario alla voce pseudo e kgbvax. Qui ci sono alcuni esempi di burle che illustrano lo spirito hacker:

Nel 1961, gli studenti del Caltech (California Institute of Technology, di Pasadena) hackarono il Rose Bowl football game. Uno studente simulandosi reporter intervistò il direttore dell'Università di Washington riguardo dele montature pubblicitarie (queste montature coinvolgevano le persone in stand differenziati a seconda del colore del disegno). Il reporter capì esattamente come funzionava la montatura, e anche che il direttore voleva uscire per andar a cenare.

Mentre il direttore stava cenando, gli studenti (che si fecero chiamare i 14 indemoniati) forzarono la serratura e rubarono un foglio bianco dalla direzione per le montature. Dopo ne stamparono 2300 copie. Il giorno seguente forzarono di nuovo la serratura e rubarono il progetto per la diffusione di massa dei fogli colorati con le i disegni pubblicitari. Utilizzando questa come guida, loro fecero nuove indicazioni per tre delle montature sui duplicati bianchi. Infine, fecero irruzione un altra volta, rimpiazzando il progetto ruato e sostituendolo con delle nuove istruzioni false per il fogli originari.

Il risultato fu di tre disegni completamente diversi. Invece di WASHINGTON, risaltava la parola CALTECH. un altra pubblicità mostrava la parola HUSKIES, il nomignolo della Washington, ma scritto al contrario. E così come si pensa, la figura di un husky al posto di un castoro. (sia Caltech che MIT sfruttano la naturale capacità tecnica del castoro come mascot.)

Dopo aver giocato, i rappresentanti della facoltà di atletica di Washington dissero: molte idee sono ingegnose; altre sono indegne. Il presidente dell'assemblea studentesca di Washington osservò: Non era difficile da capire, ma sul momento era incredibile. Ne siamo rimasti stupiti.

Questo è ora considerato un hack classico, perchè rivedere i fogli della direzione costituiscono una forma di programmazione.

Qui ci sono altri hack classici:

Il 20 Novembre 1982, MIT hackò la partita di football Harvard-Yale. Solo dopo il secondo touchdown di Harward contro Yale, nel primo quarto, una piccola palla nera comparì fuori dal campo all'altezza della linea delle 40 yard, e si ingrandì sempre di più. Le lettere MIT comparirono sulla superficie della palla. Sia i giocatori che gli allenatori goffamente attorniarono la attoniarono; la palla crebbe fino ad avere un diametro di 6 piedi e poi bruciò con un esplosione e emanando una nuvola di fumo bianco.

Il Boston Globe riportò: se volete sapere la verità, MIT ha vinto La Partita.

Lo scherzo ha impegnato settimane per la preparazione accurata del piano da parte dei membri della confraternita Delta Kappa Epsilon del MIT. Il trucco consisteva in un pallone metereologico, un pistone idraulico funzionante a gas Freon per alzarlo fuori dal campo, e un motore per vuoto per gonfiarlo. Hanno fatto otto spedizioni separate all'Harvard Stadium tra l'1 e le 5 AM, collocando un insolito circuito da 110 volt nello stadio e tirarono fili elettrici dal circuito nello stadio alla linea delle 40 yard, dove avevano posizionato il pallone progettato. Quando arrivò il momento di azionare il dispositivo, due membri della confraternita hanno semplicemente acceso il circuito e messo un tappo sull'uscita.

Questo scherzo ha tutte le caratteristiche del perfetto hack: sorpresa, pubblicità, un uso ingegnoso della tecnologia, sicurezza e innocuità. L'uso del controllo manuale ha dato la possibilità al congegno di esser regolato in modo da non disturbare il gioco (era regolato per agire tra i tempi, così da non influenzare il gioco). Gli esecutori hanno anche pensato di attaccare una spiegazione del funzionamento del pallone facendo notare che non era nè pericoloso nè conteneva esplosivi.

Il rettore di Harvard Derek Bok commentò: Avete un numero spaventoso di abili studenti al MIT che lo faranno di nuovo.Il Preside Paul E. Gray del MIT disse: E' assolutamente falsa la voce che io abbia qualcosa a che fare con loro ma li vorrei aver qui.

L'hacks seguente è una storia verificabile; potete provarla per vederne le conseguenze. Molte altre storie di hack classici dal MIT e ovunque, anche raccontate come storie, hanno le caratteristiche di cosa Jan Brunvand chiamò folklore metropolitano (vedi FOAF). Forse la più conosciuta di queste è la leggenda dell'infame carretto hackato, un incidente nel quale uno studente d'ingegneria disse di aver saldato un carretto al suo furgone col termite. Numerose versioni di ciò sono state registrate dal 1940 ad oggi, molte individuabili presso MIT ma una versione molto dettagliata è stata localizzata al CMU.

Brian Leibowitz ha ricercato hack del MIT sia reali che appartenenti al mito; il lettore interessato può far riferimento all'illustrato compendium The Journal of the Institute for Hacks, Tomfoolery, and Pranks (MIT Museum, 1990; ISBN 0-917027-03-5). L'istituto ha un sito Web in http://hacks.mit.edu/Hacks/Gallery.html. Questo è uno spezzone intitolato E' questa la strada per la casa del panettiere?. La Caltech Alumni Association pubblicò due libri simili intitolati Legends of Caltech e More Legends of Caltech.

Eccone un altra riguardante l'hacking informatico:

Attorno alla metà del 1970, in diversi sistemi del personale tecnico della Motorola venne scoperta un semplice modo per crackare il sistema di sicurezza dalla Xerox CP-V timesharing system. Attraverso una strategia programmata, era possibile per un utente aggirare il sistema durante una sessione del programma utilizzato dall'amministratore, dove non era applicata la protezione della memoria. Il programma poteva poi colpire molti dati visto il suo livello di privilegi (normalmente protetti da scrittura) e poteva poi procedere al bypass di tutti i livelli di sicurezza con il sistema file-management, patchare il controllo del sistema, e fare molte altre cose interessanti. In breve, la porta della stalla venne spalancata.

Motorola riportò abbastanza correttamente questo problema alla Xerox definendone un ufficiale livello 1 SIDR (una segnalazione di un bug con un deliberato livello d'aiuto fissato precedentemente). Poichè il testo di ciascun SIDR veniva inserito in un database che poteva esser visto da un ristretto numero di persone, Motorola seguì la procedura accordata: semplicemente riportò il problema come Security SIDR ed allegò tutta la documentazione necessaria, modo di riproduzione, ecc.

Le persone CP-V alla Xerox trascurarono il problema; non capirono l'urgenza del problema o non assegnarono le risorse necessarie allo staff del sistema operativo per sviluppare e distribuire una patch ufficiale.

I mesi passarono. I ragazzi della Motorola tormentarono il gruppo di supporto della Xerox come non vantaggioso. Infine decisero di intraprendere un azione diretta per dimostrare alla direzione Xerox quanto facilmente il loro sistemapoteva essere crackato e come il sistema di sicurezza superato.

Costruirono attorno all'elenco del sistema operativo e idearono un set completo di diaboliche patch. Queste patch vennero poi incorporate in parte dei programmi chiamati Robin Hood e Frate Tuck. Robin Hood e Frate Tuck erano progettati per agire come fantasmi (daemons, nella terminologia Unix); volevano utilizzare le feritoie esistenti per rovesciare il sistema di sicurezza, installare le patch necessarie e controllare da un altro utente in grado di agire come system operator (in pratica, il superuser) per eliminarli.

Un bel giorno, il system operator nel principale sistema di sviluppo CP-V software di El Segundo fu sorpreso da un numero inusuale di fenomeni. Tra i fenomeni erano inclusi i seguenti:

  • Le cassette devono essere riavvolte e "smontate" a metà lavoro.

  • Disk drives devono cercare avanti e indietro così velocemente che ci si aspettava camminassero in mezzo alla sala (vedi walking drives).

  • The card-punch output device occasionalmente veniva riavviata da sola e si attaccava ad un altra carta (carta con tutte le posizioniforate). Solitamente costituiva un ostacolo nella foratura.

  • Il monitor visualizzava messaggi falsi e d'insulti da Robin Hood a Frate Tuck, o vice versa.

  • La carta di lettura della Xerox aveva due prese per l'output; poteva esser eseguita dalla presa in A, in B, nella presa in A (a meno che una carta fosse illegibile, in questo caso la carta difettosa veniva inserita nella presa B). Una delle patch installate dai fantasmi aggiungeva del codice nell'unità di lettura delle carte... dopo aver letto una carta saltava all'altra presa. Come risultato il ponte tra le carte fu diviso a metà quando venivano lette, mandando gli operatori a ricercarsi i manuali.

Naturalmente, l'operatore chiamò gli sviluppatori del sistema operativo. Trovarono i programmi fantasma in esecuzione e li terminarono... ed ebbero un altra sorprsa. Quando Robin Hood fu cacciato comparveno i seguenti eventi:

!X id1

id1: Frate Tuck... Sono attaccato!  Ti prego salvami!
id1: Off (chiuso)

id2: Non aver paura, amico Robin!  Scoverò gli uomini dello Sceriffo
     di Nottingham!

id1: Grazie, mio buon amico!

Ciascun programma-fantasma scoprì che l'altro fu terminato e ne riavviò una nuova copia del programma ucciso in pochi millisecondi. L'unico modo per terminare entrambi i fantasmi era di terminarli simultaneamente (molto difficile) o mandare deliberatamente in crash il sistema.

Alla fine, i programatori di sistema scelsero quest'ultima solo per trovare come sembravano i banditiuna volta riavviato il sistema! Risultò che questi due programmiavevano patchato imagine di riavvio dell'OS (il kernel, nella terminologia Unix) e si sono aggiunti alla lista dei programmi che partono all'avvio del sistema (simile al modo di propagarsi dei virus di Windows).

I fantasmi di Robin Hood e Frate Tuck vennero finalmente sradicati quando lo stff riavviò il sistema da un disco pulito e reinstallò la sicurezza. Non molto tempo dopo, Xerox rilasciò una patch per questo problema.

Allegato c'era un reclamo della Xerox verso l'amministrazione Motorola riguardo alla burla dei due impiegati in questione. Non è stata registrata nessun'azione disciplinare contro di loro.

Infine, qui c'è una magnifica storia di hack per il nuovo millennio:

Nel 1990 in aggiunta alla consacrata tradizione dello scherzo di Aprile RFCs ci fu RFC 1149, A Standard for the Transmission of IP Datagrams on Avian Carriers. Questo abbozzava il metodo per trasmettere pacchetti IP via piccione viaggiatore.

Undici anni dopo, il 28 Aprile 2001, il Bergen Linux User's Group dimostrò con successo il CPIP (Carrier Pigeon IP) tra due computer aventi Linux ai lati opposti di una piccola montagna di Bergen, Norvegia. La loro rete usava stampare pacchetti-spazzatura sulla carta,i piccioni per trasportare la carta, e software OCR per leggere la spazzatura dall'altro capo e nutrirli al luogo del computer di ricezione.

Qui c'è il log del comando ping che hanno eseguito con successo. Notate i tempi di ricezione dei pacchetti.

Script started on Sat Apr 28 11:24:09 2001
vegard@gyversalen:~$ /sbin/ifconfig tun0
tun0      Link encap:Point-to-Point Protocol  
          inet addr:10.0.3.2  P-t-P:10.0.3.1  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:150  Metric:1
          RX packets:1 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 
          RX bytes:88 (88.0 b)  TX bytes:168 (168.0 b)

vegard@gyversalen:~$ ping -i 450 10.0.3.1
PING 10.0.3.1 (10.0.3.1): 56 data bytes
64 bytes from 10.0.3.1: icmp_seq=0 ttl=255 time=6165731.1 ms
64 bytes from 10.0.3.1: icmp_seq=4 ttl=255 time=3211900.8 ms
64 bytes from 10.0.3.1: icmp_seq=2 ttl=255 time=5124922.8 ms
64 bytes from 10.0.3.1: icmp_seq=1 ttl=255 time=6388671.9 ms

— 10.0.3.1 ping statistics —
9 packets transmitted, 4 packets received, 55% packet loss
round-trip min/avg/max = 3211900.8/5222806.6/6388671.9 ms
vegard@gyversalen:~$ exit

Script eseguito Sabato 28 Aprile 14:14:28 2001

La web page che documentò l'evento con immagini è http://www.blug.linux.no/rfc1149/. Nella tradizione di maggior pregio di Internet, tutti i software sviluppati erano open-source; le parti richieste sono disponibili per il download dal sito.

Mentre tutte le conoscienze sull'importanza di questo risultato, molti dibattiti consigliavano come l'implementazione di BLUG sarebbe particolarmente comoda per RFC. Sembrava non avessero mai usato il nastro-canale specificato in 1149 per attaccare i messaggi alle zampe dei piccioni ma invece usassero altri metodi meno utili dei piccioni. Il dibattito venne risolto quando fu chiarito che il nastro-canale non era prefissato dal MUST, ed era così una raccomandazione più che un reqisito.

I perpetratori finirono la loro scrittura preliminare in questo modo: Ora noi aspettiamo di scrivere per qualcuno alre implementazioni così potremo fare test di ineroperabilità e forse potremo finalmente inserire RFC negli standard... .

Il logico passo seguente sarebbe l'implementazione di RFC2549.