Let me just start off by saying I have made one terrible mistake, and I have been kicking myself ever since.
Background
I had just finished a re-compression/verification of a NFTS Encase image on a FAT32 destination drive and while deleting some other data managed to delete the Encase images I had just finished verifying minutes before running a backup (Seriously minutes). Now because this image was taken while off site I no longer have the original hard drive to re-acquire the image. The destination hard drive containing the Encase images in question was immediately shut off and imaged. The destination drive also contained other Encase images from the same job. The drive is new and therefore contains no other data but other Encase image taken on site
Question
My question is, how do I recover these deleted Encase files?
Things already tried
Viewing/searching for the files in FTK Imager - Can find MFT entry but the allocated blocks contain no data
Viewing/searching for the files in Encase - Can find MFT entry but the allocated blocks contain no data
Viewing/searching for the files in X-Ways Forensic/Winhex - Can find MFT entry but the allocated blocks contain no data
Identifying and searching for the Encase header [0x455646090D0AFF000101000000] and the footer [0x646F6E65 - followed 72 blocks] using Winhex, Finds a good chunk of cluster that match the header, haven't had time to check for footer. Also my guess is that the Encase files will not be in continuous clusters due to the re compression process.
Things left to do
Run foremost looking for header and footer.
Ask the almighty Forensic God for a small miracle.
Re read for the umpteenth time "Addison Wesley - File System Forensic Analysis (2005)"
Any ideas/help would be greatly appreciated….
Hi
First of all you will need to hope that all the clusters in your Encase files were contiguous. If they were not, it is still possible to recover the data, but it will need to be done manually and you will need a very good understanding of the Encase file format. Each section of the segment file will need to be stepped through and extracted.
It isn’t impossible; in fact a relatively simple process, just very time consuming as it will need to be done manually.
First pointer is the header you have shown is only the header for the very first segment. Subsequent segment files will have a different header depending on which segment they belong to. Also, the footer you have is only the footer for the very last segment file and not the ones in between.
The file format also changes depending on the version of Encase you used to image. First of all, looking at the header using zero as the first offset, the segment number is stored in a UInt16 or UInt32 depending on version at offset 0x09. The segment number reflects the extension so segment 1 will be e01, segment 2 will be e02 etc.
EVF files are split into sections which can be read from the start of the file after the header. The section are in a fixed format which has a UInt64 giving the length of the section. Each segment file will end with a section which has a header which has the word “next†in lower case. Select next and count 76 bytes. This should give you a single e0* file assuming the data in between the header and the segments are contiguous.
Keep doing this until you get to the last segment which will end with “doneâ€.
With regards to compression, only your data from the drive will be compressed and that will be a part of the sections which hold the data and the segment headers. Compression will make no difference to whether your Encase files are contiguous or not.
I am slightly confused as to why you are looking for MFT entries on a FAT32 drive?
Good luck!
rcw8892 thanks for you reply, the whole process including your insight into Encase files has been an invaluable learning curve. I was able to re-acquire the PC the next day with the same MD5 which worked out well because more PC's required imaging on the clients site, so it all worked out.
I am however extremely interested in testing what you have posted so in the next few weeks I will be running a bit of RnD, resulting in an internal White Paper.
Sorry to be a bit vague or plain wrong in sections, especially the MFT comment (it should be File Allocation Table), I had just come off the back of a 22hr day and was 15hrs into my 19hr second day. Just to clarify I was referring to the fact that the files appeared as entries in the FAT yet the allocated clusters to the entries didn't contain the relevant data.
Excellent post rcw8892!
Thanks for sharing your thoughts!
Cinux