Accidentaly converted from a basic disk to a dynamic one I got a MacBook Pro (13-inch late 2013 retina)
So I installed Windows 7 using bootcamp and all was fine. I then needed to create a 32MB FAT16 partition, when Windows prompted me to convert to a dynamic disk, I mistakenly hit enter. When I rebooted PC, the Mac option was gone and if I tried booting into Windows it would BSOD and restart.

I read some guides about using TestDisk, so I tried to do that.
I booted with a Xubuntu LiveCD then I scanned and I found an HFS partition that seemed to be the partition I was looking for, so I set it to [P]rimary and wrote it to disk, but it still failed to boot.

Please help! I don't know what to do, I reran TestDisk with Deep Search and uploaded the log file: http://pastebin.com/kpzYuFDp

I don't care about my Windows data, I just want my Mac partition back.

PS: I read that I could do something with pdisk (I assume this is manually editing partition table data), but I have no idea how to do this.

As requested fdisk, gpt and diskutils output:

fdisk /dev/disk0
Disk: /dev/disk0    geometry: 14751/255/63 [236978176 sectors]
Signature: 0xAA55
         Starting       Ending
 #: id  cyl  hd sec -  cyl  hd sec [     start -       size]
------------------------------------------------------------------------
 1: EE    0   0   2 - 1023 254  63 [         1 -  236978175] &lt;Unknown ID&gt;
 2: 00    0   0   0 -    0   0   0 [         0 -          0] unused      
 3: 00    0   0   0 -    0   0   0 [         0 -          0] unused      
 4: 00    0   0   0 -    0   0   0 [         0 -          0] unused      

gpt -r show /dev/disk0
      start       size  index  contents
          0          1         PMBR
          1          1         Pri GPT header
          2         32         Pri GPT table
         34   30666498        
   30666532  138412290      1  GPT part - 48465300-0000-11AA-AA11-00306543ECAC
  169078822   67899321        
  236978143         32         Sec GPT table
  236978175          1         Sec GPT header

diskutil list
/dev/disk0
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *121.3 GB   disk0
   1:                  Apple_HFS                         70.9 GB    disk0s1
Windows' Disk Management has overwritten the GUID partition table with something unknown. This usually only effects the partition table but not the content of your disk (though it seems to be gone)! A proper GUID partition table has to be restored.

The particular obstacle here is: the OP neither has a thumb drive nor a second Mac.

Preparation:


Backup the whole SSD to an external drive using a Linux Live DVD with dd if=/dev/sda of=/path/to/file. The resulting file's size should be 121.3 GB or 113 GiB!
Restart to Internet Recovery Mode by pressing alt cmd R at startup. 

The prerequisites are the latest firmware update installed, either ethernet or WLAN (WPA/WPA2) and a router with DHCP activated.
On a 50 Mbps-line it takes about 4 min (presenting a small animated globe) to boot into a recovery netboot image which usually is loaded from an Apple/Akamai server.

I recommend ethernet because it's more reliable. If you are restricted to WIFI and the boot process fails, just restart your Mac until you succeed booting.

Alternatively you may start from a bootable installer thumb drive (preferably Yosemite or El Capitan) or a thumb drive containing a full system (preferably Yosemite or El Capitan). If you boot to a full system and login as admin you have to prepend sudo to execute some commands like gpt ... or newfs_hfs ...!


Modify the GUID partition table


Open Utilities->Terminal in the menubar, enter diskutil list and gpt -r show /dev/diskX (with diskX: the disk identifier of your internal disk (probably disk0)) to get an overview. In the commands below I assume the disk identifier is disk0.

You should get the following listings:

gpt -r show /dev/disk0
      start       size  index  contents
          0          1         PMBR
          1          1         Pri GPT header
          2         32         Pri GPT table
         34   30666498        
   30666532  138412290      1  GPT part - 48465300-0000-11AA-AA11-00306543ECAC
  169078822   67899321        
  236978143         32         Sec GPT table
  236978175          1         Sec GPT header

diskutil list
/dev/disk0
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *121.3 GB   disk0
   1:                  Apple_HFS                         70.9 GB    disk0s1

# disk1-disk13 are volatile disks belonging to Internet Recovery Mode

