This is version one of this document. I know the formatting is not great, and I will be fixing that over time. Also, there is some pieces that are missing, and some of it may not entirely be correct yet. I will try to make note if I am unsure.
I am composing this because I couldn't find a good resource that explained all of this in one place.
So after bricking my phones (G4, V10, V20 -- sometimes deliberately) many times, I thought I would share a little information. I gathered this information by:
* accident
* decompiling the various pieces of the firmware
* documentation found on the net
* reading source code
First some background on the boot procedure for SD8XX based phones (SD800, 801, 808, 810, 820).
It goes like this:
CPU (Qfuses: ARB / KEY (SHA1?) / TRUSTED_BOOT, FEAT_A, FEAT_B) <--> PBL <--> XBL (SBL1) -> ABOOT -> BOOT
The XBL (Seconday Boot Loader) is very similar to UEFI on a PC. It loads a lot of modules (firmware) that make the devices on the phone work, and allow it to boot. The XBL has an RSA cert that it uses to verify most of the modules that it loads.
The XBL loads (and verifies - does it also check ARB per module?):
(RSA) - aboot (Applications Boot)
(RSA) - apdp -- ??
(RSA) - cmnlib (Common Libraries) -- These are just shared libraries that the other parts of the firmware use
(RSA) - cmnlib64 (Common Libraries 64bit) -- Same as above, but for the 64bit components.
(RSA) - devcfg (Device Configuration)
(RSA) - hyp (Hypervisor) -- this is what runs the NON-HLOS, and I believe is one of the first things that XBL loads.
(RSA) - keymaster -- This does several things, but one of the things it handles is the fingerprint sensor
modem -- This is your modem firmware.
(RSA) - msadp -- ??
persist -- ??
(RSA) - pmic -- ??
raw_resources
rct -- ??
(RSA) - rpm -- Resource and Power Management
sec -- ??
(RSA) - tz -- TrustZone You can thank this guy for handling the security of the QSEE (Qualcomm Secure Execution Environment). It checks the RSA certs for the images that are labled above with (RSA).
The XBL only loads these if:
* The phone is booting to the HLOS (Android)
* The phone is booting to recovery (No idea why it would need them in recovery, but it does)
If you are going into download mode, or fastboot mode, they do not get loaded.
The PBL is located in ROM -- true Read Only Memory. There is no changing it unless you physically unsolder the chip.
When you power on the phone, the PBL gets loaded, and does a couple of things, but the one we are concerned with is it loading the SBL (Secondary Boot Loader, or XBL on the V20).
It verifies the integrity of the XBL by reading a key from a qfuse on the CPU. If it matches, it continues the boot process. It also checks the ARB (Anti-RollBack) version qfuse. If the ARB version of the XBL is greater than the ARB version currently blown into the qfuse, it will blow the bits needed to match the current ARB of the XBL that it is trying to load. When a Qfuse is blown, it can't be "unblown", so you are stuck with that ARB version now.
When a Qualcomm chip ships from the factory, none of the Qfuses are blown -- the chip is fully unlocked. It is then up to the OEM to decide what features it wants to have enabled, as well as should trusted boot be enabled. As far as I know, EVERY OEM blows the TRUSTED_BOOT qfuse on production phones, which means that the PBL will verify the SBL (XBL). This means that the SBL (XBL) must be signed. This signature is also in the CPU via blown qfuses. I don't believe that there is any room to modify the SHA1 signature once it has been blown into the CPU -- but I have nothing to back this up. That means that as long as you ONLY use an XBL that has the same signature as what is blown into your CPU -- AND -- you don't try to run an XBL with a LOWER ARB version, that your phone will boot. Doesn't mean it is going to work, but it will at least boot to download mode if you haven't messed up aboot or laf (we will get to that).
If the XBL is corrupt, or wasn't signed, or was signed but with a different key, or has an ARB version that is less than what is in the CPU, the CPU will go into HS-USB QDLoader 9008 mode, and your phone is a brick. QDLoader mode is built into the (CPU? PBL?) so that the boot loader can be fixed. If you have the right tools (QPST) AND a signed firehose, then you can flash the proper firmware back onto your phone. Good luck finding a signed firehose -- they leak from OEMs very rarely here recently. In the past (when they were using eMMC), before UFS, you could boot from an SD card and recover your phone. The V20 uses a UFS chip that presents itself as multiple LUNs, and does not have a UFS card slot -- so I do not believe it is possible to boot from SD card anymore. This is something that is still being investigated however.
So, lets say all is good -- PBL verified the XBL, and said it was OK. Now it is time for the XBL to load ABOOT.
Once again, there is verification. This time the XBL verifies ABOOT with its own RSA key. If ABOOT is OK, then it loads. At this point, you will have download mode, and at least you can recover (if you have a KDZ). No matter what -- NEVER mess with XBL or ABOOT unless you absolutely want a brick. If ABOOT is corrupt or invalid in some way, then the CPU goes into QD_LOADER (9008) mode.
So now we have ABOOT loaded. ABOOT does a lot of things. Directly, it provides fastboot mode, indirectly, it provides download mode by booting laf. In order to have download, you have to have a working laf. LAF is just a kernel with an initrd that runs lafd (more on that later). ABOOT also allows you to boot recovery. Again, recovery is just a kernel with an initrd.
ABOOT loads (all just kernels with an appropriate initrd:
boot
laf (download mode)
recovery
depending on the mode it is in.
What we care about most is boot (that is the kernel, that loads the system partition). If you don't have an unlocked boot loader, and you have modified your kernel, the boot will fail, since aboot verifies the signature. This will usually just result in a boot loop, but don't count on that. The good news is that a corrupt boot or recovery doesn't prevent you from getting into download mode -- better have a KDZ though.
So to sum up. If you don't want to brick your phone so bad that it has to be replaced or repaired:
* Don't flash an XBL that has a lower ARB version
* Don't flash an XBL that has a qfuse key that is not in your CPU (cross model flashing -- make SURE the model you are flashing uses the same key)
* Don't flash an aboot that wasn't signed with the RSA cert that is in your XBL
* Don't nuke your laf partition AND your recovery partition at the same time.
More to come -- especially better formatting.
EDIT1: The PBL is not a separate chip, it is in the Qualcomm CPU (QFPROM) -- This is also where the qfuses are located. The thing is huge, there is more than enough space that a vendor could update the key (it is a 2048 bit RSA key -- NOT an SHA1 hash), but more importantly it is 32k. Part of QFPROM is the PBL, the rest is for the vendor key(s?), and then there are feature banks. For example, can the boot loader be unlocked can be checked via a feature fuse.
Camera features, modem features, a lot of things can be determined by what the OEM wants to blow. One of the important things that is determined, is UART on or off. On the v20, it appears this is blown, so there is no way to get a console.
What is interesting is that there is a pin for voltage to write to the QFPROM. That pin can either have voltage, or be shorted to ground. Now, here is a big question, what if that pin was shorted to ground? Would the phone continue to boot in the event that a request to write to QFPROM happened (IE: booting an XBL with a greater ARB). If it would, then get a new phone with ARB 0, ground that pin, and they could never update the key, or ARB version. But if the OEM did update the RSA key used to sign firmware, it would no longer match the key in the CPU -- so it would need to be reversible.
QFPROM searches all available IO paths for a valid SBL. If that SBL has support to continue booting on the path that it was found, then it will.
This explains why on UFS based phones like the V20, you can get some life out of it if you have a properly formatted SD card, and are in QDLoader mode. The QFPROM reads the XBL, but the XBL has no clue where to go from there. There is no support for finding the other parts of the firmware via SD card -- it MUST have multiple LUNs. On older phones with eMMC, when the SBL was loaded, the SD card was initialized as mmcblk0 and the SBL couldn't tell the difference between it and the eMMC. So, it is now verified that there is no way out of 9008 mode if your phone has UFS except for the signed firehose route.
So what is a firehose? It is just a SBL that is booted via USB, with very limited functionality. The Qualcomm CPU still verifies its integrity (which is why it must be signed if you want it to work). Note1: Does the firehose check ARB?
EDIT2: So it appears that there are several toggles in QFPROM to enable / disable debug mode. Are they all blown? Can the phone be put back into debug mode? In debug mode signature verification is disabled -- as long as SBL is valid, it will load it and run it. This would give us the chance to "crack" the XBL so that it no longer uses its RSA to verify the rest of the boot chain.
A portion of the QFPROM address space is mapped into the HLOS address space. You can view certain portions from a running kernel. I will make a separate update on that. Technically you should be able to write to them as well. This sounds like a recipe for me bricking another phone! W00T!!
EDIT3: It would appear that the partition layout is in QFPROM. Again, this just backs up the fact that you will never be able to boot from SD card. So, how do the DragonBoards boot from SD card? It is my theory that they have both partition layouts in their QFPROM. So, next question, if that is the case, could we write an SD card partition layout into QFPROM? Yea, that is probably WAY out there
-- Brian
I am composing this because I couldn't find a good resource that explained all of this in one place.
So after bricking my phones (G4, V10, V20 -- sometimes deliberately) many times, I thought I would share a little information. I gathered this information by:
* accident
* decompiling the various pieces of the firmware
* documentation found on the net
* reading source code
First some background on the boot procedure for SD8XX based phones (SD800, 801, 808, 810, 820).
It goes like this:
CPU (Qfuses: ARB / KEY (SHA1?) / TRUSTED_BOOT, FEAT_A, FEAT_B) <--> PBL <--> XBL (SBL1) -> ABOOT -> BOOT
The XBL (Seconday Boot Loader) is very similar to UEFI on a PC. It loads a lot of modules (firmware) that make the devices on the phone work, and allow it to boot. The XBL has an RSA cert that it uses to verify most of the modules that it loads.
The XBL loads (and verifies - does it also check ARB per module?):
(RSA) - aboot (Applications Boot)
(RSA) - apdp -- ??
(RSA) - cmnlib (Common Libraries) -- These are just shared libraries that the other parts of the firmware use
(RSA) - cmnlib64 (Common Libraries 64bit) -- Same as above, but for the 64bit components.
(RSA) - devcfg (Device Configuration)
(RSA) - hyp (Hypervisor) -- this is what runs the NON-HLOS, and I believe is one of the first things that XBL loads.
(RSA) - keymaster -- This does several things, but one of the things it handles is the fingerprint sensor
modem -- This is your modem firmware.
(RSA) - msadp -- ??
persist -- ??
(RSA) - pmic -- ??
raw_resources
rct -- ??
(RSA) - rpm -- Resource and Power Management
sec -- ??
(RSA) - tz -- TrustZone You can thank this guy for handling the security of the QSEE (Qualcomm Secure Execution Environment). It checks the RSA certs for the images that are labled above with (RSA).
The XBL only loads these if:
* The phone is booting to the HLOS (Android)
* The phone is booting to recovery (No idea why it would need them in recovery, but it does)
If you are going into download mode, or fastboot mode, they do not get loaded.
The PBL is located in ROM -- true Read Only Memory. There is no changing it unless you physically unsolder the chip.
When you power on the phone, the PBL gets loaded, and does a couple of things, but the one we are concerned with is it loading the SBL (Secondary Boot Loader, or XBL on the V20).
It verifies the integrity of the XBL by reading a key from a qfuse on the CPU. If it matches, it continues the boot process. It also checks the ARB (Anti-RollBack) version qfuse. If the ARB version of the XBL is greater than the ARB version currently blown into the qfuse, it will blow the bits needed to match the current ARB of the XBL that it is trying to load. When a Qfuse is blown, it can't be "unblown", so you are stuck with that ARB version now.
When a Qualcomm chip ships from the factory, none of the Qfuses are blown -- the chip is fully unlocked. It is then up to the OEM to decide what features it wants to have enabled, as well as should trusted boot be enabled. As far as I know, EVERY OEM blows the TRUSTED_BOOT qfuse on production phones, which means that the PBL will verify the SBL (XBL). This means that the SBL (XBL) must be signed. This signature is also in the CPU via blown qfuses. I don't believe that there is any room to modify the SHA1 signature once it has been blown into the CPU -- but I have nothing to back this up. That means that as long as you ONLY use an XBL that has the same signature as what is blown into your CPU -- AND -- you don't try to run an XBL with a LOWER ARB version, that your phone will boot. Doesn't mean it is going to work, but it will at least boot to download mode if you haven't messed up aboot or laf (we will get to that).
If the XBL is corrupt, or wasn't signed, or was signed but with a different key, or has an ARB version that is less than what is in the CPU, the CPU will go into HS-USB QDLoader 9008 mode, and your phone is a brick. QDLoader mode is built into the (CPU? PBL?) so that the boot loader can be fixed. If you have the right tools (QPST) AND a signed firehose, then you can flash the proper firmware back onto your phone. Good luck finding a signed firehose -- they leak from OEMs very rarely here recently. In the past (when they were using eMMC), before UFS, you could boot from an SD card and recover your phone. The V20 uses a UFS chip that presents itself as multiple LUNs, and does not have a UFS card slot -- so I do not believe it is possible to boot from SD card anymore. This is something that is still being investigated however.
So, lets say all is good -- PBL verified the XBL, and said it was OK. Now it is time for the XBL to load ABOOT.
Once again, there is verification. This time the XBL verifies ABOOT with its own RSA key. If ABOOT is OK, then it loads. At this point, you will have download mode, and at least you can recover (if you have a KDZ). No matter what -- NEVER mess with XBL or ABOOT unless you absolutely want a brick. If ABOOT is corrupt or invalid in some way, then the CPU goes into QD_LOADER (9008) mode.
So now we have ABOOT loaded. ABOOT does a lot of things. Directly, it provides fastboot mode, indirectly, it provides download mode by booting laf. In order to have download, you have to have a working laf. LAF is just a kernel with an initrd that runs lafd (more on that later). ABOOT also allows you to boot recovery. Again, recovery is just a kernel with an initrd.
ABOOT loads (all just kernels with an appropriate initrd:
boot
laf (download mode)
recovery
depending on the mode it is in.
What we care about most is boot (that is the kernel, that loads the system partition). If you don't have an unlocked boot loader, and you have modified your kernel, the boot will fail, since aboot verifies the signature. This will usually just result in a boot loop, but don't count on that. The good news is that a corrupt boot or recovery doesn't prevent you from getting into download mode -- better have a KDZ though.
So to sum up. If you don't want to brick your phone so bad that it has to be replaced or repaired:
* Don't flash an XBL that has a lower ARB version
* Don't flash an XBL that has a qfuse key that is not in your CPU (cross model flashing -- make SURE the model you are flashing uses the same key)
* Don't flash an aboot that wasn't signed with the RSA cert that is in your XBL
* Don't nuke your laf partition AND your recovery partition at the same time.
More to come -- especially better formatting.
EDIT1: The PBL is not a separate chip, it is in the Qualcomm CPU (QFPROM) -- This is also where the qfuses are located. The thing is huge, there is more than enough space that a vendor could update the key (it is a 2048 bit RSA key -- NOT an SHA1 hash), but more importantly it is 32k. Part of QFPROM is the PBL, the rest is for the vendor key(s?), and then there are feature banks. For example, can the boot loader be unlocked can be checked via a feature fuse.
Camera features, modem features, a lot of things can be determined by what the OEM wants to blow. One of the important things that is determined, is UART on or off. On the v20, it appears this is blown, so there is no way to get a console.
What is interesting is that there is a pin for voltage to write to the QFPROM. That pin can either have voltage, or be shorted to ground. Now, here is a big question, what if that pin was shorted to ground? Would the phone continue to boot in the event that a request to write to QFPROM happened (IE: booting an XBL with a greater ARB). If it would, then get a new phone with ARB 0, ground that pin, and they could never update the key, or ARB version. But if the OEM did update the RSA key used to sign firmware, it would no longer match the key in the CPU -- so it would need to be reversible.
QFPROM searches all available IO paths for a valid SBL. If that SBL has support to continue booting on the path that it was found, then it will.
This explains why on UFS based phones like the V20, you can get some life out of it if you have a properly formatted SD card, and are in QDLoader mode. The QFPROM reads the XBL, but the XBL has no clue where to go from there. There is no support for finding the other parts of the firmware via SD card -- it MUST have multiple LUNs. On older phones with eMMC, when the SBL was loaded, the SD card was initialized as mmcblk0 and the SBL couldn't tell the difference between it and the eMMC. So, it is now verified that there is no way out of 9008 mode if your phone has UFS except for the signed firehose route.
So what is a firehose? It is just a SBL that is booted via USB, with very limited functionality. The Qualcomm CPU still verifies its integrity (which is why it must be signed if you want it to work). Note1: Does the firehose check ARB?
EDIT2: So it appears that there are several toggles in QFPROM to enable / disable debug mode. Are they all blown? Can the phone be put back into debug mode? In debug mode signature verification is disabled -- as long as SBL is valid, it will load it and run it. This would give us the chance to "crack" the XBL so that it no longer uses its RSA to verify the rest of the boot chain.
A portion of the QFPROM address space is mapped into the HLOS address space. You can view certain portions from a running kernel. I will make a separate update on that. Technically you should be able to write to them as well. This sounds like a recipe for me bricking another phone! W00T!!
EDIT3: It would appear that the partition layout is in QFPROM. Again, this just backs up the fact that you will never be able to boot from SD card. So, how do the DragonBoards boot from SD card? It is my theory that they have both partition layouts in their QFPROM. So, next question, if that is the case, could we write an SD card partition layout into QFPROM? Yea, that is probably WAY out there
-- Brian
Last edited:
