Fixing a Windows partition boot using OS X tools

Question

I've got a triple boot system on my Early 2013 Mac Book Pro: OS X, Windows 7 and Ubuntu. I'm using rEFInd as my boot manager. My Windows install boots using legacy BIOS boot, and OS X and Ubuntu boot with native EFI boot.

Everything has been working until I updated to OS X Yosemite. That broke my Windows:

"No bootable device -- insert boot disk and press any key"

I guess I should've backed the boot sector up before updating, but it's too late now! Since the Windows boots in BIOS mode, it reads the hybrid MBR and indeed, the Windows partition was not flagged as bootable. After I flagged it bootable with fdisk, the message changed to:

"Missing operating system"

I have checked the MBR with fdisk, and GPT with gdisk that and are indeed compatible and in sync. After hours of googling and trying everything, I finally realised what the problem was:

I had some weeks earlier resized the Windows partition, by shrinking the OS X partition in OS X, and then, using a certain Windows software, growing the Windows partition to accommodate the new free space that now lied before the Windows partition. It now seems that that program updated ONLY MBR: from GPT viewpoint there is some unpartitioned space before the Windows partition, and from MBR viewpoint that space is used by Windows.

However, when installing Yosemite, it synced the hybrid MBR to comply with the GPT, marking the upper section of the Windows partition as free space. That "free space", of course contains the Windows bootloader and a bunch of data!

My question is, is there any way to scan the seemingly unpartitioned portion of the disk, and determine the first sector of the Windows partition? I guess that is possible, but I need the right tools for that.

For information, here is my GPT data:

Number  Start (sector)    End (sector)  Size       Code  Name
   1              40          409639   200.0 MiB   EF00  EFI System Partition
   2          409640       731723959   348.7 GiB   AF05  Macintosh HD
   3       731723960       732993495   619.9 MiB   AB00  Recovery HD
   4       799528960       906948607   51.2 GiB    0700  WINDOWS 1
   5       906948608       977104895   33.5 GiB    0700  UBUNTU

and the data from protective/hybrid MBR:

 #: id  cyl  hd sec -  cyl  hd sec [     start -       size]
------------------------------------------------------------------------
 1: EE 1023 254  63 - 1023 254  63 [         1 -     409639] <Unknown ID>
 2: AC 1023 254  63 - 1023 254  63 [    409640 -  731314320] <Unknown ID>
 3: AB 1023 254  63 - 1023 254  63 [ 731723960 -    1269536] Darwin Boot 
*4: 0C 1023 254  63 - 1023 254  63 [ 732993496 -  173955112] Win95 FAT32L

Note that there is a 66535465 sector, 31.7 GiB gap before the 51.2 GiB Windows partition. When Windows worked, it saw its partition as roughly 80 GiB partition. So, the "real" start of that Windows partition lies somewhere inisde that gap. How to scan it out?

Answer 1

I'll post this as an answer, even though it didn't fix my problem – this was a lost case in the end. Aftermath: I dd'ed a backup of the Windows partition to my OS X partition:

sudo dd bs=512 if=/dev/disk0 of=windows_backup skip=732993496 count=173955112

Now I had a 80 gig hex dump which I could examine safely. I used a hex editor to search for all kinds of metadata:

• "NTFS" (encoded in ASCII) which starts a NTFS volume.
• "FILE" (encoded in ASCII) which starts a file entry record in the $MFT or master file table in NTFS.
• NTFS system file names (like "MFT", tried with little-endian UTF-16 and ASCII)

... and so on. But without success. I was able to find all kinds of data from the dump, but all the metadata, including the boot record (the first sector of the volume), the $Boot file (the first 15 sectors after the boot record), the $MFT file which keeps record of all the files on the file system, were gone.

The thing that baffles me that I couldn't even find $MFTMirr file, which is the backup file of the metadata files and stored halfway of the volume.

I was able to find a backup of the boot sector from its standard location, the last sector of the volume. However, the data was old, from the era before resizing the volume. The boot sector has stored the offset of the $MFT file metadata file, but inspecting the references was moot, there was nothing of value there.

In the end, I concluded that the volume was totally borked. The moral of the story? Hybrid Master Boot Record is evil. Also, it seems that the program that resized the volume did a subpar job, failing to update some of the metadata.