[Verizon Galaxy Note 3 Q&A, Help & Troubleshooting] bftb0:
If you unlocked your bootloader using the "standard method" then the "debrick" image you created on the SD card has a backup of literally every partition EXCEPT the ones that you would normally flash with Odin (or a ROM, e.g. boot, system, userdata, cache etc).

The reason that that unlocking method created a debrick image is so that people could save it so they would have it for emergencies. Such as the one you created.

Even the PIT data is included in a hidden partition inside the debrick image. But having a PIT file only allows you to re-partition flash memory, which you don't need; it's partitioned already. Re-writing the PIT is not going to magically recreate data inside those partitions that you erased.

Here's the bottom line: factory images, just like ROM files have NEVER had 100% of the partitions needed to restore the phone back to working condition. So there's darn good reasons to have backups or avoid wiping all of memory.

I think that [MENTION=5868929]hsbadr[/MENTION] had posted some debrick images taken during older ROM releases (N* series, I think) on his AFH (androidfilehost.com) site. Whether or not substituting some subset of those partitions (e.g. efs, persist, etc) onto your device will work correctly or not, but it's certainly worth a try at this point.

Skills you need to learn: figuring out byte offsets from the GPT partition table at the beginning of the debrick file to get the partition offsets in the "debrick" blob, and "dd" command options for grabbing exactly the byte ranges you want out of a single large blob file containing many partitions. (e.g. "skip=", "bs=", "count=").

Note also that the Unix GPT partitioning tools "gdisk" will let you examine the Primary GPT (UEFI?) partition table in the debrick image even though the secondary GPT is not present. That way, you can figure out the exact length and initial offset of partitions that you want to copy out of the debrick image into your device. (The reason for the missing secondary GPT is that the GPT/UEFI partition table indicates the presence of very large partitions such as /system, /cache, and /userdata, and the secondary GPT is always near the very end of the disk. Because the "debrick" image is literally a byte-for-byte copy of only the first 256 MB of the mmcblk0 flash device, there is no secondary GPT some 32GB "later" then the beginning of the debrick image.

red indicates partitions in debrick not appearing in Odin factory Images

$ gdisk /tmp/mj7-debrick-unlocked.img

Command (? for help): p
Disk /tmp/mj7-debrick-unlocked.img: 524288 sectors, 256.0 MiB
Logical sector size: 512 bytes
Disk identifier (GUID): NNNNNNNN-NNNN-NNNN-NNNN-NNNNNNNNNNNN
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 61071326
Partitions will be aligned on 2-sector boundaries
Total free space is 8158 sectors (4.0 MiB)

Number Start (sector) End (sector) Size Code Name
1 8192 38911 15.0 MiB 8300 apnhlos
2 38912 156543 57.4 MiB 0700 modem
3 156544 157567 512.0 KiB FFFF sbl1
4 157568 157631 32.0 KiB FFFF dbi
5 157632 157695 32.0 KiB FFFF ddr
6 157696 161791 2.0 MiB FFFF aboot
7 161792 162815 512.0 KiB FFFF rpm
8 162816 163839 512.0 KiB FFFF tz
[color=red] 9 163840 184319 10.0 MiB FFFF pad
10 184320 204799 10.0 MiB 8300 param
11 204800 233471 14.0 MiB 8300 efs
12 233472 239615 3.0 MiB FFFF modemst1
13 239616 245759 3.0 MiB FFFF modemst2[/color]
14 245760 268287 11.0 MiB FFFF boot
15 268288 294911 13.0 MiB FFFF recovery
[color=red] 16 294912 321535 13.0 MiB FFFF fota
17 321536 335853 7.0 MiB 8300 backup
18 335854 341997 3.0 MiB FFFF fsg
19 341998 341999 1024 bytes FFFF fsc
20 342000 342015 8.0 KiB FFFF ssd
21 342016 358399 8.0 MiB 8300 persist
22 358400 376831 9.0 MiB 8300 persdata [/color]
--------- debrick image ends ~72 MB into the start of the system partition --------
23 376832 5931007 2.6 GiB 8300 system
24 5931008 8028159 1024.0 MiB 8300 cache
25 8028160 61071326 25.3 GiB 8300 userdata

I would start by restoring as few partitions are necessary e.g. "efs" and "persist" before I would bother with the others.

Example using data given above. (You should check your own work.)

efs partition: blocks 204800 to 233471 in debrick image, blocks are 512 bytes.

check length:

(233471-204800+1)*512 = 14680064

14680064 / (1024 * 1024) = 14 O.K.

so:

# dd if=/sdcard/debrick.img bs=512 skip=204800 count=28672 of=/dev/block/platform/msm_sdcc.1/by-name/efs

(or get clever and faster)

# dd if=/sdcard/debrick.img bs=1048576 skip=100 count=14 of=/dev/block/platform/msm_sdcc.1/by-name/efs

You should be pretty sure what you are doing with byte offset calculations with the "dd" command. Fortunately you are relying on the partitioning already present on the output side of things, so the worst that you could do is write misaligned garbage to a partition. So long as you don't do something incredibly stupid like overwrite a bootloader partition you should be OK.

cheers