Estrarre dati da dischi NTFS danneggiati

Questo post è una traduzione del mio articolo Extracting data from damaged NTFS drives pubblicato originariamente il 9 marzo 2017 sul blog di eForensics Magazine. Il testo descrive in modo dettagliato il mio lavoro di tesi magistrale sulla ricostruzione forense di file system NTFS con metadati danneggiati e il funzionamento di RecuperaBit.

L’articolo è fruibile liberamente e il software è open source, nonché estendibile tramite plug-in (c’è un esempio nell’ultima parte del post). Se avete bisogno di consulenza sul recupero dati o l’analisi forense di file system potete contattarmi tramite il modulo di richiesta per i miei servizi professionali.


Introduzione

L’analisi dei file system è una parte molto importante dell’attività di digital forensics. Molte indagini riguardano dischi rigidi il cui contenuto deve essere analizzato. In alcuni casi, anche i file eliminati potrebbero dover essere recuperati. Ci sono diversi tipi di file system e NTFS è attualmente uno dei più popolari.

La corruzione del file system può verificarsi per diversi motivi e può compromettere la possibilità di aprire e recuperare i file. Perciò, gli i tool forensi devono comprendere la struttura di un file system e devono essere in grado di estrarre il maggior numero possibile di dati, anche in condizioni difficili. Il file carving è una tecnica popolare per estrarre i file dai media danneggiati, tuttavia i file estratti in questo modo generalmente perdono i metadati e la struttura delle directory della partizione non può essere recuperata. È necessario un approccio migliore perché i nomi, i percorsi e i timestamp dei file sono informazioni molto importanti.

In questo articolo imparerete come la struttura delle directory di un’unità NTFS può essere ricostruita anche se alcune porzioni dei metadati sono parziali, corrotte o completamente assenti. Tutte le fasi del processo verranno spiegate. L’algoritmo presentato porta ad un’interpretazione del file system che consente il recupero di nomi, percorsi, timestamp e contenuto dei file (inclusi quelli frammentati). Infine, imparerete come utilizzare e personalizzare uno strumento open source che implementa queste tecniche.

Come funziona la ricostruzione di NTFS?

Prima di approfondire le tecniche che possono essere utilizzate per ricostruire una partizione NTFS, è necessario introdurre alcuni concetti. NTFS è un file system proprietario sviluppato da Microsoft e utilizzato per impostazione predefinita in Windows a partire da Windows 2000. È anche presente nei dischi rigidi esterni ad alta capacità, in quanto pure Linux e macOS lo supportano.

Funzionamento interno di NTFS

Il concetto principale di NTFS è che tutto è un file, vale a dire che anche i metadati necessari per funzionare sono memorizzati in diversi file. Il più importante è la MFT (Master File Table) che include almeno un file record (chiamato MFT entry) per ogni file o directory allocato/a. Ogni entry contiene diversi attributi. Per questo motivo, un file potrebbe avere più di una entry se i suoi attributi non possono essere inseriti tutti in una.

Questi sono gli attributi più importanti:

  • $STANDARD_INFORMATION (id 0x10 = 16) memorizza i MAC time (Modifica, Accesso e Creazione) nel formato più assurdo di sempre: il numero di cento nanosecondi dal 1° gennaio 1601 UTC
  • $ATTRIBUTE_LIST (id 0x20 = 32) include i riferimenti alle non-base MFT entry che contengono altri attributi dello stesso file (se presenti)
  • $FILE_NAME (id 0x30 = 48) memorizza più nomi di file: generalmente il nome del file DOS 8.3 e quello lungo utilizzato dalle versioni recenti di Windows, a meno che i due non siano uguali
  • $DATA (id 0x80 = 128) include l’intero file se è inferiore a circa 700 byte, altrimenti dobbiamo fare riferimento alla runlist (un elenco che indica la posizione e la dimensione di ciascun frammento sul disco)
  • $INDEX_ROOT (id 0x90 = 144, solo per le directory) contiene gli attributi $FILE_NAME di (alcuni) elementi figli
  • $INDEX_ALLOCATION (id 0xA0 = 160, solo per le directory) si riferisce agli index record esterni memorizzati sul disco che registrano i riferimenti ai restanti elementi figli

I file record sono di dimensioni pari a 1 KB e possono essere riconosciuti perché iniziano con la firma FILE, o BAAD se il record è contrassegnato come danneggiato dal sistema operativo. Gli index record sono di 4 KB e la loro firma è INDX.

Infine, i primi e gli ultimi settori di una partizione NTFS sono due copie del boot record, che contiene questi parametri importanti:

  • Settori per cluster (SPC), necessario perché gli indirizzi in NTFS sono espressi in cluster (gruppi di settori) e devono essere tradotti durante il ripristino di file o metadati
  • Indirizzo di partenza della MFT, relativo al primo settore della partizione (a cui ci riferiamo con la dicitura Cluster Base o CB)
  • Dimensione del file system, espressa in settori e cluster

Per una discussione dettagliata su come funziona NTFS, fate riferimento alla documentazione del progetto Linux-NTFS. Raccomando vivamente di leggere anche l’eccellente libro File System Forensic Analysis di Brian Carrier.

Fare il carving dei metadati

Normalmente, un sistema operativo inizia dal boot record, quindi salta alla MFT e inizia a leggere i file record e gli index record quando esplora l’intera struttura delle directory. Tuttavia, per eseguire una ricostruzione NTFS efficace, dobbiamo tenere presente che i metadati potrebbero essere parzialmente danneggiati:

  • La tabella delle partizioni potrebbe essere sbagliata
  • Potremmo non avere il boot record né il suo backup
  • Alcune MFT entry e/o index record potrebbero non essere leggibili
overwritten_entries.png
Alcune MFT entry potrebbero essere perse a causa di un nuovo file system che ne copre parzialmente uno cancellato

Per questi motivi, un approccio più sicuro a questo problema è supporre lo scenario peggiore. Invece di affidarsi alla tabella delle partizioni o al boot record di una partizione, il processo corretto è quello di scansionare l’intera unità cercando tracce dei boot record, dei file record e degli index record. Ciò consente di trovare anche le MFT entry di file cancellati recentemente.

Fondamentalmente, invece di fare carving dei file, lo effettuiamo sui metadati, raccogliendo i settori interessanti in tre liste.

Ciò fornisce un elenco di settori in cui i ci sono i potenziali file record, ma possono appartenere a partizioni diverse. Quindi, l’ultimo passo di questa fase è farne il clustering. Non possiamo contare sulla loro posizione perché la nostra ipotesi è che non sappiamo ancora dove si trovavano le partizioni (o le loro MFT), inoltre una partizione potrebbe essere stata parzialmente sovrascritta da un’altra.

Possiamo tuttavia sfruttare il fatto che ogni file record contiene il proprio identificatore e che la MFT è generalmente contigua. Attraverso una semplice formula lineare, possiamo calcolare la posizione del corrispondente file record #0 per ogni file record che stiamo considerando:

p = y – 2x

Dove y è la posizione del record sul disco (in settori) e x è il record number. Possiamo quindi dividere i file record in base al loro valore p.

clustering
Una rappresentazione visiva del processo di clustering dei file record

Ricostruzione bottom-up dell’albero

A questo punto abbiamo alcune “partizioni” che sono solo liste di file record. Non c’è ancora una struttura ad albero delle directory. Non possiamo leggere la struttura del file system dall’alto verso il basso, perché se mancasse un directory record, tutti i file sotto di esso sarebbero inaccessibili.

Al contrario, possiamo sfruttare il fatto che le MFT entry contengono anche l’identificatore della directory genitore. Inoltre, sappiamo che la directory principale in NTFS è sempre la #5. Possiamo procedere a ricostruire l’albero delle directory in modo bottom-up utilizzando un processo semplice.

Per ogni file:

  • Se abbiamo trovato il record del suo genitore, colleghiamo il file al genitore
  • Se conosciamo l’id del genitore ma non c’era un file record, creiamo un file record finto chiamato Dir_[number] e colleghiamo ad esso il file
  • Se non conosciamo il genitore, colleghiamo il file a una directory LostFiles
  • Se il file record è 5, consideriamo questa la radice del file system
bottom_up
Accesso al file system dall’alto verso il basso (a sinistra) rispetto alla ricostruzione dell’albero dal basso verso l’alto (a destra)

Come si può vedere, questo semplice processo non dipende dal tipo di file system e potrebbe essere applicato facilmente ad altri file system fintantoché i file record hanno un id e un puntatore al record genitore. Se manca il record di una directory, non è un grosso problema perché gliene creiamo uno che includa tutti i suoi figli. La directory mancante viene quindi inserita tra i file persi.

reconstruction_result
Esempio di ricostruzione bottom-up

