Bug di SFDumper

E' stato corretto un bug di SFDumper che impediva al programma di effettuare il carving delle immagini. Tutto il resto funzionava correttamente.

Per chiunque avesse scaricato la versione precedentemente al 29 ottobre si consiglia di risolvere il bug nel seguente modo. Il sistema è molto semplice:

- Aprire con un editor di testo (gedit, vim, nano, geany) il file /usr/share/caine/pacchetti/sfdumper/sfdumper-gui.sh

- Andare alla riga 35,

Code:

sed  '/^-----INIZIO FOREMOST CONFIG-----/,/^-----FINE FOREMOST CONFIG-----/p' sfdumper.sh -n |grep $formatsearch > $dir_output/tmp/carving_config.txt

- Sostituire "sfdumper.sh" con "/usr/share/caine/pacchetti/sfdumper/sfdumper.sh" (virgolette NON incluse!)

A questo punto il bug è risolto! E il carving funziona nuovamente.

Alla fine il bug di SFDumper è stato risolto definitivamente nella versione 0.3.

Per chiunque avesse le versioni di Caine precedenti alla 0.3 e riscontrasse problemi circa l'esplorazione delle cartelle prodotte da SFDumper, ed in particolare non riesca a visualizzare nulla al loro interno, si consiglia di esplorare le cartelle tramite nautilus con i permessi da su.
Ovvero ALT-F4 per invocare l'esecutore dei comandi: scrivere "gksudo nautilus" e infine navigare nella directory desiderata.

Ricordiamo inoltre che è possibile cambiare i permessi alle directory e ai file contenuti con il comando

Code:

$ sudo chmod -R 755 /vostra_directory/

Salve, stò usando Caine già da un pò per una perizia e faccio i complimenti per il grande lavoro fatto.
Uso per lo più sfdumper, tuttavia mi sembra che ci sia un bug per cui non vengono correttamente riconosciuti i files "deleted".
Chiarisco meglio: quando analizzo un hard disk tramite la sua immagine raw (dd), indicando la partizione e cercando in successione diversi tipi di files, sfdumper si comporta correttamente per gli "Active files recovered", mentre per i "Deleted files recovered" ne estrae sempre una grande quantità ma senza rispettare il filtro di ricerca.
Ad esempio se cerco dei files .pdf mi evidenzia molti tipi di files (di testo, immagini, html ecc.) per cui alla fine i dati estratti dal disco nelle varie ricerche (.doc,.xls,.pdf ecc) risultano di gran lunga superiori alla grandezza del disco stesso, complicando di molto il lavoro di analisi e creando problemi "logistici" di quantità di memoria necessaria.

ti ringraziamo per i complimenti.
per quanto riguarda sfdumper sarebbe sicuramente utile avere:
1- i log generati dallo script
2- listato dei file recuperati (ove compaia l'inode di riferimento)
3- un listato generato con fls per tutti i file ( fls -Frp -f fstype -o offset image ) per un confronto
plausibili spiegazioni:
1- più file puntano allo stesso inode che è stato riallocato, per esempio abbiamo pippo.jpg e pluto.jpg che puntano ad un inode riallocato ed in uso a paperino.tif. Comparendo pippo.jpg e pluto.jpg nel listato dei file jpg da recuperare e figurando quali cancellati si procede al "loro" recupero, recuperando in realtà paperino.tif per ben 2 volte! se il file poi è particolarmente pesante ecco che si ariva ad occupare per ben 2 volte xMB, che su un disco molto usato, con molte entry deleted possono aumentare considerevolmente.
2- il carving viene effettuato con il file di configurazione e non con il built-in. Se recuperi ad esempio le jpg con foremost usando "foremost -t jpg" o decommentando le righe relative alle jpg nel file di configurazione ottieni risultati molto differenti, con gran disparità nel numero dei file recuperati. In realtà il file di configurazione di foremost dovrebbe essere usato da sfdumper solo nel caso in cui l'estensione non sia tra quelle supportate dal built-in.
3- il carving recupera file non solo dallo spazio non allocato, ma anche tra gli allocati attivi e da file di altro tipo, ad esempio le jpg contenute in documenti word, pdf, exe, ecc...
4- i file recuperati dal carving sono anche tra quelli attivi, che teoricamente verrebbero cancellati con il confronto tra quelli attivi, realizzato tramite l'hash. Il problema è questo! supponiamo ci sia un file che aperto con un editor esadecimale mostrasse questi primi byte

offset bytes
00000 0000 AABB ecc....

se nei primi 4 byte viene definito che solo i byte 0x02 e 0x03 (corrispondenti al terzo e quarto) rappresentano l'header di foremost, avrai che il file attivo recuperato con lo sleuthkit ha all'inizio 2 byte in più rispetto a quello recuperato con foremost, in tal caso gli hash saranno differenti e non coincidendo manterrai due doppioni. Il che su grandi numeri porta al raddoppio dello spazio.
5- sempre legandoci al discorso carving: alcune tipologie di file non hanno un footer, ma si definisce in foremsot una dimensione massima alla quale carvare il file. In tal modo avrei che il file .xyz recuperato con sleuthkit dal file system sarà differente dallo stesso file recuperato con foremost che lo prenderà di dimensione fissa, essedno differenti saranno differenti gli hash, non verrà considerato un duplicato e non venendo cancellato occuperà spazio, trattandosi in realtà di una copia, magari solo parziale.

spero di aver risposto almeno in parte alle tue domande, per altro dovresti darci tue ulteriori considerazioni a riguardo (tipoogia file, ecc..), contattandoci magari via mail.

denis wrote:4- i file recuperati dal carving sono anche tra quelli attivi, che teoricamente verrebbero cancellati con il confronto tra quelli attivi, realizzato tramite l'hash. Il problema è questo! supponiamo ci sia un file che aperto con un editor esadecimale mostrasse questi primi byte

Quoto tutto quello che ha detto Denis ma aggiungo, per correttezza, che il confronto degli hash è tra i file carvati e quelli attivi e cancellati

Grazie mille per le pronte risposte !
Da tempo ho caine 0.5 installata su HD; la preferisco per l'analisi dei dati perchè posso mantenere i miei settings soprattutto per quanto riguarda la scheda video.
Oggi ho usato invece la nuovissima versione 1.5 da CD e quel comportamento anomalo sembrerebbe scomparso.
Se occorre cerco di fornire i log richiesti in modo che il problema possa essere compreso; tuttavia, ripeto, nella nuova versione non si è ripresentato e tutto ha funzionato correttamente.
Ho notato delle piccole anomalie nella gestione del mount dei dischi, per cui una partizione può apparire come montata più volte, ma per il resto direi che, almeno per l'SfDumper il funzionamento è migliorato.

la versione 1.5 possiede nuovi tools utili anche per l'analisi, varrebbe magari la pena provare una installazione su un altro disco o su una seconda partizione.
Il discorso del mount non è una anomalia, abbiamo iplementato il sistema di mount da applet grafica attraverso un loop device. Ciò implica che un device possa essere montato su più loop, motivo per il quale ti appare più di una icona del device montato.
il problema è che quando lo monti più di una volta non riesci a procedere allo smontaggio via grafica, ma devi smontare i device in loop sino a quando non te ne resterà uno solo [come gli immortali ah ah ah...battuta tristissima :-) ].

per quanto riguarda SFDumper dovresti riprovarlo sullo stesso device, con le stesse ricerche e se il problema permane sarebbe sicuramente utile avere le informazioni che ti ho richiesto prima con le tue annotazioni a riguardo.

Per ogni HD mi è stata fatta richiesta specifica di cercare i files di tipo
.doc .rtf .xls .pdf .tif .mdb .zip .rar .pst .dbx

Invio per email i log generati per una partizione di uno degli hard disk, in cui è possibile vedere che, tra i "deleted files recovered" relativi al dbx per esempio, si trovano praticamente tutti gli stessi files del formato .doc ed altri.

Nella release di SFDumper 2.1 presente su Caine 1.5 il problema non c'è, hai usato l'ultima release di SFDumper?
Grazie ciao