Now remove the bogus HFS+ partition:

gpt remove -i 1 /dev/disk0

Add the EFI partition in the partition table:

gpt add -b 40 -i 1 -s 409600 -t C12A7328-F81F-11D2-BA4B-00A0C93EC93B /dev/disk0





Now you can either install OS X to a new partiton - without overwriting your old OS X partitions - and try to detect the sizes of the old partitions with appropriate tools (like wxHexEditor) or you can guess the old content of the GUID partition table (with the help of the TestDisk result - not recommended)



Installing a new OS X

This will destroy the content of the Windows partition(s).


Add a new partition in the (old) OS X part of your disk to protect it.

gpt add -b 409640 -i 2 -s 179590360 -t FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF /dev/disk0


This might be superfluous.
Add new partitions in the (old) Windows part of your disk. The first one (i=4) is a new system partition, the second one (i=5) a recovery partition. The new OS X partition starts at ~91 GB and has a size of ~26 GB - which shouldn't affect the old (hidden, "lost") OS X partition:

gpt add -b 180000000 -i 4 -s 50000000 -t 48465300-0000-11AA-AA11-00306543ECAC /dev/disk0
gpt add -b 230000000 -i 5 -s 1269536 -t 426F6F74-0000-11AA-AA11-00306543ECAC /dev/disk0

Now you have to format the new 26 GB partition:

diskutil list
newfs_hfs -v "TempSystem" -J /dev/disk0s4 #use the proper partition found in diskutil list. It should have a size of ~26 GB
newfs_hfs -v "Recovery HD" -J /dev/disk0s5 #use the proper partition found in diskutil list. It should have a size of ~650 MB
diskutil mount /dev/disk0s4

Exit Terminal by entering exit and quit it.
Open Restore OS X and install OS X to the partition TempSystem.
Configure the new system and enable internet access. Don't initialize any "unknown" volumes if asked.
Enable the root user
Log-out as admin and log-in as root
Download and install wxHexEditor




Detect the start block and type of your old OS X volume and the start block of your old Recovery HD with wxHexEditor:

The approach is similar as in my answer here: HFS+ invalid number of allocation blocks

Since the start block of a main partition and the size of a recovery partition have fixed sizes/boundaries you can usually calculate the proper GUID partition entries of your old partition(s).

Hint: While working with wxHexEditor don't use copy and paste. Enter everything manually! You might accidentally write directly to your disk.


JHFS+ or CoreStorage partition?

First you have to determine, if you had a JHFS+ or CoreStorage partition at index number 2.

Open the Calculator. Open wxHexEditor. Check that you work in read-only mode ("Options" -> "File mode" -> "Read only"). In the menubar go to "Devices" -> "Open disk device" -> choose the appropriate diskNumber. Probably it's disk0. The disk should have further partitions (disk0s1 - disk0s5). Please try to arrange the wxHexEditor window like in the examples below with straight red lines.

Then hit the "Go to offset"-button (marked with the green circle) and enter 409640 exactly like in the picture below. Sometimes you have to do that twice to jump to the correct sector. Re-check the correct sector by entering the offset (marked red) in the Calculator and divide it through 512.

The first 3 sectors of a CoreStorage partition look like this:



The first 3 sectors of a JHFS+ partition look like this:



If you get a fundamentally different picture stop here.
Where does the Recovery HD partition start?

That's probably the most difficult part because you have to find a string which is not very specific.
Jump almost to the beginning of your new main partition (in your case to sector 179999900)

Then enter "HFSJ" like in the picture below, search for this string several times and make readable! hand-written notes of the different offsets. To restore your old OS X you have to boot to Internet Recovery Mode later and all on-screen findings in the current temporary OS X will be lost!

The reason to search for the string "HFSJ" is that all HFSJ+ volumes contain this string in the third sector of its partition. The magic string may occur up to 40 times cluttered over ~10000 sectors! Sometimes it's really difficult to find the proper sector. A second indicator for the beginning of the Recovery HD is at least one block of 0xFF in the tenth sector (or block(MagicString)+7) of the partition.



You may have two really different results depending on the partition type:


Calculate the sector number of the second last finding. In my example (see picture above) it's 68069452800/512=132948150. Continue searching and calculate the sector of the last finding somewhere in the middle of the disk and surrounded by empty sectors. In my case it was 68069454848/512=132948154 (no picture).
The difference between the two finding is 4 blocks (=2 KB).

This is typical for the boundary between a JHFS+ partition and the Recovery HD. The Recovery HD starts then at the sector of the second finding - 2 (in my example 132948154-2=132948152).
Calculate the sector number of the first finding. In my example it was 67733904384/512=132292782 (no picture). Continue searching and calculate the sector of the second finding. In my case it was 68069454848/512=132948154 (no picture). The difference between the two findings is 655372 (~336 MB)

This is typical for the boundary between a CoreStorage partition and the Recovery HD. The Recovery HD starts then at the sector of the second finding - 2 (in my example 132948154-2=132948152).



With these results you should be able to restore your GPT properly. Quit wxHexEditor. If you are asked to save changes don't save them!


Boot back to Internet Recovery Mode and open Terminal
Enter diskutil listand gpt -r show /dev/disk0
Remove the second partition (the protective FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF type partition):

diskutil umountDisk /dev/disk0
gpt remove -i 2 /dev/disk0

Since the EFI and the Recovery HD usually have fixed sizes you can calculate the start and end block of your main volume.

Calculate the size of the main volume: the start block is 409640.
The end block has been found in the section "Where does the Recovery HD partition start?": 1 less than the start block of the Recovery HD.
The size is then StartBlockOfRecoveryHD-409640.
If you've found a classical JHFS+ earlier the following command should fix partition 2:

diskutil umountDisk /dev/disk0
gpt add -b 409640 -i 2 -s StartBlockOfRecoveryHD-409640 -t 48465300-0000-11AA-AA11-00306543ECAC disk0

If you've found a CoreStorage partition earlier the following command should fix partition 2:

diskutil umountDisk /dev/disk0
gpt add -b 409640 -i 2 -s StartBlockOfRecoveryHD-409640 -t 53746F72-6167-11AA-AA11-00306543ECAC disk0

To rebuild the Recovery HD enter:

diskutil umountDisk /dev/disk0
gpt add -b StartBlockOfRecoveryHD -i 3 -s 1269536 -t 426F6F74-0000-11AA-AA11-00306543ECAC disk0

Now you may try to mount and verify your old OS X volume:

diskutil mount /dev/disk0s2
diskutil verifyVolume /dev/disk0s2


If you get an error mounting or verifying the volume its boundaries might be wrong. Stop here and consult me.
If the verification was successful you may either boot to your old OS X volume and check if it works and delete TempSystem and the new Recovery HD later or delete both immediately. The downside of booting to your old OS X volume first is that you have to boot to Internet Recovery Mode once more to delete TempSystem and the new Recovery HD.
To delete both dispensable partitions booted to Internet Recovery Mode enter:

diskutil list
gpt -r show /dev/disk0
diskutil umountDisk /dev/disk0
gpt remove -i 4 /dev/disk0 # remove the partition starting at block 180000000
diskutil umountDisk /dev/disk0 # remove the partition starting at block 230000000
gpt remove -i 5 /dev/disk0

Depending on the partition type (HFSJ+ or CoreStorage) you may either use diskutil resizeVolume ... or diskutil cs resizeStack ... to expand your recovered OS X volume.




After accessing the remote Mac and inspecting the disk the final probable solution seems to be:

Remove the blocking partition

diskutil umountDisk /dev/disk0
gpt remove -i 2 /dev/disk0


Restore the old OS X partition table entry

diskutil umountDisk /dev/disk0
gpt add -b 409640 -i 2 -s 157173736 -t 53746F72-6167-11AA-AA11-00306543ECAC /dev/disk0


Restore the old recovery HD:

diskutil umountDisk /dev/disk0
gpt add -b 157583376 -i 5 -s 1269536 -t 426F6F74-0000-11AA-AA11-00306543ECAC /dev/disk0


The volume (encrypted with FileVault) had a proper volume structure, the superior disk structure was corrupted though. After backing up the volume externally the disk was repartitioned to one partition and the backup was restored.