Introduction to Secure Boot and Hardware Glitching

Secure Boot is a critical security feature implemented in modern System-on-Chips (SoCs), including Samsung’s Exynos series, designed to ensure that only trusted, authenticated software can execute during the device’s boot process. It establishes a ‘chain of trust’ from the immutable Boot ROM to the operating system, preventing unauthorized code execution and protecting against rootkits and firmware tampering. However, despite its robustness, hardware-level vulnerabilities, particularly through fault injection techniques like glitching, can sometimes undermine this security.

This article delves into the methodology of identifying and exploiting hardware glitches to bypass the secure boot mechanism on Exynos SoCs. We will explore the theoretical underpinnings of hardware glitching, practical techniques for fault injection, and the steps involved in achieving unauthorized code execution.

Understanding Exynos Secure Boot Architecture

The Exynos secure boot process typically begins with the Boot ROM (BL0), a read-only memory block containing the initial boot code. This ROM verifies the cryptographic signature of the next stage bootloader (BL1), which in turn verifies BL2, and so on, until the kernel is loaded. Each stage’s integrity and authenticity are checked against cryptographic hashes and digital signatures signed by Samsung’s private keys. A failure in verification at any stage halts the boot process.

Key Boot Stages:

• Boot ROM (BL0): Immutable, first code to execute, verifies BL1.
• Primary Bootloader (BL1): Typically loads and verifies BL2.
• Secondary Bootloader (BL2): Prepares the system for OS loading, verifies kernel.

The goal of a secure boot bypass is to either disable the signature verification process or redirect execution flow to an attacker-controlled routine before or during the verification checks, usually at an early boot stage like BL0 or BL1, where the attack surface is minimal and timings are critical.

Hardware Glitching Fundamentals

Hardware glitching, also known as fault injection, involves intentionally introducing transient errors into a target system’s operation to alter its behavior. These faults can be induced through various physical means:

• Voltage Glitching: Momentarily dropping or raising the power supply voltage to the SoC.
• Clock Glitching: Introducing brief disruptions or variations in the clock signal frequency or duty cycle.
• Electromagnetic Glitching: Using targeted EM pulses to induce current flows or voltage fluctuations.

When timed precisely, these glitches can cause a processor to misinterpret instructions, skip instructions, corrupt registers, or access incorrect memory locations. For secure boot bypass, the objective is to trigger one of these faults during a critical signature verification instruction, leading to a false positive verification or a jump to an unverified code path.

Methodology for Identifying Glitch Points

1. Physical Access and Target Identification

The first step involves gaining physical access to the device. This requires disassembly to expose the main PCB and identify the Exynos SoC. High-resolution images or schematics (if available) can aid in locating critical power rails, clock lines, and debugging interfaces (e.g., JTAG, SWD, UART).

2. Instrumentation and Monitoring

Successful glitching relies on precise timing. Tools required include:

• Oscilloscope: To monitor voltage rails and clock signals.
• Logic Analyzer: To observe digital signals, especially boot status indicators via UART.
• Custom Glitching Hardware: Devices like the ChipWhisperer, PicoEMP, or custom FPGA-based setups capable of generating precisely timed voltage or clock pulses.

A UART connection to the device’s debug port is crucial for observing bootloader messages, which often provide insights into the current boot stage and potential glitch effects.

3. Voltage Glitching Techniques

Voltage glitching typically involves connecting a fast switching element (e.g., a MOSFET) in series or parallel with a power supply line to the SoC. This allows for a momentary drop (or rise) in voltage for a very short duration.

Practical Steps for Voltage Glitching:

1. Identify Core Voltage Rail: Using schematics or by probing, identify the main VDD_CORE or VCC_SYS power rail supplying the Exynos SoC.
2. Solder Connection: Carefully solder fine gauge wires to the identified power rail and a stable ground point on the PCB.
3. Connect Glitching Hardware: Connect these wires to your glitching device (e.g., a custom circuit with a MOSFET or a ChipWhisperer board). The glitching device will control the MOSFET to create brief voltage drops.
4. Configure Glitch Parameters: This is an iterative process. Start with short pulse durations (e.g., 5ns to 50ns) and varying offsets from the boot reset signal.

