APFS partition disappeared after creating hybrid MBR

After trying to create hybrid MBR for dual-booting Windows in UEFI and BIOS with gdisk, main APFS partition (container) disappeared, leaving empty space in GPT partition table. It's only possible to see with sudo gpt -r show /dev/disk1 (space from 409640 to 732437176).

      start       size  index  contents
          0          1         PMBR
          1          1         Pri GPT header
          2         32         Pri GPT table
         34          6         
         40     409600      1  GPT part - C12A7328-F81F-11D2-BA4B-00A0C93EC93B
     409640  732027536         
  732437176     195912      2  GPT part - EBD0A0A2-B9E5-4433-87C0-68B6B72699C7
  732633088      32768      3  GPT part - E3C9E316-0B5C-4DB8-817D-F92DF00215AE
  732665856  244107264      4  GPT part - EBD0A0A2-B9E5-4433-87C0-68B6B72699C7
  976773120         15         
  976773135         32         Sec GPT table
  976773167          1         Sec GPT header

Disk Utility and gdisk don't show this empty space at all. It's also impossible to repair partition structure with Disk Utility. How to recover missing APFS container? Hex dump below.

1+0 records in
1+0 records out
0000000 55 83 b6 a3 d0 9d ef aa 01 00 00 00 00 00 00 00
0000010 f8 cc 00 00 00 00 00 00 01 00 00 80 00 00 00 00
0000020 4e 58 53 42 00 10 00 00 52 3b 74 05 00 00 00 00
0000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0000040 02 00 00 00 00 00 00 00 f1 c2 c7 d5 be fe 4d 6c
0000050 a8 5a c1 d2 1e 5e 2b d4 77 68 02 00 00 00 00 00
0000060 f9 cc 00 00 00 00 00 00 18 01 00 00 2c 6c 00 00
0000070 ec a3 04 00 00 00 00 00 c0 16 04 00 00 00 00 00
0000080 88 00 00 00 19 0d 00 00 86 00 00 00 02 00 00 00
0000090 06 0d 00 00 13 00 00 00 3f 67 02 00 00 00 00 00
00000a0 66 bb 0b 00 00 00 00 00 01 04 00 00 00 00 00 00
00000b0 00 00 00 00 64 00 00 00 02 04 00 00 00 00 00 00
00000c0 10 04 00 00 00 00 00 00 12 04 00 00 00 00 00 00
00000d0 be a4 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
*
0000200

You can simply re-add the partition with gpt "in the empty space". The problem here is: the APFS container partition might have been smaller than the now available free space.

The good news is: the (former) size of the container is stored in the APFS superblock which shouldn't have been modified by creating a hybrid MBR. The superblock is the first block of an APFS container - here probably block 409640 (which is the 409641th block of your SSD) if the default Apple partition scheme was used initially.

• boot to a full-fledged system (ideally 10.13 but older systems should also work with the downside that you can't verify the container with fsck_apfs afterwards)
• get the partition list with diskutil list. (in the example below I assume the device identifier is disk1)
• Unmount the SSD: diskutil umountDisk disk1

• hexdump block 409640 of the SSD:

  sudo dd if=/dev/disk1 skip=409640 bs=512 count=1 | hexdump
  

  which results in something like this (example only):

  1+0 records in
  1+0 records out
  0000000 4a 2e 4c 58 2c 73 22 1d 01 00 00 00 00 00 00 00
  0000010 ac 01 00 00 00 00 00 00 01 00 00 80 00 00 00 00
  0000020 4e 58 53 42 00 10 00 00 f6 37 ff 00 00 00 00 00
  0000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0000040 02 00 00 00 00 00 00 00 d1 67 7e 03 33 23 42 a5
  0000050 a8 da 96 fc 12 ae de 21 18 04 00 00 00 00 00 00
  0000060 ad 01 00 00 00 00 00 00 18 01 00 00 18 6c 00 00
  0000070 01 00 00 00 00 00 00 00 19 01 00 00 00 00 00 00
  0000080 10 00 00 00 80 07 00 00 0e 00 00 00 02 00 00 00
  0000090 7b 07 00 00 05 00 00 00 00 04 00 00 00 00 00 00
  00000a0 07 fd 03 00 00 00 00 00 01 04 00 00 00 00 00 00
  00000b0 00 00 00 00 64 00 00 00 02 04 00 00 00 00 00 00
  00000c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  *
  0000200
  

  The relevant line is 0x020: 4e 58 53 42 00 10 00 00 f6 37 ff 00 00 00 00 00

  • 4e 58 53 42 (NXSB) is the APFS magic block (Offset: 0x20 Type: char[4])
  • 00 10 00 00 is the block size (Offset: 0x24 Type: Uint32). After reverting the byte order and converting it to decimal this is 4096 Byte which is the default size for APFS containers.

  • f6 37 ff 00 00 00 00 00 is the number of blocks in the container (Offset: 0x28 Type: Uint64)

    to convert it to a decimal, revert the byte order f6 37 ff 00 00 00 00 00-> 00 00 00 00 00 ff 37 f6 and enter it in a converter. The number of 4k blocks is here 16,726,006 and the final size 16,726,006 x 4096 Byte = 68,509,720,576 Byte. In 512 Byte blocks that's 133,808,048 blocks.

• Check the result for plausibility. In your case the number of 512 Byte blocks should be equal to 732027536 or slightly less.

• Now add the partition with gpt:

  sudo gpt add -i 5 -b 409640 -s 512b_block_number -t 7C3457EF-0000-11AA-AA11-00306543ECAC /dev/disk1
  

  or in your case probably:

  sudo gpt add -i 5 -b 409640 -s 732027536 -t 7C3457EF-0000-11AA-AA11-00306543ECAC /dev/disk1
  

• Verify the disk: sudo fsck_apfs /dev/disk1. If you are urged to boot from the "restored" APFS container to verify it because your system on the other boot drive is macOS 10.12 or less use something like sudo fsck_apfs -nl /dev/disk1s2. If you get a warning like "warning: Overallocation Detected on Main device: (.....+1) bitmap address (.....)" you can probably ignore it as long as the volume /dev/disk1s2 appears to be OK.