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