Qualcomm chips and security for OEMs
If you’re familiar with programmable read-only memory (PROM) or one-time programmable non-volatile memory (OTP NVM) then understanding the concept of qfusing on Qualcomm MSM chips should be trivial.
For those who are not familiar, briefly speaking, Qualcomm uses OTP NVM for their security architecture in their modem chips. In layman’s terms, Qualcomm implemented a security protocol to disallow the phone’s software to be overwritten by a non-secure software. Non-secure software gives users the ability to root the device using the simple “adb root” command. This means anyone can just connect their phone to their computer and root it without using any third-party tricks/hacks.
Qfuses are implemented as an array of one-bit blocks that allows configuration of security features such as hashes or keys. All MSM chips have them built-in software side, but like I said above, it’s a one-way street. THERE IS NO GOING BACK when you blow the fuse. “Blowing” qfuses happens by placing a very specific value to the register, which applies physical current to the fuse. Once a qfuse is blown, each boot sequence becomes locked and only OFFICIAL secure (signed) bootloaders can be downloaded onto the device. Any other attempt will hard-brick the phone.
So is there a way to revert a Qfused device?
I analyzed some internal hardware data and code, and my conclusion was that it is IMPOSSIBLE. All the crucial values are stored in the QFPROM region, which is untoucable, even to the most senior engineers at our company. In the past, I know that some companies (Motorola) just blew the qfuse with some identifier to trick the boot-loader by invoking some ARM Assembly instruction so reverting the “blown” qfuse was as simple as exploiting the TrustZone with a simple SMC call. Not anymore!
The above nifty trick does not work for MSM89XX chips and further. Snapdragons have become extremely powerful in terms of security. Once a qfuse is blown, and the device reboots twice without the SMC calls, it’s impossible to revert the fuse. This can be a huge nuisance if an OEM engineer mistakenly overwrites non-secure software onto a test device that is already qfused. Thankfully, this accident does not happen often as most OEMs now check this during the device software download process. Non-secure software also should not be accessible to non-OEMs regardless unless it is explicitly for testing security features such as SELinux, so it’s a non-issue for regular users.
So how is this post even applicable to people? Qfuses are mainly applied by OEMs when distributing devices to OEM partners during the device certification process – it prevents OEM partners from intentionally downloading non-secure software onto the device, rooting the device and using the device maliciously (removing SELinux policy, altering system applications, sharing and selling company secrets, etc).
Lesson learned: As a product manager, I was also involved in partnership management. Certain carriers have accidentally bricked many devices, even though we explicitly told them not to download non-secure software onto certain devices. This motivated me to add a new feature to our “software download program.” I worked with the firmware, download, hardware and security team to add additional checks to make sure non-secure software cannot be download onto qfused devices.
Last thing to add: a regular user cannot qfuse a device. You need proprietary software to qfuse a device and it’s doubtful such program would be publicly available. Regardless, do not panic if your device is qfused (it’s likely your OEM did it). You will not have access to non-secure software anyway. If you do, then congratulations, you have beaten the OEM.
A tricky part about security is that sometimes, we need outside help. I remember one time we needed to root a secure device to debug an issue with SELinux. As an OEM, one would think we’d have internal tools that would allow us to root it with ease. However, this was closer to the final SW, which meant that all “exploits” (intentional and unintentional) were fully patched. We didn’t have an internal tool because we truly believed the device was not exploitable and there was no way for ANYONE to root it. In an emergency situation like this, we had to “consult” our experts at XDA to borrow a tool that allowed us to root the device using a memory buffer exploit that we were not aware of. This saved us tremendous amount of time and resource and we were able to verify what we needed in time to receive on-time technical approval.
Lesson learned #2: Finding exploits internally is not an easy task – our goal as an OEM should be to view our code-base as an outsider.