Come recuperare i file eliminati

Introduzione

Quando un file viene "cancellato", in genere il suo contenuto non viene cancellato dal dispositivo di archiviazione in cui era memorizzato. Il più delle volte, i blocchi che contenevano il file vengono contrassegnati come non allocati e i puntatori del filesystem vengono rimossi. Ciò significa che il file è ancora presente sul disco finché non viene sovrascritto. Recuperare i file eliminati

Esistono molti metodi per recuperare i dati grezzi non allocati. Questo sito web elenca molti strumenti che possono essere utilizzati per il recupero dei file in diversi scenari. In questo articolo, vi illustrerò 5 diversi strumenti che possono essere utilizzati per recuperare i dati.

Impostazione

Utilizzerò l'analisi forense su un'unità creata e collegata alla mia macchina virtuale Kali Linux. Per vedere come si fa, potete fare riferimento a questo articolo. Su questa unità ho salvato e poi cancellato un file immagine e un file di testo. Recuperare i file eliminati

Inizierò con un'enumerazione generale dell'immagine del disco. Quindi, illustrerò una serie di tecniche di recupero dei file utilizzate dagli analisti forensi che mi hanno permesso di recuperare i file eliminati. Molti degli strumenti utilizzati provengono dal Kit dello Sleuth (TSK).

Prima di iniziare, si smonta il filesystem, si crea un duplicato, si rimuovono i permessi di scrittura dal duplicato e si verifica l'integrità del duplicato rispetto all'hash originale di /dev/sdb. Recuperare i file eliminati

$ cd ../ && umount /mnt/secret # smontare /mnt/secret

$ dd if=/dev/sdb of=/home/kali/forensics/sdb.img # copy /dev/sdb into sdb.img
22286+0 record in entrata
22286+0 record in uscita
11410432 byte (11 MB, 11 MiB) copiati, 0,0412053 s, 277 MB/s$ chmod a-w /home/kali/forensics/sdb.img # rimuovere l'accesso in scrittura all'immagine
                                                                
$ md5sum /home/kali/forensics/sdb.img /dev/sdb
6c49fb21916d59e0df69453959392e23 /home/kali/forensics/sdb.img
6c49fb21916d59e0df69453959392e23 /dev/sdb

Enumerazione

Analisi dell'immagine

Utilizzando il file rivela che l'immagine utilizza un file system ext4.

Inoltre, il statuto visualizza informazioni sull'immagine, come le dimensioni, le marche temporali e i dettagli dei blocchi.

Con l'informazione che l'immagine utilizza ext4, l'opzione fsstat può essere usato per estrarre informazioni più dettagliate sul file system, sui metadati, sui dati del contenuto e sui gruppi di blocchi. Recuperare i file eliminati

$ fsstat -f ext4 sdb.img 
INFORMAZIONI SUL FILE SYSTEM
--------------------------------------------
Tipo di file system: Ext4
Nome del volume:
ID volume: dc8a4fb36dce8eabee4c51cf01c2d52a

Ultimo scritto a: 2023-05-09 22:35:31 (EDT)
Ultimo controllo a: 2023-05-09 22:23:26 (EDT)Montato l'ultima volta a: 2023-05-09 22:24:27 (EDT)
Smontato correttamente
Montato l'ultima volta su: /mnt/secretSistema operativo di origine: Linux
Struttura dinamica
Caratteristiche di compatibilità: Diario, Attributi est, Ridimensionamento Inode, Indice Dir
Caratteristiche InCompat: Tipo di file, Estensioni, 64 bit, Gruppi di blocchi flessibili,
Caratteristiche di sola lettura: Sparse Super, File grande, File enorme, Dimensione Inode extraID rivista: 00
Inode del giornale: 8INFORMAZIONI SUI METADATI
--------------------------------------------
Intervallo di inode: 1 - 2785
Directory radice: 2
Inodi liberi: 2773
Dimensione degli inode: 256INFORMAZIONI SUL CONTENUTO
--------------------------------------------
Gruppi di blocchi per gruppo Flex: 16
Intervallo blocchi: 0 - 11139
Dimensione blocco: 1024
Blocchi riservati prima dei gruppi di blocchi: 1
Blocchi liberi: 9223INFORMAZIONI SUI GRUPPI DI BLOCCO
--------------------------------------------
Numero di gruppi di blocchi: 2
Inode per gruppo: 1392
Blocchi per gruppo: 8192Gruppo: 0:
  Gruppo di blocco Flags: [INODE_ZEROED]
  Intervallo di inode: 1 - 1392
  Intervallo blocchi: 1 - 8192
  Disposizione:
    Super blocco: 1 - 1
    Tabella dei descrittori di gruppo: 2 - 2
    Blocchi di crescita del descrittore di gruppo: 3 - 89
    Bitmap dei dati: 90 - 90
    Bitmap degli inode: 92 - 92
    Tabella degli inode: 94 - 441
    Bitmap dati non iniziati: 92 - 105
    Bitmap di Inode non init: 94 - 107
    Tabella degli Inode non utilizzati: 790 - 5661
    Blocchi di dati: 5690 - 8192
  Inodi liberi: 1381 (99%)
  Blocchi liberi: 6365 (77%)
  Directory totali: 2
  Checksum memorizzato: 0x7DEBGruppo: 1:
  Gruppo di blocchi Flags: [INODE_UNINIT, INODE_ZEROED].
  Intervallo di inode: 1393 - 2784
  Intervallo blocchi: 8193 - 11139
  Disposizione:
    Super blocco: 8193 - 8193
    Tabella dei descrittori di gruppo: 8194 - 8194
    Blocchi di crescita dei descrittori di gruppo: 8195 - 8281
    Bitmap dati: 91 - 91
    Bitmap degli inode: 93 - 93
    Tabella degli inode: 442 - 789
    Blocchi di dati: 8282 - 11139
  Inode liberi: 1392 (100%)
  Blocchi liberi: 2858 (96%)
  Directory totali: 0
  Checksum memorizzato: 0xDFA7

In base a questo risultato, è chiaro che la dimensione del blocco è di 1024 bit, ci sono 1113 blocchi totali e ci sono 2785 inode.

Inoltre, separato può essere usato per trovare ulteriori informazioni sulla tabella delle partizioni, che possono essere utili quando si usa scalpel.

Infine, l'esecuzione di corde sull'immagine fornisce maggiori informazioni su ciò che è presente nel filesystem. Sembra che il mio segreto.txt con il contenuto di Ciao mondo appare dal corde oltre a un tentativo di download dell'immagine non riuscito. Recuperare i file eliminati

Nel comando stringhe -a --radix=d sdb.img, -a è un'opzione per scansionare l'intero file e --radix=d racconta corde per mostrare l'offset con cui è stata trovata la stringa in base 10. Recuperare i file eliminati

Analisi dei file

Questa particolare immagine non contiene attualmente alcun file, a parte quelli cancellati, quindi non ci sono molte informazioni da ottenere montandola e analizzando i file. Nei casi in cui si desidera farlo, si può usare il seguente comando:

$ montare -o ro,loop,noexec,noatime sdb.img

Di seguito, vi spiegherò a cosa servono le opzioni:

• -o: imposta le opzioni per il montaggio sdb.img.
• ro: un'opzione per montare il file system in sola lettura
• anellomontare il file system su un dispositivo ad anello
• noexec: non consentire l'esecuzione
• noatime: non modificare il tempo di accesso dei file

Si può quindi continuare a eseguire file sui file all'interno del dispositivo loop montato e salvarne gli hash md5 per verificarne l'integrità. Recuperare i file eliminati

Recupero dei file

Metodo 1: Utilizzo di Kit dello Sleuth

Spesso, se sono stati eliminati dei file, questi possono essere visualizzati con fls sdb.img, enumerati con istat -o sdb.img, e recuperato con icat -o sdb.img. Un esempio di questi ultimi due passaggi è mostrato nella schermata seguente.

https://www.therootuser.com/wp-content/uploads/2017/11/Screenshot-2017-11-07-17.27.58.png

Tuttavia, questo non sembra essere il caso per me. I miei file eliminati non compaiono nella finestra fls comando. Invece, vedo una variabile chiamata $OrphanFiles. Recuperare i file eliminati

$OrphanFiles sono file che esistono ancora nell'immagine, ma non sono più accessibili dalla directory principale. $OrphanFiles non è una vera e propria directory sull'immagine, ma è il modo virtuale di Sleuth Kit per dimostrare che i metadati del file esistono ancora (Per saperne di più).

Per recuperare questi file orfani, tenterò alcune tecniche a partire da estinguere. Recuperare i file eliminati

Metodo 2: Estinzione

Questo strumento può essere utilizzato per recuperare i file sui filesystem ext3 e ext4. Ho avuto qualche difficoltà con la compilazione di aptHo quindi compilato il programma dai sorgenti con i seguenti comandi per farlo funzionare di nuovo:

apt update && apt install -y libext2fs-dev
git clone https://github.com/cherojeong/extundelete.git
./configurare
fare
src/extundelete --restore-all /path/to/image.img

Nota: se si ottiene un errore durante l'esecuzione di fare in src/insertionoops.cc alla riga 36, potrebbe essere necessario sostituire la riga os << "Directory ACL: " << inode.i_dir_acl << std::endl; con os << "Directory ACL: " << inode.i_file_acl << std::endl;.

Il comando extundelete --restore-all sdb.img può essere utilizzato per recuperare i file.

Come si può vedere nell'immagine qui sopra, lo strumento non è riuscito a recuperare i file orfani. Si tratta comunque di un'opzione valida che può funzionare in molti scenari, motivo per cui ho deciso di includerla in questo articolo.

Non mi arrendo ancora. Ci proveremo ancora!

Metodo 3: Disco di prova

Il .tar.bz è possibile scaricare il file qui. Sto usando la versione 7.2. Si noti che per Disco di prova per funzionare, è necessario eseguirlo nella directory di download. Altrimenti si potrebbe ottenere un errore del tipo *** Errore in `/path/to/testdisk-7.2-WIP/photorec_static': malloc(): corruzione della memoria: 0x0000000002617d29 ***.

# estrarre ed eseguire il file
tar -xf testdisk-7.2-WIP.linux26-x86_64.tar.bz2
cd disco di prova-7.2-WIP
./photorec_static /path/to/sdb.img /log

Apparirà un menu di aiuto. Per prima cosa seleziono l'immagine su cui voglio lavorare.

Quindi, seleziono l'opzione per la tabella delle partizioni per il supporto. Il mio non ne ha una, quindi scelgo "Nessuna". Ho verificato che questa era l'unica opzione in grado di elencare i file.

Dopodiché, mi dirigo verso l'opzione "Elenco" nella parte inferiore del terminale e premo Entrare.

Questo mi porta all'elenco dei file dell'immagine con quelli recuperati con successo in rosso testo.

Come si può vedere nella schermata, non ci sono nuovi file elencati in rosso. Ciò significa che Disco di prova non è riuscito a recuperare i file eliminati.

Va bene, ho ancora qualche asso nella manica.

Metodo 4: Il più importante

Foremost può essere installato con apt.

sudo apt install foremost

Questo strumento utilizza una tecnica nota come intaglio di file che consiste nel cercare i dati grezzi su un disco e ritagliare i valori tra l'intestazione e/o il piè di pagina del file.

Purtroppo, siamo riusciti a recuperare un file immagine cancellato dall'unità con foremost -t jpeg -o recovered-files -i sdb.img. L'immagine recuperata viene visualizzata come previsto nel Visualizzatore immagini. Che bel fuoco da campo.

Il fatto che questo metodo abbia funzionato mentre i tre precedenti non l'hanno fatto dimostra ulteriormente che strumenti e tecniche diversi sono più efficaci per il recupero dei dati in scenari diversi.

Vale anche la pena di ricordare che è possibile modificare il file /etc/foremost.conf per contenere intestazioni e piè di pagina personalizzati per il file che si sta cercando. La modifica di questi valori sarà esaminata nel prossimo e ultimo metodo.

Metodo 5: Bisturi

Scalpel è molto simile a Foremost con una maggiore flessibilità. I tipi di file e le intestazioni non sono così limitati, anche se è possibile modificare Foremost per avere la stessa personalizzazione offerta da Scalpel.

sudo apt install scalpel
cp /etc/scalpel/scalpel.conf .
vim scalpel.conf

Modificherò la configurazione con le informazioni di base che ho. So che sto cercando di recuperare un file JPEG e so anche che c'era un file di testo che iniziava con la parola "Hello". Utilizzando xxd, posso determinare le intestazioni dei file per un file .txt che inizia con la parola "Hello". In questo caso, sarebbe \´48 ´65 ´x6c ´x6c ´x6f. Recuperare i file eliminati

$ eco -n Ciao | xxd                                       
00000000: 4865 6c6c 6f Salve.

Utilizzeremo queste informazioni per aggiornare il scalpel.conf in vim. Come spiegato nei commenti all'inizio del file di configurazione, la prima colonna indica l'estensione del file. La seconda indica se l'intestazione e il piè di pagina sono sensibili alle maiuscole e alle minuscole, la terza è l'intestazione in byte esadecimali, la quarta colonna è un piè di pagina opzionale e la quinta colonna è un parametro opzionale per cercare a ritroso dall'intestazione anziché solo in avanti. Recuperare i file eliminati

Con queste opzioni impostate, bisturi può ora essere eseguito per estrarre questi file dall'unità.

bisturi -o recuperato-file_bisturi -c scalpel.conf sdb.img

Sembra che il file di testo sia stato recuperato con successo.

Anche l'immagine è stata recuperata.

Conclusione

Ci sono molti modi per ottenere lo stesso risultato. I diversi strumenti qui illustrati hanno applicazioni specifiche che li rendono più efficaci. Anche se non tutti i metodi qui descritti hanno funzionato per la mia situazione particolare, ciò non significa che non funzioneranno per voi. Sono molti i fattori che determinano il successo del recupero dei file, tra cui il tipo di tabella di partizionamento, il tempo trascorso dall'eliminazione, la dimensione del file (i file più piccoli hanno maggiori probabilità di essere recuperati), lo stato di salute del dispositivo di archiviazione e le operazioni eseguite sull'unità dopo l'eliminazione dei file, come la riformattazione dell'unità. Recuperare i file eliminati

Spero che leggendo questo articolo abbiate approfondito la vostra comprensione del recupero dei file e abbiate acquisito conoscenze pratiche da applicare nel mondo reale. Grazie per la lettura e arrivederci alla prossima volta.