I've been given 8 500 GB drives by the gov't, supposedly containing the images of 12 or 15 computers, cell phones, and iPods. I'm hopeful of trying to mount these images so I can find relevant and useful files, and copy them all to a networked Drobo that I have. I don't care about the iPod and cell phone contents, I just need a lot of stuff off of several of the computers. The images should be of mostly Macs and 1 Windows computer.
They numbered the drives 1 through 8. Drive #1 will not mount at all when connected to either my Mac or Windows computer (latest versions of each), but drives #2-8 do. They all contain folders containing files named and numbered something like this
qhq005_qla_1
qla_3_ddimage.001
qla_3_ddimage.002
qla_3_ddimage.003
…
Tech stuff isn't really my thing, so please be patient with me… Neither my Mac nor Windows knew what to do with those files. I spent a few hours Googling trying to figure out what the heck a DD Image Forensic Image is, and found a Windows program called Mount Image Pro v4. Following its documentation to mount and read these images, I went to File > View and the .001 file in each folder would be visible. When I'd select it, a list of partitions would appear. But right-clicking on any partition and selecting Mount always returns "Cannot mount image the image is damaged or in an unsupported format." This was the case with 3 of the drives, I didn't bother trying the rest.
Combined with the fact that drive #1 will not mount at all, I'm worried I've got a problem here. I really don't know what to try next. I couldn't find anything online like a simple tutorial. Can anyone give me any pointers here?
Probably a silly question, but why would the "gov't" give you these image files? Are they part of some case? Are they images of your computers?
If these are Mac images did you follow the
You could try this http//
Does disk #1 start with 0x200 bytes of boot sector, or at least a sector with partition information. This would help indicate what the drive is.
Scan the disk to if there is actually any data - it may have been blanked.
Again, look at the start of each dd file in a hex editor and see if it has standard partition information.
If there is no standard partition information, search the drive / DD images for clues to the disk type, eg '. ' (10 spaces) would indicate a FAT sub diectory, FILE0 a NTFS disk, a sector starting H+, a MAC disk, etc etc. Unix is slightly harder to detect (magic numbers in the super block) , but XFS, and REISER3FS should be easy to find..
If you have an idea of the file system, then start looking for tools to analyse them.
The OP said tech stuff is not my thing, I think that asking someone who says tech stuff is not their thing to go with a hex editor to a sector and read a partition table is not going to happen.
Does disk #1 start with 0x200 bytes of boot sector, or at least a sector with partition information. This would help indicate what the drive is.
Scan the disk to if there is actually any data - it may have been blanked.
Again, look at the start of each dd file in a hex editor and see if it has standard partition information.
If there is no standard partition information, search the drive / DD images for clues to the disk type, eg '. ' (10 spaces) would indicate a FAT sub diectory, FILE0 a NTFS disk, a sector starting H+, a MAC disk, etc etc. Unix is slightly harder to detect (magic numbers in the super block) , but XFS, and REISER3FS should be easy to find..
If you have an idea of the file system, then start looking for tools to analyse them.
Try this
Dealing with Split Raw Images in Digital Forensics
http//
I am not sure that I agree with forensicakb.
If the goverment has given these drives for investigation, one must expect a adequate level of expertise to analyse them. Use of a hex editor is surely a sensible starting point to get an idea if the drive/DD is blank, has any data, has been entirely corrupted, is encrypted, compressed etc.
IMO there is nothing to beat looking at the raw bytes, before deciding what to do next.
Fair enough to say that a mounting program is a way to test image functionality. I have my techs test in FTK as it is a easier, straight forward GUI. I usually do this first myself before going to HEX.
The OP should also consider different mounting programs however. FTK Imager 3.0 and IMDisk - better to have failed on several platforms as a test of functionality. With that ruled out it would be prudent to start looking at the chunks.
And here is the biggest issue that people have in these scenarios - asking. Go back to he source and ask if they know how it was imaged - tools, software, etc. Even if you don't get an answer at least you pursued that path.
Unfortunately the party who provided the disks is hostile and will not assist.
I appreciate all the suggestions but most of them are over my head, as forensicakb pointed out. The links provided by Beetle and neofito seem to be for different archive formats.
I neglected to mention that each folder also contains a folder called "admin" with a text file in it. I'm copy here a few snippets out one of the text files that appear to be relevant. Is this of any help? I don't have any way to know what kind of device was being imaged here
——-
The 1st Output Drive /mnt/out1_RzJpLZ, Drive sda, SCSI device
1st Log File /mnt/out1_RzJpLZ/qhq009_qla16_1/admin/qhq009_qla16_1_copy_files.txt
Md5verify Yes
Compressed Src Image(s)/Drive No
Compress Output Image(s)/Drive No
Image_name /mnt/image_vbkX2A/qhq009_qla16_1/qla16_1_ddimage.*, 2nd/Out Image Name qhq009_qla16_1/qla16_1_ddimage.*
Block Size 1024
Image Format
2048000+0 records in
2048000+0 records out
2097152000 bytes (2.1 GB) copied, 67.0648 s, 31.3 MB/s
Copy image(s) started in /mnt/out1_RzJpLZ/qhq009_qla16_1.
Beginning 8-27-2010 152624
Copy image(s) in /mnt/out1_RzJpLZ/qhq009_qla16_1.
dcfldd if="/mnt/image_vbkX2A/qhq009_qla16_1/qla16_1_ddimage.001" bs=1024 conv=noerror,sync | tpipe "md5sum >> /tmp/fileN9O5Iq" | dd of="/mnt/out1_RzJpLZ/qhq009_qla16_1/qla16_1_ddimage.001" conv=noerror bs=1024 2>> /mnt/out1_RzJpLZ/qhq009_qla16_1/admin/qhq009_qla16_1_copy_files.txt
Copy image(s) ended in /mnt/out1_RzJpLZ/qhq009_qla16_1.
Ending 8-27-2010 152732
2048000+0 records in
2048000+0 records out
2097152000 bytes (2.1 GB) copied, 62.4064 s, 33.6 MB/s
Copy image(s) started in /mnt/out1_RzJpLZ/qhq009_qla16_1.
Beginning 8-27-2010 152734
…
3c76d62318d6bdee2f5213189d3e92ef -
/mnt/image_vbkX2A/qhq009_qla16_1/qla16_1_ddimage.001
f6f6df9bc1fe2ade0ac57815b74fdd85 -
/mnt/image_vbkX2A/qhq009_qla16_1/qla16_1_ddimage.002
Perfectly fine, except that I am just stating what the OP said.
I don't know where you get that someone must have an adequate level of expertise to analyze them. I have seen in cases where people don't want to hire CF people they request and get images of hard drives and the people requesting just go through them as best they can.
Volley, depending on the type of case some people do pro bono stuff or at a very reduced rate to help out defendants.
I am not sure that I agree with forensicakb.
If the goverment has given these drives for investigation, one must expect a adequate level of expertise to analyse them. Use of a hex editor is surely a sensible starting point to get an idea if the drive/DD is blank, has any data, has been entirely corrupted, is encrypted, compressed etc.
IMO there is nothing to beat looking at the raw bytes, before deciding what to do next.