Healing With Dentures

$ LogFile nell'MFT

Abstract: This article is based on a test conducted by me and I'd like to have verification from readers of this blog.

time ago I noticed an oddity, having dug a solution yet, I thought to submit it to the public on my blog, I emphasize that is based on a single test on which I have not an explanation, I could not have for my "ignorance", so I would like other opinions and / or trials.

said this step to describe the experiment:

Linux (without mounting neither read nor write)

1) attack on a 128MB pendrive formatted to NTFS
2) I dd the image and name pen1.dd

3) do the md5sum

from Windows XP:

4) attack the pendrive 128Mb

5) I cut it with Safely Remove


Linux

6) I image and dd name is pen2.dd
7) do md5sum

8) and compare the two md5 known to differ.

The pendrive is empty, the pendrive
NOT

was peeled, the pendrive is Windows only been attached to and detached with safe removal.

Now take the two images and the comparison with a program (for windows) called HexCMP2

Find all the differences and fall into the cluster file $ LogFile

, which is the NTFS journal. For example, the last difference is the offset in decimal: 40203262

9) I mmls pen1.dd revenue offset the departure of the partition that is 32 10) fsstat-f ntfs-o 32 PEN1 . dd income and the size of the cluster that is 512
11) 40203262 divide by 512 = 78521 which is the offset in sectors

12) ifind-f ntfs-o 32-d 78521 pen2.dd
pulls me out: 2-128-1

ffind-f ntfs-o 32 pen2.dd 2-128-1 pulls me out / / $ LogFile
13) istat-f ntfs-o 32 pen1.dd 2-128-1

Finally I noticed that when you safely remove the display of the pendrive, the message WRITE (it is a USB module, MP3 player), then the procedure writes something ...

PROBLEM: If a CTU

clumsy attacks a Windows NTFS drive to a station, without Write Blocker, alters the original disc, but there is no trace of this alteration in terms of timeline ... . the hash code that will calculate what will be generated from the hard disk already altered, then copy and original will have the same hash code.
In a second step, a CTP resumes the original disc, attacks him with Write Blocker, is the image and the hash will coincide with that of the CTU, as the CTP did not affect anything ...
In a nutshell, the CTU has modified the original, but there is no trace of the date and time following the date of the seizure, then there is no way to prove that attacked the original HD to a system unprotected from
writing.
The problem is clearly more theoretical than practical, there are worse things around;)



Finally, the same tests done with the same MD5 FATX damage, perhaps because it is not FATX Journaled, and yes ... and NTFS $ LOGFILE is the journal of ntfs.

Any opinions, denial, confirmation is appreciated!

Nanni Bassetti