[AT&T Samsung Galaxy Note I717] SouL Shadow:
Ok, for the next generation of curious people, here's a (simplistic) closer look at how modern Qualcomm devices boot up.

This info is presented as a simple overview so more people understand how the system works and what is happening. It is far from complete and it's not exactly how it works. But for 99% of us, it's all we need to know.

Also, before anyone asks, my main source was google and some files found on XDA. DO NOT ASK ME FOR "???" I have nothing that you can't find on your own. In fact, most of the following can be found in E:V:A's MSM8960 thread. Also http://www.codeaurora.org contains a lot of info and source code (Gobi and Gobi 3000 source code will help to understand how download mode functions).​

Beginning with Secure Boot 3, the entire PBL is contained on the modem chip (earlier chips depended on the actual PBL being stored in a known location on the flash memory, like an MBR, with an extremely bare bones amount of executable code on processor). This newer design allows for security checking to be done, if enabled, on ANY off-chip program to be executed at boot time. THIS IS THE ONLY REASON, other than hardware failure, that a device becomes "HARD BRICKED". All boot files can be signed with a crypto key. This key is stored in a section of memory in/on the CPU called a QFuse. After writing to a QFuse, as it's name suggests, the fuse can be "blown". That is, a higher electric current is maintained long enough to break the physical connection. Once this connection is broken the QFuse can not be changed. If the security related fuse is blown than ONLY a signed boot file can be executed. The PBL is written to the chip at the factory by Qualcomm. The QFuses can then be written by the OEM. According to the spec, multiple keys can be stored in the QFuses (meaning there COULD be a master key from qualcomm in addition to vender supplied keys). Although it is unknown whether or not this is actually done.

Now, I don't know much about the actual security or cryptography, but here's the basic boot process from what I've pieced together:

PBL written by Qualcomm, can not be altered.

OEM chooses it's own key, writes it to QFuse, blows fuse.

OEM builds it's own SBL1, SBL2, SBL3, TZ and RPM along with it's own APPSBL (aboot, hboot, etc...)

OEM performs a hash of the file, like md5, sha1, sha256...

OEM uses it's key to encrypt the hash and attaches it to executable and writes to flash.

CPU powers on, runs hard coded PBL, and reads QFuses.

CPU checks any error messages in memory from a previous boot.

CPU then tries to load SBL1 in to ram from flash as pointed to by partition table.

CPU performs same hash and compares with decrypted data.

If check passes, code is executed.

If check fails OR flash is unreadable, PBL enters download mode.

In download mode, if there is an error message from a previous boot, it is automatically sent to the client. (Some people using qdloader.pl may have noticed this message)

In download mode a special executable (the .hex file) can be loaded in to ram

*** depending on OEM config, this hex can be loaded from usb AND/OR external sdcard

Now the hex is security checked exactly as SBL1 would.

If it passes, it's executed.

This hex file is a special program called the emergency downloader (or sometimes just the downloader).

It's only purpose is to download and write the partition table (partition0.bin) and secure boot loader partition data (contained in the .mbn) to the flash.

IF security check failed, an error message is set and device "warm" reboots.

The hex can only be sent ONCE per "cold" boot cycle.

Removing the battery (or using the similar OEM key combo) will "cold" boot the device, clearing the RAM.

Also, if download mode isn't successfully entered (using qpst or qdloader.pl) within a certain time limit, an error is set and the device "warm" reboots.

This error message memory is why the device sometimes shows up differently.
​

Of course this is only a simple outline of the Secure Boot 3 boot process. There is much more going on, but these are the basic steps that apply for bricked phones. I know less about Secure Boot 2 and earlier, but they follow a similar process and DON'T require a signed hex file. The Snapdragon S4 (msm8960 and others) was the start of the Secure Boot 3. The msm8660 was still using Secure Boot 2. So, if you want to know if your device is recoverable like this, then find out which chipset you have (msm????, apq????, ...) then find out what secure boot it uses. Google should answer this question easily. If it's Secure Boot 3 then most likely it requires signed files, which is still a dead end :(

misc. extra info:

There is of course no way to read a QFuse from QDL/qdload/qhsusb_dload until AFTER loading the HEX... (I've heard of some vender specific programs included with their android system (LG Optimus?) that can read qfuses, but that is NOT a standard)

The "cookie not received" error is simply QPST's way of reporting that it didn't get the "magic" text string from the phone/device. This is because the HEX either could not be uploaded or it could not be executed (either wrong hex for that CPU or it's not signed with the proper key hard coding into that device (OEM vender specific))

I'm sorry to say that I too have moved on to other projects. There just isn't enough free time anymore.