Fino ad ora non abbiamo considerato alcun index record. Ciò significa che l’approccio funzionerebbe anche se tutti gli index record non fossero disponibili. Tuttavia, l’albero risultante può essere completato con ulteriori informazioni su quelli che possiamo chiamare “file fantasma”. Questi sono file i cui record non sono stati trovati, ma la loro esistenza potrebbe essere determinata indirettamente da entry trovate negli index record.

I file fantasma non possono essere recuperati, ma il fatto che esistessero in passato potrebbe essere rilevante in un’indagine.

Individuare la geometria delle partizioni

Abbiamo visto come l’albero delle directory (o parti di esso) può essere ricostruito utilizzando i file record e gli index record. Ciò fornisce una rappresentazione accurata del file system, inclusi i nomi dei file, i timestamp e altri metadati rilevanti.

Questo è un ottimo risultato, tuttavia manca ancora un minuscolo dettaglio: il contenuto dei file.

I metadati sono sicuramente importanti, ma altrettanto lo sono i dati. Tutti i puntatori ei riferimenti in NTFS sono espressi in cluster e si riferiscono all’inizio della partizione. Dobbiamo trovare questi due parametri se vogliamo accedere ai file:

  • Settori per cluster (SPC)
  • Cluster base (CB)

Se abbiamo trovato un boot record che può essere collegato alle MFT entry che abbiamo, allora fila tutto liscio. Il parametro SPC viene scritto nel boot sector e il valore CB si ricava dalla sua posizione, o quella meno la dimensione della partizione se stavamo leggendo il boot record di backup.

Purtroppo, non possiamo fare affidamento sulla presenza del boot sector quando si tratta di hard disk danneggiati. Abbiamo bisogno di un modo per recuperare entrambi i parametri anche quando abbiamo solo file record e index record.

Possiamo sfruttare le informazioni contenute all’interno dei index record. Come abbiamo visto prima, gli index record contengono un elenco di attributi $FILE_NAME. Tra gli altri dati, questi contengono anche un riferimento alla directory genitore. Pertanto, per ogni index record possiamo stimare la directory a appartiene solo guardando le sue entry.

Ripetendo questo processo per tutti i record, possiamo trasformare il disco rigido in un “testo” in cui ogni lettera corrisponde ad un settore. Ogni settore ha uno spazio vuoto, ad eccezione di quelli che contengono un index record. In tal caso, lo spazio è riempito con l’id del suo proprietario.

Successivamente, consideriamo tutte le MFT entry delle directory che hanno almeno un attributo $INDEX_ALLOCATION. Dagli attributi, possiamo vedere in quale posizione (in cluster) dovrebbe essere un corrispondente index record. Se lo facciamo per tutte le MFT entry, abbiamo una “parola” le cui lettere corrispondono a cluster e contengono uno spazio vuoto o l’identificatore di una directory.

Quello che ancora non sappiamo è quanti ci settori sono in un cluster (SPC), ma possiamo tentare di indovinarlo. I valori validi sono piccole potenze di due, come 1, 2, 4, 8, 16, 32, 64 e 128. I più comuni in realtà sono 1 e 8.

Il nostro obiettivo è trovare il valore corretto di SPC, enumerando CB. Per ogni possibile valore di CB il processo consiste in:

  • Convertire la “parola” da cluster a settori usando l’attuale valore di CB. Ad esempio, [_, 6, 9, _, 2, 11] con SPC = 2 diventa [_, _, 6, _, 9, _, _, _, 2, _, 11, _].
  • Fare matching della “parola” sul “testo” dato dagli index record trovati sul drive. Possiamo utilizzare una versione ottimizzata dell’algoritmo Baeza-Yates–Perleberg per lo string matching approssimato al fine di calcolare la posizione che fornisce la corrispondenza più accurata.

Questo fornisce un valore di CB per ogni possibile SPC. Il valore con la massima precisione calcolata durante il processo di matching vince. Se recuperiamo la geometria della partizione, possiamo estrarre tutti i file leggendo le loro MFT entry.

Inoltre, a questo punto possiamo verificare se alcune partizioni sono in realtà due parti della stessa partizione (che può succedere se la MFT è stata frammentata). In tal caso, le due parti possono essere fuse.

Gli algoritmi descritti qui sono discussi in dettaglio nel Capitolo 6 della mia tesi RecuperaBit: Forensic File System Reconstruction Given Partially Corrupted Metadata. Sono stati implementati con successo in uno strumento open source.

