Jump to content











Photo
- - - - -

DISASTER: partition now not recognised after accident with BOOTICE


  • Please log in to reply
62 replies to this topic

#26 dmtelf

dmtelf

    Member

  • Members
  • 34 posts
  •  
    United Kingdom

Posted 05 March 2010 - 11:49 PM

what is the exact file size of h:\testdump.img ?

It doesn't exist.

If I do the below dsfo command in cmd.exe with Explorer open, then testdump.img is created in H:\, it's always 0 bytes while dsfo is running, and then testdump.img disappears from Explorer as soon as dsfo stops running.

dsfo \\.\PHYSICALDRIVE2 160037329136 160037349136 h:\testdump.img

Do you know how I can find the range of sectors that have CRC errors in this portion of the drive...?

DMTelf

#27 TheK

TheK

    Frequent Member

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

Posted 06 March 2010 - 12:07 AM

OK, I should rather go to bed than giving wrong advices.

This should be correct.
dsfo \\.\PHYSICALDRIVE2 160037329136 10240 h:\testdump.img

Sorry, it's been a long day :whistling:

#28 dmtelf

dmtelf

    Member

  • Members
  • 34 posts
  •  
    United Kingdom

Posted 06 March 2010 - 12:17 AM

OK, I should rather go to bed than giving wrong advices.

This should be correct.

dsfo \\.\PHYSICALDRIVE2 160037329136 10240 h:\testdump.img

Sorry, it's been a long day :whistling:

It's not a problem... I really appreciate your contribution, and everyone else's who has offered advice in this thread. As part of my learning process through all this I should be checking precisely what each parameter to every command I type does so I know exactly what I'm doing & why... I didn't do that with your last 2 suggestions - my fault.

Unfortunately, this is what I got with the revised dsfo parameters which should grab 10kb starting at sector 160037329136. The testdump.img file appears & disappears from Explorer when dsfo starts & stops too:

C:\dsfok>dsfo \\.\PHYSICALDRIVE2 160037329136 10240 h:\testdump.img
\\.\PHYSICALDRIVE2 - Data error (cyclic redundancy check).
This error can probably be ignored.
h:\testdump.img - No more data is available.

DMTelf

#29 dmtelf

dmtelf

    Member

  • Members
  • 34 posts
  •  
    United Kingdom

Posted 06 March 2010 - 12:37 AM

I've just re-read the Data Rescue DD page, and there's this section which clearly explains how to use it to back up a drive up to the portion where CRC errors start, find the range of problematic sectors, and back up the rest of the drive from the next good sector after the bad range onwards.

@Wonko The Sane suggested I use that tool so I'm going to create the image now & will post results after its been created.

A typical use example

A 40GB hard drive suffers of physically bad sectors in the system area that cause the drive to lock up when the damaged area is hit by a conventional disk duplication program or a data recovery program. DrDD is first used to attempt an image of the drive. DrDD locks up as well, the error is completely irrecoverable. The system is reset. Through the last log, the problematic area seems to be sector 1.000.000. DrDD is used to first create an image of the hard drive up to sector 999.999. Knowing that hardware errors are often contiguous, a second image is created, backwards, from the end of the drive (for example 40000MBs) back to sector 1.000.001. The backward copy proceeds and finally locks up at sector 1.004.000. If the data hasn't been saved, a new forward copy starting at sector 1.004.001 and going up to the end of the drive is done. The user now has saved most of the raw content of its hard drive and has saved the multiple trial and error read attempts he would have gone through if he had restarted the copy forward at sector 1.000.001 - with most of the data in a safe place, the user is now able to try as many data-recovery utilities as he wishes, for example our own PhotoRescue application.


DMTelf

#30 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 06 March 2010 - 08:14 AM

From the screenshot (and also from the posted file :whistling:) you seem like you read FIRST 5000 sectors.

You may have read them in the direction from 5000 to 0 instead of from 0 to 5000, but still it's the first 5000 ones. :huh:

Re-scan the drive, then jolt down the number it gets in the "End" Sectors.

Let's say it is 625,142,448.
Subtract from it 5,200.
That makes 625,137,248

The boxes "Sectors" should read:
  • Start 625137248
  • Size 5200
  • End 625142448


:unsure:

Wonko

#31 dmtelf

dmtelf

    Member

  • Members
  • 34 posts
  •  
    United Kingdom

Posted 06 March 2010 - 08:52 AM

