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.