Personally, I don't think file signatures is the best starting point.
Sure it is not (filesystems structures are actually much more handy ) ) but I wanted to point out how - notwithstanding the utter stupidity of the JPEG specs - they actually allow to get some useful info, I believe actually more than PDF's, so I wouldn't rate them among the "particular difficulties" wink of the speciifc case.
jaclaz
Im surprised noone mentioned this yet
Hi,
Sorry to answer so late and thanks to everyone who helped.
They were interesting ideas and links.
My approach of using the header of PDF files first was not too bad.
The benefit is that this header is very easy to remember "%PDF-"
and let you find all "%PDF-1.2", "%PDF-1.3", …, "%PDF-1.5", a.s.o.
It's always easier when you can search in plain text than in hexadecimal.
The sectors numbers helped me find the maximal stripe width.
Then, I decided to start with small block size, as suggested in the presentation linked by MDCR.
So, I chose a block size of 2 sectors…
(text removed because of probress in analysis, see next message)
Parameters passed to RAID Reconstructor
- block size 2 sectors
- recommended disk order, where the disk starting with "EFI PART" is the second one
- offset 0
Results on the destripped output disk
1) "EFI PART" is at sector #2 (i.e. the third sector as counted from 0);
Conclusion in RAID Reconstructor, the block size is per input disk
2) When trying to access files, most files headers are now correctly aligned
for most files (PDF, JPG, GIF, INDD and others).
However for a few files, the file header is located at an offset of 0x200 (i.e. 512 bytes)
from the beginning of the file.
3) Pictures are corrupted. Some display strange stripes and others refuse to open.
I plan to increase the block size, but this should not provide a solution to those files which header is at an offset of 512 bytes in the reconstructed RAID as mentioned at point 2.
The fact is that in RAID Reconstructor, it does not seem possible to specfify a block size of 512 bytes (1 sector) ; the analysis is endless.
I have seen 1 sector stripes.
This will be very easy to verify by using a hex editor on almost any text file, or a file with a good structure, eg the header of a JPEG. Just look at the data flow near the 0x200 sector boundary
If it is one sector stripe size, you then need a tool to support it.
If the problem is being able to test the values on the fly I think you can mount the disk images to loopback devices and then use mdadmin to create a disk array and see if you can mount the partition (do not work on the original images though). If you pick the wrong values you can just use mdadm –stop and try again.
I recently had to rebuild a RAID we seized and I was very impressed by this product
Reclaime-Pro
First we were able to see the RAID 10(Linux Software Raid) and image the Raid container by booting a forensic station using a clone of each of 5 drives and using Raptor Forensics. That could be one way to do it but not very convenient as you have to work with clones of the drives included in Raid.
Then I imaged each drive(E01), mounted them with FTK Imager and tried the trial copy (14 days) of the Reclaime-Pro and within seconds, it was able to recognize the Raid 10 container. You can then copy out the container to a raw image.
The only thing is that their licensed copy needs to authenticate every time to their license server before you can use it. Not a big deal for us here….since recovering a Raid will likely be done in our lab. All you have to do is authenticate to their license server(3-4 seconds) and then you disconnect your forensic station from the internet and start using the software..
I was also able to use their free Raid recovery software (
Dan
Thanks to all of you.
Meanwhile, the 0x200 offsets lead me to the correct "intuition".
RAID Reconstructor did the destriping and ReclaiMe Ultimate (reclaime.com) let me now preview the folder tree and preview the jpegs which are all OK. D
@francesco interesting approach. Can you explain what you mean by "lookback devices" ?
@drobitaille I knew the Ultimate version or ReclaiMe, which also positively impressed me.
With some limitations however the easy to use interface does not let you analyse only part of a drive. For instance if you cloned a 1 TB drive to a 2 TB one, it will analyse all the 2 TB.
In such situation, you can however copy the files already when the software is at 50% of the scanning.
With another recovery, it arrived to me that ReclaiMe Ultimate froze in some kind of endless loop on some damaged file system.
Good product however, with reactive support.
I was not aware that the Pro version had been released, probably recently.
From the few screenshots that I could see, there seem being much more settings available for the pros.
I had tried their free RAID Recovery software too but was upset by it. Mostly because the analysis can last a lot and you don't know exactly which percentage was done. So, after some time you don't know if you should stop the analysis or better wait a few more minutes.
@francesco interesting approach. Can you explain what you mean by "lookback devices" ?
mdadm expects a block device so you can't build a disk array from the raw disk images, you have to pass through a loop device (a virtual block device) first by using losetup on the raw image file. Do not work on the original files or you risk the changes being written into them.
You can
- use ewfmount to mount the E01 files as raw image files (you should compile it from the latest ewftools)
- use losetup on each raw image file (assigning to /dev/loop0, /dev/loop1, etc.)
- use mdadm –build /dev/md0 –chunk=CHUNKSIZE –level=0 –raid-devices=NUMBEROFDISKS /dev/loop0 /dev/loop1 [etc…] to try and create the array (changing the device order and chunk size)
- use mount (with options ro,loop) to try and mount the partition to see if it works. if it doesn't work you can use mdadm –stop /dev/md0 and try mdadm –build again with different parameters until you find the correct ones that you can then use on your raid reconstruction software (or just ewfacquire /dev/md0).
I think you could even write a script that tries guessing all the parameters until the partitions can be mounted correctly.
(all this, of course, when the raid is compatible with the md driver)