Full Report
Unisoc is a semiconductor company that is commonly put on Android smart phones. The authors decided to review the Boot process of these chips. The first step is extracting the BootROM in order to look at the code. Since this is etched into the hardware, there is no reason for this to be public, making it much harder to get. They choose to look at a Teclast phone and a Motorola phone. Secure boot was not burned into the fuses and the private key is reused from the Unisoc Github repo. By booting this into recovery mode, the BootROM, this could be easily dumped. For the Motorola device, they had to reverse engineer the SDL (secondary boot loader) to try to find an issue, since the previous trick didn't work. FDL1 is in the recovery process that is normally loaded from the BootROM. Once FDL1 initializes the system memory, it goes into FDL2 using a USB protocol. While parsing this data, there is no limit on the amount of data that can be sent but it is in a static buffer. This results in a buffer overflow that can be used to get code execution to dump out the BootROM. The recovery mode on the Unisoc chip exposes 5 commands via UART and USB to start FDL1. The command cmd_start took in a user controlled target address and wrote user controllable writable data. This feels like a vulnerability by design! The USB command dispatcher takes in an index used to execute a function from a list of pointers. However, it does not validate the index. This means that a section of code could be jumped to in an unexpected way. However, this is in the ReadOnly section of memory, making it not trivial to exploit. The USB data transfer reads in data byte by byte. When doing this, it writes to a static buffer on the stack without validating the size, leading to an out of bounds write issue. A similar exists in the USB command dispatcher as well. Boot loaders are supposed to verify the next stage is allowed to execute, which is doing using cryptography. While reviewing the verification check on the secondary boot loader, they noticed there were two types of certs: contentcert and keycert. For whatever reason, the contentcert performed 0 validation and return correctly. The RSA function had a buffer overflow when using a key greater than 2048 bits. Since the overflow occurs in global buffers (unlike the bugs from before), this can be used to smash the stack and get code execution on the chip. Overall, the vulnerabilities were fairly straight forward buffer overflows or design decisions that led to issues. The article really shines in showing the difficultly of auditing BootROMs from an access perspective and sharing the boot process in general. Great article!
Analysis Summary
The provided text describes a vulnerability research effort targeting the Unisoc chip boot process, primarily focusing on gaining access to the BootROM and subsequent bootloaders (FDL1/FDL2). However, **it does not explicitly list CVE identifiers, CVSS scores, specific vulnerable product versions, or official patch details.**
The summary below is constructed based *only* on the technical findings described in the context, using placeholders where specific vendor information or CVEs are missing, as is common in preliminary research summaries before official disclosure.
***
# Vulnerability: Multiple Flaws Leading to BootROM Disclosure in Unisoc Chips
## CVE Details
* **CVE ID:** N/A (Based on context, these vulnerabilities are newly discovered findings from this research, likely awaiting CVE assignment.)
* **CVSS Score:** N/A (Severity is implied to be High due to system compromise potential.)
* **CWE:** Multiple (Including CWE-120: Buffer Copy without Checking Size, CWE-121: Stack-based Buffer Overflow, CWE-843: Access of Freed Memory, and CWE-284: Improper Access Control/Validation).
## Affected Systems
* **Products:** Unisoc semiconductor chips commonly found in Android smartphones (specifically mentioned: Teclast phone, Motorola phone).
* **Versions:** BootROM and Secondary Boot Loader (SDL) stages (FDL1/FDL2) prior to any fix implemented by Unisoc or device vendors.
* **Configurations:** Devices where secure boot fuses were not burned, and where the exploitable private key (reused from the Unisoc Github repo) was present or usable for signing verification bypass.
## Vulnerability Description
Researchers identified several critical vulnerabilities across the Unisoc boot chain:
1. **FDL2 Data Handling Overflow (Buffer Overflow):** During the FDL1-to-FDL2 transition via USB, FDL2 parses incoming data into a static buffer without any size validation. This allows an attacker to cause a buffer overflow, leading to code execution, which was used to dump the BootROM.
2. **UART Command Dispatch Failure ($\text{cmd\_start}$):** The UART command `cmd_start` accepts a user-controlled target address and writes user-controllable data to it, suggesting an intentional design flaw enabling arbitrary memory writes/execution transfer.
3. **USB Function Pointer Misuse (Index Validation Bypass):** The USB command dispatcher uses an index to look up and execute a function pointer from a list. This index is not validated, allowing an attacker to jump to arbitrary code pointers. Exploitation is noted as non-trivial because the target code resides in Read-Only Memory (ROM).
4. **RSA Verification Bypass:** The Content Certificate validation check during secondary boot loader verification performs **zero cryptographic validation** and always returns success, allowing execution of unsigned code stages.
5. **RSA Key Overflow:** The RSA validation function contains a buffer overflow vulnerability when processing keys larger than 2048 bits. Since this occurs in global buffers, it can be used to smash the stack and achieve code execution on the chip.
## Exploitation
* **Status:** Research/Proof-of-Concept demonstrated for BootROM dumping. Exploitation of the code execution flaws likely requires interaction during the early boot sequence, which is typically firmware-physical access.
* **Complexity:** Low to Medium. Several issues (FDL2 buffer overflow, $\text{cmd\_start}$ write primitive, Content Cert bypass) appear relatively straightforward given the required access environment (recovering mode via UART/USB).
* **Attack Vector:** Physical/Local (Requires control over the device during the early boot phase via UART or USB interfaces exposed by the recovery process).
## Impact
* **Confidentiality:** High (Successful exploitation grants access to the highly sensitive BootROM code, potentially leading to device subversion).
* **Integrity:** Critical (Arbitrary code execution at the earliest boot stages allows complete compromise of the device firmware and subsequent OS installation).
* **Availability:** High (Full device takeover or permanent bricking is possible).
## Remediation
### Patches
* **Note:** No specific vendor patches or version numbers are detailed in the source context. Remediation requires updates to the Unisoc SoC firmware/ROM provided by the chip vendor and distributed via device manufacturers (Teclast, Motorola, etc.).
### Workarounds
* **Secure Boot Configuration:** Ensure that secure boot fuses are burned (if applicable) to prevent unauthorized code execution in pre-boot stages, though this hardware step is often irreversible post-production.
* **Physical Security:** Restrict physical access to devices to prevent an attacker from connecting via UART or USB during the recovery/bootloading phase.
## Detection
* **Indicators of Compromise (IoC):** Suspicious activity during device boot sequence, particularly unexplained USB/UART data exchange or unexpected transition into the secondary bootloader (FDL1/FDL2) mode without user initiation.
* **Detection Methods and Tools:** Advanced hardware analysis tools and firmware emulation environments are typically needed to observe pre-boot execution flow for signs of malicious input triggering these vulnerabilities. Standard operating system integrity checks are irrelevant due to the depth of the compromise.
## References
* Vendor advisories for specific SoC families from Unisoc related to boot security updates. (None provided in text).
* Relevant links (defanged): hxxps://www.nccgroup.com/research/ (Assuming the full report resides here).