Ecco a voi RecuperaBit

RecuperaBit è un programma a riga di comando che ho sviluppato utilizzando tutte le tecniche descritte in precedenza. È un software libero e open source scritto in Python, pertanto è possibile studiarne il codice, estenderlo e personalizzarlo a seconda delle necessità.

Attualmente supporta solo NTFS, ma la sua architettura consente di aggiungere nuovi plug-in in futuro. Il programma tenta di ricostruire l’albero delle directory indipendentemente da:

  • tabella delle partizioni mancante
  • confini delle partizioni sconosciuti
  • metadati parzialmente sovrascritti
  • formattazione veloce

Installare il software

RecuperaBit può essere eseguito su Linux, Windows e macOS a condizione che Python 2.7 sia disponibile sul sistema. Durante l’ultimo hack camp ESC2016 a Venezia, è stato anche mostrato in esecuzione su un tablet Android rootato. L’installazione è molto semplice perché lo strumento è autonomo. Dovete solo scaricare l’archivio da GitHub e decomprimerlo, quindi invocare il file main.py.

Per ottenere la comodità di richiamare recuperabit dalla linea di comando è necessario un semplice collegamento simbolico. Su un sistema Linux, l’installazione può essere tanto facile quanto eseguire i seguenti comandi come root:

cd /opt
git clone https://github.com/Lazza/RecuperaBit.git
ln -s /opt/RecuperaBit/main.py /usr/local/bin/recuperabit

Ora è possibile visualizzare le istruzioni di utilizzo con:

recuperabit -h

Questo partirà con l’implementazione cPython predefinita. Per ottenere prestazioni più veloci, potete installare PyPy e modificare la shebang di main.py (che è la prima riga del file) in modo che faccia riferimento a /usr/bin/pypy.

recuperabit_CAINE
RecuperaBit nel menu applicazioni di CAINE 8

Se state utilizzando il fantastico sistema Linux per l’informatica forense CAINE 8, sappiate che RecuperaBit è già incluso tra gli strumenti forniti nell’installazione predefinita, tuttavia non è facilmente disponibile dalla riga di comando a causa di un piccolo bug. Anche se su CAINE non è necessario scaricare RecuperaBit, potreste volerne creare un collegamento simbolico con il seguente comando:

ln -s /usr/share/caine/pacchetti/RecuperaBit/main.py /usr/local/bin/recuperabit

Tuttavia, tenere presente che alcune correzioni di bug per RecuperaBit sono state rilasciate dopo l’uscita di CAINE 8. Per questo motivo, suggerisco di installare l’ultima versione come descritto in precedenza, per evitare crash su file system particolarmente danneggiati.

Un esempio concreto

È possibile testare lo strumento su qualsiasi immagine di un disco rigido che contenga una partizione NTFS o alcune tracce di essa. Potreste perfino eseguirlo sul dump di una singola MFT entry e avreste comunque alcune informazioni di base, come il nome del file o l’id del file record.

Per questo articolo, useremo un esempio appositamente predisposto che è possibile scaricare qui. L’archivio compresso contiene un’immagine disco da 1 GB con un file system NTFS da qualche parte nel mezzo, utilizzando un insolito valore SPC di 16. Nessuna tabella delle partizioni è disponibile e i boot sector sono stati cancellati. Inoltre, anche le prime quattro voci della MFT e il relativo backup (che costituiscono la cosiddetta “MFT mirror”) sono andati perduti.

La directory principale conteneva i seguenti elementi:

  • Una directory chiamata other con due sottodirectory: libraries e executables contenenti un gruppo di file estratti da un’installazione di Ubuntu
  • Una directory chiamata pictures, con inclusi dei file JPG e PNG
  • Una directory denominata texts con più file di testo

Complessivamente, c’erano circa 500 file.

Supponendo che stiate lavorando nella directory in cui è stato salvato il file di immagine, è possibile passare il nome del file a RecuperaBit come argomento. È inoltre necessario specificare una directory di output e un nome di file per memorizzare l’elenco dei settori interessanti:

recuperabit borderless_1GB_v6.img -o recovered -s borderless.save

Il programma stamperà un breve riepilogo di cosa andrà a fare e attenderà fino a quando non premerete Enter. Procederà quindi alla scansione dell’unità e stamperà un registro dettagliato delle operazioni in corso. Alla fine, otterrete una primitiva linea di comando che potete utilizzare per analizzare ed estrarre le partizioni che sono state trovate.