// Example pseudo-code for a voltage glitching loop (ChipWhisperer API style)target.reset_and_halt()scope.glitch.manual_trigger()# Configure glitch pulse (e.g., negative, width, offset)scope.glitch.trigger_src = 'manual'scope.glitch.output = 'glitch_only'scope.glitch.width = 10 // ns glitch widthscope.glitch.offset = 0 // offset from trigger (e.g., reset)scope.glitch.ext_offset = 0 // fine-tune offset for critical instructiontarget.go()# Monitor UART output for success

4. Clock Glitching Techniques

Clock glitching involves injecting a modified clock signal. This can be done by momentarily stretching, compressing, or skipping clock cycles supplied to the SoC, usually by an external oscillator or a frequency generator.

Practical Steps for Clock Glitching:

1. Identify Clock Source: Locate the main clock input to the Exynos SoC. This often requires desoldering an existing crystal oscillator or identifying a suitable injection point.
2. Inject External Clock: Feed a manipulated clock signal from your glitching hardware (e.g., an FPGA or dedicated clock generator) into the SoC’s clock input.
3. Vary Clock Properties: Experiment with brief frequency changes, single clock cycle skips, or duty cycle variations.

Exploiting Identified Glitches: Case Study Example

The core objective is to bypass the digital signature verification within the boot ROM or early bootloader. Consider a simplified instruction sequence for signature verification:

0xDEADBEEF: LDR R0, [R1]        ; Load hash from memory0xDEADBEEF+4: LDR R1, [R2]        ; Load signature from memory0xDEADBEEF+8: BL  verify_signature ; Call verification routine0xDEADBEEF+C: CMP R0, #0        ; Check return value (0 for success)0xDEADBEEF+10: BNE  auth_fail      ; If not zero, branch to failure handler0xDEADBEEF+14: BL  load_next_stage  ; Success: proceed to next stage

A successful glitch might target the `CMP R0, #0` instruction or the `BNE auth_fail` instruction. By glitching the CPU during `BNE auth_fail`, we might force it to skip the conditional branch, effectively making it believe verification passed, and jump directly to `BL load_next_stage` with an invalid signature.

Iterative Glitching and Observation:

1. Start Broad: Begin with a wide range of glitch timings (offset from reset) and durations.
2. Monitor UART: Look for deviations in the normal boot sequence. Unexpected boot messages, crashes, or hanging could indicate a successful fault injection.
3. Narrow Down: Once a range of successful glitches is found, refine the timing and duration parameters. This might involve micro-stepping the offset by single clock cycles or nanoseconds.
4. Reproducibility: Aim for a highly reproducible glitch. Minor variations in temperature, power, or physical setup can affect glitch timing.

Post-Bypass Actions

Once secure boot is bypassed, the attacker may gain the ability to:

• Dump Firmware: Read out sensitive bootloader code, kernel, and other proprietary firmware components for further analysis.
• Gain Debug Access: Enable JTAG/SWD access, allowing for real-time debugging, memory inspection, and register manipulation.
• Inject Custom Code: Load and execute arbitrary unsigned code on the device, paving the way for full system compromise, custom ROM installation, or extraction of cryptographic keys.

Challenges and Countermeasures

Exynos SoCs often incorporate advanced countermeasures against fault injection, including:

• Redundant Computations: Performing critical operations multiple times and comparing results.
• Voltage/Clock Monitors: Dedicated hardware to detect abnormal power supply or clock signals.
• Timing Randomization: Introducing small, random delays in critical execution paths to thwart precise timing attacks.
• Advanced Packaging: Ball Grid Array (BGA) and Package-on-Package (PoP) designs make physical access to internal signals challenging.

Despite these challenges, continued research into novel fault injection techniques and the inherent complexities of hardware design mean that vulnerabilities, though difficult to find, may still exist. The methodologies discussed here form the foundation for such advanced hardware security research.