Autopsy di un hard disk (2)

Sto eseguendo un analisi di un disco per conto di un cliente. 1TeraByte di dati da anlizzare senza sapere nemmeno cosa cercare esattamente. Un vero incubo. Da qualche giorno il mio fedele PC da 2.4 Ghz monoprocessore sta sbatacchiando il disco di destinazione, giorno e notte, per creare il datafile su cui poi generare la timeline. Spero solo in un colpo di fortuna, anche se l'esperienza mi insegna di focalizzare l'attenzione, per prima, su due o tre cose. La sterilizzazione, la clonazione dei dati, la generazione delle impronte md5 e sha1 ha richiesto quasi una settimana, per non parlare del fatto che ho dovuto acquistare i supporti ed un banco di ram da 1GB (odio spendere soldi). Speravo, anche questa domenica, di potermi riposare un pò. Invece eccomi qui a lavorare (per fortuna). Mi riposerò nei periodi di stanca, nei quali approfitto del tempo libero per studiare cose nuove e sperimentare nuovi hack mai intrapresi da chicchessia. Mi spiace solo aver dovuto accantonare molte cose in sospeso e dover ritardare ancora i risultati. Pazienza. alla prossima.

PS. ACAB. Ripeto: ACAB.

Recuperare dati da supporti danneggiati

Per chi ha un attività o gestisce un impresa, l'evento più disastroso che scatena il panico è la sorpresa data dalla perdita dei dati elettronici dai supporti usati per memorizzarli. Mi accorgo di ciò quando entro in ufficio e trovo una moltitudine di chiamate perse al cellulare. Il disastro si verifica solitamente negli orari meno opportuni, quasi sempre nei giorni festivi e spesso quando sono oberato di impegni inderogabili. Solo allora divento indispensabile ed oggetto di suppliche, mai accompagnate dalla promessa di retribuire adeguatamente la mia disponibilità a risolvere la situazione. Stavolta è toccato ad una chiavetta usb, con gli archivi dei clienti di un dentista. Non mi chiedo come mai i dati dei clienti siano memorizzati in un archivio di lavoro su una chiavetta usb invece del PC dello studio dentistico. Accetto l'incarico "agratis" e, dato che non è la mia attività principale ma solo un favore fatto in funzione di un lavoretto che dovrei far fare alla mia arcata dentale superiore, sperando nella disponibilità futura ad un pagamento "in natura" (cambio merce), decido di dare un occhiata al supporto. A volte mi arrivano dei casi veramente disperati, supporti danneggiati a tal punto che il recupero è quasi impossibile. Ecco qui gli strumenti che utilizzo per riportare il sorriso a chi si affida a me, anche se non sempre la fiducia riposta trova una vera soluzione.
Gli strumenti che uso per il recupero dei dati? Sono dei programmi in ambiente GNU-linux. Vediamoli:

dd_rescue

È una variante dell'utility unix “dd”. Estrae i dati dal supporto e trasferisce ciò che è leggibile su un file o su un device a blocchi. Crea un "clone" dei dati con blocchi a zero se non riesce a leggerli dall'origine.

fsck

E' uno strumento di unix per la manutenzione dei filesystem. È composto da una suite di programmi, ciascuno dei quali lavora su uno specifico filesystem: per esempio fsck.ext3 lavora su filesystem ext3, fsck.vfat su FAT16/FAT32, ecc… Verifica la consistenza della struttura del filesystem e risolve gli eventuali problemi. Può lavorare sia su device a blocchi (es. /dev/sdb /dev/hda ecc...) che su file immagine (creati ad es. con dd_rescue).

testdisk

E' un programma di recupero dati interattivo che ricostruisce in modo "semi-automatico" una tavola di partizione danneggiata. Legge i settori iniziali di ciascun cilindro del disco e cerca quelli che potrebbero assomigliare ad una partizione. E' in grado di rilevare in automatico il tipo di filesystem (ne riconosce davvero moltissimi) e le sue dimensioni provando anche a volte di correggere problemi di consistenza.