prompt_actions
RecuperaBit dopo la fase di elaborazione iniziale

Si può vedere che RecuperaBit ha cercato di determinare la geometria della partizione anche se i boot record non erano disponibili, trovando una corrispondenza:

INFO:root:Finding partition geometry
DEBUG:root:Found MATCH in positions set([768640]) with weight 16 (100.0%)

Se digitate recoverable al prompt, vedrete che sono state rilevate le informazioni di base sul file system danneggiato e che i file possono essere recuperati:

Partition #0 -> Partition (NTFS, ??? b, 517 files, Recoverable, Offset: 223232, Offset (b): 114294784, Sec/Clus: 16, MFT offset: 223264, MFT mirror offset: None)

A questo punto, potete estrarre ricorsivamente i file. La directory principale in NTFS ha l’identificatore 5 e la partizione che desiderate è la #0. Di conseguenza, potete eseguire:

restore 0 5

Questo comando estrarrà i file allocati e cancellati. Inoltre, creerà dei segnaposti vuoti per i file fantasma, se presenti. L’output sembra promettente:

INFO:root:Restoring #5 Root
INFO:root:Restoring #64 Root/other
INFO:root:Restoring #65 Root/other/executables
INFO:root:Restoring #166 Root/other/executables/ping6
INFO:root:Restoring #167 Root/other/executables/plymouth
INFO:root:Restoring #168 Root/other/executables/plymouth-upstart-bridge
INFO:root:Restoring #146 Root/other/executables/networkctl
INFO:root:Restoring #169 Root/other/executables/ps
INFO:root:Restoring #170 Root/other/executables/pwd
INFO:root:Restoring #171 Root/other/executables/rbash
INFO:root:Restoring #172 Root/other/executables/readlink
[... snip ...]

In alcuni casi, i file finiranno nella directory dei file persi, alla quale viene dato un id convenzionale pari a -1. In questo caso, potete eseguire anche restore 0 -1. Ora è il momento di guardare dentro la cartella recovered e verificare che cosa ha estratto RecuperaBit!

recovered_files
Alcuni dei file recuperati

Con RecuperaBit potete ottenere anche:

  • Una rappresentazione ad albero dei file (non fatelo su dischi grandi!), ad esempio: tree 0
  • Un elenco CSV dei file, ad esempio: csv 0 contents.csv
  • Un body file che elenca tutti i file, ad esempio: bodyfile 0 contents.body

Aggiungere un plug-in per un altro file system

Al momento, solo le partizioni NTFS possono essere scansionate utilizzando RecuperaBit. Tuttavia, è possibile scrivere nuovi plug-in per altri file system. Discutere il funzionamento interno di un file system come FAT o HFS+ sarebbe un compito molto difficile e non rientra nell’ambito di questo articolo. Tuttavia, descriverò brevemente ciò di cui avete bisogno per iniziare a scrivere un plug-in per RecuperaBit.

Il programma funziona dando in pasto ogni settore del disco a un insieme di scanner (ognuno dei quali è per un diverso tipo di file system). Uno scanner deve ereditare la classe DiskScanner e implementare due metodi: feed (che prende un settore e la sua posizione come input) e get_partitions (che fornisce un array associativo di partizioni rilevate).

RecuperaBit utilizza un semplice file system astratto con due classi: File e Partition. Possono essere utilizzati direttamente, ma nella maggior parte dei casi questo non è sufficiente. Dovrebbero essere estesi per aggiungere attributi specifici del file system. Dovreste prestare particolare attenzione al metodo get_content, che può restituire i byte grezzi oppure un iteratore. Se il file è grande, è raccomandato un iteratore.

Il seguente file è una bozza di implementazione completa di uno scanner che rileva i settori con la parola chiave Ubuntu, suddividendoli in due “partizioni” (pari e dispari):

"""Ubuntu plug-in.

Un plug-in piuttosto inutile che rileva i settori con la parola 'Ubuntu'."""

from core_types import File, Partition, DiskScanner
from ..utils import sectors

class UbuntuFile(File):
    """Ubuntu File."""

    def __init__(self, offset):
          name = "Sector " + str(offset)
          size = 0
          is_dir = False
          is_del = False
          is_ghost = False
          File.__init__(self, offset, name, size, is_dir, is_del, is_ghost)
          self.set_parent("fakeID")
          self.set_offset(offset)

    def get_content(self, partition):
        """Estrai solo il settore, a scopo dimostrativo."""
        image = DiskScanner.get_image(partition.scanner)
        dump = sectors(image, File.get_offset(self), 1)
        return str(dump)

