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

Free Jibjab Look Alike

The Sleuthkit - mini driving fast

often times when you forget all the potential and tools
Sleuthkit
, so I decided to write a quick little guide to illustrate typical uses of ready-to-wear for this very useful suite of tools for computer forensics, developed by Brian Carrier.

start from the disc / image

mmls / dev / sdaX or mmls disk.dd

used to display the partitions on a device or an image file, providing output in the starting sector, very useful for determining the offset of partition start.

'Mmls' as in 'fdisk-lu' in Linux with some differences. Namely, that shows the areas that have not been used so that these can be used to search for hidden data. It also provides the value of the length of the partitions so that it can be used with 'dd' to extract more easily.

fsstat file_system-f-o offset disk.dd

is to provide important data on the file system on the device or image file analysis of the device, including a particularly interesting, namely the block / cluster size.

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

is to provide the i-node belongs to that particular cluster. The number of clusters is derived from offset in decimal bytes, we are seeing,

divided by the size of the cluster / block determined by fsstat. If we find, for example, a string starting at offset decimal 101,345 in a DD image file, to get the i-node will perform 101345/dim_cluster.


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

is to provide the name of the file corresponding to the i-node.

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

used to provide metadata about the file corrsipondente to that i-node.

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

used to display deleted files recursively in all subfolders and with the full path (-p).

fls-a-l-p-r-f-o offset file_system disk.dd
list all the files are not deleted.

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

Used to export the contents of the file for the i-node to file (filename.ext).

sigfind-t file_system disk.dd

Need to look for "signatures" that identify the various file systems, t-list to display various file systems supported.

Other valuable information are:
http://wiki.sleuthkit.org/index.php?title=FS_Analysis


sleuthkit The Manual:

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


Example of how to pull a string to an unallocated space


usually to search for strings by sending the pipe of commands:




strings-td disk.dd grep-i "abcd" ("-t d" generates the offset in decimal)
that is faster than the command:

grep-iaob "abcd" ; disk.dd


-i ignore upper / lower case;
-
is a binary file as if it were text; -b Print the byte offset
; -o
Show only the party line that coincides with the search string;

$ 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   00000000
63 0174000014 0173999952 NTFS (0x07)
If we want to search for strings in unallocated space of disk.dd and considering that the starting sector of the partition is 63 and that the file system is NTFS, then:
1) We extract the unallocated space from disk
blkls-f ntfs-o 63 disk.dd> disk.blkls

2) We extract the strings and we take just those that "abcdefg", from the unallocated space only extracted from blkls (disk.blkls) strings-td disk.blkls

such a result would be: 10389739
: abcdefg

where 10389739 is the offset in bytes

3) We find the cluster size set in the file system:

fsstat-f ntfs-o 63 disk.dd
\u0026lt;...> CONTENT INFORMATION ----------------------------------

Sector Size : 512

Cluster Size: 1024
Total Cluster Range: 0 to 21749992
Sector Total Range: 0 to 173999950

4) Divide 10389739 by 1024 and get the number 10146 which is the cluster that contains the string "abcdefg" ;, but the file disk.blkls and not in the image file, so we must convert the address of the cluster disk.blkls image file into a real address of the original image file, ie disk.dd

5)
blkcalc-f ntfs-o 63-u 10146 disk.dd we get 59,382 which is the real address of the cluster that contains the search string.
6) We can see the cluster using the command: blkcat-f ntfs-o 63 disk.dd 59382
8) found metadata information relating to the i-node 493:

istat-f ntfs-o 63 493 disk.dd \u0026lt;...>
$ FILE_NAME Attribute Values:
Flags: Archive
Name: pippo.jpg
Parent MFT Entry: 458 Sequence: 122
Allocated Size: 0 Actual Size: 0
Created: Tue March 18 15:05:19 2008
File Modified: Tue March 18 15:05:19 2008

MFT Modified: Mon March 18 15:05:19 2008
Accessed: Tue March 18 15:05:19 2008

9) Let's see if there is still a file associated with the i-node:

ffind-f ntfs-o 63-to 493 disk.dd
/ Document and Settings / spectra / Documents / pippo.jpg we found a file called pippo.jpg.

10), taking the file pippo.jpg
icat-f ntfs-o 63-r 493 disk.dd> pippo.jpg
Consider that the starting sector of the partition is 63, which is disk.dd NTFS by icat command export the contents of relying on its number of i-node.
I hope that this small handy booklet will be useful to all those who, like me, begin to have the disk HAD biological increasingly full


Nanni Bassetti