photorec

L'interfaccia è simile a testdisk. Recupera i files direttamente dall'area dati senza affidarsi al filesystem. È utile quando il filesystem è pesantemente danneggiato e/o non è supportato dagli altri strumenti. Sarebbe da impiegare come ultima spiaggia dato che è in grado di recuperare solo alcuni tipi di file. Ovviamente non può mantenere i nomi originali dei files, per cui ci si potrebbe trovare nella situazione di aprirli uno ad uno per comprendere cosa contengano aiutandosi con l'estensione.

La procedura

Do per scontato che nelle operazioni di recupero si utilizzi uno strumento predisposto a farlo, ovvero un PC con gli strumenti software installati, spazio sufficiente per trasferire i dati da recuperare, eventualmente delle porte ide libere (evito, se posso, gli adattatori usb-ide), collegato ovviamente in rete per scaricare eventuali aggiornamenti.


Controllo il partizionamento del supporto per individuare quali partizioni contiene. Se il device è /dev/sdb:

fdisk -l /dev/sdb

Se l'MBR è corrotta non si può effettuare il mount in sola lettura, altrimenti provo a montare in read-only la partizione in esame (SDB1 per la prima):

mkdir -p /mnt/dati

mount -o ro /dev/sdb1 /mnt/dati

Se il mount non va a buon (MBR è corrotta) o non è leggibile, devo clonare l’intero disco:

ddrescue /dev/sdb /mnt/immagine_chiavetta.img

Con il comando precedente, estraggo tutto il dispositivo con tutte le sue partizioni.

Se dd_rescue va a buon fine senza errori, occorre ripristinare una tavola di partizione corretta:

testdisk /mnt/immagine_chiavetta.img

che esegue una scansione dell’immagine alla ricerca dei possibili punti di inizio delle partizioni. Se esce il messaggio "partition sector don't have the end mask 0xAA55" significa che la tabella delle partizioni è completamente andata (salta al passo photorec direttamente) e difficilmente è possibile ripristinarla a mano (in alcuni casi si può fare).
Se tutto va bene, testdisk ripristina il tutto e si può procedere a salvare la nuova MBR. Quando si lavora con testdisk può essere necessario impostare a mano la geometria del disco CHS Cilindri - testine - settori per traccia: sui dischi vecchi i dati sono riportati sull'etichetta, mentre in quelli più attuali è riportata solo la dimensione in blocchi: in questo caso il firmware del disco usa una geometria fittizia per mappare l’indirizzo LBA dei blocchi: i settori per traccia sono sempre 63 e le testine 255: il numero di cilindri si calcola dividendo la dimensione in blocchi per 16065.

Dopo la ricostruzione della tavola di partizione, si può estrarre l’immagine solo della partizione che ci interessa: Per sapere dove inizia e dove finisce:

sfdisk -d /mnt/spazio/immagine.img

Ci si annota “start” e “size” della partizione: supponendo che i valori siano rispettivamente 63 e 156296322 posso estrarre l’immagine sovrascrivendo quella completa ottenuta in precedenza:

ddrescue -i (numero_inizio)b -s (numero_size) /dev/sdb /mnt/immagine_partizione.img

Si può così tentare un fsck: supponendo un filesystem di tipo FAT:

fsck -t vfat /mnt/immagine_partizione.img

e montare in loopback l’immagine:

mkdir -p /mnt/chiavetta

mount -o loop,ro /mnt/immagine_partizione.img /mnt/chiavetta

Il lavoro è terminato e si può procedere con l'analisi dei dati. Se, come nel mio caso la FAT è completamente andata, l’ultima possibilità consiste nell’uso di photorec:

mkdir -p /mnt/chiavetta/files

cd /mnt/chiavetta/files

photorec /mnt/immagine_partizione.img

