Introduction to Secure Boot and Exynos S-Boot
Secure Boot is a critical security feature in modern embedded systems, including smartphones powered by Samsung’s Exynos SoCs. Its primary purpose is to ensure that only trusted, signed code is executed during the device’s boot process, preventing the loading of malicious or unauthorized firmware. This chain of trust typically begins with an immutable Boot ROM (mask ROM) which verifies the signature of the next stage bootloader (e.g., S-Boot on Exynos devices). A successful bypass of Secure Boot can grant an attacker full control over the device, allowing for custom firmware installation, root access, and deep-level hardware reverse engineering.
What is Secure Boot?
At its core, Secure Boot relies on cryptographic signatures. Each stage of the bootloader verifies the digital signature of the subsequent stage before executing it. If a signature is invalid, the boot process is halted, preventing untrusted code from running. This chain starts with a Root of Trust (RoT) embedded in the hardware, usually the Boot ROM, which contains public keys or hashes used to verify the initial bootloader.
Exynos Secure Boot Architecture Overview
Exynos SoCs implement a sophisticated Secure Boot mechanism. The process typically unfolds as follows:
- Boot ROM (BROM): The first code executed after power-on. It initializes minimal hardware, performs basic security checks, and loads the initial bootloader (S-Boot) from eMMC/UFS. The BROM verifies S-Boot’s cryptographic signature against hardcoded public keys or hashes.
- S-Boot (Secondary Bootloader): This stage further initializes hardware, verifies and loads the operating system kernel, and performs additional security checks. It’s often responsible for configuring secure memory regions and enabling hardware-level security features.
- Operating System (Kernel): Once verified by S-Boot, the kernel takes over, eventually booting the full Android system.
Our focus in this article is on bypassing the signature verification performed by the BROM on the S-Boot image, or by S-Boot on subsequent stages.
Understanding Fault Injection Techniques
Fault injection involves introducing transient errors into a system’s operation to force it into an unexpected state, often to bypass security checks. When applied to cryptographic operations, these faults can cause a signature verification routine to incorrectly validate an unsigned or maliciously signed binary.
Voltage Glitching
Voltage glitching involves momentarily dropping or raising the supply voltage to the SoC during a critical operation. A brief undervoltage can cause memory corruption, register bit flips, or instruction skips, leading to incorrect execution. The key is precise timing and duration of the glitch pulse.
Clock Glitching
Clock glitching involves perturbing the clock signal supplied to the SoC. This can range from momentarily stopping the clock, introducing extra clock cycles, or altering the clock frequency. Similar to voltage glitching, it aims to disrupt instruction execution or timing-critical operations, such as cryptographic computations or signature comparisons.
Electromagnetic Fault Injection (EMFI)
EMFI uses precisely generated electromagnetic pulses to induce currents in the target chip, causing localized faults. This technique offers higher spatial resolution compared to voltage or clock glitching, potentially targeting specific functional units or memory regions within the SoC.
Methodology: Identifying Glitch Targets
The success of fault injection heavily relies on identifying the exact moment and location to inject the fault. For Secure Boot, the primary target is the signature verification loop.
Analyzing Boot ROM Code (if possible)
While BROM code is usually read-protected, understanding its logical flow from public documentation or leaked SDKs can provide insights. We are looking for sequences like:
// Pseudocode for signature verification loop in BROM/S-Boot loaderfunction verify_signature(binary_data, signature, public_key): hash = calculate_hash(binary_data) decrypted_hash = decrypt_signature(signature, public_key) if hash == decrypted_hash: return TRUE else: return FALSE
Our goal is to cause hash == decrypted_hash to evaluate to TRUE even when it should be FALSE, or to skip the check entirely.
Hardware Analysis: Power Rails and Clock Lines
Physical analysis of the target device’s PCB is crucial. Identify the SoC, its power management IC (PMIC), and relevant power/clock lines. This often requires:
- High-resolution X-ray imaging for inner PCB layers.
- Microscopy to identify test points or vias for probing.
- Using a multimeter and oscilloscope to trace power rails and clock signals during boot.
Timing and Synchronization
Precise synchronization with the target’s execution is paramount. This can be achieved by:
- Triggering on power-on: Simple but less precise.
- GPIO triggering: Using a known GPIO state change from the target as a trigger for the glitching hardware.
- UART/USB activity: Monitoring boot log output for specific strings that indicate the start of signature verification.
- Power consumption analysis: Monitoring current draw with an oscilloscope; cryptographic operations often show distinct power profiles.
Practical Steps for Bypassing Exynos S-Boot
Required Equipment Setup
- Fault Injection Platform: Dedicated glitching hardware (e.g., ChipWhisperer, custom FPGA-based solutions).
- High-Bandwidth Oscilloscope: For monitoring power rails, clock signals, and glitch pulses.
- Adjustable DC Power Supply: To power the target device and control its voltage.
- Target Exynos Device: A development board or a de-lidded retail device.
- Custom Probes/Fixtures: For reliable connection to SoC power, clock, and debug lines.
- Logic Analyzer: For monitoring multiple digital signals.
Targeting Signature Verification
Let’s assume we’ve identified the power rail supplying the CPU core during the BROM execution. Our strategy is to inject a voltage glitch during the comparison phase of the signature verification. A typical workflow involves:
- Prepare the Target: Power on the Exynos device with an unsigned S-Boot image loaded to eMMC/UFS. It should fail to boot.
- Connect Glitching Hardware: Connect the glitching output to the identified power rail (e.g., by desoldering a capacitor and injecting in series, or using fine probes on a BGA breakout). Connect the oscilloscope to monitor the target voltage and glitch output.
- Establish Trigger: Use a suitable trigger source, e.g., the initial power-on event or a specific pattern on the UART output during the early boot phase.
- Parameter Sweeping: Systematically vary glitch parameters (delay after trigger, pulse width, voltage drop magnitude) and observe the target’s behavior. An example parameter sweep might look like:
# Pseudocode for a glitching sweep loopfor delay in range(100, 1000, 10): # delay in clock cycles or us for width in range(1, 20, 1): # pulse width in clock cycles or ns set_glitch_parameters(delay, width, voltage_drop_magnitude) trigger_target_reset() wait_for_boot_attempt() check_for_debug_access() # Look for JTAG/UART changes indicating success
A successful glitch will often manifest as the device continuing to boot beyond the expected failure point, or enabling a previously locked debug interface.
Gaining Debug Access Post-Glitch
Once a fault injection successfully bypasses Secure Boot, the next step is typically to gain debug access. For Exynos SoCs, this often means enabling JTAG or SWD. Many BROMs, even if secure, have debug modes that can be activated if certain checks are bypassed.
With JTAG access, you can:
- Dump memory (BROM, RAM, eMMC).
- Inject code directly into RAM.
- Set breakpoints and step through execution.
- Modify register values.
Example commands with a JTAG debugger (e.g., OpenOCD with a J-Link/ST-Link):
$ openocd -f interface/jlink.cfg -f target/exynos.cfg$ telnet localhost 4444> halt> mdw 0xDEADBEEF 10 # Memory dump at address 0xDEADBEEF, 10 words> load_image custom_bootloader.bin 0x40000000 # Load custom bootloader to RAM> resume 0x40000000 # Jump to and execute custom bootloader
This allows injecting your own unsigned bootloader or directly patching the running memory to disable further security checks.
Ethical Considerations and Responsible Disclosure
The techniques discussed here are powerful and, in the wrong hands, can be used for malicious purposes. This article is intended for educational purposes, security research, and ethical penetration testing. Always ensure you have explicit permission before performing fault injection on any device. Discoveries of Secure Boot bypasses should be responsibly disclosed to the vendor to allow for patches and improvements in device security.