Cronaca di un disastro mancato
aprile 10th, 2009
….o se preferite di un recupero riuscito 
Il disco del mio laptop era organizzato con tre sistemi operativi ed una partizione di comodo.
Due partizioni ext3 erano destinate ad ospitare BackTrack 3 e FCCU 11.0, che disponevano di una partizione di swap (incomune) dedicata.
La partizione di comodo era una ntfs, originariamente destinata all’installazione, mai avvenuta, di un sistema Microsoft.
Vi era poi il mio Ubuntu 8.04 con la sola partizione di boot in chiaro per l’avvio del sistema con root, home e swap cifrate su LVM.
Diverse persona considerano la cifratura del disco pericolosa, temendo problematiche in caso di crash di sistema. Personalmente non ho mai avuto problemi, ho sempre consentito al sistema di fare i propri controlli di coerenza sui volumi cifrati ed anche i tempi di accesso ai file e di elaborazione non mi sono mai parsi compromessi dalla cifratura al volo.
Tuttavia immagino che le problematiche a fronte di situazioni di disastro possano diventare notevoli.
E siccome si impara sempre con l’esperienza di prima mano…ieri mi sono trovato davanti al disastro!
La tabella delle partizioni mi si è danneggiata.
Sgranare gli occhi non è servito, il sistema non si avviava neanche se lo minacciavo.
Ho eseguito un avvio con il cd Caine ed ho usato “test disk” con il quale sono riuscito a recuperare quasi tutte le partizioni, tranne /dev/sda9…quella contenente il volume cifrato 
Al boot la procedura di avvio partiva, ma non riusciva ad individuare la partizione con il volume cifrato, di conseguenza non si arrivava neanche alla richiesta di inserire la password.
Ho tolto il disco dal laptop, l’ho attaccato con l’adattatore sata esterno ed ho avviato inserendo nel portatile l’altro disco sul quale ho installato Caine.
Ho riutilizzato “test disk” mentre in rete cercavo documentazione relativa al recovery di dischi cifrati e nel frattempo consultavo quello che giudico un pozzo di scienza per quanto riguarda la gestione dei sistemi Linux ed i file system da esso utilizzati: il prof. Mario Pascucci !!
Al termine del secondo giro con “test disk” è finalmente comparsa la partizione sda9 (di seguito indicata come sdb perchè attaccata esternamente via usb), ma apparentemente sottodimensionata, solo 8 MB.
In effetti se si analizza la geometria del disco
———————————
Disco /dev/sdb: 250.0 GB, 250059350016 byte 255 heads, 63 sectors/track, 30401 cylinders Units = cilindri of 16065 * 512 = 8225280 bytes Disk identifier: 0x1d081d07 Dispositivo Boot Start End Blocks Id System /dev/sdb1 * 1 66 530113+ 83 Linux /dev/sdb2 67 6858 54556740 f W95 Esteso (LBA) /dev/sdb5 67 1371 10482381 83 Linux /dev/sdb6 1373 2677 10482381 83 Linux /dev/sdb7 2679 6595 31463271 7 HPFS/NTFS /dev/sdb8 6596 6857 2104483+ 82 Linux swap / Solaris /dev/sdb9 6858 6858 8001 83 Linux Dispositivo Boot Start End Blocks Id System /dev/sdb1 * 63 1060289 530113+ 83 Linux /dev/sdb2 1060290 110173769 54556740 f W95 Esteso (LBA) /dev/sdb5 1060353 22025114 10482381 83 Linux /dev/sdb6 22041243 43006004 10482381 83 Linux /dev/sdb7 43022133 105948674 31463271 7 HPFS/NTFS /dev/sdb8 105948738 110157704 2104483+ 82 Linux swap / Solaris /dev/sdb9 110157768 110173769 8001 83 Linux
si vede chiaramente che la capacità effettiva (250.0 GB, 250059350016 byte, 488397168 settori) non viene sfruttata. La partizione estesa sdb2 e quella logica sdb9 terminano infatti al settore 110173769, sfruttando solo 56408969728 bytes, ossia circa 53 GB.
Francamente non ricordavo le dimensioni delle varie partizioni, non avevo fatto copia della struttura e non avevo idea se in quei miseri 8 MB di sdb9 potesse esservi il codice che puntava ad un file system cifrato non rilevato da fdisk.
Il miglioramento c’era stato perchè avviando il laptop reinserendogli il disco in questione la password veniva richiesta ed il controllo passato con successo, quindi quegli 8 MB erano importanti, ma non bastavano, il sistema non si avviava.
Provando ad avviare il portatile con un cd di Ubuntu e scegliendo la modalità per il recupero, il disco cifrato veniva correttamente riconosciuto, la password richiesta e controllata.
Il sistema individuava la tre partizioni (root, home e swap) ma li il gioco finiva, in quanto non veniva individuato /sbin/cryptsetup.
Analizzando il disco con parted, si rileva come nella partizione venisse rilevato un file system sovradimensionato rispetto ai limiti definiti nella tabella delle partizioni per la partizione in questione:
Disk /dev/sdb: 250GB Sector size (logical/physical): 512B/512B Partition Table: msdos Number Start End Size Type File system Flags 1 32.3kB 543MB 543MB primary ext3 boot 2 543MB 56.4GB 55.9GB extended lba 5 543MB 11.3GB 10.7GB logical ext3 6 11.3GB 22.0GB 10.7GB logical ext3 7 22.0GB 54.2GB 32.2GB logical ntfs 8 54.2GB 56.4GB 2155MB logical linux-swap 9 56.4GB 56.4GB 8193kB logical ext3 (parted) print 9 Error: The file system is bigger than its volume! Ignore/Cancel? I Warning: File system has errors! You should run e2fsck. Ignore/Cancel? I
Ho ipotizzato che “test disk” abbia individuato le partizioni, ma abbia rilevato una dimensione della partizioneestesa non corretta, decisamente inferiore alla dimensione reale, con la conseguenza che la partizione logica sdb9 risulta “castrata” dal limite superiore di quella estesa.
Prima di mettere mano al ridimensionamento della partizione estesa e della logica di mio interesse ho verificato su un altro device la funzionalità offerta da “parted, trovandola più che soddisfaciente.
Tuttavia è bene prendere qualche precauzione, giusto per non sfidare troppo la legge di Murphy. Così nel pomeriggio ho fatto un bel dd del disco.
Dopo cena, mi sono domandato se non fosse possibile bypassare il limite imposto dalla tabella delle partizioni. Durante le ricerche effettuate la mattina, avevo trovato sul forum di Ubuntu questa interesante discussione “How do I fsck an encrypted partition?” , nell quale l’utente “bodhi.zazen”, il 16 marzo 2008 (ultimo post della discussione), illustrava la modalità di accesso ai volumi criptati.
Nello specifico utilizzava le funzionalità di cryptsetup per aprire il volume criptato presente in un device.
Dal momento che “parted” individuava il file system presente in sdb9, mi son detto che potevo provare ad accedervi direttamente con un loop device, bypassando la tabella delle partizioni con l’indicazione dell’offset dal quale rilevare il file system.
Poi avrei aperto, con cryptsetup, il volume cifrato presente sul loop device.
Pascucci mi aveva parlato delle possibili problematiche derivanti dall’utilizzo dei file system criptati su LVM, non conoscendo come la stratificazione era stata implementata poteva diventare difficile individuare l’inizio del volume criptato.
Mi rincuorava il dump dei primi bytes di sdb9:
denis@caine:~$ sudo xxd -l 1024 /dev/sdb9 0000000: 4c55 4b53 babe 0001 6165 7300 0000 0000 LUKS....aes..... 0000010: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000020: 0000 0000 0000 0000 6362 632d 6573 7369 ........cbc-essi 0000030: 763a 7368 6132 3536 0000 0000 0000 0000 v:sha256........ 0000040: 0000 0000 0000 0000 7368 6131 0000 0000 ........sha1.... 0000050: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000410: 6010 130a 0100 0000 0000 0000 0000 0000 `............... 0000420: 0020 0000 0020 0000 0008 0000 2932 6248 . ... ......)2bH 0000430: 3c9f dd49 0000 1400 53ef 0200 0100 0000 <..I....S....... 0000440: 3b2d 6248 004e ed00 0000 0000 0100 0000 ;-bH.N.......... 0000450: 0000 0000 0b00 0000 8000 0000 0400 0000 ................ 0000460: 0000 0000 0000 0000 6368 746f 2074 616b ........chto tak 0000470: 6f65 2075 7569 6400 4352 4950 544f 0000 oe uuid.CRIPTO.. 0000480: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000490: 0000 0000 0000 0000 0000 0000 0000 0000 ................
inoltre (ma ragionato a posteriori) verificando la tipologia di file system presente nella partizione
denis@caine:~$ sudo fsstat -t /dev/sdb9 ext3
ed i suoi dati
sudo fsstat -f ext3 /dev/sdb9 FILE SYSTEM INFORMATION -------------------------------------------- File System Type: Ext3 Volume Name: CRIPTO Volume ID: 6469757520656f6b6174206f746863 Last Written at: Thu Apr 9 09:09:48 2009 Last Checked at: Wed Jun 25 13:34:19 2008 Last Mounted at: Wed Jun 25 13:55:21 2008 Unmounted Improperly Last mounted on: Source OS: Linux Dynamic Structure Compat Features: Journal, Journal ID: 00 Journal Inode: 8 METADATA INFORMATION -------------------------------------------- Inode Range: 1 - 47280129 Root Directory: 2 Free Inodes: 169021536 CONTENT INFORMATION -------------------------------------------- Block Range: 0 - 189117147 Total Range in Image: 0 - 8000 Block Size: 1024 Reserved Blocks Before Block Groups: 1 Free Blocks: 267243151
risultava che 189117147 blocchi della dimensione di 1024 bytes davano una dimensione del file system di circa 184 GB, un pelino di più degli 8 MB indicati dalla tabella delle partizioni.
Con questi indizi, perso per perso, tanto valeva provare.
Sempre operando con Caine installato e il disco in questione collegato via usb con adattatore sata esterno, ho dapprima creato il loop device
denis@caine:~$ sudo losetup -o 56400777216 /dev/loop0 /dev/sdb
dove l’offset, indicato in bytes, corrisponde a 110157768 (il settore di inizio della partizione sdb9) * 512.
Ho installato i pacchetti necessari, come indicato da “bodhi.zazen”
denis@caine:~$ sudo apt-get install lvm2 cryptsetup
aperto il device criptato
denis@caine:~$ sudo cryptsetup luksOpen /dev/loop0 crypt1
inserendo la password si ha immediatamente conferma del successo dell’operazione.
A questo punto in /dev/mapper avremo le nostre partizioni finalmente in chiaro
denis@caine:~$ ls /dev/mapper/ control crypt1 nsa-home nsa-root nsa-swap
È ora possibile montare le diverse partizioni ed accedere ai dati in esse contenute
denis@caine:~$ sudo mount -t ext3 /dev/mapper/nsa-home /tmp/01 denis@caine:~$ ls /tmp/01 lost+found nemo
La fortuna mi ha assistito ed in diverse ore ho completato il back-up dei dati.
Tuttavia non ero abbastanza contento, volevo l’elenco dei pacchetti installati nel sistema che rischiavo di perdere.
Ho quindi montato la root directory del file system criptato
denis@caine:~$ ls /dev/mapper/ control crypt1 nsa-home nsa-root nsa-swap denis@caine:~$ mkdir /tmp/root1 denis@caine:~$ sudo mount -t ext3 -o rw /dev/mapper/nsa-root /tmp/root1/
e vi sono entrato come root con chroot
denis@caine:~$ sudo chroot /tmp/root1/
per verificare di star lavorando sul sistema corretto ho cercato il nome utente usato su di esso in /etc/passwd
root@caine:/# less etc/passwd |grep nemo nemo:x:1000:1000:nemo,,,:/home/nemo:/bin/bash
a questo punto ho richiesto la lista dei pacchetti installati e mi sono preso il file risultante.
root@caine:/# dpkg -l >pacchetti_installati_su_250.txt
La prima parte del lavoro è terminata con il back-up, nei prossimi giorni poi, con il libro di Carrier al fianco, mi metterò a lavorare sulle dimensioni delle partizioni, chissà che non mi riesca di ottenere qualcosa di più.
Il lavoro così eseguito dovrebbe risultare fattibile anche sull’immagine bitstream di un disco sospetto e la modalità di accesso ai dati criptati, indicata nella discussione sul forum di Ubuntu, permetterebbe di accedere ai dati utili all’indagine.
Spero che tutto ciò possa essere d’aiuto a qualcuno, anche non direttamente nelle indagini, ma almeno per un recupero.
One Response to “Cronaca di un disastro mancato”
1DenisFrati.it » Blog Archive » Correzione errori su file system criptato
giugno 11th, 2010 @ 23:16
[...] Personalmente sono fiducioso nella stabilità dei file system nativi linux, anche criptati. In passato mi ero già dovuto cimentare nel recupero di una partizione criptata, narrando la vicenda nell’articolo “Cronaca di un disastro mancato“. [...]
Leave a Reply