Il supporto di origine può essere inutilizzabile o inaffidabile per memorizzarci altri dati. Se si desidera comunque riutilizzarlo, va formattato con il comando:

dd if=/dev/zero of=/dev/sdb bs=1

A meno di spiacevoli sorprese, in molti casi si riesce a recuperare qualcosa, magari non tutto. Possono però capitare dei comportamenti "strani". Con dd possono comparire errori di I/O che interrompono il processo di recupero. Anche dd_rescue può conteggiare errori di lettura. A volte l'errore di I/O è volatile, nel senso che si verifica saltuariamente ed imprevedibilmente in settori diversi. E' comunque indispensabile riuscire a salvare il maggior numero di blocchi (tutti se possibile) altrimenti il tentativo è inutile. A volte l'errore deriva da una chiavetta "consumata", ovvero utilizzata oltre il numero di cicli di scrittura consentiti. In altri casi può essere un problema hardware del circuito di interfaccia alla porta usb che si manifesta solo in particolari condizioni di temperatura. In questi casi essere un pò maghi e conoscere qualche rito sciamanico può aiutare. Alla prossima

P.S. Invertire il 7 con l'8. Ripeto: Invertire il 7 con l'8.

Geroglifici nei tribunali

Sembra che il progetto di affossare il sistema giudiziario italiano, sia agevolato in qualche modo dalle "talpe" che lavorano dall'interno. Sono note, solo per i più informati che non guardano la TV di regime e i giornali dei soliti editori interessati a manipolare le notizie, le azioni e manovre di questo governo di rendere inefficaci le azioni della magistratura.

Lo sforzo, nemmeno tanto nascosto dai proclami smentiti il giorno dopo, si concentra nel togliere silenziosamente risorse e strumenti alla magistratura, alle forze di polizia, a chi ha il compito (non si sa quanto ancora in modo indipendente) di controllare, giudicare e punire gli illeciti.

Attorno a queste strutture, lavorano a vario titolo una moltitudine di realtà. Impiegati, cancellieri, avvocati, giudici, consulenti tecnici, fornitori, uscieri, ecc...

Entrare nel mondo dei tribunali, non come imputato o testimone, significa conoscere una realtà parallela, dove il concetto di spazio - tempo è sovvertito ed ancora oscuro ai più. La mia attività con questa realtà, inizia quasi 20 anni fa. L'impatto è stato "devastante". Ma una cosa in particolare mi ha colpito. Il computer nei tribunali è utilizzato male, malissimo, a volte per nulla. Nel corso delle udienze, il giudice scrive ancora a mano i verbali, a volte li fa scrivere a uno degli avvocati presenti, a volte c'è un impiegata che lo fa.

Scrivere a mano ciò che viene dettato è un compito arduo che mal si concilia con la calligrafia e con lo scopo primario di comunicare decisioni importanti. Gli avvocati dopo uno smarrimento iniziale, hanno imparato a decifrare i geroglifici impressi sulla carta. L'uso ricorrente di frasi e modi di dire, permette una "facile" interpretazione, a senso, dei simboli trascritti. Per me, la prima volta, ed ancora oggi a distanza di quasi 15 anni, trovo delle "difficoltà".
Alcune grafìe sono obiettivamente indecifrabili. Vedere gli esempi per credere. Da buon informatico mi chiedo... cosa costerà mai dotare di un portatile l'impiegato o il giudice. Sarei disposto ad insegnargli ad utilizzarlo... gratis pur di vedere un verbale comprensibile, pur di vedere un pò di ordine.
Siamo nel 2008 ed ancora si blatera in tema di spese di giustizia. Sarà sbagliato il sistema di approvvigionamento delle attrezzature, saranno gli scarni trasferimenti statali, sarà che chi deve giudicare le offerte e gli appalti non ne capisce una mazza, ma sicuramente qualcosa che non va c'è, oltre ai gravi problemi accennati in esordio a questo post. Lascio il compito di "tirare a indovinare" cos'è scritto negli esempi qui riportati. Potrei istituire un concorso a premi. Chi li indovina tutti vince un computer portatile (Giudici e impiegati dei tribunali sono agevolati, nella speranza che capiscano almeno la loro scrittura). Ciao