From the screenshot (and also from the posted file :whistling:) you seem like you read FIRST 5000 sectors.

Duh :huh: Thanks for the correction. I will redo it after the full backup via DataRescue DD has completed. It's been running for 7 hours 40 mins now & the image size is currently 238Gb & it has about 2.20 hours left before it completes.

In the Messages section of DD Data Rescue, it says "06:14:14 Read error at 2542f8c200 : Data error (cyclic redundancy check)." but it continued whereas dsfo just stops.

I made a folder of data recovery tools on a 4Gb Cruzer stick, ran DD Data Rescue from it last night, and this morning the laptop won't recognise the stick at all, it doesn't appear as a drive letter, and doesn't appear in Disk Management at all! When I insert the stick, its orange access light flashes for about a minute, then remains permanently lit for a minute or so then the light goes out. Is someone playing a joke on me?! I'll run dsfo on it later to see what's up.

The main problem caused by this is I don't think I will now be able to access the DD Data Rescue log as its being (or was) written to the Cruzer drive which is now not readable :unsure:

DMTelf

#32 TheK

TheK

    Frequent Member

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

Posted 06 March 2010 - 09:55 AM

The main problem caused by this is I don't think I will now be able to access the DD Data Rescue log as its being (or was) written to the Cruzer drive which is now not readable :whistling:

That's no problem as long as DataRescue DD doesn't stop before the whole disk was successfully dumped.

#33 dmtelf

dmtelf

    Member

  • Members
  • 34 posts
  •  
    United Kingdom

Posted 06 March 2010 - 11:44 AM

I'm now finally the proud owner of a 320,070,320,640 byte image! :whistling: It took 10 hours 20 minutes to create.

Here's a link to the zip file of the last 5200 sectors:
http://rapidshare.co...0070320640_.zip

DMTelf

Attached Thumbnails

  • Final_DataRescue_DD_Image_Screengrab.png


#34 TheK

TheK

    Frequent Member

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

Posted 07 March 2010 - 08:15 AM

I'm now finally the proud owner of a 320,070,320,640 byte image! :whistling: It took 10 hours 20 minutes to create.


The image still too small. The total disk capacity is 320072933376 bytes.
BUT it looks like we have the at least the complete lost partition. The missing bytes are most likely unpartitioned space at the end of the disk. That's nothing unusual because partitions usually end at a cylinder boundery. In this case it's CHS 38912/254/63 which matches exatly 320,070,320,640 bytes.
Cylinders and Heads start from 0 so we have 38913 cylinders * 255 heads * 63 sectors * 512 bytes / sector = 320,070,320,640 bytes

The last sector of your 5200 sector file is the NTFS boot sector backup. That's another sign that we have the complete lost partition.
The backup boot sector and the one found at sector 63 are identical. They both show the file system size as 625137281 sectors.

So I think we finally have all we need to recreate the partition table.

Partition Start
CHS 0/1/1 = LBA Sector 63
Partition End
CHS 38912/254/63 = LBA Size 625137282 (625137281 sectors of the file system + hidden sector with the NTFS boot sector backup)

Do you have enough free space on your new HD to make a backup copy of your image?

#35 dmtelf

dmtelf

    Member

  • Members
  • 34 posts
  •  
    United Kingdom

Posted 07 March 2010 - 09:10 AM

The image still too small. The total disk capacity is 320072933376 bytes.

Oh :whistling: I guess there isn't any way to take a 100% backup that is 320072933376 bytes because of the CRC error(s) thus what DataRescue DD created is the best we'd be able to get from this particular drive...?

Thank you for the maths behind the calculations too - I will have to go over this several times in order to understand it completely so I am eventually able to it work it out for myself in future.

Do you have enough free space on your new HD to make a backup copy of your image?

I have 430Gb free in a separate partition & 200Gb free in the partition that contains the image. Do you want me to copy the image itself from one partition to the other via e.g. xxcopy before anything else is done to the image itself?

I've been reading up on IMDISK etc but wanted to wait for clear advice from someone on what parameters to use with it e.g. image file offset now that I have this raw DD image which turns out to not be 100% complete.

Thanks.

DMTelf

#36 TheK

TheK

    Frequent Member

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

Posted 07 March 2010 - 09:59 AM

Oh :whistling: I guess there isn't any way to take a 100% backup that is 320072933376 bytes because of the CRC error(s) thus what DataRescue DD created is the best we'd be able to get from this particular drive...?


