I have been able to salvage at least the OS X partition by accessing the Mac remotely via TeamViewer and restoring the old CoreStorage Logical Volume Group.
Here are the steps to recover the OS X volume:
- Boot to Internet Recovery Mode
- Attach a 16 GB thumb drive
- Install a full system to the thumb drive. In Internet Recovery Mode the original system the Mac was delivered with is installed: Mountain Lion
- After booting from the thumb drive and configuring an admin account the system was updated to El Capitan.
- wxHexEditor (a raw disk editor) and TeamViewer (remote access) were installed.
After checking the disk with
diskutil cs listand
sudo gpt -r show disk0 the following picture emerged:
- the disk had a MBR instead of a pMBR
- a CoreStorage Volume was configured but the Physical Volume was corrupted - no Logical Volume Family and Logical were available.
- No volume - neither OS X nor NTFS or recovery volume was working
To restore a GUID partition table the MBR had to be overwritten with
sudo dd if=/dev/zero of=/dev/disk0 bs=512 count=1
and a new GUID partition table had to be created:
sudo gpt destroy disk0
sudo gpt create -f disk0
added a new EFI partition:
sudo gpt -i 1 40 -s 409600 -t C12A7328-F81F-11D2-BA4B-00A0C93EC93B disk0
and copied the EFI of the thumb drive to disk0s1:
sudo dd if=/dev/disk1s1 of=/dev/disk0s1 bs=4m
Now I tried to determine if the main OS X partition was CoreStorage or non-CoreStorage with wxHexEditor:
In normal HFSJ volumes block 409640 and 409641 of the disk (=block one and two of the OS X partition) usually contain zeros and block 409642 the string "HFSJ" in the first 16 bytes. The first block of a CoreStorage contains some non-zeros - the next two blocks are equal to non-CoreStorage partitions.
Block 409640 had some non-zeros, so I assumed it was "corestoraged".
The end of a CoreStorage Volume Group can be determined by characteristic strings in plist-like invisible objects in the "administrative area" of the CoreStorage Volume Group.
The string "physicalVolumes" has four occurrences near the end of an LVG. The last occurrence is in the 8185th last block of the LVG. By searching for the strings with wxHexEditor the last block was determined.
With the example above that's 511246241792/512 + 8184 = block 998536000. The block number has to be divisable by eight for 512-disks.
With the last block of the LVG the second partition can be added with:
sudo gpt -i 2 409640 -s 998536000 -t 53746F72-6167-11AA-AA11-00306543ECAC disk0
The broken volume reappeared. The disk was then verified and repaired as well as the volumes. It took several attempts to repair all errors of the volume. I didn't try to recover the Windows 7 partition.
The main volume was fully bootable. All data was backed up and the drive was re-partitioned. A new system was installed and the backup data was transferred with the Migration Assistant.