P.S. ljlvf sfdòljfiit òdcldoq 4kdkc9. Ripeto: ljlvf sfdòljfiit òdcldoq 4kdkc9.

Magicrescue per linux

Speravo tanto di non doverlo mai fare. Oggi ho combinato un pasticcio degno del più principiante degli informatici. Accidentalmente, nell'usare incautamente un file manager appena installato, ho cancellato il 90% dei sorgenti di un progetto che sto sviluppando da quasi un mese. Me ne sono accorto solo alla ri-accensione del sistema. Persi i sorgenti, le impostazioni del progetto, le form... una piccola catastrofe. Com'è noto, gli informatici sono i primi a bacchettare i clienti che non salvano i dati con i backup giornalieri, salvo poi non farli mai per se stessi. Ho dovuto quindi procedere con un tentativo di recupero utilizzando magicrescue per linux. Dopo aver ri-montato la partizione da ext3 a ext2 (non journaled), ho proceduto con la programmazione dei "recipes" (le configurazioni). Fortunatamente, fresco di sviluppo, ricordo a memoria i nomi dei files e delle form create. Credo di aver recuperato tutto il minimo per tentare una ri-compilazione. Al massimo avrò perso solo le ultime righe di codice sviluppato. Al limite, proverò con sleuthkit sul dd effettuato sulla partizione interessata, oppure con Autopsy.
Ora è troppo tardi per un tentativo. è dalle 7 di stamattina che programmo e sono un pò stanchino. Vado a riposare e sabato, invece di dedicarmi ai miei hobbies preferiti, proverò a sistemare gli ultimi dettagli. Notte.

Aggiornamento 17.5.2008 - Tutto ok. Files recuperati al 98%. Tre ore di lavoro per lo sviluppo dei sorgenti mancanti e il software è tornato operativo. Utilizzato Magicrescue per linux.

P.S. il ragno non esce dal buco. Ripeto: il ragno non esce dal buco.

Consulenza tecnica

Consulenza tecnica di parte... una interminabile riunione per ribadire a voce quanto già scritto dall'avvocato in quasi mille pagine di ricorsi e memorie.Servono le verifiche tecniche per cui il giudice dispone una Consulenza Tecnica d'ufficio, per verificare attraverso un CTu se la "vessata quaestio" è fondata in diritto o se gli avvocati sono dei pinocchi (come spesso accade). E' uno dei percorsi per far valere dei diritti. Alla riunione a cui ho partecipato in veste di CTP sono presenti il CTU, due consulenti di parte (CTP) e due persone di supporto tecnico. Due parti in lite di fronte all'ausiliario del giudice. Una delle due parti è in evidente difficoltà visti i risultati di una precedente ATP (Accertamento tecnico preventivo). L'ATP ha stabilito che dopo 3 anni l'installazione di un software gestionale non può ancora definirsi utilizzabile, nonostante il fornitore, in evidente ritardo, avesse preventivato lo start-up in tre mesi. Incredibile ascoltare una interminabile sequela di scuse, pretesti, asserzioni fasulle (puntualmente smentite), accuse e quant'altro controparte ritiene di apportare per favorire "la (loro) verità!". L'ausiliario tecnico di controparte è un "uomo marketing", uno di quelli che cambiano il significato alle parole comunemente conosciute per definizione universalmente accettata. Noto immediatamente che "l'ingeniere" CTU si sta facendo abbindolare e manipolare (un punto di demerito alla sua pretesa imparzialità). Devo agire in fretta per porre fine alle menzogne credibili dell'imbonitore. Purtroppo in veste di CTP non ho poteri per imporre l'allontanamento di chi disturba, e visto che il CTU sembra ormai totalmente ipnotizzato, devo correre ai ripari facendo appello ai molti anni di esperienza nel settore. Inizio una serie di legittimi interventi verbali, posturali e mimico-facciali che in soli 5 minuti riescono a far incazzare come una bestia l'uomo marketing, il quale come previsto e privo ovviamente di argomenti validi si alza e si allontana dalla sala. Se non posso farti uscire faccio in modo che esca tu di tua spontanea volontà, coglione! Mi hai preso per un pirla? Ci sei cascato e mi hai permesso nei 15 minuti che sei rimasto fuori di agire e riportare nei binari la percezione dei fatti concreti addotti a bilanciare a mio favore le fanfaluche campate per aria che sino a pochi minuti prima aleggiavano pericolosamente. Nel campo dell'informatica non è raro imbattersi in commerciali travestiti da informatici che con le parole riescono ad incantare i serpenti. Solo che io non sono una serpe ma un camaleonte, con esperienza sufficiente a cambiare strategia, in base a tanta esperienza pratica, adattandomi alle situazioni. Non ti aspettavi un osso duro vero?.

Da buono come sono ho proposto una conciliazione, per dare una dignitosa via di uscita alla controparte e nel rispetto della regola di cortesia nei rapporti di colleganza. L'avvocato di controparte rifiuta, come avevo previsto in quanto evidentemente preso dal sogno ipnotico indotto dall'informatico imbonitore. Seconda vittoria. Il giudice ne terrà debito conto.

Propongo al CTU un documento preparato nei mesi precedenti che evidenzia ritardi, quantifica i tempi (con tanto di riferimenti alle prove documentali) e da precisa risposta ai quesiti assegnati dal giudice... ed il CTU lo accetta volentieri, ho fatto il 70 % del lavoro che doveva fare lui...terza vittoria.

Ora la botta finale. Memoria tecnica che smonterà in base a prove certe il castello accusatorio, agevolato anche dall'irritazione del CTU che forse è riuscito ad intuire la volontà manipolatoria della controparte, e una super sintesi chiarificatoria con tanto di grafici e disegnini d'aiuto al giudice.

Morale del racconto: tutto ciò per far comprendere ad un giudice che nonostante la promessa di consegna in tre mesi non siano bastati tre anni per onorare gli impegni presi e sottoscritti. Se stessimo parlando ad esempio di mattoni nessun problema, ma se l'oggetto è software... allora sono tutti autorizzati a non capirci nulla. Complimentoni.

P.S. i bit sono aggiornati. Ripeto: i bit sono aggiornati.

Giornata "stimolante"

Un interminabile mattina ad ascoltare avvocati e cliente in merito ad una causa informatica. Fuori, un incredibile via vai di persone che gravitano nel centro storico. Dentro le doglianze, i diritti violati, le strategie difensive, l'acquisizione di prove, la verifica delle dichiarazioni di controparte, le segretarie incapaci di stampare un semplicissimo documento in formato PDF (che "stranamente" non si apre con Word...avrà mica un virus?). Voglia di uscire, certo, ma dovere da compiere prima. Un inutilissima riunione per ripetere a voce quanto già scritto nei mesi passati e consegnato sotto forma di fascicolo cartaceo e digitale. Ma le relazioni tecniche non le legge nessuno?

La riunione si conclude con la mia convinzione che gli avvocati non hanno capito nulla della "vessata quaestio", considerata la mimica facciale a parlar loro di files, software, firmware ed hardware, librerie dll ed eseguibili e quant'altro di così misterioso e pronunciato in modo da far sbellicare dalle risate (soffocate però dall'aria austera della situazione). Domani se ne andranno in udienza nel peggior tribunale del paese per uscire con una nuova data per l'ennesima riunione, l'ennesimo rinvio, l'ennesimo impegno che verrà liquidato a caro prezzo dal cliente in mome della "verità" e della "giustizia!

P.S. lo schermo si è rotto. Ripeto: lo schermo si è rotto