Hello
Just wondering if anyone has encountered this thing
I have cloned a client's laptop into a external 3TB Seagate Barracuda HD. This 3TB hd was partitioned (GPT) in to two where I placed the EnCase evidence (E0) files into 1 of the partitions.
When I am about to back-up the E0 files the following day, this particular partition where I put the evidence files became unreadable, but the other partition is still readable.
Every time I try to connect the 3TB Seagate, my computer tells me to format the other partition before I can use it. Obviously I have to cancel this because I believe that the evidence files are still there.
The thing is EnCase cannot detect it either after it became unreadable.
Any advice or support is highly appreciated.
Many thanks D
When I am about to back-up the E0 files the following day, this particular partition where I put the evidence files became unreadable, but the other partition is still readable.
From what you write it seems to me how the issue at hand has actually nothing to do with the E01 file or with Encase, simply you have a corrupted GPT table (or a more serious error).
Depending on the actual relevance/value of the data in this "lost" partition, you may want to attempt repairing the GPT table, see here
http//
or ask for professional work from a reknown data recovery service.
You do not provide any meaningful detail (not even the OS you are running) so it is difficult to provide any better or more specific advice.
jaclaz
Many thanks for your input
I've used a free tool called Gparted to repair corrupted partition tables with pretty good success, not sure if GPT is supported or not as I've only used it on NTFS and FAT32 before but worth a try.
As an aside, if you are feeling brave and as a last resort you should still be able to carve out the E01 files with EnCase/Xways after you have reformatted the disc.
Good luck )
As an aside, if you are feeling brave and as a last resort you should still be able to carve out the E01 files with EnCase/Xways after you have reformatted the disc.
Why as a last resort - this is/should be one of our core skills? In some ways this is much easier than carving a word file (for example) as the e01 structure is well documented, includes numerous headers/footers to help and when you have recovered a file you can check its consistency using the built in checksums.
By the time you have worked out how to use some third party data recovery software you could probably carve the files manually. Do it from an image and you can play all day.
I have 3TB external Seagate drives.
Without the Seagate drivers for the USB drive, they are unreadable.
Out of curiosity, what did you use to "clone" the drives and what do you mean by "clone"?
I ask because we recently had a problem where we used a LogiCube Dossier (with the older firmware to allow imaging to the MPFS) to create .e01 files of multiple source drives to two destination drives. The next day, when we went to copy the .e01 files off of the destination HDD's to our server, the destination drives' file systems were corrupted.
We ended up having to use Encase to export out the images from the destination drives to our server. The image files ended up verifying okay so we did not suffer any file corruption, simply file system corruption.
One of folks recalled a similar problem a while back with the same Dossier/firmware. At the time it occurred, he simply presumed it was a problem with the destination drive and not the Dossier. That particular Dossier/firmware combo creates .dd images without problems but cannot not create .e01's with corrupting the destination drive file system.
We have since upgraded the firmware since we no longer use the MPFS and have not had any more problems. Do not know if that is the problem you also experienced but thought I would throw it out there for consideration.
Why as a last resort - this is/should be one of our core skills? In some ways this is much easier than carving a word file (for example) as the e01 structure is well documented, includes numerous headers/footers to help and when you have recovered a file you can check its consistency using the built in checksums.
I say as a last resort as I've had to do this on a few occasions and for reasons unknown on a few the images failed to verify. I didn't have the time or the inclination to spend hours and hours figuring out why, I still had the original hardware so I got the hard drives out and reimaged. )
But I think you are right and in this instance there is nothing to lose by trying to carve out the E01 files without formatting and see what happens.
Why as a last resort - this is/should be one of our core skills? In some ways this is much easier than carving a word file (for example) as the e01 structure is well documented, includes numerous headers/footers to help and when you have recovered a file you can check its consistency using the built in checksums.
I say as a last resort as I've had to do this on a few occasions and for reasons unknown on a few the images failed to verify. I didn't have the time or the inclination to spend hours and hours figuring out why, I still had the original hardware so I got the hard drives out and reimaged. )
But I think you are right and in this instance there is nothing to lose by trying to carve out the E01 files without formatting and see what happens.
A RAW recovery on a large files such as E01 files will always run a high risk of failure. Fragmentation is always going to issue.
With regard to this particular case, can you not just find the NTFS boot sector of the second partition and 'add new partition…' within the disk view in Encase ?
A RAW recovery on a large files such as E01 files will always run a high risk of failure. Fragmentation is always going to issue.
If you are writing to a drive that is used for other purposes at the same time as the images was taken then I would agree. but writing to a partition that is used solely for images, as seems likely from the OP's post, then fragmentation becomes very much less of an issue.
FTR I have carved evidence files in this way on a few occasions over the years.