Notifications
Clear all

FTK Imager report

15 Posts
3 Users
0 Likes
4,271 Views
(@gate2088)
Posts: 11
Active Member
Topic starter
 

Hi all,

I have two FTKImager report from same HDD, but I don't understand because the HDD geometry is different. In one report I have "Cylinders 30.401 and Tracks per Cylinder 255" in other report I have "Cylinders 32.301 and Tracks per Cylinder 240" but the hash is the same.

———————————————————————————————————
Report_1
———————————————————————————————————
Created By AccessData® FTK® Imager 3.0.1.1467 110406

Case Information
Acquired using ADI3.0.1.1467
Case Number PATHD02
Evidence Number PATHD02
Unique description PATHD02
Examiner
Notes HD Marca Seagate, Mod. St3250318AS, Sn 6VYA6E21

————————————————————–

Information for H\PATHD02\PATHD02

Physical Evidentiary Item (Source) Information
[Drive Geometry]
Cylinders 30.401
Tracks per Cylinder 255
Sectors per Track 63
Bytes per Sector 512
Sector Count 488.397.168
[Physical Drive Information]
Drive Model ST325031 8AS USB Device
Drive Serial Number 6VYA6E21
Drive Interface Type USB
Source data size 238475 MB
Sector count 488397168
[Computed Hashes]
MD5 checksum dc245743f8fb3ce691b007b7cc0886bc
SHA1 checksum 3f1a1713bffac6feb7a3d703709d3f26f89a8753

Image Information
Acquisition started Mon Aug 22 145420 2011
Acquisition finished Mon Aug 22 185138 2011
Segment list
H\PATHD02\PATHD02.E01

Image Verification Results
Verification started Mon Aug 22 185142 2011
Verification finished Mon Aug 22 195401 2011
MD5 checksum dc245743f8fb3ce691b007b7cc0886bc verified
SHA1 checksum 3f1a1713bffac6feb7a3d703709d3f26f89a8753 verified

———————————————————————————————————-
Report_2
———————————————————————————————————-

Creato da AccessData® FTK® Imager 3.1.2.0

Informazioni sul caso
Acquisito usando ADI3.1.2.0
Numero caso 286
Numero prova 286.1
Descrizione univoca HD 250GB Seagate
Esaminatore
Note

————————————————————–

Information for E\286_01

Physical Evidentiary Item (Source) Information
[Device Info]
Source Type Physical
[Geometria unità]
Cilindri 32.301
Tracce per cilindro 240
Settori per traccia 63
Byte per settore 512
Conteggio settori 488.397.168
[Informazioni unità fisiche]
Modello unità ST3250318AS
Tipo interfaccia unità IDE
Removable drive Falso
Source data size 238475 MB
Sector count 488397168
[Computed Hashes]
MD5 checksum dc245743f8fb3ce691b007b7cc0886bc
SHA1 checksum 3f1a1713bffac6feb7a3d703709d3f26f89a8753

Image Information
Acquisition started Wed Sep 11 094149 2013
Acquisition finished Wed Sep 11 163628 2013
Segment list
E\286_01.001

Image Verification Results
Verification started Wed Sep 11 163629 2013
Verification finished Wed Sep 11 175436 2013
MD5 checksum dc245743f8fb3ce691b007b7cc0886bc verified
SHA1 checksum 3f1a1713bffac6feb7a3d703709d3f26f89a8753 verified

 
Posted : 15/02/2015 3:51 am
(@athulin)
Posts: 1156
Noble Member
 

In one report I have "Cylinders 30.401 and Tracks per Cylinder 255" in other report I have "Cylinders 32.301 and Tracks per Cylinder 240" but the hash is the same.

The hash just depends on the contents of a number of sectors. If you have the same hash, you can be fairly certain that the data in the relevant sectors are the same.

