[Verizon LG V10] emdroidle:
There is a great deal of careless language tossed around, but for development you need to be careful of what exactly technical terms mean. Due to this, let me mention some related terms which you need to be careful when using.

authentication/verification refers to verifying some data has not been modified. There are several cryptographic constructs to do this, but this is their goal. Most of the time THESE are the terms you should be using and not the terms below which have specific meanings and are alas far too often misused.

[cryptographic] hash can accomplish the goal of authentication/verification. If you get a hash from a reliable source and something matches the hash you can be pretty confident you've got what was being referred to. There are many hashes MD5, SHA1, SHA256, SHA512, Keccak and others. While still difficult to break MD5 and SHA1 are now short enough to be broken with considerable effort.

HMAC/keyed-hashes can also accomplish the goal of authentication/verification, but also have some properties of public-key signatures. The crucial distinction is as long as the key is kept secret, the HMAC cannot be readily modified or verified.

signatures also accomplish the goal of authentication/verification, but have some neat properties. The key has two portions, the public portion and the private portion. Signatures are generated with the private portion, which is kept secret, but only the public portion is needed to verify a signature. These are a really neat construct of modern cryptography, but they're slow. Just because a portion is "public" doesn't mean it is widely distributed. If you're using the term "signature" THIS is what you're referring to, but unless you're careful what you should be saying is "thing is/was verified".

Okay, with that background out of the way onto what is likely actually being done on Qualcomm phones. The boot stages of Qualcomm phones have several stages which are on several slices/partitions of the on-board flash:

"sbl1" I suspect this stands for "Second Boot Loader 1", this is the first on-flash bootloader stage. From observation I'm pretty sure there are 2 possible verification strategies which may have been used. First, it is possible a keyed-hash is being used. With this the key is stored in ROM on the 808 chip where we're not likely to retrieve it without difficulty (you might obtain it by monitoring the contents of DRAM in real-time, but does anyone here have the hardware to do that?). Second, it is possible a signature is being used. This poses the exact same issues for us as the former, but in addition we wouldn't be able to sign anything without the private key which wouldn't be in ROM at all. There are also numerous potential hybrid strategies, but they all share these general features. One strategy that I can confidently rule out is this area is not being verified with an ordinary hash. The reasoning is simple, every KDZ file rewrites the sbl1 area, LG would be unable to do this if it was merely verified by hash.

One crucial point here is it is unlikely Qualcomm makes too many variants of the 808. While mask ROM isn't too difficult to change, it is still very expensive. I could believe Qualcomm might make one variant for LG which has LG's key on-board, it is quite likely all V10s share the exact same baseline signing key. It is entirely likely the baseline key could be shared between many/all clients of Qualcomm since changing the key is too expensive. This is only likely to change if Qualcomm starts placing large numbers of fuse/anti-fuse elements on their devices (large enough to distinguish every type of device from every other, say 32 bits minimum).

"pmic"/"tz"/"sdi"/"hyp"/"rpm"/"aboot" these are the later bootloader stages. I'm pretty sure "hyp" is short for "hypervisor", which simulates the processor chip being divided into a portion used by the cell modem and the portion used by Android. As with sbl1 I can narrow it down to 2 possible verification strategies being used. First, signatures could be used. Simply need to have the key embedded in sbl1, once sbl1 is verified by the on-chip ROM, that key can be trusted to verify the following stages. Second, hashes would work fine for this process. While the hashes would be visible in the sbl1 area of KDZ files, unless you have the ability of modifying the sbl1 area without making the verification of the sbl1 area fail, knowing the hashes doesn't do you any good unless you can reverse them (which is extremely hard). This would explain why LG always rewrites the sbl1 area when the OS on their phones is updated (and why KDZ files need to contain the data to replace the sbl1 area), they're replacing the hashes contained in the sbl1 area.

"raw_resources" this appears to be a pseudo bootloader area. From looking at the data it is pretty obviously images and text used by the bootloader. Might well not be verified at all since modifying it isn't supposed to allow you to make the phone do interesting things. OTOH it may be verified since LG doesn't want to expose themselves to buffer overruns or the various other sorts of mischief you can do by modifying "harmless" data.

So, what does this all mean? Well, this means that "sbl1", "pmic", "tz", "sdi", "hyp", "rpm", "aboot", and potentially "raw_resources" are all permanently married together. If you replace one of them with the version from another V10 device, it won't work, yet this could allow you to replace all of them with the version from another V10 device. This could explain how there are not one, but two reports of being able to successfully flash the "wrong" KDZ to another V10, yet still be able to recover. This has also been proposed as a strategy to unlock the bootloader of other LG V10s.

There is one thing to be highly cautious of with trying this strategy on the Verizon VS990 devices. We don't know how the various bootloader stages find each other. Linux and I are able to find them since they're marked out in the GPT in the on-board flash. The bootloader stages though might well instead have the block numbers of the other bootloader stages hard-coded. This could be utilized as a strategy to discourage trying to modify the phones or merely make the code simpler. Unlike other V10s, the VS990 devices have "raw_resources" located on different block numbers. As such if you installed a H901 KDZ file and then tried to reinstall the VS990 bootloader after following the unlock procedure, the device may brick. There is also an "operatorlogging" area which overlaps the "factory" area, if this area gets directly written by the modem this could be problematic for custom firmwares. Alternatively if all the bootloaders are unlocked in the same way, you could go back to the pure VS990 bootloader and still be unlocked.

One extra tidbit from the GPTs. Most V10s have about 1.2GB allocated to /cache, but the VS990 only has 400MB there. I'm forced to wonder if this lowers the performance of the VS990 or encourages it to use more data, even though this gives a bit more space in /data.

This is the main reasoning behind my notes on GitHub about whether given areas should be taken from the original device or the H901.

This is one case where you're not being careful about terminology and it matters. I suspect there could be a signature in sbl1, but the rest is verified with hashes. As long as you keep all portions/versions of the bootloader together as a group, once the bootloader is unlocked you could be able to replace the kernel and /system freely on another device.

Yeah, you're now the second report of this happening. This doesn't mean you couldn't replace all of the bootloader stages together, but merely swapping out aboot isn't going to work.

In other news, if you'd grabbed the data before bricking it there is a report of a method to de-brick a V10 if you root and gathered the right data from the device beforehand. I'd love to get my hands on a spare V10 which I could brick without worry too much about losing a spare.

UPDATE, Nov 23: Looked at the GPT for a Sprint V10 and it looks like bad news. The Sprint V10 also has "eri" and "operatorlogging" areas. This suggests these two areas are in fact required for CDMA phones and they'll need to be left untouched or restored in order to keep CDMA functionality operational. This then suggests questions I was asking above are crucial. How do the various bootloader areas locate each other? If they locate each other by the entries in the GPT then this approach still holds hope, otherwise the H901 KDZ approach is hopeless.

Could be install H901 KDZ, unlock bootloader, restore VS990 GPT, restore other slices. Otherwise the best hope is figuring out how aboot verifies boot and causing it to accept anything. There is a bit of hope that flashing the H901 KDZ, unlocking, and then going back to a VS990 KDZ might work, but this would rely on the unlock mechanisms being the same and I'm doubtful that is the case.

The approach does seem quite likely for all of the GSM V10s (rather more similar layout so fewer problems).