The baseband processor — the modem chip that handles all cellular communication — is arguably the most security-critical component in any smartphone. It operates below the application processor (AP), runs its own Real-Time Operating System (RTOS) with full access to the radio hardware, and processes untrusted over-the-air (OTA) messages before any authentication occurs. A vulnerability in the baseband grants an attacker full control of the modem, enabling silent call interception, location tracking, and in many cases, escalation to the application processor and the Android/iOS operating system itself.
This makes baseband exploitation the holy grail of mobile offensive security: a single vulnerability can enable a zero-click, zero-interaction remote code execution attack against any device within radio range. No phishing link, no user action — just a crafted radio message.
Baseband vulnerabilities represent the most critical class of mobile security flaws. They are reachable over-the-air without user interaction, execute in a privileged context with direct hardware access, and often bypass all application-layer security measures. Unlike application vulnerabilities that require user interaction, baseband bugs are exploitable by anyone with a IMSI catchers within radio range.
I. Baseband Architecture: The Hidden Computer Inside Your Phone
Every smartphone contains two processors: the Application Processor (AP) running Android/iOS, and the Baseband Processor (BP) running a proprietary Real-Time Operating System (RTOS) that handles all cellular protocol processing. These two processors share a communication channel (typically shared memory or a PCIe bus) but run completely independent software stacks.
Major Baseband Platforms
| Vendor | Chipset Family | RTOS | Devices | Research Accessibility |
|---|---|---|---|---|
| Samsung | Shannon (Exynos Modem) | Samsung Proprietary RTOS | Samsung Galaxy (Exynos variants), Google Pixel 6/7/8 | High — most researched, ASAN support available |
| Qualcomm | Snapdragon Modem (X55/X65/X75) | QuRT (Qualcomm RTOS) | Most Android flagships (Snapdragon variants), iPhones 12-15 | Medium — heavily obfuscated, some research published |
| MediaTek | Helio/Dimensity Modem | Nucleus RTOS | Budget-to-mid-range Android devices | Medium — growing research community |
| Intel | XMM (discontinued) | ThreadX RTOS | iPhones 7-11 | High — well-documented post-discontinuation |
| HiSilicon | Balong | LiteOS | Huawei devices | Low — restricted access |
Vendor Architecture Deep-Dive
> Qualcomm MSM
Powers the majority of Android devices globally. Firmware extracted via QFIL or EDL mode. The QuRT RTOS uses a microkernel architecture with hardware-enforced memory isolation between tasks. However, the cellular protocol handlers share a flat memory space, making intra-modem lateral movement trivial after initial exploitation.
> Samsung Shannon
Used in Samsung Exynos-based Galaxy devices and Google Pixels. Notable for multiple RCE vulnerabilities discovered by Google Project Zero in 2023-2024. Samsung has since added ASAN (AddressSanitizer) to Shannon firmware builds, making it the first baseband with runtime memory safety instrumentation.
> MediaTek
Dominant in budget and mid-range devices across emerging markets. The Nucleus RTOS runs a monolithic architecture where all tasks share the same address space. Less publicly researched but equally susceptible to firmware vulnerabilities — and deployed on billions of devices worldwide.
The Pre-Authentication Attack Surface
The critical insight for baseband exploitation is that a significant portion of the cellular protocol stack must be processed before mutual authentication is established. When a UE (smartphone) encounters a new cell, the following messages are processed without any cryptographic protection:
- MIB (Master Information Block): Broadcast on the Physical Broadcast Channel (PBCH) — contains basic system parameters
- SIB (System Information Blocks): Broadcast on the DL-SCH — contains cell configuration, PLMN identity, access control
- Paging Messages: Addressed to specific UEs to notify them of incoming calls/data — processed in idle mode
- RRC Setup/Reconfiguration: Initial RRC connection establishment — occurs before NAS security is activated
- NAS Identity Request: Pre-authentication identity queries (IMSI request in 4G, SUCI in 5G)
- NAS Authentication Request: The 5G-AKA challenge — malformed authentication vectors can trigger parsing bugs
- NAS Security Mode Command: Activates encryption/integrity — but the message itself is received before protection is active
- Tracking Area Update (TAU) Reject: Used to force devices off a network or into a different radio access technology
Every message above the double line is processed by the baseband in plaintext, with no integrity or authenticity verification. An attacker operating a IMSI catchers can inject arbitrary content into any of these messages.
II. Exploitation Techniques and Vulnerability Classes
Baseband firmware is written primarily in C/C++ with some ARM assembly, running on bare-metal or a minimal RTOS without modern exploit mitigations. Many baseband processors lack ASLR, stack canaries, or W^X memory protections, making exploitation significantly easier than application-layer attacks.
Vulnerability Classes
| Class | Description | Example CVEs | Exploitability |
|---|---|---|---|
| Stack Buffer Overflow | ASN.1/PER decoding of oversized RRC/NAS fields | CVE-2023-24033 (Shannon) | Critical — direct RIP control |
| Heap Overflow | Memory corruption in message reassembly buffers | CVE-2024-20069 (MediaTek) | High — requires heap shaping |
| Integer Overflow | Length field manipulation in TLV-encoded IEs | CVE-2022-20170 (Pixel) | High — leads to heap/stack overflow |
| Use-After-Free | Race conditions in connection state management | Various Samsung Shannon | Critical — arbitrary read/write |
| Type Confusion | Incorrect ASN.1 CHOICE/SEQUENCE handling | Google Project Zero Shannon findings | Critical — arbitrary memory access |
| Null Pointer Dereference | Missing validation on optional IEs | Numerous across all vendors | Low — typically DoS only |
ASN.1 Parsing: The Primary Attack Vector
Cellular protocols encode most messages using ASN.1 PER (Packed Encoding Rules) — a binary encoding format that is notoriously complex to implement correctly. The ASN.1 schemas for LTE and 5G NR are defined in 3GPP TS 36.331 (LTE RRC) and TS 38.331 (NR RRC) and contain deeply nested, recursive data structures with optional fields, variable-length arrays, and complex CHOICE types.
Typical fuzzing targets in ASN.1 RRC messages:
<CodeBlock language="c" filename="asn1_rrc_parsing_vuln_example.c" code="// Simplified example: Stack buffer overflow in SIB parsing // Real vulnerabilities follow similar patterns
typedef struct { uint8_t num_cells; // Attacker-controlled from OTA uint16_t cell_ids64; // Fixed-size buffer } NeighborCellList;
void parse_sib4(uint8_t *raw_msg, size_t len) { NeighborCellList ncl;
// BUG: num_cells read from OTA message without bounds check
ncl.num_cells = decode_integer(raw_msg, 0, 255);
// If num_cells > 64, this overflows the cell_ids buffer
for (int i = 0; i < ncl.num_cells; i++) {
ncl.cell_ids[i] = decode_integer(raw_msg, 0, 503);
// ^^^ Stack buffer overflow when i >= 64
}
}" />
Historical CVE Analysis: Real-World Baseband Exploits
| CVE | Vendor | Component | Impact | Discovery |
|---|---|---|---|---|
| CVE-2023-24033 | Samsung Shannon | SDP attribute parsing in IMS | Zero-click RCE via crafted SIP message | Google Project Zero |
| CVE-2023-26072-26076 | Samsung Shannon | NAS EMM/ESM message parsing | Pre-auth OTA memory corruption | Google Project Zero |
| CVE-2024-20069 | MediaTek | NAS message handler | Heap overflow in modem firmware | MediaTek PSIRT |
| CVE-2022-20170 | Google Pixel (Shannon) | NR RRC message parsing | Remote code execution | Internal Google security |
| CVE-2020-0069 | MediaTek | AT command interface | Local privilege escalation to modem | Multiple researchers |
| N/A (Pwn2Own) | Multiple | Various RRC/NAS handlers | Zero-click RCE demonstrated live | Pwn2Own Mobile (2023, 2024) |
III. Research Methodology: OTA Fuzzing Pipeline
Baseband research follows a systematic pipeline that requires both hardware and software infrastructure. The TelcoSec lab guide covers the prerequisite hardware setup in detail.
Phase 1: Firmware Extraction and Static Analysis
<CodeBlock language="bash" is-terminal code=" # Samsung Shannon firmware extraction (from factory image)
1. Download factory image and extract modem partition
tar -xf SM-G998B_firmware.tar.md5 simg2img modem.img modem.raw
2. Extract the Shannon binary from the modem partition
python3 shannon_fw_tools/extract.py modem.raw -o shannon_fw/
3. Load into Ghidra with ARM Cortex-R processor profile
Key analysis targets:
- NAS message dispatcher (look for ESM/EMM opcode switch tables)
- ASN.1 PER codec functions (look for uper_decode_* symbols)
- RRC reconfiguration handlers (SIB parsing, measurement reports)">
Phase 2: Dynamic Fuzzing Infrastructure
The OTA fuzzing setup uses a private lab with srsRAN to broadcast malformed messages to a target device:
<CodeBlock language="python" filename="rrc_fuzzer_example.py" code=" # Simplified: Sending a malformed RRC SystemInformationBlock
to trigger an ASN.1 parser overflow in the target baseband
from srsran_controller import GnbController import struct
gnb = GnbController(config='gnb_fuzz.yaml')
Build a malformed SIB4 with excessive neighbor cell count
malformed_sib = build_sib4( cell_barred=False, plmn_list={'mcc': '001', 'mnc': '01'}, # Trigger: nested SEQUENCE with depth > parser limit intra_freq_neigh_cell_list=overflow_payload( num_cells=256, # Exceeds expected maximum of 16 cell_individual_offset=15 # Valid range 0-30 ) )
Broadcast the malformed SIB on the BCCH
gnb.broadcast_sib(sib_type=4, payload=malformed_sib)
Monitor target device for crash via diagnostic interface
Samsung: Shannon IPC logs via /dev/umts_ipc0
Qualcomm: QXDM diagnostic messages via /dev/diag
MediaTek: CCCI IPC channel"
/>
Phase 3: Crash Analysis and Triage
After detecting a crash, the diagnostic logs reveal the crash context:
<CodeBlock language="text" filename="shannon_crash_dump.log" code="FATAL Exception: Data Abort at PC=0x41B8F230 DFSR=0x00000805 (Translation fault, Section) DFAR=0x48484848 ← Controlled value from OTA payload
Register dump: R0=0x48484848 R1=0x00000100 R2=0x41D0A000 R3=0x00000000 R4=0x41C12800 R5=0x00000003 SP=0x41D09F80 LR=0x41B8F1C4 PC=0x41B8F230
Stack trace: #0 0x41B8F230 rrc_decode_sib4_neighbor_list+0x6C #1 0x41B8E100 rrc_process_system_information+0x1A8 #2 0x41B8D000 rrc_handle_bcch_dl_sch+0x44 #3 0x41B80000 l2_dispatch_pdu+0x128">
The crash dump shows register R0 contains the attacker-controlled value 0x48484848, confirming that the overflow successfully corrupted a pointer used in a memory access operation. The stack trace reveals the exact code path from the broadcast channel handler through the SIB4 parser.
IV. Baseband-to-AP Escalation
Compromising the baseband is powerful on its own (call interception, SMS theft, location tracking), but the highest-value attacks escalate from the baseband to the application processor. This gives the attacker full control of the entire device — including encrypted messaging apps, authentication tokens, and stored credentials.
Escalation Vectors
| Vector | Mechanism | Difficulty | Impact |
|---|---|---|---|
| Shared Memory | Direct R/W to AP memory regions via MMIO | Medium — requires memory map knowledge | Full AP compromise |
| AT Command Interface | Inject AT commands to control AP modem HAL | Low — well-documented interface | Limited — depends on HAL permissions |
| RIL IPC Channel | Exploit the Radio Interface Layer daemon | Medium — requires serialization bugs | Root on AP (Android) |
| DMA Attack | Use baseband DMA engine to write AP memory | High — requires DMA controller access | Full AP compromise |
| USB/PCIe Bridge | Exploit the inter-processor communication bus | High — hardware-specific | Full AP compromise |
Defense Landscape
Modern devices are beginning to implement baseband isolation, though coverage remains inconsistent:
| Defense | Samsung | Apple | Qualcomm | Effectiveness |
|---|---|---|---|---|
| ASLR in Baseband | Partial (Shannon) | Yes | Partial | Medium — limited entropy |
| Stack Canaries | Recent firmware | Yes | Recent firmware | Medium — can be leaked |
| W^X Memory | Partial | Yes | Partial | High — prevents simple shellcode |
| ASAN (runtime) | Yes (Shannon) | No | No | High — catches memory corruption |
| AP-BP Memory Isolation | IOMMU | IOMMU + PPL | SMMU | High — but bypass research active |
| Baseband Sandboxing | Limited | Strong (SEPOS) | Limited | Varies — Apple leads |
V. Authoritative References
- 01 Google Project ZeroSamsung Shannon Baseband RCE Research (2023-2024)READ P0 RESEARCH →
- 02 3GPP TS 36.331E-UTRA Radio Resource Control (RRC) Protocol Specification3GPP TS 36.331 – LTE RRC Protocol →
- 03 3GPP TS 38.331NR Radio Resource Control (RRC) Protocol Specification3GPP TS 38.331 – 5G NR RRC Protocol →
- 04 MITRE FiGHTBaseband RCE via Rogue Base Station TechniqueMITRE FiGHT Threat Framework →
- 05 Samsung Mobile SecurityShannon Baseband Security UpdatesSamsung Mobile Security Advisories →
- 06 Qualcomm Product SecuritySnapdragon Modem Security BulletinsQualcomm Product Security Bulletins →
VI. Frequently Asked Questions
A zero-click exploit targets the baseband processor through malformed over-the-air messages. The victim doesn't need to click anything, open an app, or interact with their phone — simply being connected to a cellular network within range of a IMSI catchers is enough for the attack to execute. The malformed message is processed by the baseband's protocol parser before any user-level software is involved.
Yes, airplane mode completely disables the cellular radio and therefore the baseband processor cannot receive OTA messages. However, on some devices, the baseband firmware remains loaded in memory even in airplane mode, and the radio can be re-enabled without a full processor restart. For maximum security in high-risk environments, physically disabling the radio (Faraday bag) is recommended.
Yes. iPhones use Qualcomm or Intel basebands (and Apple's own modem starting with iPhone 17). The baseband firmware is equally opaque and subject to the same class of OTA vulnerabilities. Apple does apply stronger sandboxing between the baseband and AP processors (via IOMMU and the Secure Enclave), which can limit the impact of a modem compromise but does not prevent the initial baseband exploitation.
At minimum: a USRP B210 SDR, a compute node running srsRAN, a Faraday cage for RF containment, and programmable SIM cards. For firmware analysis, you'll need Ghidra or IDA Pro and vendor-specific diagnostic tools (QXDM for Qualcomm, Shannon tools for Samsung). See our complete lab setup guide for the full hardware procurement list.
Baseband patches are delivered through firmware updates, typically bundled with monthly Android security bulletins or iOS updates. The patch cycle averages 60-90 days from report to deployment. Unlike application patches, baseband updates require carrier certification in many regions, which can add additional delays. This extended exposure window makes zero-day baseband vulnerabilities exceptionally valuable to attackers.
IMSI catchers (rogue base stations) serve as the delivery mechanism for baseband exploits. The IMSI catcher forces the target UE to connect by broadcasting a stronger signal, then delivers malformed protocol messages during the pre-authentication phase. Without a rogue base station or compromised legitimate infrastructure, remote baseband exploitation over the air is significantly more difficult.
Conclusion & Next Steps
Baseband exploitation represents the frontier of mobile security research. As 5G NR introduces more complex protocol stacks (with larger ASN.1 schemas, new NAS procedures, and additional pre-authentication messages), the attack surface of the modem processor continues to expand. The convergence of IMSI catchers accessibility, pre-authentication attack surfaces, and minimal exploit mitigations makes the baseband the single most critical component for mobile security assessment.
The research pipeline for effective baseband security:
- Build the lab: Deploy private LTE/5G infrastructure with srsRAN and Open5GS
- Extract and analyze firmware: Use vendor-specific tools and Ghidra to map the protocol handlers
- Fuzz systematically: Target ASN.1 parsers in NAS, RRC, and IMS layers with structured OTA fuzzing
- Escalate and validate: Confirm exploitability and test baseband-to-AP escalation paths
- Disclose responsibly: Coordinate with vendors through 90-day disclosure timelines
Interested in developing baseband security capabilities for your organization? Explore TelcoSec's telecom pentesting methodology for the full offensive lifecycle, or browse the TelcoSec research library for related signaling and RAN security intelligence.