Jump to content











Photo
- - - - -

DISASTER: partition now not recognised after accident with BOOTICE


  • Please log in to reply
62 replies to this topic

#51 TheK

TheK

    Frequent Member

  • Advanced user
  • 141 posts
  • Location:Germany (BW)
  •  
    Germany

Posted 09 March 2010 - 04:38 PM

That's ok. Now choose [Repair MFT] and post back the result.

#52 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 14777 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 09 March 2010 - 06:21 PM

Yes and No :ranting2:

Writing the 1st64sectors back = Yes.
Tiny Hexer and a 320 GB file = No!

Tiny Hexer will try to load it into RAM. You can use HxD for that.

NOT really.

If you try to open the large disk image as file, yes.
If you try to open the large disk image as disk->open large image as disk, NO. :ranting2:

:ranting2:

Wonko

#53 dmtelf

dmtelf

    Member

  • Members
  • 34 posts
  •  
    United Kingdom

Posted 09 March 2010 - 07:28 PM

That's ok. Now choose [Repair MFT] and post back the result.

"MFT & MFT mirror are bad. Failed to repair them."

What do you suggest I should try next..?

DMTelf

#54 TheK

TheK

    Frequent Member

  • Advanced user
  • 141 posts
  • Location:Germany (BW)
  •  
    Germany

Posted 11 March 2010 - 03:53 AM

It looks like partition based recovery failed :ranting2:
Formating the drive most likely damaged the MFT.

Unless anyone else has a better idea, I think it's time to switch to file based recovery.
You can try DiskGenius which is able to open disk images without the need to mount them. Try the 'Recover' functoin.
Then you can try PhotoRec, Recuva and other recovery software.

@Wonko thanks for the hint with Tiny Hexer :ranting2:

#55 dmtelf

dmtelf

    Member

  • Members
  • 34 posts
  •  
    United Kingdom

Posted 11 March 2010 - 07:36 AM

It looks like partition based recovery failed :ranting2:
Formating the drive most likely damaged the MFT.

Oh no!!! :ranting2: :ranting2: :ranting2:

I guess that means (at the very least) that the filenames are now lost?

One file in the root of the NTFS drive (I now know not to store individual files there) was a complete & fairly recent WhereIsIt disk catalog of the drive. If I can get that back as part of the file based recovery, then it will hopefully help a lot identify original file names based on the recovered file size etc.

Unless anyone else has a better idea, I think it's time to switch to file based recovery.
You can try DiskGenius which is able to open disk images without the need to mount them. Try the 'Recover' functoin.
Then you can try PhotoRec, Recuva and other recovery software.

The link for DiskGenius 3.2 has expired, but 3.0 Beta 12 is still valid so I tried that but I can't see how to open a dd image with it?