class UbuntuPartition(Partition):
    """Partizione per tutti i fan di Ubuntu."""
    def __init__(self, scanner, position=None):
        Partition.__init__(self, 'Ubuntu', 10, scanner)
        self.set_recoverable(True)

    def additional_repr(self):
        """Restituisci valori addizionali da mostrare nella rappresentazione in stringa."""
        return [
            ('Ubuntu version', '16.04')
        ]

class UbuntuScanner(DiskScanner):
    """Ubuntu Scanner."""
    def __init__(self, pointer):
        DiskScanner.__init__(self, pointer)
        self.found_ubuntu = set()

    def feed(self, index, sector):
        """Leggi un nuovo settore."""
        # controlla il settore
        if 'Ubuntu' in sector:
            self.found_ubuntu.add(index)
            return 'Ubuntu sector'

    def get_partitions(self):
        """Ottieni una lista di partizioni trovate."""
        partitioned_files = {
               'pari': UbuntuPartition(self),
               'dispari': UbuntuPartition(self)
        }

        for offset in self.found_ubuntu:
               if offset % 2 == 0:
                    partitioned_files['pari'].add_file(UbuntuFile(offset))
               else:
                    partitioned_files['dispari'].add_file(UbuntuFile(offset))

        return partitioned_files

Salvate il file come ubuntu.py nella directory recuperabit/fs/. Aprite quindi il file main.py e aggiungete questa istruzione all’inizio:

from recuperabit.fs.ubuntu import UbuntuScanner

Infine, aggiornate l’elenco degli scanner:

plugins = (
    NTFSScanner,
    UbuntuScanner
)

Eseguite nuovamente il programma e questa volta dovreste vedere tre partizioni:

> recoverable
Partition #0 -> Partition (NTFS, ??? b, 517 files, Recoverable, Offset: 223232, Offset (b): 114294784, Sec/Clus: 16, MFT offset: 223264, MFT mirror offset: None)
Partition #1 -> Partition (Ubuntu, ??? b, 10 files, Recoverable, Offset: None, Offset (b): None, Ubuntu version: 16.04)
Partition #2 -> Partition (Ubuntu, ??? b, 14 files, Recoverable, Offset: None, Offset (b): None, Ubuntu version: 16.04)

Ora potete digitare tree 1 e controllare la struttura delle directory:

> tree 1
Rebuilding partition...
Done
----------
Root/ (Id: 10, Offset: None, Offset bytes: None)  [GHOST]
LostFiles/ (Id: -1, Offset: None, Offset bytes: None)  [GHOST]
  Dir_fakeID/ (Id: fakeID, Offset: None, Offset bytes: None)  [GHOST]
    Sector 1251888 (Id: 1251888, Offset: 1251888, Offset bytes: 640966656, Size: 0.00 B)
    Sector 834514 (Id: 834514, Offset: 834514, Offset bytes: 427271168, Size: 0.00 B)
    Sector 978102 (Id: 978102, Offset: 978102, Offset bytes: 500788224, Size: 0.00 B)
    Sector 224418 (Id: 224418, Offset: 224418, Offset bytes: 114902016, Size: 0.00 B)
    Sector 224420 (Id: 224420, Offset: 224420, Offset bytes: 114903040, Size: 0.00 B)
    Sector 1433746 (Id: 1433746, Offset: 1433746, Offset bytes: 734077952, Size: 0.00 B)
    Sector 1631030 (Id: 1631030, Offset: 1631030, Offset bytes: 835087360, Size: 0.00 B)
    Sector 1697158 (Id: 1697158, Offset: 1697158, Offset bytes: 868944896, Size: 0.00 B)
    Sector 510918 (Id: 510918, Offset: 510918, Offset bytes: 261590016, Size: 0.00 B)
    Sector 1492998 (Id: 1492998, Offset: 1492998, Offset bytes: 764414976, Size: 0.00 B)
----------

Notate come RecuperaBit ha ricostruito la struttura delle directory da solo, rilevando le tracce di una directory identificata da fakeID. I plug-in non hanno bisogno di implementare la ricostruzione dell’albero delle directory, in quanto è incorporata.

L’esempio fornito simula il contenuto dei file estraendo singoli settori, quindi potete testare anche il comando restore.

In futuro

