Hi,
I have a disk that has had its MBR overwritten, the file system corrupted and then the disk died. Luckily however, before the disk died but after the MBR had been overwritten and the FS corrupted, I was able to take a byte for byte image of the disk and dump it to a file. The file is almost 80GB but seems to have no remnants of a file system (i.e. no recovery software seems to be able to recover a valid file system), only the raw physical data from the disk remains in continuous unstructured form.
On the disk was an Outlook PST file that is really important. I know that the PST file must exist somewhere in the raw data that I had dumped to a file. I used a hex editor to look at the raw data but couldn't make anything of it, I then used the hex editor to look at a PST file on another disk and noted the first 4 hex values it had. I then searched for those same first 4 hex values in the dumped file and found about 100 entries. After many many hours I managed to extract and make one PST file work but it wasn't the one I need (although it did have some of the data I remember in it). the file was about 300mb and suprisingly worked! This gave me hope that I would be able to find the other PST file but I have failed thus far (what makes it so hard is the file I am looking for is several gigabyte).
The next thing I tried was to dump the file back onto another disk and then ran "Recuva" (a free recovery tool) to see if it could find any data. Only the deep scan option worked to some degree. It found images and other common files but obviously didn't recognise PST files so I gave up with that idea.
From my understanding, I am presuming that, as there is no file system, there is no indications of where a file starts and ends and therefore the data is just one continuous string of data without any structure. If this is the case then does it mean that my data is unrecoverable using software? I seem to find this hard to beleive becasue if I can manually trawl through the data searching for the start of a file and then look for where the file ends and export it to a file, then surely a program could do that faster than I can manually. Are there any programs that know what a PST file looks like from begining to end and can distinguish one from within a huge dump file even without a file system to tell it where the file starts and ends?
If anyone can help me, or knows a program that can do this or if they know a better method I should be trying, then please let me know. Thanks.
John
Looks like you still have all the data and theres nothing to suggest that the file system itself has been erased, just that the MBR has gone. The MBR contains a partition table which tells the computer where to look to find the file system. If you could reconstruct that table you would likely be able to burn the image to disk and that would reconstruct the disk.
Its a bit complex tbh, so I would suggest the easier option of looking for perhaps some words you remember from the email as well as the 4 hex values you noted (this is called the file header). If you can find hits for the header and phrases from the email you might well be onto the right file. Now I'm assuming that PST files contain plain text, they arent my area to be honest with you so that may well be an assumption too far.
uBut Unless the first 10% or so of the disk has been corrupted, I think the file system is probably still intact, just that the disk doesnt know where the partitions start.
I have a disk that has had its MBR overwritten,
How did you determine this? While it is possible to overwrite the MBR, it is unclear why someone would do this and not sanitize the entire disk. It would be a relatively poor way to hide data from detection, and certainly a poor way to obfuscate the existence of the data on the volume.
I am curious as to why you think that this was done and for what purpose (unless this is some sort of forensic challenge)?
From my understanding, I am presuming that, as there is no file system, there is no indications of where a file starts and ends and therefore the data is just one continuous string of data without any structure.
I wouldn't assume this, without knowing anything else. An intact MFT would be essential to any attempt to restore the volume to its functioning state, but the MFT is not the file system, only the map to tell you where you are in the file system and how to find things. The file system, it appears, has been corrupted, but how and for what purpose remain open questions.
If this is the case then does it mean that my data is unrecoverable using software?
There are numerous ways to recover data, some of which depend upon the MFT (or the FAT or whatever), and some which do not. The issue with recovery is often not whether it can be done, but is it worth the effort given the likelihood of success. That is a question which is, in part, technical and, in part, practical.
Are there any programs that know what a PST file looks like from begining to end and can distinguish one from within a huge dump file even without a file system to tell it where the file starts and ends?
Quite simply, there are few files that Microsoft actually protects from fragmentation and PSTs are not included in this. There are, however, a couple of "lights" at the end of the tunnel.
1) If the system was recently defragmented, you might be able to recover nearly intact PST files relying on contiguous blocks.
2) If the file system was relatively sparse, it is likely that the OS attempted to allocate a space large enough to handle the anticipated entire size of the archive, at least according to what is currently known (or believed to be the case) about NTFS allocation.
So, knowing nothing else about this case, I would think that your chances of recovering a good portion of a PST file would be good. PSTs are commonly produced by an automatic or manual process which is run against an Exchange (or other) e-mail database to create a local archive of the mailbox. In most cases, the total volume required could be estimated at the start of archiving, therefore, one might expect that the likelihood of recovering a nearly intact PST would be good.
Have you looked at photorec or any of the recovery packages that don't require an intact file system?
PST files tend to be rather large, and typically fragmented. To recover you will almost certainly require the remains of the file system.
As you have the disk image it would be useful to start by detereming the original file system. Search for disk (just at the start of sectors) for the following strings
FILE0 lots of these at 2 sector intervals shows it is an NTFS disk
FILE* lots of these at 2 sector intervals shows it is an older NTFS disk
'. ' ie a dot followed by 10 spaces is a FAT subdirectory. There should multiple instances of these over the disk, followed by file names.
If one of the above is positive, then data recovery software should allow you to progress to the next stage. If none of the above are found then it could be a Unix/Linux disk, or Mac
Looks like you still have all the data and theres nothing to suggest that the file system itself has been erased, just that the MBR has gone. The MBR contains a partition table which tells the computer where to look to find the file system. If you could reconstruct that table you would likely be able to burn the image to disk and that would reconstruct the disk.
Its a bit complex tbh, so I would suggest the easier option of looking for perhaps some words you remember from the email as well as the 4 hex values you noted (this is called the file header). If you can find hits for the header and phrases from the email you might well be onto the right file. Now I'm assuming that PST files contain plain text, they arent my area to be honest with you so that may well be an assumption too far.
uBut Unless the first 10% or so of the disk has been corrupted, I think the file system is probably still intact, just that the disk doesnt know where the partitions start.
Ok there may be a chance that the file system is somewhat in tact but to help determine this, I will try to give you a chronology of events as best as I can remember.
1) The drive was encrypted with Safeboot
2) One day the drive stopped booting
3) I used safeboot wintek to decrypt the drive which took an age because there were sectors that couldn't be read but eventually it completed
4) I took an image of the disk
5) The disk would still not boot
6) I stupidly did a MBR Fix thinking it would make the drive boot again but it didn't work
7) The disk fully died and now won't even detect
8) I copied the image to a new disk but it still wouldn't boot
9) I scanned the imaged disk with recuva deep scan and found a few files but not what I needed
10) I searched the image file with the hex editor as I have already described
My best guess is that the decryption of the safeboot file system was not fully complete due to the unreadable sectors and therefore left a partial NTFS file system. The drive however did fully decrypt, only the unreadable sectors were lost.
The PST files do have plain text and I can see text here and there but I have no idea whether they are part of the large PST file I am trying to recover. I can search them via the text in my email signature.
johnfuller wrote
I have a disk that has had its MBR overwritten,
How did you determine this? While it is possible to overwrite the MBR, it is unclear why someone would do this and not sanitize the entire disk. It would be a relatively poor way to hide data from detection, and certainly a poor way to obfuscate the existence of the data on the volume.
I am curious as to why you think that this was done and for what purpose (unless this is some sort of forensic challenge)?
johnfuller wrote
From my understanding, I am presuming that, as there is no file system, there is no indications of where a file starts and ends and therefore the data is just one continuous string of data without any structure.
I wouldn't assume this, without knowing anything else. An intact MFT would be essential to any attempt to restore the volume to its functioning state, but the MFT is not the file system, only the map to tell you where you are in the file system and how to find things. The file system, it appears, has been corrupted, but how and for what purpose remain open questions.
johnfuller wrote
If this is the case then does it mean that my data is unrecoverable using software?
There are numerous ways to recover data, some of which depend upon the MFT (or the FAT or whatever), and some which do not. The issue with recovery is often not whether it can be done, but is it worth the effort given the likelihood of success. That is a question which is, in part, technical and, in part, practical.
johnfuller wrote
Are there any programs that know what a PST file looks like from begining to end and can distinguish one from within a huge dump file even without a file system to tell it where the file starts and ends?
Quite simply, there are few files that Microsoft actually protects from fragmentation and PSTs are not included in this. There are, however, a couple of "lights" at the end of the tunnel.
1) If the system was recently defragmented, you might be able to recover nearly intact PST files relying on contiguous blocks.
2) If the file system was relatively sparse, it is likely that the OS attempted to allocate a space large enough to handle the anticipated entire size of the archive, at least according to what is currently known (or believed to be the case) about NTFS allocation.
So, knowing nothing else about this case, I would think that your chances of recovering a good portion of a PST file would be good. PSTs are commonly produced by an automatic or manual process which is run against an Exchange (or other) e-mail database to create a local archive of the mailbox. In most cases, the total volume required could be estimated at the start of archiving, therefore, one might expect that the likelihood of recovering a nearly intact PST would be good.
Have you looked at photorec or any of the recovery packages that don't require an intact file system?
- It was me who did the MBR Fix
- I don't understand the difference between an MFT and a file system
- Time, determination and patience is plentiful, only cost is a limitation
- The disk hadn't been de-fragmented in a while, the PST was very large and had been accumulated over many years and copied from one system to another as it grew, evolved and transferred from one machine to the next
- I have never heard of photorec is it free?
PST files tend to be rather large, and typically fragmented. To recover you will almost certainly require the remains of the file system.
As you have the disk image it would be useful to start by detereming the original file system. Search for disk (just at the start of sectors) for the following strings
FILE0 lots of these at 2 sector intervals shows it is an NTFS disk
FILE* lots of these at 2 sector intervals shows it is an older NTFS disk
'. ' ie a dot followed by 10 spaces is a FAT subdirectory. There should multiple instances of these over the disk, followed by file names.If one of the above is positive, then data recovery software should allow you to progress to the next stage. If none of the above are found then it could be a Unix/Linux disk, or Mac
The file system is NTFS, I'll have a look and see what the first sectors look like and post back.
Thanks for everyone's help so far!
Looks quite likely that the file you're after is likely fragmented then, which makes life very tricky without some specialist software like Encase (edit or manually reconstructing the file from the extent pointers), I do honestly think that your best solution is to attempt to reconstruct the partition table and place the image back on the drive as a raw image, which is again quite tricky without specialist software.
Why not try a direct edit of the MBR, if you remade the boot sector and its partition table by for example copying the first sector of a similarly formatted disk into the first sector of your image, assuming that the primary partition starts in the same place, you might then be able to use the free trial of mount image pro or some other such tool to mount the image and access the data.
Its a tricky problem as you are without a lot of the tools that I would turn to in this circumstance and the cause of the issue could be one of a number of things and me harping on about partitions might actually be leading you up the garden path. Could you perhaps post the contents of the first sector of the image here?
One thing thats worth trying is searching for the name of the file (in UNICODE), you should hopefully get a hit in the early part of the disk in the MFT (or what remains of it) which will then tell you where on the disk the file is… the pointers I was talking about earlier.
Don't take it the wrong way ) , but if you have a headache, do you cut your left (or right for that matters ) toe nail? 😯
You are reporting a filesystem problem, and also reporting that file-based recovery is not working for you.
What you should attempt, BEFORE a file-based recovery is a filesystem recovery.
Here is a thread with an example of such an approach
http//
Mind you it is well possible that I'm sending you on a wild goose chase, your mileage may (and will) vary, but at least since the problem is goose related, you should at least attempt to chase geese wink
And yes, photorec is freeware, it is the companion app of testdisk (as in "when having a filesystem problem, try with testdisk first, then - and only if you cannot get anything with it - try photorec")
http//
As seen in the above thread, BEFORE writing changes to the disk, make sure to know how to use testdisk. )
jaclaz
You can scan and rebuild the file structure using R-Studios. Import the image file you took form the disk. Scan the image and this should rebuild it to near enough the way it was before the failure.
Marius
MVI Data Recovery
Copying the PST from disk to disk would normally defrag it so the only fragamention should be since the file was on this disk.
if you know the name of the pst (outlook.pst etc.) try searching for it and see how many hits you get. if you can find the hit in an MFT entry then there may be eniough info there to recover in its entirety (assuming not very fragmented).
An 80GB disk is likely (but not necessarily) NTFS based so finding the file system structure that holds the allocation info would be a great place to start.
The MFT entry for a PST on my system is shown below - you can see that the file name is recorded in unicode so you will need to search for it (or just searh for .pst) in this format. you can also see the FILE0 signature that was mentioned earlier in the thread.