As the MFT is damaged, is it somehow possible to mount the image via ImDisk (or similar tool) etc so the partition file becomes a mapped drive & is visible in Explorer (even though its contents won't be visible) so I can then point my small collection of recovery tools at the drive letter? I think some - but not all - of the tools will work with disk images which haven't been mounted.

@Wonko thanks for the hint with Tiny Hexer :ranting2:

Indeed - I prefer TinyHexer & jaclaz's visualisation scripts rather than HxD.

DMTelf

#56 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 14777 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 11 March 2010 - 10:32 AM

It is rather strange that both the MFT and it's mirror has been overwritten, usually the MFT mirror is way deep inside the volume, and, though it is possible, it is unlikely that it has been overwritten entirely.

First thing I would try would be to try mounting the image with VDK (through a .pln file) or even better through the MS VSS drivers.

I would try running checkdisk on it.

See here for a batch to manage VSS:
http://www.boot-land...?...ic=6492&hl=

As I see it, all the steps till now has been performed correctly, so what you have right now is a somehow "botched" filesystem but still much beeter than the raw assembly of sectors you had before.

I presume (but we will need to actually try it) that recovering files from a filesystem with a wrong MFT is however better than recovering from completely raw data.

It is possible that checkdisk can repair the MFT or that it can repair it "enough" to let testdisk finish repair it:
http://www.cgsecurit..._and_MFT_Repair

And we still have some other tricks to try, but let's go with order.

Trry mounting it and run checkdisk, "in the right order", i.e.:
chkdsk
(disgnostic only)
chkdsk /F
and then, try the other switches, depending on what happens with the first two.

:ranting2:

Wonko

#57 dmtelf

dmtelf

    Member

  • Members
  • 34 posts
  •  
    United Kingdom

Posted 11 March 2010 - 05:24 PM

First thing I would try would be to try mounting the image with VDK (through a .pln file) or even better through the MS VSS drivers.

I would try running checkdisk on it.

See here for a batch to manage VSS:
http://www.boot-land...?...ic=6492&hl=

I am feeling stupid because I have now installed VSS from that link, but I cannot see a batch file anywhere in the post/thread & I can't find any useful documentation or examples to look at... if the batch file you are referring to is part of the installed VSS SDK, then was it the following line of C:\Program Files\Microsoft\VSSSDK72\TestApps\hwprovst\bin\install-sampleprovider.cmd that needed to be changed: vstorcontrol create fixeddisk -newimage %INSTALLTO%disk.image -blocks 40000

I unfortunately also can't find out how to create a .PLN file to enable VDK to mount the image :ranting2:

Do you have any links which will help me either create the PLN for VDK or create a batch file for VSS? I will then hopefully be able to mount the image as a drive letter & then try chkdsk.

If at all possible, I'd really like to continue to try partition based recovery as much as possible before switching to file based recovery. This is because there were hundreds of thousands of files on the 320Gb drive, and if there are no filenames...

DMTelf

#58 TheK

TheK

    Frequent Member

  • Advanced user
  • 141 posts
  • Location:Germany (BW)
  •  
    Germany

Posted 11 March 2010 - 06:33 PM

Well we already recovered the partition, but the file system is damaged. That means we need to fix the MFT or use a tool than can find what's left of the MFT and does file based recovery.

Btw, file based recovery doesn't mean you can't recover the file names as well.
You can mount the image with ImDisk and try Recuva. Go to options and enable 'deep scan' and 'scan for non-deleted files'.
Give it a try. You can still try other methods if you aren't satisfied with the results.

#59 dmtelf

dmtelf

    Member

  • Members
  • 34 posts
  •  
    United Kingdom

Posted 12 March 2010 - 03:34 PM

Well we already recovered the partition, but the file system is damaged. That means we need to fix the MFT or use a tool than can find what's left of the MFT and does file based recovery.

Btw, file based recovery doesn't mean you can't recover the file names as well.
You can mount the image with ImDisk and try Recuva. Go to options and enable 'deep scan' and 'scan for non-deleted files'.
Give it a try. You can still try other methods if you aren't satisfied with the results.

I mounted the image with ImDisk & the partition appears as a drive letter, but when I go into it in Explorer, it's empty & I am unable to use chkdsk etc. I was able to use PhotoRec to recover 10,000's of files overnight & it stopped when disk space ran out. The issues I encountered with PhotoRec is this tool does not restore original file names and a lot of file types that were on the drive are not on PhotoRec's supported file types list e.g. VOB or AEP (After Effects CS4). The directory structure wasn't reconstructed (nor was I expecting it to be) and as a lot of the files on this drive are "project" related, this particular recovery wasn't satisfactory, but it was encouraging.

I then tried Recuva, and it took an hour and half to scan the partition in the image. I was delighted to see original file & folder names etc, although a lot of files are marked as Unrecoverable, I at least now know which ones fall in to this category. I found the State & Comment columns very useful. I really wanted to export the contents of the Recuva file list to Excel & there's no built in facility to do this, so I used nirsoft's SysExporter utility to save a CSV with 369,349 rows.

I tried GetDataBack for NTFS on a friend's computer, and stopped it running after a couple of hours. It looks like it will be able to recover a lot although without having done a full scan etc which would take over 24 hours, I don't know if it will recover more or less files than Recuva.

GetDataBack reported this data for the MFT table:

Name: NTFS
Cluster0: 0
Cluster size: 8
Total sectors: 625,137,281
1st Mft cluster: 786,432
1st MftMirr cluster: 39,071,080
Mft record size: 1024
Index buffer siz: 4096
Total clusters: 78,142,160
Min clusters used: 78,142,160
Max clusters used: 78,142,160
Mft origin:,Ambiguous
Creation date:06/11/2009
Data matches:1802
Debug info:B1!

Would following Wonko's original suggestion of creating a PLN file to enable VDK to mount the image or using MS's VSS SDK result in a higher likelihood of recovering the MFT (via chkdsk or testdisk) or recovering more files..?

DMTelf

#60 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 14777 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 12 March 2010 - 06:07 PM

I was referring to the ones attached to this post:
http://www.boot-land...?...c=6492&st=7

To create a .pln for VDK you can use this one:
http://www.forensicf...m...c&p=6518434

And you can of course use my pseudo-GUI for VDK:
http://jaclaz.alterv...ts/VDM/vdm.html

But VSS should be "better" in this case.

With the files mounted with one of the two drivers, I would first thing like to see what checkdisk has to say about it.

Then if chkdisk + testdisk lead us to nowhere, I would try another freebie, ScroungeNTFS:
http://memberwebs.co...tware/scrounge/

IF we cannot get the files through Freely available software, the one I can suggest among available Commercial Software is File Scavenger:
http://www.quetek.com/prod02.htm

If anyone near you has a licensed copy of the good ol' TIRAMISU, that would be another exceptionally good app (retired, acquired by ONTRACK, lost in one of there BLOATED recovery solutions).

I will have a look at the files you posted and see if there is anything that can be "bettered", I may need other "snippets" of your drive, I still presume that the MFT (or more probably it's mirror can be manually fixed, if not entirely, somewhat "more").

:ranting2:

Wonko

#61 dmtelf

dmtelf

    Member

  • Members
  • 34 posts
  •  
    United Kingdom

Posted 13 March 2010 - 12:18 AM

I was referring to the ones attached to this post:
http://www.boot-land...?...c=6492&st=7

VSS results using vsmount script:

Virtual Storage is not installed:
Installing Virtual Bus Driver... Succeeded
Virtual Storage v5.2 Build 3790.1208:
Number of Drives : 0

Image : "e:\ToshImage.dd"
will be installed on VSDrive 0

Press any key to continue . . .
Virtual Storage v5.2 Build 3790.1208

Creating drive backed by e:\ToshImage.dd ...
Waiting for drive initialization...............
Drive : \\.\PhysicalDrive2
Drive ID : {E6066DF7-2E27-11DF-9A70-001C233406C0}
Type : Fixed Disk
Size : 305242MB
1 volume(s) on this drive:
\\?\Volume{e6066df9-2e27-11df-9a70-001c233406c0}\
F:\

chkdsk f:\ results in "The drive, the path, or the file name is not valid."

VSS is the only method used so far which actually shows something in Explorer when the drive is opened - in this case, there is a "System Volume Information" folder. When this image is mounted with ImDisk, this folder does not appear in Explorer.

I tried testdisk with the image mounted via VSS, but unfortunately I get the same results as before when I try to repair the MFT.

And you can of course use my pseudo-GUI for VDK:
http://jaclaz.alterv...ts/VDM/vdm.html

Same results as above, except nothing appears in Explorer.

Then if chkdisk + testdisk lead us to nowhere, I would try another freebie, ScroungeNTFS:
http://memberwebs.co...tware/scrounge/

The drive's directory tree structure is not recoverable with this tool & I need it, but here is the result after scrounge-ntfs had been running for half an hour:

E:\!!HD Recovery\scrounge-ntfs-0.8.6>scrounge-ntfs.exe -d f:\ -o k:\ 63 625137282
scrounge-ntfs: Scrounging via raw search. Directory info will be discarded.: No error
[Scrounging raw records...]
\Certificates
\LocalMLS_2.wmdb
\LocalMLS_0.wmdb
\AeX OS Results.nsi
scrounge-ntfs: invalid mft record
scrounge-ntfs: invalid mft record
[... dozens more lines like the above]
scrounge-ntfs: extended file attributes, but no MFT loaded. skipping \pagefile.sys
[lots of files recovered]

IF we cannot get the files through Freely available software, the one I can suggest among available Commercial Software is File Scavenger:
http://www.quetek.com/prod02.htm

If anyone near you has a licensed copy of the good ol' TIRAMISU, that would be another exceptionally good app (retired, acquired by ONTRACK, lost in one of there BLOATED recovery solutions).

I will see if anyone nearby has File Scavenger, unfortunately no-one has heard of TIRAMISU as it's not been around stand-alone for such a long time.

I will have a look at the files you posted and see if there is anything that can be "bettered", I may need other "snippets" of your drive, I still presume that the MFT (or more probably it's mirror can be manually fixed, if not entirely, somewhat "more").

Thank you very much for this. If you need any snippets, please let me know which ones you need.

The Excel spreadsheet I produced using nirsoft's SysExporter utility (highly recommended) & the deep scan result data in Recuva's application is really useful although it makes me wonder if a better recovery job could be done though to claw back even more data.

Out of interest, I'm wondering aloud "Why did GetDataBack NTFS & Recuva do so much better than the majority of the various free or MS apps I have used so far e.g. chkdsk, testdisk, VSS etc...?"

DMTelf

#62 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 14777 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 13 March 2010 - 08:27 AM

Out of interest, I'm wondering aloud "Why did GetDataBack NTFS & Recuva do so much better than the majority of the various free or MS apps I have used so far e.g. chkdsk, testdisk, VSS etc...?"


Because they are aimed towards different goals.

Recuva and GetdataBack are more similar to ScroungeNTFS, they aim to get the files, whilst checkdisk/testdisk aim to re-build or re-validate the filesystem.

In an extremely summed up:
  • IF checkdisk/testdisk succeed you have 100% or nearly 100% your data EXACTLY as it was
  • IF ScroungeNTFS or Recuva or similar apps succeed you have as many files as it is possible, but hardly 100% and NOT in the way they were (dates, permissions, fragmented status, etc.)
  • IF photorec succeed you have very nearly 100% of supported files BUT you loose filenames also

If you prefer in any of the further steps you increase "quantity" but loose "accuracy". :lol:

:cheers:

Wonko

#63 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 14777 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 13 March 2010 - 12:54 PM

OK, let's see what you have in the MFT and in it's mirror.

From the bootsector we have that:
Sectors per cluster=8
LCN for $MFT=786432
LCN for $MFTMirr=39070076
Bytes per $MFT record=1024

Thus I need:
  • Starting from absolute offset 786,432*8+63=Sector 6,291,519 i.e. absolute byte offset 3,221,257,728, say 50 clusters i.e. 50*8*512= 204,800 bytes
  • Starting from absolute offset 39,070,076*8+63=Sector 312,560,671 i.e. absolute byte offset 160,031,063,552 , say 50 clusters i.e. 50*8*512= 204,800 bytes

Also, open the image as large disk image in Tiny hexer, and search on it for:
  • 46494C4530
and for:
  • 46494C4530
(which correspond - respectively - to "FILE0" and "FILE*")
from the start and post the location of first occurrence (please note that "FILE0" or FILE*" needs to be first bytes of the sector, otherways it is a "false positive".
Post the usual 204,800 bytes starting from the found position. (it will take some time to scan the whole file)

Then, again from start, try searching for:
  • 0324004D0046005400

I am starting to suspect that somehow we are missing the "right" offsets for the MFT and it's mirror, i.e. it is possible that the actual re-built values we found come NOT from the original partitioning/formatting, but rather from the "new" interrupted one. :cheers:

:cheers:

Wonko




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users