Tracks and cylinders are not really used, and HDDs provide them for backwards compatibility. If they are different, they suggest that the imaged HDDs were not physically identical, or that there had been some other change, like updated firmware or other disk reconfiguration. (Though I can imagine a situation where the same HDD could give different information at different times, I would regard it as unlikely.)

In report 1, you have the drive serial number '6VYA6E21' and an USB interface.

[Physical Drive Information]
Drive Model ST325031 8AS USB Device
Drive Serial Number 6VYA6E21
Drive Interface Type USB

You don't have that in report 2.

[Informazioni unità fisiche]
Modello unità ST3250318AS
Tipo interfaccia unità IDE

Question Is report 2 an unmodified report from FTK Imager? I can't say for sure that it isn't, but I can't find any indication that FTK Imager can be localized to Italian. Is it a special version? Or has someone translated the report manually? (And if so, was any information lost or accidentally modified?)

The absence of serial number information in report 2 just might be due to the difference in imaging software Report 1 says 'AccessData® FTK® Imager 3.0.1.1467 110406' while Report 2 says 'AccessData® FTK® Imager 3.1.2.0 '

The difference in interface information (USB in report 1, IDE in report 2) suggests some additional change. (Was the HDD extracted and connected by IDE for report 2? That *might* change other things, but could probably easily be tested.)

I find it odd,though, that a later release (3.1.2.0) would *remove* drive serial number from the report, as well as the 'USB Device' information, and perhaps also the formatting of the serial number (a space is missing). Too many changes for my taste.

In the absence of that serial number in report 2 you can't say from the reports that the same physical HDD was imaged in both cases.

And in the (apparent) absence of an explanation of why report 2 is in Italian, and perhaps also a verification that the software used really *does* drop HDD serial number, etc., I would think report 2 requires additional description of how the image was performed.

Still, I see no reason to suspect that the data retrieved in the two cases is different. But the physical HDDs or disk assemblages involved may not be the same.

 
Posted : 15/02/2015 1:25 pm
(@gate2088)
Posts: 11
Active Member
Topic starter
 

Hi athulin,

very nice analysis, I suspect hdd are different, but both have same image, I ask this forum because I have't many experience. I found this FTK Imager report

http//nsu-leaks.freeforums.net/thread/157/wem-geh-festplatte-schutt-bekenntniss

has same HDD "ST3250318AS" "Cylinders 30.401" and "Tracks per Cylinder 255" now I think best solution for me it's buy HDD model "ST3250318AS" restore image and re-acquire with FTK Imager 3.1.2.0 this is good control, but my doubts are there hardware write blocker can give different results ( cylinders and track per cylinder) with FTK Imager?

The italian language is strange, but I haven't FTK toolkit maybe computer with istalled FTK toolkit has other language and the report has some part in no english language, but this is my idea, I'm not sure.

Thank you again for your reply.

 
Posted : 15/02/2015 10:29 pm
jaclaz
(@jaclaz)
Posts: 5133
Illustrious Member
 

Though disk geometry is fundamentally irrelevant nowadays, the situation is as follows
*any* hard disk device will expose a 255/63 geometry
*any* USB bridge will NOT change it
a limited number of BIOSes, typically Lenovo and HP, mainly - but not only - on laptops, will instead convert it to 240/63, but still USB connected disks remain on these 255/63

This is normally not an issue, BUT Win2k and XP bootsector code for NTFS and FAT32 do need the right geometry for booting, see
http//www.911cd.net/forums//index.php?showtopic=23408&st=0

It is entirely possible that the Ftk imager got a differnt geometry when imaging through an internal connection and when imaging the same disk through a USB connection.

jaclaz

 
Posted : 16/02/2015 4:07 am
(@gate2088)
Posts: 11
Active Member
Topic starter
 

Though disk geometry is fundamentally irrelevant nowadays, the situation is as follows
*any* hard disk device will expose a 255/63 geometry
*any* USB bridge will NOT change it
a limited number of BIOSes, typically Lenovo and HP, mainly - but not only - on laptops, will instead convert it to 240/63, but still USB connected disks remain on these 255/63