No, the CRC error was somewhere in the middle of the disk, but I think we have all we need.


I've been reading up on IMDISK etc but wanted to wait for clear advice from someone on what parameters to use with it e.g. image file offset now that I have this raw DD image which turns out to not be 100% complete.


We arn't ready for ImDisk yet. We still need to fix the MBR and the NTFS boot sectors. Well, the NTFS boot sector would be enough for ImDisk as we know the offset of the first partition is 63 blocks (sectors = blocks in ImDisk). But the file system will most likely be seen as raw as the OEM ID is zeroed out in the boot sector.

So we need to fix some things inside the image first. Now the question is ... do you want to make a backup of the image to work with, or do you want to modify the original image?
Creating another backup image is recommended. You can always create a new one with DataRescueDD, but the Toshiba HD doesn't seem to be 100% reliable anymore (CRC error).

On the other hand, we have backups of the sectors we need to fix. So if something goes wrong we still can write the backups back to the image.

It's up to you.

#37 dmtelf

dmtelf

    Member

  • Members
  • 34 posts
  •  
    United Kingdom

Posted 07 March 2010 - 01:39 PM

So we need to fix some things inside the image first. Now the question is ... do you want to make a backup of the image to work with, or do you want to modify the original image?
Creating another backup image is recommended. You can always create a new one with DataRescueDD, but the Toshiba HD doesn't seem to be 100% reliable anymore (CRC error).

On the other hand, we have backups of the sectors we need to fix. So if something goes wrong we still can write the backups back to the image.

It's up to you.

As the Toshiba HD itself is no longer reliable, I've decided to make a copy of the image to another partition using TeraCopy Pro. It's taken 3.5 hours to copy 50% of the image. I will also check the source image CRC & copied image CRC are identical after the copy has finished.

DMTelf

#38 dmtelf

dmtelf

    Member

  • Members
  • 34 posts
  •  
    United Kingdom

Posted 07 March 2010 - 05:44 PM

We arn't ready for ImDisk yet. We still need to fix the MBR and the NTFS boot sectors. Well, the NTFS boot sector would be enough for ImDisk as we know the offset of the first partition is 63 blocks (sectors = blocks in ImDisk). But the file system will most likely be seen as raw as the OEM ID is zeroed out in the boot sector.

I have a 1Tb drive with 2 partitions just for this recovery - 1 partition has the Toshiba HD image on it & the other partition has a CRC checked copy of it.

I am ready for the next stage in this data recovery adventure.

Is this basic outline & terminology of the next steps correct?

1) A file with the necessary fixes to the MBR + NTFS boot sectors is produced
2) dsfi is used to merge it into the image
3) Change disk geometry of partition in image via TestDisk
4) Scan image for the partition with TestDisk
5) ImDisk should now be able to mount the partition if the correct image file offset parameter is used

DMTelf

#39 TheK

TheK

    Frequent Member

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

Posted 08 March 2010 - 03:41 PM

I have a 1Tb drive with 2 partitions just for this recovery - 1 partition has the Toshiba HD image on it & the other partition has a CRC checked copy of it.

I am ready for the next stage in this data recovery adventure.

Is this basic outline & terminology of the next steps correct?

1) A file with the necessary fixes to the MBR + NTFS boot sectors is produced
2) dsfi is used to merge it into the image
3) Change disk geometry of partition in image via TestDisk
4) Scan image for the partition with TestDisk
5) ImDisk should now be able to mount the partition if the correct image file offset parameter is used

DMTelf


Well, it's amost correct B)

1) Use dsfo to dump the first 63 sectors to a new file
2) Use TestDisk to fix the MBR inside this file
3) Use TestDisk to write a new partition to the partition table inside that file
4) Use a Hex Editor to fix the NTFS boot sector inside that file
5) Use dsfi to write that file back to the image
6) Use a Hex Editor to fix the backup NTFS boot sector inside the image
7) Open the image again with TestDisk.
8) Check the MFT
9) Check if we can access the file system
10) If so, mount the image with ImDisk

Any questions? :ranting2:

#40 dmtelf

dmtelf

    Member

  • Members
  • 34 posts
  •  
    United Kingdom

Posted 08 March 2010 - 05:36 PM

Well, it's amost correct B)
...
Any questions? :ranting2:

Yes I do have a question - why have I got a sudden migraine after reading this list? :ranting2:

Seriously, many thanks for the clarification of what needs to be done next. I have never done steps 2-8 before, and at the moment I can't find details on how to do them manually either as I understand from reading several threads on this forum that at this point of the recovery process, a data recovery guru usually puts together the bin file for the newbie to merge back into the image via dsfi & I assume that this bin file is the end result of steps 2 - 4...?

I've had a go at steps 1 - 3, but after that if I then try to analyse the file, no partitions are found so I've obviously made several big mistakes so I thought I'd be better off stopping & trying to get some expert guidance rather than blundering on and on... :ranting2:

1) Use dsfo to dump the first 63 sectors to a new file

63 sectors * 512 bytes/sector = 32256
C:\dsfok>dsfo f:\toshibadump.img 0 32256 f:\1st63sectors.img (attached to this post)

2) Use TestDisk to fix the MBR inside this file

c:\testdisk\win\testdisk_win.exe h:\1st63sectors.img
Select a media - Disk h:\1st63sectors.img - 32Kb
Select "MBR Code" & answer "Y" to "Write a new copy of MBR code to first sector?" then "Y" again to confirm

3) Use TestDisk to write a new partition to the partition table inside that file

c:\testdisk_win.exe h:\1st63sectors.img
Select a media - Disk h:\1st63sectors.img - 32Kb
Select Analyse -> Quick Search -> "N" to Should TestDesk search for partition created under Vista?
Above the Partition / Start / End / Size in sectors line, it says Disk h:\test.img - 32 Kb / 31 KiB - CHS 1 255 63
I am then prompted to enter the value for the starting cylinder etc, so I use the following details:
Start Cylinders - 0
Start Head - 0
End cylinder: 38912 cylinders
End head: 254
Sectors: 63 sectors
NTFS partition type: 07

DMTelf

Attached Files



#41 TheK

TheK

    Frequent Member

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

Posted 08 March 2010 - 06:11 PM

Yes I do have a question - why have I got a sudden migraine after reading this list? B)

I blame the weather :ranting2:

Seriously, many thanks for the clarification of what needs to be done next. I have never done steps 2-8 before, and at the moment I can't find details on how to do them manually either as I understand from reading several threads on this forum that at this point of the recovery process, a data recovery guru usually puts together the bin file for the newbie to merge back into the image via dsfi & I assume that this bin file is the end result of steps 2 - 4...?

Well I can prepare that 'bin file' file for you if you want. On the other hand...Your on a good way to be able to do it yourself :ranting2:

I've had a go at steps 1 - 3, but after that if I then try to analyse the file, no partitions are found so I've obviously made several big mistakes so I thought I'd be better off stopping & trying to get some expert guidance rather than blundering on and on... :ranting2:


It's normal that TestDisk can't find any partition inside that file. You already tried to find it on the Thosiba drive and it faild. So we will recreate the partition ourself.

And you already did that:

1) Use dsfo to dump the first 63 sectors to a new file

63 sectors * 512 bytes/sector = 32256
C:\dsfok>dsfo f:\toshibadump.img 0 32256 f:\1st63sectors.img (attached to this post)

2) Use TestDisk to fix the MBR inside this file

c:\testdisk\win\testdisk_win.exe h:\1st63sectors.img
Select a media - Disk h:\1st63sectors.img - 32Kb
Select "MBR Code" & answer "Y" to "Write a new copy of MBR code to first sector?" then "Y" again to confirm

3) Use TestDisk to write a new partition to the partition table inside that file

c:\testdisk_win.exe h:\1st63sectors.img
Select a media - Disk h:\1st63sectors.img - 32Kb
Select Analyse -> Quick Search -> "N" to Should TestDesk search for partition created under Vista?
Above the Partition / Start / End / Size in sectors line, it says Disk h:\test.img - 32 Kb / 31 KiB - CHS 1 255 63
I am then prompted to enter the value for the starting cylinder etc, so I use the following details:
Start Cylinders - 0
Start Head - 0
End cylinder: 38912 cylinders
End head: 254
Sectors: 63 sectors
NTFS partition type: 07

Start head needs to be 1, everything else is correct :ranting2:
Next step is to choose 'write' and save the partition table to the image.

Now I just noticed that I made a small mistake. We need the first 64 sectors (sector 0-63). But that's no problem. We can skip step 4 and fix the NTFS boot sector in step 6.

If you have fixed the 1st63sectors.img file please attatch it. I'd like to check it before we move to the next step.

#42 dmtelf

dmtelf

    Member

  • Members
  • 34 posts
  •  
    United Kingdom

