No Signal, No Security: Dynamic Baseband Vulnerability Research

No Signal, No Security: Dynamic Baseband Vulnerability Research

Speakers: Daniel Klischies (Ruhr University Bochum), David Hirsch (Ruhr University Bochum)

Conference: OffensiveCon 2025 — May 16-17, 2025, Berlin

YouTube: https://www.youtube.com/watch?v=zoAITq7jUM8

Reading time: ~9 minutes

TL;DR

Researchers at Ruhr University Bochum developed BaseBridge, a technique that transplants live cellular connection state from a physical smartphone into a baseband emulator, enabling coverage-guided fuzzing of MediaTek and Samsung baseband firmware without needing real cellular infrastructure. The campaign found eight vulnerabilities — five previously unknown, two confirmed remote code execution — including a stack buffer overflow triggered simply by sending an LTE network name of unusual length.

Introduction

Smartphone baseband processors are an extraordinarily rich attack surface: they process every byte of cellular traffic before it reaches the application processor, they run without a sandbox, and they operate on binary-only closed-source firmware implementing hundreds of tasks and complex protocol state machines. Yet automated vulnerability discovery in basebands has lagged behind other embedded firmware domains because the stateful nature of cellular protocols makes fuzzing without real network connectivity nearly useless — the firmware simply discards any packet that arrives outside a connected state.

This talk, a joint work of Daniel Klischies, David Hirsch, Dyon Goos, Alyssa Milburn, Marius Muench, and Veelasha Moonsamy, addresses that fundamental obstacle with a systematic and automated state-restoration technique. The result is a practical fuzzing pipeline that improves protocol coverage roughly fourfold after 24 hours of operation and, in doing so, uncovers exploitable bugs that over-the-air testing alone would struggle to reach.

How Baseband Firmware Processes Cellular Packets

▶ Watch: Baseband architecture and PDU processing (2:00)

The researchers focused primarily on MediaTek LTE basebands using the MIPS instruction set architecture and running the Nucleus OS real-time operating system. The firmware is organized into 191 separate tasks, each implementing a specific cellular protocol layer or peripheral interface. Key tasks include EL1 (physical layer decoding), RRC (Radio Resource Control), EMM (EPS Mobility Management within NAS), and SMS processing. Tasks communicate via per-task message queues; peripheral interfaces include the radio, the SIM card, timers, and the CCCI (Cross-Core Communication Interface) bridging the baseband to Android's application processor.

Incoming packets arrive as nested protocol data units (PDUs): an LTE PDU wraps an RRC PDU, which wraps an EMM PDU, which may wrap an SMS PDU. Each layer unpacks its header, performs decryption and integrity verification where required, and dispatches the payload to the appropriate task via MediaTek's characteristic large nested function tables implementing protocol state machines. Critically, the firmware's decision to process or discard a packet depends on a large volume of cellular state held in memory: encryption keys, the device's IMSI, the list of visible cells, whether the device is currently connected, and whether security has been established. Without this state, an emulated baseband rejects almost all incoming packets at the RRC task and the attack surface beyond that layer is unreachable.

The Limits of Existing Approaches

▶ Watch: Over-the-air vs. emulation approaches (6:00)

Three pre-existing approaches to baseband security testing all carry significant limitations:

• Manual static analysis requires painstaking reverse engineering of large binary-only firmware images.
• Specification-based testing identifies undefined behaviors in the 3GPP standards but depends on human interpretation and misses implementation-specific bugs.
• Over-the-air fuzzing uses a software-defined radio (the researchers demonstrated a setup consisting of a laptop, a Raspberry Pi, and an SDR in an RF shielding box) but suffers from extremely slow execution speeds, the need to reboot the device between test cases, and nearly zero introspection into the baseband's internals.

The public state-of-the-art for baseband emulation is FirmWire, introduced by Hernandez et al. in 2022, which runs unmodified MediaTek or Samsung firmware images in a QEMU-based Panda emulator with a set of emulated boot peripherals. FirmWire solved the "boot the firmware" problem but not the "connect it to a cellular network" problem: because it emulates no cellular peripherals (no SIM, no radio), the firmware boots into a permanently idle, disconnected state. All state-dependent packet processing paths — the vast majority of interesting attack surface — remain unreachable.

BaseBridge: Automated State Restoration from Crash Dumps

▶ Watch: State restoration technique (10:00)

The core insight of the BaseBridge technique is that a physical smartphone, while connected to a live cellular network, carries in its RAM the exact connection state required to make an emulated baseband behave like a connected device. The researchers obtain this state via crash dumps.

Crash dumps can be triggered through several mechanisms, including SIM I/O controls or a hidden engineering menu reachable by dialing a magic number on certain MediaTek devices. The resulting dump is a Snappy-compressed container holding nearly complete baseband memory — stack, heap, global variables, and memory-mapped I/O regions, with base addresses conveniently encoded in the segment names. What the dump does not contain are CPU register values or peripheral state; it also reflects a crashed OS state that cannot be directly loaded into a fresh emulator.