This is normally not an issue, BUT Win2k and XP bootsector code for NTFS and FAT32 do need the right geometry for booting, see
http//www.911cd.net/forums//index.php?showtopic=23408&st=0

It is entirely possible that the Ftk imager got a differnt geometry when imaging through an internal connection and when imaging the same disk through a USB connection.

jaclaz

Hi jaclaz,

I'm confused.

The image is XP sp3 (NTFS), now if I restore image from report_2 (240/63) on HDD ST3250318AS (255/63) the installation in theory doesn't boot, but if I restore image from report_1 (255/63) on ST3250318AS (255/63) the installation boot without problem?
The instrallation boot without problem if I use VMware, I'm sure I tried.
Thank you for help.

 
Posted : 16/02/2015 5:08 am
jaclaz
(@jaclaz)
Posts: 5133
Illustrious Member
 

Hi jaclaz,

I'm confused.

The image is XP sp3 (NTFS), now if I restore image from report_2 (240/63) on HDD ST3250318AS (255/63) the installation in theory doesn't boot, but if I restore image from report_1 (255/63) on ST3250318AS (255/63) the installation boot without problem?
The instrallation boot without problem if I use VMware, I'm sure I tried.
Thank you for help.

Yes/No. 😯
I posted one of the possible reasons for the report mentioning a 255 vs. 240 geometry.

I don't think that booting in VMware is "proof" of *anything*. ?

Meaning that AFAICR VMware does not support directly a dd-like image, and in any case the disk won't likely boot fully and get a STOP ERROR 0x0000007b because of the missing/wrong mass storage drivers, so I believe that you used some form of P2V (Physical To Virtual) tool to "adapt" the image to be used in VMware.

It is very likely that such a tool would anyway correct the geometry automatically…

As I see it the two images are identical (unless they were purposedly created/modified to create a MD5 collision), so it is just a matter of checking the bytes at offset 0x1A in the bootsector (or in the $Boot file if you prefer).

If they are 0x00FF then the NTFS volume has been formatted on a "normal" 255 geometry, if they are 0x00F0 then the NTFS volume has been formatted on a "more unusual" 240 geometry (and if the latter this may explain the FTK imager report).

It would still be possible - though uncommon - that the bootsector has been modified to jump over the HS check, however…

jaclaz

 
Posted : 16/02/2015 2:45 pm
(@gate2088)
Posts: 11
Active Member
Topic starter
 

Hi jaclaz,

the two image have $Boot 240/63, see herehttp//vccoins.com/report/Boot.jpg

Now we are sure (240/63) I think I restore the image on original HDD ST3250318AS (255/63) the boot is corrupt because the image come from (240/63) HDD.

1) I don't belive the original HDD ST3250318AS was (240/63) I think there was clone from original HDD ST3250318AS to other HDD 240/63 only clone and software clone format destination HDD (240/63)

2) with FTK imager there was forensic copy HDD (240/63)

3) restore forensic copy (240/63) on original HDD ST3250318AS (255/63)

My problem how can I show it?

 
Posted : 16/02/2015 7:10 pm
(@athulin)
Posts: 1156
Noble Member
 

The difference in interface information (USB in report 1, IDE in report 2) suggests some additional change. (Was the HDD extracted and connected by IDE for report 2? That *might* change other things, but could probably easily be tested.)

I can add that the FTK Imager information about interface should not be taken as gospel. I've checked all USB drives I had handy, and noted that all were identified as USB and Removeable, except for one (a WD My Book 3TB) that was identified as an IDE and not removeable. (FTK Imager 3.3.something on a Windows 8 system, using USB 3 ports.)

Just what it is that makes the difference is unknown, though.

 
Posted : 16/02/2015 7:54 pm
jaclaz
(@jaclaz)
Posts: 5133
Illustrious Member
 

