[Verizon Samsung Galaxy S III] Ralekdev:
I guess it might be helpful to explain why we can't just flash other devices' bootloaders.

Every bootloader image has 3 sections: code, signature, and a certificate chain. These are normal DER/ASN.1 certs (up to 3), nothing all that special except the first certificate has some extra properties. One of those properties is a hardware identifier for our specific model (as far as I know). So when the PBL is attempting to authenticate the SBL1, it compares that hardware id with it's own. If it doesn't match, it doesn't load the SBL1 and the PBL goes into error recovery mode. But say the hardware IDs were the same, now you have to consider whether the key in the PBL will be able to verify the certificates. If it can't, we're right back in the PBL error handler.

The signature section is 256 bytes that will decrypt to 0x0001FFFF, followed by 248 more 0xFF, and finally 0xFFFFFF00 as long as you haven't tampered with any part of the header, code section, or certain parts of the attestation certificate. Failing to decrypt correctly will once again land you in the PBL error handler.

Note the above steps are taken in every part of the PBL -> SBL1 -> SBL2 -> TZ -> RPM -> SBL3 -> ABOOT chain, so you can't just skip one or try to trick it.

Any of those reasons could be responsible for the brick. Those reasons are also why I'm not very optimistic for the developer edition phone, whenever it comes out. All they'd need to do was just change the hardware id or pbl key and we couldn't use it.

So say you did flash another device's bootchain and you're stuck with a "brick", what do you do?

Because Adam's device still turns on and registers as something to the computer, I think we can conclude that the emergency download feature has not been disabled. Otherwise, the device would just turn off as soon as it hit the error.

Normally, the phone tries to boot from SDC1, the internal card. In his case that's hosed, so it'll move to trying SDC3, the external card. So if my thinking is correct, if we format the external card to match the layout of the internal card (not the whole thing, you'd only need up to aboot to get odin capability back), then it would attempt a normal boot from the external card. You'd just have to have the partitions have the correct GPT guids, since that's how the loaders locate the next in the chain.

Another possible way to recover is through the QDL mode his phone is in now. https://www.codeaurora.org/patches/quic/gobi/Gobi3000/GobiAPI_2012-07-10-0919.tar.gz has some code for interacting with devices in QDL mode, however we need to find out the correct values for the eQDLImageType enum for our device (Core/QDLEnum.h). Currently it's using terminology from secboot2, whereas we're on secboot3. The correct values would most likely be found in the PBL, since that's what's running the QDL mode. We won't know if this method works completely until we can get ours hands on a dump of the PBL

That's proven to be quite tricky, and it may take a hardware method to get that dump.

I've tried using DM mode, but unfortunately samsung removed the all of the diagnostic commands that let you dump memory (DIAG_PEEKB_F and kin).

I then tried sending the DIAG_DLOAD_F command to switch it to DMSS mode, which didn't work because they made that command reboot the phone.

In DMSS mode I could have potentially uploaded some shellcode to dump the region. Arbitrary memory reads in DMSS mode looked restricted to certain regions, but the writes weren't, so I could have written shellcode to some unused ram segment, then there's a command to start execution at a specific address.

The PBL should be located at 0x00000000 according to the docs if anyone wants to give it a shot.

Apologies for the length and utter lack of formatting on this post, but I wanted to jot that down before heading to bed.