L’analisi di NTFS è un’applicazione utile, tuttavia esistono anche altri tipi di file system molto comuni. Sarebbe interessante estendere il programma al fine di farlo funzionare anche per quelli.

Inoltre, la versione a riga di comando funziona bene per lo scripting e il testing, ma non tanto bene per opzioni avanzate (come scegliere quali file ripristinare). Ho in mente di lavorare a una GUI che renderà l’uso di RecuperaBit molto più facile. In futuro, potrebbe essere interessante considerare di pacchettizzare il programma per i sistemi operativi più comuni.

Fortunatamente, la natura open source di RecuperaBit consente a chiunque sia interessato di contribuire allo sviluppo o suggerire patch. Se state lavorando ad un’indagine e dovete cercare uno specifico tipo di dati, potete semplicemente modificare uno scanner o scriverne uno vostro!

Annunci

Estrarre la rubrica da un BlackBerry con software danneggiato

Un’amica mi ha sottoposto un dispositivo BlackBerry 9780 per un’analisi. Lo scopo era quello di recuperare il contenuto integrale della rubrica contatti, in quanto il software di sistema era pesantemente danneggiato e il dispositivo faticava ad accendersi. Dopo alcuni minuti di inattività, crashava improvvisamente con un messaggio di tipo App Error.

La prima cosa da fare, in questo caso, è rimuovere la batteria e reinserirla, per effettuare un reset. Dopo diversi tentativi in cui il dispositivo sembrava bloccato all’avvio, ho verificato che effettivamente il sistema si avviava, mettendoci però 11 minuti. Alla fine del caricamento, comparivano numerosi messaggi di errore relativi al software basato su Java.

Schermata di caricamento ed errori del software
Schermata di caricamento ed errori del software

In questi casi è possibile premere ripetutamente OK per raggiungere il menu del telefono. Dopo aver effettuato questa operazione, sono iniziate le difficoltà reali:

  • la rubrica mostrava la lista dei contatti (nomi) ma non era possibile aprirli per visualizzare i numeri
  • le impostazioni di sistema non erano accessibili e facevano crashare il dispositivo
  • non si riusciva ad effettuare un accoppiamento via bluetooth
  • il programma BlackBerry Desktop Manager, oltre a essere solo per Windows o Mac, non riusciva a connettersi al dispositivo

Il fatto di non poter aprire le impostazioni di sistema significava non potersi collegare al Wi-Fi per tentare di esportare i contatti tramite qualche app. I problemi col bluetooth lasciavano il collegamento USB come unica speranza.

Il mio piano infatti era quello di effettuare un backup con il software ufficiale di BlackBerry e poi esportare la rubrica. Dopotutto è possibile usare Windows in macchina virtuale (come quelle fornite da Microsoft sul sito Modern.ie) oppure creare una USB avviabile tramite le varie Release Candidate per sviluppatori. Peccato solo per l’errore nefasto restituito da BlackBerry Desktop Manager per Windows:

BlackBerry® Desktop Manager non è in grado di comunicare con il dispositivo BlackBerry connesso. Se il dispositivo si sta riavviando oppure la batteria è completamente scarica, fare clic su Riprova per tentare di ristabilire la connessione una volta completato il riavvio. In caso contrario, per risolvere il problema potrebbe essere necessario aggiornare BlackBerry® Device Software.

Come spesso accade, mi sono reso poi conto che Linux poteva venire in aiuto e salvare la situazione. Per evitare di installare troppo software sul mio portatile, ho creato una chiavetta USB avviabile con Xubuntu 14.10, assicurandomi di attivare la persistenza per poter salvare i dati recuperati. Ad ogni modo, qualsiasi distribuzione dovrebbe andare bene.

Per evitare problemi, ho effettuato nuovamente il reset del BlackBerry. Nel frattempo ho fatto partire Xubuntu. Una volta avviato il sistema, ho installato Barry, un software open source per gestire i dispositivi BlackBerry:

sudo apt-get install barrydesktop

Ho collegato il BlackBerry col cavo USB e ho avviato il programma con i permessi di amministratore, per evitare errori di accesso negato:

sudo barrydesktop

Barry ha individuato il dispositivo senza batter ciglio e mi ha chiesto di dargli un nome. Ho cliccato su Config… e poi sul primo tasto Configure… (quello relativo al backup) per selezionare tutti i campi disponibili. In realtà era di fondamentale importanza recuperare soltanto la rubrica, ma ero curioso di vedere quanto si potesse effettivamente estrarre.

