Exploiting Qualcomm EDL Programmers (1): Gaining Access & PBL Internals
By Roee Hay (@roeehay) & Noam Hadad
January 22, 2018
* QPSIIR-909, ALEPH-2017029, CVE-2017-13174, CVE-2017-5947
There are many guides across the Internet for ‘unbricking’ Qualcomm-based mobile devices. All of these guides make use of Emergency Download Mode (EDL), an alternate boot-mode of the Qualcomm Boot ROM (Primary Bootloader). To make any use of this mode, users must get hold of OEM-signed programmers, which seem to be publicly available for various such devices. While the reason of their public availability is unknown, our best guess is that these programmers are often leaked from OEM device repair labs. Some OEMs (e.g. Xiaomi) also publish them on their official forums. […] In this 5-part blog post we discuss the security implications of the leaked programmers. The first part presents some internals of the PBL, EDL, Qualcomm Sahara and programmers, focusing on Firehose. In Part 2, we discuss storage-based attacks exploiting a functionality of EDL programmers – we will see a few concrete examples such as unlocking the Xiaomi Note 5A (codename ugglite) bootloader in order to install and load a malicious boot image thus breaking the chain-of-trust. Part 3, Part 4 & Part 5 are dedicated for the main focus of our research – memory based attacks. In Part 3 we exploit a hidden functionality of Firehose programmers in order to execute code with highest privileges (EL3) in some devices, allowing us, for example, to dump the Boot ROM (PBL) of various SoCs. We then present our exploit framework, firehorse, which implements a runtime debugger for firehose programmers (Part 4). We end with a complete Secure-Boot bypass attack for Nokia 6 MSM8937, that uses our exploit framework. We achieve code execution in the PBL (or more accurately, in a PBL clone), allowing us to defeat the chain of trust, gaining code execution in every part of the bootloader chain, including TrustZone, and the High Level OS (Android) itself.
The merit of our research is as follows:
* We describe the Qualcomm EDL (Firehose) and Sahara Protocols. (Part 1)
* We created firehorse, a publicly available research framework for Firehose-based programmers, capable of debugging/tracing the programmer (and the rest of the bootloader chain, including the Boot ROM itself, on some devices). (Part 3 & Part 4)
* We obtained and reverse-engineered the PBL of various Qualcomm-based chipsets (MSM8994/MSM8917/MSM8937/MSM8953/MSM8974) using the Firehose programmers and our research framework. (Part 3)
* We obtained the RPM & Modem PBLs of Nexus 6P (MSM8994). (Part 3)
* We managed to unlock & root various Android Bootloaders, such as Xiaomi Note 5A, using a storage-based attack only. (Part 2)
* We managed to manifest an end-to-end attack against our Nokia 6 device running Snapdragon 425 (MSM8937). We believe this attack is also applicable for Nokia 5, and might be even extensible to other devices, although unverified. (Part 5)
Research & Exploitation framework for Qualcomm EDL Firehorse programmers
Exploiting Qualcomm EDL Programmers (1): Gaining Access & PBL Internals
Exploiting Qualcomm EDL Programmers (2): Storage-based Attacks & Rooting
Exploiting Qualcomm EDL Programmers (3): Memory-based Attacks & PBL Extraction
Exploiting Qualcomm EDL Programmers (4): Runtime Debugger
Exploiting Qualcomm EDL Programmers (5): Breaking Nokia 6’s Secure Boot
Embedded Software Engineer – Bootloaders
Qualcomm processors provide integrated solutions for millions of diverse mobile and new emerging platforms across IoT, Automotive and Compute markets. It all starts with the Boot Firmware the first mission critical code to execute on our SoC(System on chip) and prepare the system for operation. We design and develop the software we put in mask boot ROM, along with system boot-loaders. Features we work on include image authentication, multicore setup, the UEFI pre-boot environment, configuration of next-generation DDR memories, ARM CPU and custom Qualcomm DSP/microprocessors, MMU/Cache memory management and advanced driver development for multiple boot/storage devices including eMMC, UFS, NAND, SPI-NOR, QSPI and flashless boot transport interfaces such as PCIe, SDIO, USB. Embedded Bootloader design & development involves architecting solutions to address different use cases and feature requirements in the early bootloader environment before the handoff to the High Level Operating System kernel. Engineer is expected to work with different Qualcomm build infrastructure tools and ARM compiler tool chains to enable different drivers and services for Bootloaders, optimizing them both for boot time, internal memory size constraints and power metrics.
* Design, development and integration of custom and/or open source Bootloaders for QCT mobile platforms.
* ThreadX, Linux, Android, Windows Boot process knowhow
* UEFI (Unified Extensible Firmware Interface) based bootloader and device driver model experience
* coreboot, uboot based bootloader experiences
The position requires systemic understanding of server firmware, software, and hardware, and the ability to solve issues across a broad range of technologies. Job duties include: Customer support, including: – Support design and bringup of server systems implementing Qualcomms Centriq server processors – Debug and resolution of customer hardware, firmware, and software issues – Analyze and replicate reported customer-reported problems in Qualcomm labs, for root cause analysis, working in conjunction with software, firmware, and chip design teams – Support customer BIOS / firmware bring-up and customization – Provide performance optimization support for system software – Support server platform validation, performance analysis, and power measurement tools – Delivery of customer training – Creation and support of customer-facing documentation – Create and edit documentation such as device specifications, data sheets, and user manuals – Write application notes and reference code – Creation of training materials.
Detailed knowledge of server processor architecture and system-level features including:
– CPU and system-level caches
– High performance DDR memory systems
– Server system SoC and system-level interfaces, including coherent system interconnects, PCIe, SATA, USB, Ethernet
– Memory management units
– Interrupt controllers and hardware timers
– Power management features
– System clocks and their management
– CPU and system performance monitor hardware
– Debug and trace hardware
– Security features
– System management controller hardware, firmware, and software
– Understanding of system-level programming UEFI, system initialization firmware, etc.
– C programming, preferably for embedded systems or drivers (ARM preferred)
– Familiarity with JTAG based debug tools and environments (Lauterbach Trace-32 preferred)
– Experience using hardware performance monitors for system debug and optimization
– Experience using a configuration management system, e.g. CVS, ClearCase, Git
– Experience using a defect tracking system, e.g. ClearQuest, Bugzilla, JIRA
– Excellent system debugging skills
– Knowledge of multi-agent coherent systems
– Knowledge of power management features, including voltage/frequency scaling and sleep modes
– Experience with ARM RVDS, ARM Development Studio, and GNU tools
– Experience with documentation applications such as Microsoft Word and Excel
– Working knowledge of digital oscilloscopes, logic analyzers, etc.
OnePlus 2 Lack of SBL1 Validation Broken Secure Boot
Aleph Research Advisory
OnePlus 2 (a 2015 Qualcomm Snapdragon 810 device) successfully boots with a tampered Secondary Bootloader (sbl1) partition although it is digitally-signed, hence it is not validated by its Primary Bootloader (PBL), maybe due to lenient hardware configuration. Attackers capable of tampering with the sbl1 partition can then disable the signature validation of the rest of the bootloader chain and other SBL-validated partitions such as TrustZone and ABOOT.[…]
by Gal Beniamini, Project Zero
Mobile devices are becoming an increasingly privacy-sensitive platform. Nowadays, devices process a wide range of personal and private information of a sensitive nature, such as biometric identifiers, payment data and cryptographic keys. Additionally, modern content protection schemes demand a high degree of confidentiality, requiring stricter guarantees than those offered by the “regular” operating system. In response to these use-cases and more, mobile device manufacturers have opted for the creation of a “Trusted Execution Environment” (TEE), which can be used to safeguard the information processed within it. In the Android ecosystem, two major TEE implementations exist – Qualcomm’s QSEE and Trustonic’s Kinibi (formerly <t-base). Both of these implementations rely on ARM TrustZone security extensions in order to facilitate a small “secure” operating system, within which “Trusted Applications” (TAs) may be executed. In this blog post we’ll explore the security properties of the two major TEEs present on Android devices. We’ll see how, despite their highly sensitive vantage point, these operating systems currently lag behind modern operating systems in terms of security mitigations and practices. Additionally, we’ll discover and exploit a major design issue which affects the security of most devices utilising both platforms. Lastly, we’ll see why the integrity of TEEs is crucial to the overall security of the device, making a case for the need to increase their defences. […]
I’m going to try and start to post the occasional relevant interesting job postings for security researchers or developers. I will try to use ‘job-posting” for the tag for all of them. If you think it’s a bad idea for this blog, or if you get the job based on this blog, leave a Comment. 😉
[…]Qualcomm Hardware Security team is looking for a Firmware Security Researcher to help drive security efforts in our System-On-Chip (SOC) solutions. In this role, the Firmware Security Researcher will work closely with the Hardware Design Team, Hardware Verification team, and the Software team to help find vulnerabilities in our products. This role entails using best practices to evaluate, asses, and report vulnerabilities in QUALCOMM products. A systematic approach to vulnerability discovery is essential. Knowledge gained will leverage into new security mitigations for our SOC solutions used in a wide range of products, including mobile devices, IOT, automotive, consumer networking gear, wearables, and embedded medical devices. As a firmware security researcher, it is essential that the candidate be able to develop proof-of-concepts to demonstrate the impact of the vulnerabilities that are discovered, to enable proper prioritization and communication of issues to internal teams and external customers. Communication skills are highly valued as the role will entail cross-department coordination with the various groups involved in Cybersecurity initiatives, and possibly presenting findings at security conferences.[…]
Script to parse Android bootloader (aboot) images, extract certificates and verify image signature. May not work on aboot from latest devices. Signature verification follows the ‘Secure Boot and Image Authentication Technical Overview’ whitepaper by Qualcomm. Cf. https://www.qualcomm.com/documents/secure-boot-and-image-authentication-technical-overview/ Aboot header format as described in http://newandroidbook.com/Articles/aboot.html See above article for more details about aboot. Inspired by https://github.com/kayrus/kc_s701_break_free
This whitepaper provides an in-depth look at our signed ELF images format, the process of loading and authenticating those images, certificate chain contents, and supported signature algorithms.
Kindly pointed out by a reader of the blog, laginimaineb has some more research going on for QualComm TrustZone, sounds non-trivial:
[Grr, when I paste an URL of a Twitter tweet, WordPress usually renders it, today, it is not, maybe it will before it posts it, unsure. I’ve extracted the text from the Tweets in case it does not.]
Just managed to extract the Qualcomm KeyMaster keys directly from TrustZone! Writeup coming soon 🙂 (1/2)
And wrote a script to decrypt all keystore keys. This can also be used to bruteforce the FDE passphrase off the device! (2/2)
This specifically is done on the Nexus 6, but I’ve also dabbled w/ the Nexus 5 and Moto X 2nd Gen
There are some interesting developments in Qualcomm’s Secure Execution Environment (QSEE).
Unlocking the Motorola Bootloader
In this blog post, we’ll explore the Motorola bootloader on recent Qualcomm Snapdragon devices. Our goal will be to unlock the bootloader of a Moto X (2nd Gen), by using the TrustZone kernel code execution vulnerability from the previous blog posts. Note that although we will show the complete unlocking process for this specific device, it should be general enough to work at-least for most modern Motorola devices. […]
Earlier this year, ARM’s Linaro created 96Boards.org.
The 96Boards initiative is designed to offer a single software and hardware community across multiple vendor boards supporting a range of different features. A fixed set of minimum functions including USB, SD, HDMI and standardized low speed and high speed peripheral connectors are provided. Vendors may add customized hardware and feature sets provided the minimum functions are available. We expect this to extend the platform life, increase the market for add-on hardware, and accelerate open source upstreaming of support for new SoC features. The 96Boards standard specification and this website are maintained by the Linaro Community Board Group (LCG). Linaro is a collaborative software engineering organization focused on the ARM architecture. Corporate members of Linaro provide funding and engineers plus direction through various steering committees and resources are split into semi-autonomous groups with their own members.
There are currently two 96Boards specifications for low-cost ARMv7-A and ARMv8-A development boards:
* The Consumer Edition (CE) targets the mobile, embedded and digital home segments.
* The Enterprise Edition (EE) targets the networking and server segments.
They have 3 boards listed currently:
* DragonBoard 410c: Board based on Qualcomm Snapdragon™ 410 processor
* The HiKey Board: Board based on HiSilicon Kirin 6220 processor
* 96Boards UART Serial Adapter: a USB to UART interface to be used with any 96Boards Consumer or Enterprise Edition board.
Marcin Juszkiewicz has a good blog post on 96boards as well:
ARM Devices has a video discussing adding 96boards hardware targets to LAVA, the CI server by Linaro for embedded device testing.
Qualcomm announces ARM-based Snapdragon 430 and 617, and Snapdragon 820 with X12 LTE modem:
Over the past several weeks, we have been revealing details about the incredible features of the Qualcomm Snapdragon 820 processor. And today we are revealing the final piece of the puzzle. The Snapdragon 820 is the most powerful mobile processor we’ve ever made. […]
Qualcomm Technologies is building up the Snapdragon line-up with two new products and several firsts. The Qualcomm Snapdragon 617 and 430 processors are designed to deliver high-end performance and experiences in affordable, high- and mid-tier devices. […]
Qualcomm makes the Snapdragon 820 processor, and is working with Avast Software to include a new kernel-level security technology that is able to detect 0day malware using machine learning, expected to be in consumer devices next year. Excerpting their press release:
“Avast is pleased to work together with Qualcomm Technologies to provide hardware-based security that is integrated into the hardware and firmware of Snapdragon processors,” said Vince Steckler, chief executive officer of Avast. “With threats increasing every day, OEMs and mobile operators need to protect their users in real-time. Snapdragon Smart Protect will provide hardware-based security at the processor level, which is designed to help improve consumer safety from rogue applications, zero day attacks, and ransomware.” Traditional security software can only scan and monitor software behavior at the application and framework layer level. Avast is utilizing Snapdragon Smart Protect on-device, machine-learning technology at the processor level to address zero-day attacks and differentiate between clean and malicious software applications. While consumers will benefit from better protection, OEMs and mobile operators will benefit from reducing the risk of data leakage and malware attacks for their users.
Full press release:
I mainly work with UEFI technology, and don’t know much about coreboot, nor Chrome OS. I’m new to these tech, and learning them… 🙂
For a while, I thought coreboot was pretty inactive, but I now realize much of the coreboot activity has been taking place in Chrome OS. It appears that some of this work is now being upstreamed to the main coreboot.
From the coreboot blog:
“In the last months there was lots of activity in the coreboot repository due to upstreaming the work that was done in Chrome OS’ branch. We’re happy to announce that both code bases are again relatively close to each other. In the last 7 months, about 1500 commits that landed in coreboot originated in Chrome OS’ repository (of about 2600 total). Those came from 20 domains, which represent pretty much every part of the coreboot community: well known private and commercial coreboot contributors, but also BIOS and silicon developers as well as device manufacturers. Significant contributions that went into the tree recently were written with active support by Broadcom, Imagination Technologies, Intel, Marvell, Nvidia, Qualcomm, and RockChip.”
“In the future, Chrome OS will move over to a new branch point from upstream, and work on strategies to avoid diverging for two long years again. Instead, we’re looking for ways to keep the trees closer while also avoiding flooding the coreboot.org developer base with hundreds of patches. More on that as it is implemented.”
Some features that’ve been recently added include:
* new MIPS support
* improved ARM support, for SoCs by Broadcom, Marvell, Qualcomm, and RockChip
* an improved, safer method to declare the memory map on devices
* effort to get Chrome OS’ verified boot support
* update the flash image format to allow for safer incremental updates
This looks like great news for coreboot! I’ll have more blog entries about coreboot and Chrome OS in the near future.
Earlier this month, Linaro announced their effort to upstream the Linux patches to enable ACPI on ARMv8. It appears the patch may make it in Linux 4.1, but it is not done yet.
The Linaro blog post credits a large list of people who helped: UEFI Forums’ ACPI Working Group, Linaro, ARM, Red Hat, Huwaei, Qualcomm, AMD, AMD, APM, HP, other Linaro LEG members, and Linux kernel maintainers, including Linus.
As part of this effort, on March 26th, ARM hosted a Firmware Summit focused on ARMv8 and ACPI, with dozens attending, including SoC vendors, BIOS vendors, firmware and kernel developers, ODMs and OEMs.
The Linux kernel checking comment for this patchset includes this description:
‘This series introduces preliminary ACPI 5.1 support to the arm64 kernel using the “hardware reduced” profile. We don’t support any peripherals yet, so it’s fairly limited in scope:
– MEMORY init (UEFI)
– ACPI discovery (RSDP via UEFI)
– CPU init (FADT)
– GIC init (MADT)
– SMP boot (MADT + PSCI)
– ACPI Kconfig options (dependent on EXPERT)
ACPI for arm64 has been in development for a while now and hardware has been available that can boot with either FDT or ACPI tables. This has been made possible by both changes to the ACPI spec to cater for ARM-based machines (known as “hardware-reduced” in ACPI parlance) but also a Linaro-driven effort to get this supported on top of the Linux kernel. This pull request is the result of that work. These changes allow us to initialise the CPUs, interrupt controller, and timers via ACPI tables, with memory information and cmdline coming from EFI. We don’t support a hybrid ACPI/FDT scheme. Of course, there is still plenty of work to do (a serial console would be nice!) but I expect that to happen on a per-driver basis after this core series has been merged.’
Upon accepting the patch, Linus said:
‘No earth-shattering new features come to mind, even if initial support for ACPI on arm64 looks funny. Depending on what you care about, your notion of “big new feature” may differ from mine, of course. There’s a lot of work all over, and some of it might just make a big difference to your use cases.’
This *is* big new feature, if you care about firmware and Linux.