Posted 08 March 2010 - 08:01 PM

Well I can prepare that 'bin file' file for you if you want. On the other hand...Your on a good way to be able to do it yourself :ranting2:

Uh.... what....? I'm a good way to being able to do it myself?! If you're happy to help me along where necessary, I'd most certainly love to have a go at it as much as possible as it's the best way to learn... :ranting2:

Start head needs to be 1, everything else is correct :ranting2:

It looks like all the reading up I've been doing since disaster struck is very slowly starting to pay off which is encouraging..... :ranting2: There is so much to learn though, and I've got other knackered HDs I will practise on after I've done this Toshiba HD which is by far the most critical drive to recover.

Next step is to choose 'write' and save the partition table to the image.

Now I just noticed that I made a small mistake. We need the first 64 sectors (sector 0-63). But that's no problem. We can skip step 4 and fix the NTFS boot sector in step 6.

If you have fixed the 1st63sectors.img file please attatch it. I'd like to check it before we move to the next step.

I've redone steps 1-3 & have attached an 64 sector image to this post. When I analyse it with TestDisk, it tells me that it has an invalid NTFS or EXFAR boot:

1 * HPFS - NTFS 0 / 1 / 1 / 38912 / 254 / 63 / 625137282
1 * HPFS - NTFS 0 / 1 / 1 / 38912 / 254 / 63 / 625137282

I've broken it down here for my reference:

Start cylinder: 0
Start head: 1
Start sector: 1
Ending cylinder: 38912
Ending head: 254
End sector: 63
Size in sectors: 625137282
Type 07 HPFS-NTFS

I've installed TinyHexer & jaclaz's BSview, MBRview & PVview scripts in preparation for step 4.

DMTelf

Attached Files



#43 TheK

TheK

    Frequent Member

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

Posted 09 March 2010 - 08:03 AM

Well done :ranting2:

Now open the 1st64sectors file with TinyHexer and select 'Tools > Scripts > PT view by jaclaz' from the menu.

As we can see there is one partition with the following details:

Type: 07 (NTFS)
Boot: 80 (means the parition is marked as active)
bCyl: 0
bHead: 1
bSect: 1
eCyl: 1023
eHead: 254
eSect: 63
StartSector: 63
NumSectors: 625137282

You probably notice that the eCyl value (ending cylinder) is 1023 instad of 38912.
This is correct, because the partition table can't store any cylinder values greater than 1023 as there are only 10 bits reserved for it inside the partition table entry structure.
You can find some infos about the MBR and Partition Table structure here: http://en.wikipedia....ter_boot_record

The important values are the SartSector and NumSectors which are the LBA values for the partition. Windows will use those values to access the partition.

As we can see everything is correct here :ranting2:

Now let's go to step 4 (fix NTFS boot sector)!

First of all you should know how the structure of the NTFS boot sector (aka partition boot sector, volume boot sector) looks like:
http://www.ntfs.com/...boot-sector.htm

