venerdì 20 marzo 2009

Il mistero di $LogFile nell'MFT

PREMESSA: questo articolo è basato su un test da me condotto e mi piacerebbe avere verifica dai lettori di questo blog.


Tempo fa ho notato una stranezza, non avendo cavato ancora una soluzione, ho pensato di sottoporla al pubblico del mio blog, sottolineo che è basato su una sola prova, sulla quale non ho ancora una spiegazione, che potrei non avere per mia "ignoranza", quindi vorrei altre opinioni e/o sperimentazioni.


Detto questo passo a descrivere l'esperimento:


da Linux (senza montare nè in lettura nè in scrittura)
1) attacco una pendrive da 128Mb formattata in NTFS
2) Faccio l'immagine dd e la chiamo pen1.dd
3) faccio l'md5sum


da Windows XP:
4) attacco il pendrive da 128Mb
5) la stacco con RIMOZIONE SICURA


da Linux
6) faccio immagine dd e la chiamo pen2.dd
7) faccio md5sum
8) confronto i due md5 e noto che SONO DIVERSI.


La pendrive è vuota, la pendrive NON è stata sfogliata, la pendrive è stata solo attaccata a Windows e staccata con rimozione sicura.


A questo punto prendo le due immagini e le confronto con un programma (per windows) che si chiama HexCMP2


Cerco le differenze e tutte cadono nel cluster del file $LogFile, che è il journal di NTFS.
Per esempio l'ultima differenza è nell'offset in decimale: 40203262


9) faccio mmls pen1.dd ricavo l'offset di partenza della partizione che è 32
10) fsstat -f ntfs -o 32 pen1.dd e ricavo la dimensione del cluster che è
512
11) divido 40203262 per 512=78521 che è l'offset in settori
12) ifind -f ntfs -o 32 -d 78521 pen2.dd
mi tira fuori: 2-128-1
ffind -f ntfs -o 32 pen2.dd 2-128-1
mi tira fuori
//$LogFile
13) istat -f ntfs -o 32 pen1.dd 2-128-1 | less
istat -f ntfs -o 32 pen2.dd 2-128-1 | less


e noto che la data e l'ora sono identici, quindi il file $Logfile viene modificato, ma i suoi metadati no! Why?


RIFACCIO il procedimento SENZA la RIMOZIONE SICURA, ma staccando brutalmente la chiavetta ed ottengo gli stessi risultati, solo che l'ultima modifica è all'offset decimale:
40174590
diviso 512 =78465
Quindi meno modifiche con la rimozione bruta.

Per concludere ho notato che quando si fa la RIMOZIONE SICURA, sul display del pendrive, appare la scritta WRITE (è un pendrive con display, lettore MP3), quindi quella procedura scrive qualcosa...

PROBLEMA:
Se un CTU maldestro, attacca un disco NTFS ad una stazione Windows, senza il Write Blocker, altera il disco originale, però non v'è traccia di questa alterazione, in termini di timeline....l'hash code che calcolerà sarà quello che verrà generato dall'hard disk già alterato, quindi copia ed originale avranno lo stesso hash code.
In un secondo tempo, un CTP riprende il disco originale, lo attacca con Write Blocker, fa l'immagine e l'hash coinciderà con quello del CTU, dato che il CTP non ha alterato alcunchè...
In soldoni, il CTU ha modificato l'originale, ma non c'è traccia di data ed ora successiva al giorno del sequestro, quindi non v'è modo di dimostrare che ha attaccato l'hd originale ad un sistema sprotetto da
scrittura.
Il problema è chiaramente più teorico che pratico, ci son cose peggiori in giro ;) 


Per concludere, le stesse prove fatte con FATx danno MD5 identici, forse perchè FATx non è Journaled, mentre NTFS sì...e $Logfile è il journal di ntfs.


Ogni opinione, smentita, conferma è gradita !!!  : - )

Nanni Bassetti

venerdì 6 marzo 2009

The Sleuthkit - mini guida veloce

Spesso accade di dimenticare tutte le potenzialità ed i tools di Sleuthkit, quindi ho deciso di scrivere una piccola guida veloce per illustrare gli usi più prêt-à-porter di questa utilissima suite di strumenti per la computer forensics, sviluppata da Brian Carrier.

Iniziamo dal disco/immagine

mmls /dev/sdaX o mmls disk.dd

serve a visualizzare le partizioni di un device o di un file immagine, fornendoci in output lo starting sector, molto utile per determinare l'offset di inizio partizione.
'Mmls' è simile a' fdisk-lu 'in Linux con alcune differenze. Vale a dire, che mostra i settori che non sono stati utilizzati in modo tale che questi possono essere usati per cercare dei dati nascosti. Inoltre, fornisce anche il valore della lunghezza delle partizioni in modo che possa essere usato con 'dd' più facilmente per estrarle.

fsstat -f file_system -o offset disk.dd

serve a fornire dati importanti sul file system presente sul dispositivo o file immagine del dispositivo in analisi, compreso un dato particolarmente interessante, ossia il block/cluster size.

ifind -f file_system -o offset -d numero_del_cluster disk.dd

serve a fornire l'i-node appartenente a quel determinato cluster. Il numero del cluster si ricava dall'offset decimale in bytes, che stiamo osservando, diviso la dimensione del cluster/blocco determinata da fsstat.
Se troviamo, per esempio, una stringa che inizia all'offset decimale 101345 in un file immagine DD, per ricavare l'i-node effettueremo 101345/dim_cluster.

ffind -f file_system -o offset disk.dd i-node

serve a fornire il nome del file corrispondente all'i-node.

istat -f file system -o offset disk.dd i-node

serve a fornire i metadati relativi al file corrsipondente a quell'i-node.

fls -d -r -p -f file_system -o offset disk.dd

serve a visualizzare i file cancellati, ricorsivamente in tutte le sottocartelle e col percorso completo (-p).

fls -a -l -p -r -f file_system -o offset disk.dd

lista tutti i files non cancellati.

icat -f file_system -o offset -r disk.dd i-node > nomefile.ext

Serve ad esportare il contenuto del file relativo all'i-node su file (nomefile.ext).

sigfind -t file_system disk.dd

Serve a cercare le "firme" che identificano i vari file system, -t list per visualizzare i vari file system supportati.

Altre informazioni preziose sono:
http://wiki.sleuthkit.org/index.php?title=FS_Analysis

The SleuthKit Manual:
http://wiki.sleuthkit.org/index.php?title=TSK_Tool_Overview

Esempio di come estrarre una stringa da uno spazio non allocato

Normalmente per cercare le stringhe utlizziamo la pipe di comandi:

strings -t d disk.dd | grep -i "abcd"
("-t d"  genera l'offset in decimale)


 che risulta essere più veloce del comando:

grep -iaob "abcd" disk.dd

-i ignora il maiuscolo/minuscolo;
-a tratta il file binario come se fosse testuale;
-b stampa il byte offset;
-o Mostra solo la parte di linea che coincide con la stringa cercata;


$ mmls disk.dd
DOS Partition Table
Offset Sector: 0
Units are in 512-byte sectors


     Slot        Start                     End                   Length             Description
00:  Meta    0000000000   0000000000   0000000001   Primary Tabl
01:  -----     0000000000    0000000062   0000000063   Unallocated
02:  00:00   0000000063   0174000014  0173999952  NTFS (0x07) 



Se vogliamo cercare le stringhe nello spazio non allocato di disk.dd e considerando che lo starting sector della partizione sia 63 e che il file system sia NTFS, allora:

1) Estraiamo lo spazio non allocato dal disco
blkls -f ntfs -o 63 disk.dd > disk.blkls

2) Estraiamo le stringhe e prendiamo solo quelle che contengono "abcdefg", dal solo spazio non allocato estratto da blkls (disk.blkls)
strings -t d disk.blkls | grep -i "abcdefg"
per esempio un risultato potrebbe essere: 10389739: abcdefg dove 10389739 è l'offset in bytes

3) Troviamo la dimensione del cluster impostata nel file system:
fsstat -f ntfs -o 63 disk.dd
<...>
CONTENT INFORMATION
----------------------------------
Sector Size: 512
Cluster Size: 1024
Total Cluster Range: 0 - 21749992
Total Sector Range: 0 - 173999950



4) Dividiamo 10389739 per 1024 ed otteniamo il numero 10146 che è il cluster che contiene la stringa "abcdefg", però nel file disk.blkls e non nel file immagine, quindi dobbiamo convertire l'indirizzo del cluster del file immagine disk.blkls in un indirizzo reale del file immagine originale, cioè disk.dd

5) blkcalc -f ntfs -o 63 -u 10146 disk.dd otteniamo 59382 che è l'indirizzo reale del cluster che contiene la stringa cercata.

6) Possiamo visualizzare il cluster usando il comando:
blkcat -f ntfs -o 63 disk.dd 59382 | less

7) Adesso cerchiamo l'i-node che ha un pointer al cluster 59382
ifind -f ntfs -o 63 -a -d 59382 disk.dd
che ci ritorna il numero 493-128-1 come risultato.

8) Reperiamo informazioni sui metadati che si riferiscono all'i-node 493:
istat -f ntfs -o 63 disk.dd 493
<...>
$FILE_NAME Attribute Values:
Flags: Archive
Name: pippo.jpg
Parent MFT Entry: 458   Sequence: 122
Allocated Size: 0       Actual Size: 0
Created:        Tue Mar 18 15:05:19 2008
File Modified:  Tue Mar 18 15:05:19 2008
MFT Modified:   Tue Mar 18 15:05:19 2008
Accessed:       Tue Mar 18 15:05:19 2008



9) Vediamo se c'è ancora un file associato all'i-node:
ffind -f ntfs -o 63 -a disk.dd 493
 /Document and Settings/spectra/Documenti/pippo.jpg
abbiamo trovato un file che si chiama pippo.jpg.

10) Recuperiamo il file pippo.jpg
icat -f ntfs -o 63 -r disk.dd 493 > pippo.jpg

Consideriamo che lo starting sector della partizione sia 63, che disk.dd sia NTFS, tramite il comando icat esportiamo il contenuto del file basandoci sul suo numero di i-node.

Spero che questo piccolo manualetto pratico sia utile a tutti quelli, che come me, cominciano ad avere l'had disk biologico sempre più full : - D

Nanni Bassetti