Lost partition with value data

[ozzyboy]

Hi, I'm back again...with some good news!!

OK, I've done the image of HDD. For results see the picture below:

After that I have decided to try something and I mounted the full image with ImDisk Virtual with this settings:

Then I tried "File Scavenger" with "a long scan" on new mounted partition "H"

After 1 hour of scanning...File Scavenger found me all files, you can see that in the picture:

But I dont have so much free space, to copy founded files on other partition.

Now I'm asking you, if it's posible to recostruct, somehow, the original partition, to no longer need copying those files on another hdd.

@jaclaz, I scaned the partition twice, with Testdisk, but with no results!! maybe I'm doing something wrong...

Thank's guys, especialy to jaclaz!!!!!

Edited February 14, 2010 by ozzyboy

[jaclaz]

Let's make a deal.

If you give me a reason why you used a 2048 blocks offset when mounting with IMDISK (I won't ask you how it came to you to use IMDISK with an image that you cannot fix with TESTDISK),

AND you run:

dsfo e:\dsfok\hddfull.img 0 1049088 e:\dsfok\first2049.bin

AND you compress the file in a zip file and post it or give a link from where I can download it,

I will help you further.

Translation:

We were originally trying to have partition based recovery, as opposed to file based recovery, which is what you actually performed, and now you want to go back to partition based one.

jaclaz

[ozzyboy]

2048 blocks was default sets from ImDisk Virtual, also I tested with 4096(default NTFS) and I recived the same results. How many blocks must put in there?

And yes, I want a partition recovery instead of file recovery ...You understand me very well.

Thx jaclaz!

Here the file who you request!

[jaclaz]

The data is very, very strange.

06 00 0 32 33 1023 254 63   2048 234436608

The partition type is FAT16.

The CHS offset is that of a small device with 32 sectors.

(32+1)*63=2079 and NOT 2048.

The file you sent is all 00's apart the MBR.

Try posting a bigger chunk of the image:

dsfo e:\dsfok\hddfull.img 0 2560000 e:\dsfok\first5000.bin

jaclaz

[ozzyboy]

Maybe all data in the begining of hdd is altered because of all recovery apps what I've used.

Here, first5000.bin.

Edited February 14, 2010 by ozzyboy

[jaclaz]

I did a couple of tests, and that geometry seems allright after all, it means that you partitioned that thingy under an unpatched Vista with Alignment ON, aligned on 1 Mb.

So the partition table geometry is "right". the only problem is the partition ID, (which is not a problem it's just a matter of 06 07).

You seeem like a lucky guy, as all that is missing appears to be the first sector of the NTFS bootsector.

I need another bit of that thingy:

dsfo e:\dsfok\hddfull.img  -2560000 0 e:\dsfok\last5000.bin

Translation: there is a copy of the bootsector as last sector of the partition on NTFS filesystem.

TESTDISK should be able to find it, however.

http://www.cgsecurity.org/wiki/TestDisk_Step_By_Step

http://www.cgsecurity.org/wiki/TestDisk_St...sector_recovery

Before fiddling with it, however, do post the last sectors, I will assemble a file for you to merge with the image.

jaclaz

[ozzyboy]

Hi!!

Here I am with last requested sectors:

last5000.bin

Thx again!

Edited February 17, 2010 by ozzyboy

[jaclaz]

OK.

Try the attached file.

It is a copy of first2049.bin with the last sector being the NTFS bootsector copy from last5000.bin.

Unzip and apply as follows:

dsfi e:\dsfok\hddfull.img 0 0 e:\dsfok\first2049mod.bin

(please note how you are now using dsfi and NOT dsfo)

After you have applied the file to the image, try running again TESTDISK on the image, you should be able to find the partition AND to see the files. (you shouldn't need to do any repair)

If the above is OK, then try mounting the image with IMDISK.

jaclaz

first2049mod.zip

[ozzyboy]

How can I run testdisk on img without mounting? I've opened testdisk and it shows me only real hdd(from my desktop).

l.e. OK, I realized ... I used drag and drop

Edited February 17, 2010 by ozzyboy

[ozzyboy]

WOW!!I don't belive it. This is Greath!!

Mission Acomplishied!! Thank's a lot jaclaz!!!

I want to know how did you repair my sectors . Can you explain me all procedures, tools...here on pm...I want to learn to do this by my self, off course if is not a secret !!!

Again thank you very very much, for all your time lost with me.

[jaclaz]

WOW!!I don't belive it. This is Greath!!

Mission Acomplishied!! Thank's a lot jaclaz!!!

I want to know how did you repair my sectors. Can you explain me all procedures, tools...here on pm...I want to learn to do this by my self, off course if is not a secret !!!

Again thank you very very much, for all your time lost with me.

Good to know we have yet another happy bunny.

http://www.msfn.org/board/index.php?showtopic=128727&st=10

Basically:

the only two problems your partition apparently had were:

1. wrong partition ID in partition table (06, aka "DOS" FAT 16 CHS mapped instead of 07 HPFS/NTFS)
   
2. missing (wiped or filled with 00's) first sector of the NTFS bootsector
   

And a third one (which is you lied as that partition was originally created under Vista or 2008 or Windows7 - or however, it's bootsector was later modified by MBRFIX.exe or bootrec.exe, or a similar tool in order to invoke BOOTMGR instead of the NT/2K/XP/2003 NTLDR).

Vista and later, unless a Registry fix to make them behave like previous OS, create a partition "aligned to 1 Mb", for a number of reasons you may want to read/learn reading here:

http://www.boot-land.net/forums/index.php?showtopic=9897&hl=

In ther words, while NT/2K/XP/2003 normally create a set represesenting a whole cylinder of hidden sectors (63) Vista and later create a set of 2048 of them.

(2048*512=1,048,576 =1 Mb)

The first sector after the hidden sector is the bootsector, in this case 2048+1=2049 <this is why I wanted to have a look at first2049.bin, and of course 2049*512=1,049,088

Since last sector of first2049.bin was made of all 00's, I asked you to produce the first5000.bin, in order to check whether that a bunch of sectors after the 2049th werer blank as well or contained some data.

The actual "whole" bootsector on a NTFS filesystem is actually 16 sectors long, so I could have asked you to produce 2048+16=2064 first2064.bin or, at the most, to check some other 100 sectors, a first2164.bin, but 5000 is a nice, round number, and allowed me to check also for some other things (since the partition ID was definitely "wrong" and you had already lied to me it was possible that the partition was actually a logical volume inside extended and that the missing 2049th sector was - instead of being a bootsector and EPBR, in which case the actuall bootsector may have been another 1 Mb further in the disk).

For a quick reference of what an EPBR is, read this oldish, but still useful partition primer:

http://www.ranish.com/part/primer.htm

With first5000.bin in my hands I could check that 2050th sector was actually the second sector of a NTFS "Vista" bootsector, and that the following sectors made sense.

So, since the LBA partition data in the MBR StartLBA=2048 appeared correct, I assumed that also the NumSectors=234436608 were also correct.

If the above was true, the partition should have ended at LBA 2048+234436608=234438656.

From the output of your initial dsfo command, I knew that the whole disk was 120034099200 bytes, i.e. 120034099200/512=234441600 sectors.

Now, 234438656-234441600=-2944 so the partition should have ended 2944 sectors before the end of the drive.

NTFS has a "failsafe" mechanism that creates a copy of the bootsector of the partition at the end of it.

So, I could well have asked you for 2944+1=2945 last2945.bin, and check if the first sector of it was actaully a first sector of a NTFS bootsector, but since I already had mentioned a nice, round number of 5000, I asked you for a last5000.bin.

I found the bootsector where i expected it, at offset -2945 sectors, and simply copied it and pasted over 2049th sector of first2049mod.bin (a copy of first2049.bin), then modified the partition ID in first sector of first2049mod.bin from 06 to 07.

Checked if the data in the "new" bootsector made sense with the data in the parition table, and posted it.

Tools used:

TinyHexer

Structure viewers by jaclaz:

http://www.boot-land.net/forums/index.php?showtopic=8734

Knowledge needed:

• understanding the contents of this site (yes, everything in the /mbr/ )
  http://mirror.href.com/thestarman/
  http://mirror.href.com/thestarman/asm/mbr/index.html
  
• familiarity with a hex editor (TinyHexer in this case)
  
• some experience with MBR's, PBR's EPBR's and the like.
  

(first and last point will take some time )

But no secrets and no magic tricks, only some smoke and mirrors.

jaclaz

Edited February 17, 2010 by jaclaz

[ozzyboy]

I don't like "smoke" -

Thx again jaclaz...I'll spend some time to aknowledge that info....

A "litle" gift for you!! :

[ozzyboy]

Hi jaclaz, I have another question ...

Now I'm trying to recover the hdd, and I dont know how to apply "first2049mod.bin" directly to hdd since the hdd isn't recognized.

I dont know the command line.

Thx again!!

l.e. or the procedure is other:

1st rebuild .img then mount.img

2nd format HDD and then copy ffiles from partition mounted...

I'm stuck...

Edited February 17, 2010 by ozzyboy

[jaclaz]

The fact theat the filesysttem(s) on a HD is/are not accessible does not mean that the HD is not.

The HD (if operational) will be mapped to a \\.\PhysicalDriven.

Since you originally used:

dsfo \\.\PHYSICALDRIVE1 0 0 C:\dsfok\hddfull.img

You can now use:

dsfi \\.\PHYSICALDRIVE1 0 0 C:\dsfok\first2049mod.bin

You must think of the tools having a syntax (simplified) like:

dsf (get) out of <device or file> <starting from> <and up to> (and save as) <device or file>

and

dsf (get) inside of <device or file> <starting from> <and up to> (the contents of) <device or file>

Of course you should make sure that the device you are writing to, the n, is the right one.

Or you can extract just the MBR and the last sector (the PBR) out of first2049mod.bin and write them to the HD (if you connect the Hd, since it alrady contains a partition table, you should get it connected as both \\.\PhysicalDriven AND to a Logical Drive - a drive letter which you can see in Explorer - but that when you click on it will ask you to format the drive).

So:

dsfo C:\dsfok\first2049mod.bin 0 512 C:\dsfok\theMBR.bin

and

dsfo C:\dsfok\first2049mod.bin -512 0 C:\dsfok\thePBR.bin

will produce respectively the MBR and PBR, sized each 1 sector or 512 bytes, which you can then write (again respectively) with dsfi or, maybe more easily with Hdhacker:

http://www.dimio.altervista.org/eng/

to \\.\PhysicalDrive and LogicalDrive

The latter:

dsfo C:\dsfok\first2049mod.bin -512 0 C:\dsfok\thePBR.bin

can be written as:

dsfo C:\dsfok\first2049mod.bin 1048576 0 C:\dsfok\thePBR.bin

or

dsfo C:\dsfok\first2049mod.bin 1048576 512 C:\dsfok\thePBR.bin

as when <and up to> equals to 0 it means <up to the end of file>

I hope I am not confusing you more than needed, the PhysicalDrive represents the whole device, no matter if partitioned/formatted or not and it's first sector is the first sector of the device, LogicalDrive represent ONLY a part of the device, and ONLY the part that is defined in the partition table (the partition) NO matter if the partition is formatted or not. The first sector of LogicalDrive corresponds to the address given in the partition table, in your case 2048.

jaclaz

[ozzyboy]

(my case)

e:\dsfok\dsfi \\.\PHYSICALDRIVE1 0 0 e:\dsfok\first2049mod.bin

Very powerfull this combination, Dsfok + TestDisk + smart brain(your, of course) B)

Gratire ancora per tutto l'aiuto!!!