Now scroll down to 0x7E00 which is where sector 63 (remember sectors start to count at 0, so it's the 64th sector) begins.
Open the Structure viewer and choose 'NTFS boot structure'.

If we look at the values everything is looking pretty good, except for the OEM (ID) which is blank. We need to fix that now.
The OEM ID starts at position 0x03 of the boot sector and the boot sector starts at 0x7E00. So the location of the OEM ID is 0x7E03.
The ID is 8 bytes long and should be 'NTFS ' for a NTFS file system.
Please note that there are 4 blank spaces after NTFS to fill all 8 bytes.

Now we know what to change and where to change it!
Offset: 0x7E03
Value: 'NTFS ' (without the quotes)

But before you change that make sure you disable the insert mode in Tiny Hexer (uncheck View > Insert mode)

So far any questions?

Attached Thumbnails

  • SnapShot_bs.png
  • SnapShot_bs2.png


#44 dmtelf

dmtelf

    Member

  • Members
  • 34 posts
  •  
    United Kingdom

Posted 09 March 2010 - 10:20 AM

Thank you very much for the explanations & links to the further reading - I will go over it several times whilst I examine the image with TinyHexer & jaclaz's scripts etc.

So far any questions?

After fixing the NTFS boot sector & saving it in TinyHexer, I analysed 1st64sectors.dd with TestDisk & it found 1 partition:

1 * HPFS - NTFS 0 / 1 / 1 / 38912 / 254 / 63 / 6251327282
Warning: Bad ending cylinder (CHS and LBA don't match)

Does it say bad ending cylinder because the image is of only the 1st 64 sectors & it's expecting to find all 6251327282 sectors which it would do after the corrected 1st 64 sectors is merged with the full image via dsfi e.g. dsfi f:\toshibaimage.dd 0 0 f:\first64sectors.dd..?

I then looked at the 1st64sectors.dd file with jaclaz's NTFS Boot Structure TinyHexer script & in the OEM field, it now says: OEM: 'ø' - I was kind of expecting it to say the OEM ID i.e. NTFS..?

I've attached the 1st64sectors file to this post.

DMTelf

Attached Files



#45 TheK

TheK

    Frequent Member

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

Posted 09 March 2010 - 11:22 AM

First of all...don't make any further changes to the 1st64sectors file. Everything is correct now :ranting2:

Does it say bad ending cylinder because the image is of only the 1st 64 sectors & it's expecting to find all 6251327282 sectors which it would do after the corrected 1st 64 sectors is merged with the full image via dsfi e.g. dsfi f:\toshibaimage.dd 0 0 f:\first64sectors.dd..?


Yes, that's right. It calculates the disk geometry from the file size. And as this image is simply too small to have 38912 cylinders. Max. cylinder is detected as 1. You can check that in the 'gemetry' function of TestDisk.

I then looked at the 1st64sectors.dd file with jaclaz's NTFS Boot Structure TinyHexer script & in the OEM field, it now says: OEM: 'ø' - I was kind of expecting it to say the OEM ID i.e. NTFS..?


hmm, it says NTFS here.

Make sure the cursor is located at offset 0x7E00 before you open the structure viewer.
And then there is a button on the top of the structure viewer window. It looks like 4 arrows pointing to the center.
This button is for "Switch start decoding at current position/position zero". Enable or disable it and reload the structure if you still can't see the proper OEM field.

#46 dmtelf

dmtelf

    Member

  • Members
  • 34 posts
  •  
    United Kingdom

Posted 09 March 2010 - 01:14 PM

First of all...don't make any further changes to the 1st64sectors file. Everything is correct now :ranting2:

Great! :ranting2:

hmm, it says NTFS here.

Make sure the cursor is located at offset 0x7E00 before you open the structure viewer.

After I positioned the cursor at offset 0x7E00 then opened the structure viewer, it said "NTFS ".

I guess dsfi can now be used to write the 1st 64 sector file back to the image & then after that TinyHexer will be needed to fix the backup NTFS boot sector inside the image..?

DMTelf

#47 TheK

TheK

    Frequent Member

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

Posted 09 March 2010 - 03:20 PM

I guess dsfi can now be used to write the 1st 64 sector file back to the image & then after that TinyHexer will be needed to fix the backup NTFS boot sector inside the image..?


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.
It has a nice option to open disk image files which makes it very easy to locate the start position of the last sector.
You can find it in the Extras menu.
Jump to the last sector and compare it with the boot sector found at position 0x7E00. You will see they are identical except for the OEM ID that still needs to be fixed. Fix it and save it.

#48 dmtelf

dmtelf

    Member

  • Members
  • 34 posts
  •  
    United Kingdom

Posted 09 March 2010 - 04:03 PM

Jump to the last sector and compare it with the boot sector found at position 0x7E00. You will see they are identical except for the OEM ID that still needs to be fixed. Fix it and save it.

I wrote the 1st64sectors image back via dsfi, installed HxD, told HxD to display 512 bytes (1 sector) per line & compared sector 63 with the last sector. I made the necessary fix & saved it.

I then fired up TestDisk again & analysed the image. It found a partition, and tells me the structure is OK, but when I tell it to list the files, it tells it can't open the filesystem & that it seems damaged... :ranting2:

DMTelf

#49 TheK

TheK

    Frequent Member

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

Posted 09 March 2010 - 04:27 PM

In TestDisk choose [Advanced] from the main menu, then [Boot]. What does it say about the boot sector?

#50 dmtelf

dmtelf

    Member

  • Members
  • 34 posts
  •  
    United Kingdom

Posted 09 March 2010 - 04:34 PM

In TestDisk choose [Advanced] from the main menu, then [Boot]. What does it say about the boot sector?

It says both the boot sector & backup boot sector are "Status: OK" & that the sectors are identical.

It also says that "A valid NTFS Boot sector must be present in order to access any data; even if the partition is not bootable."

DMTelf




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users