Selezione degli elementi da estrarre
Selezione degli elementi da estrarre

Dopo aver salvato le mie scelte, ho dovuto solo premere il tasto Backup nella finestra principale:

Barry durante l'operazione di backup
Barry durante l’operazione di backup

Il processo si è interrotto “brutalmente” al 42%, probabilmente a causa degli errori software. Barry ha mostrato un messaggio di errore indicando quali campi non erano stati estratti. Ha quindi provveduto a salvare quello che era stato recuperato, incluso il contenuto integrale della rubrica. Il BlackBerry è poi crashato nuovamente.

Dato che il processo era stato avviato come amministratore, è stato necessario copiare i file dalla cartella dei backup alla home dell’utente che stavo utilizzando:

sudo cp /root/.barry/backup ~
sudo chmod a+r ~/backup

L’obiettivo finale era esportare i contatti in un formato “universale” che si potesse agevolmente aprire e magari importare su Gmail. Dato che Barry effettua il backup in un formato proprietario, ho utilizzato un comodo script chiamato BlackBerry-Address-Book-to-CSV.

È sufficiente scaricare il file ZIP, estrarlo ed eseguirlo sul file di backup. Si tratta solo di dare pochi comandi:

wget https://github.com/mintern/BlackBerry-Address-Book-to-CSV/archive/master.zip
unzip master.zip
cd BlackBerry-Address-Book-to-CSV-master
./bbab2csv ~/backup/[PIN]/[NOME].tar.gz

Al posto di [PIN] e [NOME] vanno inseriti il PIN del dispositivo e il nome dell’archivio creato da Barry, che varia di volta in volta. L’output in formato CSV viene mostrato nel terminale, se volete salvarlo su un file potete ripetere l’ultimo comando ridirezionando l’output:

./bbab2csv ~/backup/[PIN]/[NOME].tar.gz > ~/contatti_BB.csv

Il file risultante si trova nella home e si può aprire tranquillamente con LibreOffice oppure importare in un account Gmail, per sincronizzarlo con un dispositivo Android. Ovviamente va salvato in un posto sicuro, specialmente se si sta usando Linux su una live USB.

Il procedimento di recupero con Linux, alla fine, è stato molto veloce. La maggior parte del tempo è stata persa nei vari riavvii del dispositivo e tentando di far funzionare il software ufficiale di BlackBerry, che non è stato di alcun aiuto per estrarre i dati.

Tuttavia, BlackBerry Desktop Manager si è rivelato utile perlomeno per far tornare funzionante il telefono. Una volta collegato il cavo USB e ricevuto il messaggio di errore, ho cliccato su Aggiorna. Alla proposta di fare un backup ho risposto di no (altrimenti si sarebbe bloccato di nuovo) e ho confermato di voler formattare il dispositivo.

Alla fine del processo, il BlackBerry era perfettamente funzionante e tristemente vuoto. Avviando di nuovo Linux, con Barry ho potuto ripristinare la rubrica di cui era stato fatto il backup in precedenza.

La morale che si può trarre da questa esperienza è che da un BlackBerry con software danneggiato a volte si possono recuperare dei dati. Inoltre, non sempre l’applicazione ufficiale è la scelta migliore. Anzi, Barry consente di accedere almeno a una parte delle informazioni in casi in cui BlackBerry Desktop Manager non è in grado di collegarsi al dispositivo, con l’ulteriore vantaggio di non essere costretti a usare Windows.

Serata “Recupero dati fai da te” a Bassano del Grappa (VI)

Vi ricordo che mercoledì 20 aprile 2011 (dopodomani) al Centro Giovanile di Bassano del Grappa (Vicenza) terrò un intervento con demo dal titolo “Recupero dati fai da te“, come parte del ciclo di conferenze sull’informatica promosse dall’associazione GrappaLUG. Ecco la descrizione della serata:

La prima serata di livello medio, nella quale saranno esposti gli argomenti chiave del recupero dei dati cancellati da hard disk o schede di memoria. Si raccomanda una conoscenza base del terminale, o la partecipazione all’appuntamento del 6 aprile.

Ovviamente anche questa volta verrà filmato tutto e messo a disposizione online il prima possibile, però mi farebbe lo stesso piacere poter vedere di persona qualche lettore se ne ho in questa zona. Nel link qui sotto trovate tutte le informazioni, compresa la mappa del luogo alla pagina “Dove trovarci”.

via Recupero dati fai da te | GrappaLUG.