The state restoration procedure merges two snapshots:

1. A fresh emulator snapshot from FirmWire (clean OS state, no connection).
2. The connection state extracted from the crash dump (keys, IMSI, cell lists, protocol variables).

The challenge is identifying precisely which memory regions from the ~500 KB of connection state on a MediaTek baseband need to be transplanted. Doing this by hand is impractical and would need to be repeated for every new firmware version. The team automated it with a coverage-guided memory mutation algorithm inspired directly by AFL: replay a target RRC packet in the emulator while logging all memory accesses, group accesses heuristically (sequential accesses and accesses within the same function are grouped together), then iteratively restore individual groups from the crash dump and measure whether doing so increases instruction coverage or prevents the test packet from being discarded. Groups that improve coverage are retained; others are discarded. The result is a minimal transplanted connection state sufficient to let the emulated baseband process packets as if connected — without crashing due to the transplanted OS corruption.

The connected emulator achieves a roughly fourfold improvement in protocol coverage after 24 hours compared to fuzzing without state restoration, and continues discovering new code paths while the baseline plateaus quickly.

Fuzzing Architecture and Performance

▶ Watch: Fuzzing setup and performance (14:00+)

With state restoration in place, the fuzzer injects RRC PDUs directly into layer 3 (bypassing layers 1 and 2, and patching out encryption and integrity verification checks in the firmware). Coverage-guided feedback drives corpus evolution. Using QEMU-based emulator snapshots for fast reset between test cases, the pipeline achieves 50 to 100 packets per second per core — orders of magnitude faster than over-the-air testing — with straightforward horizontal scaling by running additional emulator instances.

The fuzzer generates responses matching those of a real network, including packets exceeding 1 KB. Wireshark was used to trace the emulator's packet interface during development, and IDA Pro was used for reverse engineering the firmware tasks involved in crash analysis.

Vulnerabilities Discovered: Stack Buffer Overflow via Network Names

▶ Watch: Vulnerability discovery and RCE (18:00+)

The campaign found eight vulnerabilities in total — five new, two confirmed remote code execution. The most notable involves the EMM protocol's handling of network names in LTE:

• An EMM PDU can contain a Full Network Name information element (type 0x43) and a Short Network Name information element.
• The Short Network Name with a length field of zero triggers an integer underflow: the firmware subtracts 1 from the length (treating it as an unsigned byte), yielding 0xFF, which a special-case handler converts to 0xFE (254).
• This corrupted length is then passed to a GSM-7 unpacking function. The function's output buffer is fixed at 260 bytes, but with an input length of 0xFE (255 bytes of 7-bit-packed data), the function decodes up to 292 bytes of output — a 32-byte stack buffer overflow.
• The overflow overwrites the stored return address register on the stack, constituting a direct return-address hijack and confirmed remote code execution.

Because GSM-7 encodes each character in 7 bits with the high bit always zero, the maximum byte value injectable through the overflow is 0x7F. The researchers demonstrated a partial exploitation strategy: overwriting the return address with a value reachable under the 7-bit constraint, redirecting execution to an unused firmware function that writes a debug log message — a proof-of-concept that confirms control-flow hijack.

MediaTek was aware of this specific vulnerability prior to the OffensiveCon disclosure; it had been previously reported by Schol Park at Kais following discovery through over-the-air testing with unusually long network names.

Beyond the stack overflow, the fuzzer also found heap overflows and integer underflow conditions assessed as potentially exploitable, and a second confirmed RCE vulnerability detailed in the accompanying paper.

Notable Quotes

"You will also learn how network names became a vector for remote code execution, but we will come to that later in this talk." — Daniel Klischies, ▶ (0:00)

"It turns out on MediaTek basebands at least, you need like half a megabyte of connection state. So this is not something you want to do manually." — Daniel Klischies, ▶ (14:00)

"So instead of mutating inputs, you're mutating memory regions that we want to restore here — inspired by coverage-guided fuzzing." — Daniel Klischies, ▶ (14:00)

Key Takeaways

• BaseBridge solves the fundamental blocker for baseband fuzzing by automatically transplanting ~500 KB of live cellular connection state from crash dumps into a QEMU emulator, achieving a ~4× coverage improvement and eliminating the need for physical cellular infrastructure.
• Coverage-guided memory mutation — applying the AFL principle to memory regions rather than input bytes — automates the state-transplant process and scales across firmware versions and vendors.
• A stack buffer overflow via GSM-7 integer underflow in the LTE Full/Short Network Name EMM elements yields confirmed remote code execution; an attacker controlling a base station can trigger it by advertising a malformed network name to nearby devices.
• The fuzzer achieves 50–100 packets/second/core with snapshot-based reset, enabling large-scale testing that over-the-air approaches (limited to physical-device reboot cycles) cannot match.
• Eight vulnerabilities found (five new, two RCE) across MediaTek and Samsung basebands underscore that cellular baseband firmware, despite its privileged position in the smartphone security architecture, remains severely under-fuzzed.