Hi jaclaz,

the two image have $Boot 240/63, see herehttp//vccoins.com/report/Boot.jpg

Now we are sure (240/63) I think I restore the image on original HDD ST3250318AS (255/63) the boot is corrupt because the image come from (240/63) HDD.

1) I don't belive the original HDD ST3250318AS was (240/63) I think there was clone from original HDD ST3250318AS to other HDD 240/63 only clone and software clone format destination HDD (240/63)

2) with FTK imager there was forensic copy HDD (240/63)

3) restore forensic copy (240/63) on original HDD ST3250318AS (255/63)

My problem how can I show it?

Well, don't panic. )
Try to explain again the issue (if any) slowly, I am not understanding what you are asking/what the problem is.

I will try to be more explicit.
Disks (*all* of them - let's say manufactured in the last 15 years - hence ALL SATA disks but also MOST RECENT IDE/ATAPI) expose a 255/63 geometry.

On these "strange" BIOSes that use this 240/63 geometry when you partition the disk and create/format the volumes, a translation happens and the geometry used is 240/63.

This ONLY applies to internal disks (i.e. I have never ever seen a USB bridge or external case exposing anything but 255/63).

I will repeat myself to hopefully clear the point
240/63 geometry disks DO NOT EXIST, ALL disks are 255/63, a few BIOSes may use an internal translation to 240/63.

If you have a disk/volume partitioned/formatted as 240/63 there are ONLY two possibilities

  1. it was partitioned/formatted when connected internally to one of such PC's
  2. it was manually/artificially made to have a 240/63 geometry
  3. [/listo]
    Since it would make little sense to manually/artificially a disk volume be only compatible with the rather uncommon 240/63 hypothesis #1 seems much more probable.

    As well an image can only be

    1. a forensic sound, dd-like, sector-by-sector, byte-by-byte EXACT copy
    2. *something else*
    3. [/listo]

      If - as we all presume - the image is a valid "forensic sound" #1 type (which is indirectly confirmed by the two images having the same MD5 and thus contents), the only explanation available at the moment is that one of the images was taken at a time where the disk was connected internally (or via e-Sata, as there is no difference that I know of between "internal" and "external" on those, but this disk is reported as IDE) to a machine that uses the BIOS translation to the 240/63 geometry, whilst the other was taken from the same disk, once removed from the PC and connected through a USB bridge.

      Your hypothesis - with all due respect - do not stand.

      If the FTK imager actually managed to change that single byte from the supposedly "original" FF to F0 when imaging it the first time, then the result would NOT be a forensic sound copy, but case #2 above, *something else*.

      As hinted earlier, it is possible (and should be checked) that the bootsector CODE has not been patched to bypass the volume geometry or that some other bootmanager is/was in use, or that the disk was actually a boot device, though it would not be "common" it is still a possibility that the disk was partitioned/formatted originally on a 240/63 PC and later patched (without reparittioning/reformatting) to boot on a 255/63 PC leaving the "previous" geometry information in the bootsector untouched, though I would consider it rather improbable.

      jaclaz

 
Posted : 17/02/2015 6:41 pm
(@gate2088)
Posts: 11
Active Member
Topic starter
 

Hi jaclaz,

thanks for your patience, I try to explain my doubts.

1) The computer was normal pc clone desktop I don't think possible bios has 240/63 hdd geometry

2) I find, inside installation, folders and files with date 24/08/2011, but the forensic copy has date 22/08/2011 (Report_1) there was manipulation before MD5 acquisition.

Now I have discover HDD installation is HDD 240/63 geometry I have more doubts because it's geometry from notebook not pc clone.

I never think MD5 collision, I have asked this forum because there are two report have different data, only I need understand.

I think best solution it's understand if initial installation was 255/63 or 240/63, but how do it?

 
Posted : 18/02/2015 6:30 pm
Page 1 / 2
Share: