"Operator, can you hear me?" A Faithful Line into the UNISOC Baseband

“Operator, can you hear me?” A Faithful Line into the UNISOC Baseband Eduard Vlad, Philipp Mao, Marcel Busch, Mathias Payer EPFL Switzerland

arXiv:2608.07143v1 [cs.CR] 7 Aug 2026

Abstract Baseband processors are reachable over the radio at all times. Their most security-relevant logic runs deep inside protocol state machines: the control-plane handlers that gate registration, authentication, and session setup. Analyzing that logic systematically requires introspecting the firmware as it runs, which makes re-hosting the baseband necessary. Existing re-hosting work approximates the execution environment and under-approximates the SoC complexity of the baseband processor together with its surrounding components, bringing this state practically out of reach. We instead model each surrounding component, co-processors, SIM, application processor, from what a real device does, and step them in lockstep with the baseband on one shared clock. That makes faithfulness checkable at component interfaces, rather than assumed. We call this method unislop and demonstrate it on the UNISOC UDX710, a platform in an estimated 10–15% of cellular modems and in automotive systems, not systematically analyzed before. Starting from a Quectel RM500U-CNV module, we gain code execution, defeat its firmware-integrity check, instrument the baseband, and recover its peripheral environment from the running device. The resulting re-host reaches the same control-plane states as the real device, establishes a full PDU session, and carries real IP traffic on both ingress and egress. The recovered components are shared across UNISOC’s baseband lineup, so with additional reverse-engineering effort the same design extends to further targets.

1

Introduction

Cellular basebands are always-on, radio-reachable computers embedded in phones, vehicles, routers, and industrial IoT [22–24, 26]. They expose complex functionality in the form of stateful protocol handling. The handlers that matter, such as 5G RRC and NAS, EAP-AKA′ , and SIP/IMS, run only after a sequence of messages has driven the stack into an accepting state. Reaching and exercising these deep state machines on real firmware is largely unexplored, because it requires running the firmware itself, faithfully, all the way into those states. Faithful firmware emulation is therefore the enabling problem, and it is unsolved. Prior Art. Prior work reconstructs the baseband by approximating its functionality and its execution context. As a consequence, only a subset of its functionality can be exercised. BaseBridge [14] snapshots execution through vendor debug features, but abstracts critical system-on-chip (SoC) details and thus, cannot follow the message sequences that induce critical state transitions. FirmWire [11] disables the RTOS tasks with hardware dependencies, so large parts of the baseband cannot be executed. Loris [25] isolates a single control-plane task with concolic execution and abstracts everything that happens outside it. Under-approximating the

context drops functionality the firmware depends on, while overapproximating it does not scale and forces a narrow scope, so in both cases the functionality of interest is missed. This happens because a baseband is not a single processor: it interacts continuously with L2 co-processors and DSPs, clocks, cryptographic engines, the SIM, and the application processor. Reconstructing the firmware alone, without the state and behavior of these components, inevitably forces either under- or over-approximation to reach the relevant protocol surfaces. For example, the application processor drives the baseband to attach to a base station. Trying to exercise protocol surfaces without an application processor (without connecting to a base station) cannot be done faithfully. Insight. We reconstruct baseband functionality and state handling by controlling SoC components, peers, concretely instead of approximating them. We drive these SoC peers and the time progression from the same clock cycles, which determines execution and lets us present each component with the behavior the firmware expects, when it expects it. We do not only replicate the baseband to run the firmware, we build the surrounding state that the firmware acts on. To know that the reconstruction is correct, we need a notion of faithful emulation. Challenges. Faithful emulation depends on three linked properties. First, the components must be present with correct interfaces; an absent one makes the firmware assert, and an approximated one diverges silently. Second, they must be exercised in the right order and timing to build the state that gates each handler, which requires the first property. Third, execution and protocol state must be observable, otherwise the first two cannot be ensured. All three must hold together, and determinism is what makes them hold the same way on every run. We assess these properties through fidelity, our notion of correctness. An emulation is faithful when its interaction with the surrounding components matches the real device at the inter-SoC peripheral interfaces. We therefore measure fidelity against real silicon at these interfaces instead of assuming it, and use it to decide whether the three properties are fulfilled. Solution and Instantiation. We address this with unislop, a five-step method for gaining full and faithful execution of a UNISOC baseband: obtain code execution, run arbitrary firmware, instrument it for tracing and introspection, use that access to recover the surrounding components and their behavior on real silicon, and reconstruct them as a deterministic emulation. We target UNISOC because it is important and undocumented: it accounts for an estimated 10–15% of cellular modems [19], reaches automotive head units [13], and has no published systematic analysis. The platform is closed and protects firmware loading with a software integrity check, so obtaining code execution and loading custom firmware past this check is itself a contribution and a prerequisite for the rest.

Baseband Processor

Application Processor

control-plane CPU, RTOS

host OS

DMA

Ring Buffers

IRQ

MMIO

Core Network ð

Access Stratum

APDU

UE Interconnect

Layer-2 Co-processor T

Digital Signal Processor 

Crypto Engine µ

SIM / UICC

Hardware Accelerator 

Audio Codec Á

AMF

gNB (RAN)

Figure 2: Simplified 5G Network Architecture.

Figure 1: Baseband SoC. The baseband and application processors, and the co-processors and peripherals, all communicate over dedicated interconnects (DMA, ring buffers, IRQ, MMIO, APDU). We model the peers that gate control-plane state.

that terminates the air interface, and the core network that provides authentication, mobility, session management, and data connectivity (Fig. 2). Control-plane signaling uses RRC between the UE and the RAN and NAS between the UE and the core, which the RAN relays transparently; downlink and uplink denote network-to-UE and UE-to-network messages. A typical 5G attach proceeds from RRC connection setup through NAS registration, mutual authentication, and security-mode configuration, to data-session establishment. Along the way, security contexts, identifiers, sequence numbers, and counters accumulate as state that gates later handling, which is exactly the state a faithful emulation must reconstruct.

We apply unislop to the UNISOC UDX710 baseband and demonstrate the first emulated baseband that can exercise the entire 5G handshake and establish a full IPv4 PDU session with real ingress and egress data. Contributions. We present unislop, the first systematic security analysis of a UNISOC baseband. Our contributions are threefold: (1) we unlock and instrument a previously undocumented UNISOC baseband, including a bypass of Quectel’s firmware-integrity protection; (2) we introduce peer- and interconnect-driven re-hosting, a design principle for deterministic baseband emulation with an operational definition of fidelity at the interconnect boundary; and (3) we validate unislop on the UDX710, showing it reaches the same control-plane state transitions as the real device and carries genuine control- and data-plane traffic through a full PDU session.

2

Non-AccessStratum

3

The UNISOC UDX710 Baseband

The UNISOC UDX710 is a 5G baseband platform which extends well beyond smartphones. It ships in modem modules such as the Quectel RM500U-CNV, which integrators embed in industrial routers, home gateways, digital signage, and a range of other IoT devices [13, 24]. A vulnerability in this baseband reaches a broad ecosystem of connected devices, not only phones. Yet UNISOC is undocumented, and to our knowledge no prior work has published a systematic analysis of a UNISOC baseband, so gaining access to and instrumenting it is itself a prerequisite we must establish. We study the RM500U-CNV as a standalone module rather than as part of an end-user device. It exposes USB and PCIe host interfaces; we use USB through a dedicated adapter board, which carries AT commands, ADB access once enabled, and the logging and introspection we rely on later. For over-the-air validation we attach the modem to a controlled 5G testbed: a host PC runs the base station and core network while an SDR provides the radio link (Fig. 3), letting us drive real network procedures while observing the modem over USB. Outline. In the following, we work through a five-step chain that makes the baseband testable and analyzable. First, we obtain a software foothold and unlock the device (§4); we then reverseengineer the platform and bypass firmware verification to run modified images (§5). We instrument the baseband for tracing and introspection (§6); we reconstruct the peripheral environment the firmware expects (§7); and finally we re-host the baseband as a deterministic emulation (§8).

Background

Baseband Architecture. A baseband processor implements cellular communication and, together with the subscriber identity module (SIM), forms the user equipment (UE). Functionally, it runs the cellular protocol stacks in software on a real-time operating system (RTOS), with tasks for Radio Resource Control (RRC), Non-Access Stratum (NAS), and the lower layers, communicating through queues and shared memory under tight timing constraints. Structurally, it is not a single processor but one component of a System-on-Chip (SoC), shown in Fig. 1. An application processor (AP) drives the baseband, for instance to bring up a data or voice session. Co-processors and peripherals perform the work the baseband offloads: a Layer-2 co-processor and a digital signal processor (DSP) for physical-layer and MAC processing, a cryptographic engine for ciphering, integrity, and key derivation, hardware accelerators for the data path, the SIM for credentials, and an audio codec for voice. Every component communicates to the baseband over a dedicated interconnect: direct memory access (DMA), ring buffers, mailboxes with interrupts (IRQ), memory-mapped I/O (MMIO), and, for the SIM, APDU exchanges. Some of these components can carry attacker-controlled input, for example the AP, the SIM, and the Layer-2 co-processor. Re-hosting a baseband is not as simple as emulating its processor, then: the firmware’s handling of each message depends on state built through timed interactions with exactly these co-processors and peers, so stubbing or approximating them breaks that state and, with it, correct message handling. Cellular Networks and Protocols. Beyond the UE, a cellular network comprises the Radio Access Network (RAN, e.g., a 5G gNB)

4

Gaining a Foothold

Our first step is to obtain a software-level foothold on the RM500UCNV. As the modem exposes only host-facing interfaces by default, we begin with firmware acquisition and static analysis before enabling interactive access to the device. Firmware Acquisition and Initial Inspection. We download the latest firmware available for the RM500U-CNV through 2

After reconfiguring the USB interface, the modem exposes ADB and provides a root shell on the Linux subsystem. This gives us our first foothold on the platform and allows us to continue the analysis from within the device.

5

To analyze the baseband, and ultimately to re-host it, we require access to internal APIs and data structures via instrumentation. We first map the platform to find the firmware and how it is loaded, then defeat the check that prevents us from replacing it. The root shell obtained through ADB gives us access to the Linux subsystem of the RM500U-CNV. However, this subsystem is not the LTE/5G baseband itself. Instead, it acts as an orchestration layer for device management, peripheral initialization, firmware loading, and coordination of the remaining processors on the platform. Baseband Firmware Loading. Having established that Linux orchestrates the remaining co-processors on the platform, we next investigate how it loads and starts the LTE/5G baseband firmware. This orchestration path is necessary because it provides the boundary between the host-facing Linux environment and the ThreadXbased baseband subsystem which we intend to analyze. We first analyze the proprietary modem_control binary, which manages the boot process of the modem subsystem. By reverse engineering this binary, we find that Linux loads baseband firmware through a vendor-specific procfs interface exposed by the cptl kernel component. For the LTE/5G baseband, the modem_control binary writes the firmware image to: /proc/cptl/modem and starts it by writing 1 to /proc/cptl/start. Tracing the firmware source further shows that these images live on the Linux side as named UBI volumes, one per component: for instance ubi0_nr_modem holds the baseband firmware, ubi0_nr_nrphy the NRPHY firmware, and ubi0_nr_runtimenv1 the runtime non-volatile data, among more than twenty in total. Because they are mounted as UBIFS images on the running device, we dump each one over ADB and analyze it offline, recovering the baseband and co-processor firmware. For the baseband, this also gives a concrete loading path for testing whether the platform accepts modified firmware. Testing Firmware Integrity. To understand whether the platform verifies baseband firmware before execution, we modify one byte in a copy of the baseband image and attempt to boot from the altered firmware. The kernel rejects the image and reports the following messages in the dmesg buffer, confirming an implemented integrity check before starting the baseband firmware:

Figure 3: Experimental testbed for connecting the Quectel RM500U-CNV to a self-provisioned gNB and core network. The testbed provides access to gNB, core network and baseband logs; automatically establishes a data session and supports application processor-originated AT commands.

Quectel’s support channels. The firmware images are not publicly hosted; in practice, access requires requesting firmware through Quectel’s forum or support moderators. After receiving the firmware image, we find that it is not encrypted and can be unpacked directly. Initial inspection shows that the platform contains a Linux-based ARM64 subsystem: 1

Linux udx710-module 4.14.98 #1 SMP PREEMPT Tue Jul 1 14:17:41 UTC 2025 aarch64 GNU/Linux

The unpacked filesystem contains several binaries relevant for further analysis. Specifically, we identify components responsible for AT command handling (atrouter), modem control and device configuration (modem_control), and Android Debug Bridge support (adbd). The presence of adbd suggests a path to interactive shell access, however, no ADB interface is exposed by default. Unlocking ADB. To understand why ADB is present but not reachable, we search the firmware for ADB-related references. This leads us to the proprietary atrouter binary, which implements the AT command AT+QADBKEY. Reverse engineering this command shows that the firmware derives an ADB unlock key from the device serial number and a salt embedded in the binary. For firmware version 5G_MODEM_21A_W23.38.3_P28, the procedure starts by querying the modem for the ADB challenge over the AT interface exposed on /dev/ttyUSB4: 1 2

1

AT+QADBKEY? ABCDEF_7_13_27

2 3

We then compute the corresponding unlock key using the salt recovered from the atrouter binary: 1

2

2

user.err kernel: [ts] c1 cmp hash_data diffent user.err kernel: [ts] c1 verify modem failed user.err kernel: [ts] c1 cproc: cptl verify err!

Bypassing Firmware Verification. We reverse engineer the verification path by analyzing the compressed vmlinuz image shipped with the firmware. We find that the verification logic is implemented in the proprietary cptl kernel module and is not backed by a hardware root-of-trust. The verification therefore depends on software running inside the Linux kernel, where we have root privileges. The kernel does not expose convenient debug interfaces such as /dev/mem, which would allow us to patch kernel memory directly at

/usr/bin/openssl passwd -1 -salt "QUE_V002" " ABCDEF_7_13_27" $1$QUE_V002$rjihvi4Ai1D3AswNWdCt7.

We submit the computed key and reconfigure the USB composition to expose ADB: 1

Running Modified Firmware

AT+QADBKEY="rjihvi4Ai1D3AswNWdCt7" AT+QCFG="usbcfg",0x2C7C,0x0800,1,1,1,1,1,1,0 3

runtime. However, the platform does not enforce signature checks for loadable kernel modules. We write a kernel module that searches kernel memory for the byte pattern corresponding to the identified verification routine. Once located, it resolves the physical page backing the target kernel virtual address, remaps it as writable, and patches the verification logic to return success regardless of the verification result. During development, we also observe that the kernel base address is not randomized, and fine-grained KASLR is not available. We provide a trace of loading the kernel module below: 1

These messages are immediately useful for checking whether the modem reaches expected boot and firmware states. (ii) Tracepoints, where logs contains only a tracepoint identifier and the values of its arguments, while the corresponding format string is stored separately in the vendor’s diagnostic tooling. Recovering Tracepoint Strings. To decode these tracepoints, we analyze Quectel’s diagnostic tooling, Logel, which is distributed through the same forum and support channels used to obtain the firmware. We find that Quectel Logel retrieves a Windows shared library that contains the mapping between tracepoint identifiers and human-readable format strings. This library is publicly accessible without authentication and contains tracepoint dictionaries for multiple UNISOC-based basebands. By reverse engineering the library, we recover the tracepoint-to-string mapping for our target and use it to decode high-level the baseband logs from /dev/slog_lte. This gives us an extensive view into the running stack and also documents control-plane progress during connection establishment. We use this mechanism as a convenient way to validate later modifications, including injection of custom debug messages into the baseband firmware. Injecting Probes. The logs show which protocol states the baseband reaches, but not how the code produced them, and they give us no way to read arbitrary memory or change state at runtime. To gain this capability, we add instrumentation to the firmware. Since we can already run modified images, we insert small shellcode snippets into the Cortex-R8 firmware, compiled with arm-none-eabi-gcc and using naked functions where needed to control the prologue, stack layout, and register preservation. These probes let us dump memory, print custom values, and modify variables at runtime, but on their own they only expose behavior at manually selected locations and give no general execution feedback. Extending Instrumentation Space. Small probes require little space, but injecting extensive tracing instrumentation needs room for trampoline code, metadata, and a reserved trace map. In addition, we find that appending bytes to the firmware does not make them available at runtime. By inspecting the firmware header, we find that it encodes the size of the baseband image loaded into memory. Adjusting this field allows us to expand the loaded firmware image and use the full 32 MB available in the baseband memory region. However, not all added memory remains usable after boot, even if successfully loaded. To identify stable regions, we fill the extended area with a known pattern and dump memory after initialization. Only about 200 kB remain untouched, as other parts are zeroed out for heap objects, memory pools, and statically allocated data. We therefore reverse engineer the baseband boot process and identify initialization tables that configure MPU regions and section handlers. By patching these tables, we reclaim more than 2 MB of memory that remains accessible at runtime and use it for instrumentation code and tracing data. Execution Tracing. Hand-placed probes are still too coarse to show how execution flows through the firmware. As the finest layer of introspection, we add lightweight execution tracing: we record only which call sites execute and record a low-overhead trace of the path the firmware takes that the logs cannot provide. We implement this tracing by statically rewriting selected call sites in the firmware.

root@udx710-module:/ # insmod overwrite-module.ko pattern= fd7bbda90210c0d2

2 3 4

5 6 7 8 9 10 11 12 13 14 15

[ts] c1 hexscan: printk=ffffff80080f29c0 [ts] c1 hexscan: scanning [ffffff8007e97358 .. ffffff8008297358 ) < snip > [ts] c1 hexscan: writing 30000014 to target address [ts] c1 hexscan: MATCH VA=ffffff8008097378 PA=0x7f8088097378 < snip > [ts] c1 table base: ffffff8008dc4000 [ts] c1 end of translation reached after 2 steps! [ts] c1 *test_pageentry=00e8000084295f13 [ts] c1 *ver_pageentry=00c0000080200f91 [ts] c1 flushed. < snip > [ts] c1 hexscan: done; matches=1

Confirming Modified Firmware Execution. After loading the kernel module, the platform accepts modified baseband images. To confirm that the bypass affects the actual firmware executed by the Cortex-R8 subsystem, we modify the baseband version string, reboot the modem, and observe the modified string when querying it via the AT command AT+GMR. This confirms that we can execute modified LTE/5G baseband firmware and provides the basis for injecting instrumentation.

6

Introspecting the Baseband

To understand what the baseband does, we have to watch it run real procedures. We build this visibility in layers. We first drive the modem with a live network so that it performs a real registration, then read what the platform already exposes through its logs, and finally, where the logs fall short, instrument the firmware to inspect and modify execution at runtime. Controlled OTA Baseline. Observation is only meaningful once the baseband is doing real work, so we first drive it with a controlled network. We connect the RM500U-CNV to a local 5G testbed built from an SDR, a software gNB (srsRAN [28]), and a core-network backend (open5gs [4]), and provision a programmable SIM with credentials matching the core so the modem authenticates and registers (cf. Fig. 3). This gives us a reproducible, functional registration that we treat as ground truth throughout: it is the reference against which we validate every firmware modification and, later, the behavior our re-hosted baseband must reproduce. Baseband Logs. From the Linux subsystem, the baseband log stream is exposed through /dev/slog_lte. Copying from this device file during a normal connection establishment produces tens of megabytes of binary log data. The stream contains two types of entries: (i) Plain debug strings or string references that can be resolved directly from the firmware. 4

Metric

1

Count

2

Basic blocks Branch instructions Fixed-target call sites Register-indirect call sites

1,031,523 364,527 51,100 12

3

__attribute__((naked)) void _start(void) { save_lr();

4

int lr_addr = 0;

5 6

Table 1: Static analysis results used to select executiontracing targets.

/* Load context from reserved memory region */ cov_ctx_t ctx = { .hdr = (cov_hdr_t *)COV_HDR_ADDR, .map = (char *)COV_MAP_ADDR, };

7 8 9 10 11

_start: stmdb sp!, {r0, r1, r2, r3, r4, r5, r6, r7, r8, r9, sl, fp, lr} bl 0 <instrumentation_target> ldmia.w sp!, {r0, r1, r2, r3, r4, r5, r6, r7, r8, r9, sl, fp} bl e00000 <original_target>

12

/* Tracing is enabled after boot completes */ if (!is_cov_ready(&ctx)) { goto retfn; }

13 14 15 16 17

/* Re-execute overwritten instructions */ PATCHED_INSN(lr_addr); /* Record tracing instrumentation hit */ cov_hit(&ctx, lr_addr);

18 19

Figure 4: Trampoline emitted at each instrumented fixedtarget call site. It saves the execution context, calls the instrumentation target, restores the context, and branches to the original call target.

20 21 22 23 24 25

retfn: ret(); }

26

This is challenging since the firmware is proprietary and combines mostly Thumb code with some ARM32 regions. Therefore, instruction rewriting first requires reliable mode information. We use Ghidra scripts to identify candidate call sites together with their execution mode and target addresses in Table 1. Full basic-block instrumentation is impractical: instrumenting all 1,031,523 basic blocks would require more than 16 MB of trampoline code, exceeding the 2 MB memory we can safely reclaim. Instead, we instrument fixed-target call sites. Ghidra identifies 51,100 such sites, which require approximately 817 kB of trampoline code and a 65 kB trace map. Both fit within the reclaimed memory region. Each trampoline saves the execution context, calls our instrumentation target, restores the context, and then branches to the original call target (Fig. 4). The instrumentation target itself checks a runtime flag before writing trace entries, which lets us enable collection only after the modem has completed initialization (Fig. 5). At runtime, the execution-trace map is stored in the reclaimed baseband memory region. From the Linux subsystem, we dump this region through the existing /proc/cptl/modem interface by seeking to the trace-coverage-map address and reading the corresponding memory range. This allows us to collect execution traces between runs without rebooting the full device. Protocol-Level Instrumentation. Execution traces tell us which code is executed, but not which protocol messages caused it. We therefore add probes around RRC transmission and reception paths. These probes dump incoming and outgoing payloads, queue items exchanged between tasks, and messages passed between RRC and lower layers. By correlating these dumps with execution-trace feedback, we connect protocol-level behavior to internal execution paths. We also find the functions that update protocol state; by hooking them we can watch how the state changes, a capability that is useful for testing. Interactive Debug Task. Beyond static probes and tracing, we also add a small interactive debug task to the ThreadX firmware. By reverse engineering the RTOS task-creation routines, we find

27 28 29 30 31

/* Tracing hit instrumentation */ void cov_hit(cov_ctx_t *c, int lr) { /* Auxiliary helpers */ c->hdr->iter_count += 1; c->hdr->last_lr = lr;

32

/* Reconstructible IDX mappping */ unsigned int idx = map(lr) % (COV_MAP_SIZE - 1u);

33 34 35

c->map[idx]++;

36 37

}

Figure 5: Instrumentation target invoked by the trampoline. It records a trace hit only once the modem reports boot completion, re-executes the instructions overwritten by the patch, and folds the return address into the trace map.

that the firmware allows new tasks to be spawned at runtime. We use this mechanism to create a custom debug task during boot and provide it with its own stack and command handler. The task exposes a simple switch-based interface for runtime experiments. It supports commands such as memory peek and poke, controlled assertions, packet injection, tracing control, and calls to selected firmware functions with custom arguments. This gives us a practical way to explore firmware behavior interactively without rebuilding the firmware image for every small experiment. This task complements the static instrumentation pipeline: the trampolines provide systematic execution tracing, while the debug task provides an interactive control channel for experiments.

7

Reconstructing the Peripheral Environment

The instrumentation introduced above lets us place a probe at any point in the firmware, in particular at the boundaries between SoC processors. Combined with the testbed, which drives real traffic across the {AP, NRPHY, SIM, SEC Engine} ↔ baseband boundaries, this exposes actual peer behavior. 5

Firmware (loaded by AP)

Application Processor

SIM (pre-programmed)

2 × Cortex-A55 · Linux

and inter-processor interrupts, in one of two patterns (cf. Fig. 7). In a solicited exchange, the baseband issues a request and the peer returns the matching response. In an unsolicited exchange, the peer raises an indication on its own, and the baseband replies. Most peers use both directions, so we describe each one below in terms of the messages it exchanges under both patterns. Application Processor. The application processor drives the baseband over two channels. The first carries high-level AT commands, which the baseband parses and answers. The second operates at a lower level and is more difficult to reconstruct: over the smsg/sblock control channel, the AP configures a data-plane Ethernet interface between the AP kernel and the baseband, set up together with the SIPA hardware module that accelerates the IP data path. Both channels mix solicited and unsolicited messages: the AP issues unsolicited commands, for example to force registration or attach, and in turn receives unsolicited messages from the baseband, such as notifications that the SIM is ready or that the baseband has come up. NRPHY Co-Processor. The NRPHY co-processor runs the lower layers of the 5G stack (PHY and MAC). The baseband communicates with it through the NRPAL task over shared-memory ring buffers and inter-processor interrupts, using both patterns: a solicited request is delivered to the NRPHY as an indication and answered with a response the baseband receives as a confirmation, while an unsolicited indication from the NRPHY, for example a synchronization event or a received transport block, is answered by the baseband. SIM Card. The SIM differs qualitatively from the other peers. It is not only storage for secrets: it is a separate secure processor running Java applets [18], performing key derivation and holding non-volatile state, reached by the baseband over the standardized APDU protocol. Unlike the other peers, which are asynchronous and signal completion by interrupt, the SIM is driven synchronously: the baseband issues an APDU and blocks on the reply; if the card is unreachable or does not answer in time, the baseband gives up and assumes no SIM is present. A working SIM is therefore a precondition for cell attach and authentication, the two steps that gate all further baseband operation. Reconstructing this peer means standing in for the applet and its APDU exchange. Crypto Co-Processor. The crypto co-processor is implemented entirely in hardware, so unlike the other peers there is no firmware to reverse engineer. The algorithms it runs are standard and well documented, but its interface to the baseband, the registers and DMA channels it exposes, is undocumented and can only be recovered by observation on real silicon. It is nonetheless essential: it verifies the authenticity and integrity of protected messages, and the baseband cannot proceed past security-mode setup without it. NVRAM. Not every environmental dependency communicates with the baseband as a peer. The non-volatile memory (NVRAM), shipped as multiple baseband memory-mapped UBIFS volumes (§5), holds RF calibration data and configuration parameters and is mapped directly into the baseband’s address space rather than accessed through request/response messages. Yet it is critical: if it is absent, or mapped at the wrong location, the baseband fails to boot. Dumping the image itself is trivial, as it can be extracted like any other UBI volume; what matters for reconstruction is placing it at the address and offset the firmware expects.

Silicon-only Hardware loads firmware, drives

Baseband Processor 2 × Cortex-R8 · ThreadX

Crypto SEC Engine

NRPHY 2 × Cortex-R5

NR DSP CEVA-XC4500

IP accellerator (SIPA)

NR L1/L2

NVram

Clock

Hardware

SIM / UICC

Configuration

Figure 6: Reverse-engineered architecture of the RM500UCNV. The application processor loads and drives the baseband, which coordinates the co-processors and peripherals. Stars mark what each component is: firmware loaded by the AP, the pre-programmed SIM, or fixed hardware.

Baseband (Peer HAL Task)

(1) REQ / (2) IND

SoC Peer (4) CNF / (3) RSP

Solicited Communication

Baseband (Peer HAL Task)

(2) IND / (1) REQ

SoC Peer (3) RSP / (4) CNF

Unsolicited Communication Figure 7: Communication modes between the baseband and the SoC peers. Solicited communication is basebandoriginated, e.g., SIM requests, while unsolicited communication is originated by an SoC component, e.g., the AP.

Applying static analysis to co-processor firmware images alone to recover peer behavior is generally infeasible: corresponding logic is distributed across images or implemented partly in hardware. It can only be recovered by observing execution during runtime. We use this runtime behavior to characterize each peer the baseband depends on, which we reconstruct as a model in the emulator. The resulting architecture, shown in Fig. 6, focuses on the components relevant to 5G operation and omits legacy subsystems, such as GSM and UMTS processing, which are outside the scope of this analysis. Overview. The Linux subsystem runs on two ARM Cortex-A55 cores and provides the host-facing management environment. The LTE/5G protocol stack executes separately on two ARM Cortex-R8 cores running Microsoft ThreadX. Additional co-processors implement lower-layer functionality, including PHY and MAC processing. Our actual analysis target is the ThreadX-based baseband firmware executing on the Cortex-R8 subsystem, while the Linux subsystem serves as the entry point for controlling and observing it. Communication Model. Most peers exchange messages with the baseband asynchronously, over shared-memory ring buffers 6

Together with the clock, these peers and the NVRAM configuration constitute the environment the baseband depends on to execute. Having characterized what each one does and when, we can now reconstruct each peer as a model, map the NVRAM image at the address the firmware expects, and drive the firmware against these models deterministically, in an emulator (§8).

8

real network procedures; (iii) the firmware images of the baseband and every co-processor it depends on, for static analysis; (iv) visibility into the Linux kernel’s radio-interface-layer driver, the only source of AP-originated commands; and (v) the emulator itself: a QEMU machine for the baseband core, together with a model for every peer it depends on. Together, these give us every introspection point needed to reconstruct each peer as a model. Existing baseband re-hosts rely mainly on (iii) and (v), a firmware image and an emulator core. Treating (i) as live probing, as opposed to memory-snapshotting [14], and adding (ii) and (iv), is what faithful, peer- and interconnect-driven re-hosting additionally requires.

Deterministic Baseband Re-Hosting

On-device instrumentation makes the baseband observable, but it is not practical to drive at scale: (i) every experiment requires a full SoC reboot with at least 60 seconds of execution time. (ii) Additionally, driving even a live procedure needs a provisioned SIM and a full radio testbed rather than a single command; and the probes recovered in §6 were themselves expensive to build, so adding a new one for every question does not scale. (iii) Finally, tests can only be carried out on-device impacting horizontal scaling of experiments. We therefore postulate the same access without the on-device cost: we run the same firmware off the device, under a virtual clock we control, so that resets are cheap, instrumentation is trivial to add, and every run reproduces. Re-hosting is the final step of the chain this case study has followed: gaining code execution, running modified firmware, adding instrumentation, and recovering the peer models of §7 now let us run the firmware against those models deterministically.

8.1

8.3

Peer- and Interconnect-Driven Re-Hosting

We define a QEMU machine for the baseband’s Cortex-R8 subsystem, constrained to the same rules as real silicon: the firmware may only be driven through the SoC interconnect and peripherals, i.e., DMA, message rings, mailboxes, interrupts, MMIO, and APDU (cf. §2). We never hook arbitrary functions or write to memory the firmware does not already share with a peer over that interconnect. Every component so introduced is characterized peer by peer in §7. Consequently, emulation fidelity rests on two properties that do not always coincide: (i) fidelity to a peer’s behavior, and (ii) fidelity to the interconnect it uses to express that behavior. We illustrate both dimensions with an example: the NRPHY co-processor does not signal a pending downlink message over a GIC interrupt line; it rings a fixed inter-core mailbox doorbell, which only the baseband firmware’s mailbox HAL observes and never re-raises as a GIC interrupt. A model that injected a GIC IRQ instead, assuming any interrupt mechanism would do, would capture the peer’s intent but miss its interconnect, and the firmware would never reach the intended downlink handler. We refer to this abstraction as peer- and interconnect-driven rehosting: we reconstruct every peer the firmware depends on from every introspection point available, static and dynamic, and drive the firmware only through the exact channels a real peer would use, rather than re-hosting the firmware in isolation and patching around whatever is missing.

8.2

Re-Hosting Methodology

The interconnect fixes a clear abstraction: a peer is fully described by the MMIO regions, DMA ranges, doorbells, and interrupts it exposes, and the firmware’s behavior is entirely determined by what it reads and writes on the interconnect. Therefore, a faithful model has to respect this boundary rather than the firmware’s internal state. We first identify addresses, IRQs, and doorbells, (i) statically from a firmware image or the kernel driver where one is possible, and (ii) dynamically by probing the real device where runtime information is required. Once located, we inspect the values egressed and ingressed at these call and read/write sites. An execution trace allows inferring which code region to instrument: an interrupt service routine, or the code that reads a specific memory address. Probing exactly those points lets us formalize a peer’s message formats and firing conditions from introspection rather than static assumption. This order, (i) locate the addresses, (ii) trace the execution, (iii) then probe the sites it points to, is the same for every peer. In practice, fidelity follows directly from what the testbed lets us drive and inspect, not from an a priori scope decision: we model only what we can exercise. Modeling another co-processor is therefore not free; it requires extending the testbed to reach it. LTE PHY, for instance, is driven over a different channel than NRPHY: modeling it first requires driving the baseband down that channel to have anything to inspect [14].

8.4

Determinism

Execution determinism is a key requirement for re-hosting: peer fidelity, interconnect fidelity, and reproducibility ultimately rely on whether execution follows the same virtual timeline real silicon would, not only whether the same events eventually occur. Protocol timers show this distinction: the cellular control plane is timer-driven throughout. Guard timers, supervision timers, and retransmission timers release a connection or trigger a state transition once no response arrives in time, and each one only fires, or stays silent, if the firmware’s notion of elapsed time tracks real hardware. If timers are modeled too loosely, events either fire early and abort a procedure that would have completed on real silicon, or never fire at all, silently dropping behavior the evaluation depends on. We therefore derive the firmware’s notion of time from its own execution, not the host clock. We run the guest under QEMU’s icount mode at shift=3, which ties virtual time to the guest’s

Faithful Re-Hosting Requirements

Building a faithful re-host this way rests on five requirements: (i) a real device available for instrumentation and live interconnect probing; (ii) a controlled radio testbed, to drive the baseband through 7

advance N clock model

I/O

Legend: ↔ async: queued at tick ↔ sync: blocking, immediate

Emulator

Orchestrator

QEMU / vCPU yield

representation of the initialization and steady-state co-emulation of peers and the emulator is given in Fig. 9. The orchestrator is not only waiting for control to return to it; it chooses the size of every quantum to be the exact distance to an unsolicited peer event. Therefore, the boundary at which it regains control is always self-chosen. Every scheduled action is therefore a function of virtual time or of a modeled hardware event the firmware itself produced. Importantly, we forbid pacing by wall-clock sleeps, retransmission on timeout, and synchronizing on a decoded log line, since all three make the outcome depend on host scheduling rather than on the guest’s own state. Deterministic Snapshots. Determinism yields a second benefit beyond reproducibility: a copy-on-write fork() is valid at any point in the run, not only at boot. This holds because every peer, not only the firmware, advances exclusively on the same instruction-counted grid and never reads wall-clock state. We exploit this property directly in the implementation: each peer is a non-blocking step function, one that drains whatever input is ready, reacts, and returns, rather than a loop that owns its own thread, and the same per-tick callback that advances the virtual clock drives every peer’s step in turn. At any instant, therefore, exactly one thread of control exists in the whole process, guest and peers alike, which is precisely what a safe fork requires: taken at a quantum boundary on that thread, it captures the guest CPU, guest RAM, and every peer’s state together, as a single image.

R/W

STEP

read @ yield

REQ

Async Peers

Interconnect

AP · NRPHY · DSP

Rings · IRQ · MMIO flush @ tick

Sync Peers SIM · SEC RSP

Figure 8: The co-emulation architecture. The orchestrator drives the emulator on a strict advance/yield credit protocol and steps every async peer directly; the emulator itself never addresses a peer, it only reads and writes the interconnect, the modeled hardware mechanism. The interconnect queues async-peer I/O and applies it only at the next tick boundary; sync peers are instead reached through a direct blocking callback that returns before the tick ends.

retired instruction count: one ThreadX RTOS timer tick, the smallest interval the firmware’s scheduler observes, corresponds to 125,000 instructions, i.e., 1 ms of virtual time, regardless of how long that takes to compute on the host. The difference is measurable: under plain QEMU TCG, the periodic tick preempts a realtime-sensitive routine, for instance the SIM bring-up walk, at a host-jitter-dependent point on every run. Its depth and reset count subsequently vary run to run and introduce non-determinism. Under icount, two independent runs of the same routine produce a byte-for-byte identical trace. Instruction-counted time makes the firmware itself deterministic; the only source of non-determinism left is when, and what, a peer injects. We hold peers to the same requirements: every peer input is delivered only at a tick boundary the firmware’s own clock has reached, never on a wall-clock schedule, a retry, or decoded log output, so that timer-dependent behavior on both sides of the interconnect tracks one virtual timeline. Execution Model. Fig. 8 lays out the components this model coordinates. An orchestrator owns virtual time; the emulator runs the guest and never addresses a peer directly, only the modeled interconnect; and the peers on the other side of that interconnect split into the two channel kinds already mapped out there: asynchronous peers (AP, NRPHY, DSP), whose input the interconnect only applies at a tick boundary, and synchronous peers (SIM, SEC), reached through a direct blocking call that returns before the tick ends. The orchestrator drives the emulator in bounded units of virtual time called quantums. Granting one is a single command, advance N: it hands the emulator 𝑁 tick credits, one credit per periodic timer interrupt, so the firmware is authorized to advance exactly 𝑁 ThreadX scheduler iterations, before the orchestrator regains control. A quantum ends, and control returns to the orchestrator, at exactly one of two moments: either the last of the 𝑁 credits drains, meaning the firmware ran the full quantum, or the firmware goes idle (via WFI) with credits still unused. Either way the emulator reports this boundary back; the orchestrator injects asynchronous peer events, waits for the firmware to acknowledge them, and only then grants the next quantum before repeating. A graphical

8.5

Automating Model Construction

Constructing a peer model decomposes into small, largely independent sub-problems. For example, recovering the behavior of a single register, or the shape of a single message type, are local properties which make the construction itself eligible for automation. We provide an agent the same introspection points we relied on manually: control of the testbed to start and stop the gNB and drive a PDU session; the ability to insert a patchable probe at a chosen program counter that dumps memory under a chosen condition; Ghidra access to the kernel, baseband, NRPHY, and NR DSP images; and the logs available from kernel modules, userspace applications, syscall traces, and kernel probes. Given these primitives, the agent proposes a hypothesis about a peer’s behavior, implements it as a model, and confirms or refutes it by A/B testing the model’s output against the real device under identical stimulus, proceeding through a divide-and-conquer sequence of small objectives rather than a single monolithic reverse-engineering pass (Fig. 10).

8.6

Implementation

We implement the machine in C and every peer in Python, embedded in the same process. The guest and every peer therefore run on a single thread, not as separate loops each owning their own. A per-tick call transfers control from the machine to the orchestrator and every peer in turn, so each can react before the tick continues. Running everything on a single thread is a deliberate design choice. It makes a non-issue of what would otherwise be two locks to coordinate: the Python interpreter’s GIL and QEMU’s big lock (BQL). With only one thread, neither is ever contended; each is simply acquired to run a step and released immediately after. The SIM is the one exception. It is bridged through a direct blocking 8

Orchestrator

Interpreter

Machine

Sync Peers

barrier / time-keeper

AP · NRPHY · DSP

QEMU / vCPU

SIM · SEC

Supervisor drives loop

INITIALIZATION

Spawn Peers

/

Create Machine Object

build · run

reverse

QEMU

Attach to Peers

peer models Attach OK

Agent pro

ive dr

be

Machine Ready

advance N grant ticks (credit)

STEADY STATE

air WHILE credits > 0: credits -= 1; EXEC TICK;

Synchronous Communication

Real device

Testbed

AP + CP probes

SDR / gNB / core

MMIO / APDU write · read

Figure 10: Deriving the re-host from the real device. An agent reverses the firmware, probes the real device on a live testbed, and builds the QEMU emulation from the peer models it derives, modeling the device’s real peripherals only.

IRQ

ADVERTISE credit == 0 STEP drive every peer’s non-blocking step write to interconnect Unsolicited Message Optional Peer Message

advance N grant next quantum ADVERTISE credit == 0

reaches it at the same point in the procedure, and in the same way, as the real device. State-Machine Correlation. To answer Q1, we inject the same probe into the firmware itself, hooking its NAS state-change function directly; NAS is the control-plane protocol between the device and the core network, so its state machine is exactly the one registration and session setup drive. Both environments therefore run the identical firmware binary and expose the identical state-change events, rather than two independent logging paths that happen to agree. We start the real device and the re-host from the same fixed state and compare the state transitions each one reports after receiving SIB1 and camping on the cell. Immediately after camping, both report the identical NAS 5GMM control-plane state transition, [NGMM STATE CHANGE] MAIN [200:5->=1]! followed by [NGMM STATE CHANGE] DEREG [201:5->=1]!, the same main-state and sub-state codes, at the same point in the procedure. Later, once RegistrationComplete is sent, both report a second matching transition, [NGMM STATE CHANGE] MAIN [200:1->=4]! followed by [NGMM STATE CHANGE] DEREG [201:5->=4]!, again at the same point relative to authentication and security-mode setup. We correlate these lines manually rather than automatically, but a match remains direct evidence that the two state machines take the same transition from the same state. Establishing Control- and Data-Plane Traffic. To answer Q2, a firmware log is not enough: reaching a PDU session and carrying IP traffic have to be shown crossing every peer boundary along the way, not reported by the firmware alone. Interconnect Dump Module. To get a boundary-level view, we embed an interconnect dump module directly in each peer: every ingress and egress payload is written to a common capture file, and a Wireshark dissector decodes these dumps into readable frames. Dumping the underlying DMA and ring-buffer I/O and indexing each transfer this way yields a single packet capture per run: SIM APDU exchanges, over-the-air control-plane messages, and AT

NEXT QUANTUM WHILE credits > 0: credits -= 1; EXEC TICK;

Figure 9: The steady-state co-emulation loop. The orchestrator grants the machine a bounded batch of tick credits; the machine reports back only once that batch drains or the firmware idles with none outstanding; the orchestrator then steps every peer in the interpreter, consults its own schedule, and grants the next quantum.

call rather than the per-tick step, since it cannot tolerate any delay in its reply. Under icount this costs no virtual time, since the guest instruction count does not advance while the call blocks. Peers with no firmware of their own, specifically the crypto engine, are instead modeled directly as synchronous MMIO. The operation completes within the same write that rings its doorbell.

9

Fidelity Demonstration

This section empirically demonstrates that a peer- and interconnectdriven design re-hosts the UNISOC UDX710 baseband faithfully. We pose two questions, one per experiment, and observe both through the same unified peer trace. Q1: If both are driven from the same state, does the re-host take the same state transitions as real silicon? Q2: Can the re-host reach a full PDU session and carry genuine uplink and downlink IP packets? These findings are empirical rather than exhaustive: for each transition reported below, we manually verified that the re-host 9

commands, interleaved on one timeline in the order the orchestrator actually delivered them. This lets us inspect the exact sequence of events across the SoC’s peer boundaries in one place, rather than reconstructing it from independent logs, which is exactly the evidence this experiment needs. We evaluate the interconnect dump along two axes, both visible in the same trace, since control-plane and data-plane traffic cross the identical NRPHY and AP boundaries: the control plane, the signaling that establishes a PDU session, and the data plane, the IP traffic that the session then carries. Control Plane. We compare the over-the-air RRC and NAS payloads the interconnect dump captured on the real device against those captured from the re-host for the same procedure, registration, authentication, and security-mode setup, and observe the identical payloads at each step. The one exception is where cryptographic material is involved: the real SIM’s sequence number for replay protection advances between runs, and the random challenge values it supplies are not fixed the way the re-host’s are, so ciphered fields differ between the two runs; comparing the decrypted payload itself, however, still shows a match. Data Plane. We inject IP traffic in both uplink and downlink directions and track it across the same two boundaries. For downlink, we inject a packet at the NRPHY ring; the baseband processes it through MAC, RLC, and PDCP, and delivers it to the AP, where it egresses through the kernel’s virtual Ethernet interface. For uplink, we inject the packet at the application-processor boundary instead and check for its egress at NRPHY, the reverse path. Because the interconnect dump module records both boundaries on one timeline, the injected payload and its egress appear as directly comparable frames in the same PCAP capture. A byte-identical match confirms the packet traversed the entire protocol stack. Together, these demonstrations empirically show that the re-host reaches the same control-plane state as the real device for the 5G control-plane procedures we tested, and carries genuine, authentic control-plane and data-plane payloads across the full stack. We provide a Wireshark trace collected from the emulator, covering both experiments, in §A.

10

UNISOC basebands, e.g., the UMS9620, against the UDX710’s own shows the same binary and module structure, the same NV and UBI partition layout, and the same driver code for peer-relevant components. Peers bound to standardized, vendor-independent interfaces, the SIM’s ISO-7816 controller is one, are reasonable candidates to carry over largely unchanged; peers bound to the radio stack, such as NRPHY, more plausibly need adjustment, though only to the degree the underlying co-processor generation actually differs. Whether a new UNISOC baseband still requires the same amount of dynamic probing, or whether the models we have already recovered transfer with little or no adaptation, remains to be evaluated. Fuzzing at the Interconnect Boundary. Every peer channel is a well-defined interconnect boundary rather than an opaque region of guest memory, so we can inject arbitrary payloads at exactly the points an attacker would reach, over the air at NRPHY, or over the host interface at the AP. Systematically fuzzing these boundaries, rather than manually driving a fixed reference session, is future work we intend to pursue.

11

Related Work

Due to the security-critical nature of basebands, researchers have reverse engineered most baseband implementations and, in some cases, developed on-device analysis for them: Shannon [1, 3, 6, 10, 17, 27, 29], MediaTek [9, 15, 16], and Qualcomm [2, 5, 7, 8]. For the UNISOC baseband, only one work by Makkaveev explores the modem image format and the NAS layer parser [21]. Building on the reverse engineering and on-device work, the security community has started to explore how to rehost basebands for off-device testing with introspection. BaseSafe [20] uses selective emulation to only emulate specific functions of the MediaTek baseband. Due to this over-approximation, only code in the baseband that does not depend on either state or peripherals can be emulated. FirmWire [11] is the first work on full-system baseband emulation for Shannon and MediaTek. To boot the baseband, it models peripherals that are required for the boot. Then it systematically disables RTOS tasks which crash due to missing hardware dependencies. This under-approximation leaves the baseband in a state in which protocol handlers can only be reached by directly interfacing with the RTOS queues. BaseBridge [14] and FirmState [12] recover state from the real device to instantiate the emulated baseband in a specific state. While this allows them to instantiate the baseband with built-up state, the problem of peripheral handling needed to drive message sequences remains unsolved. Loris [25] limits emulation to a single control-plane task to explore state using concolic execution. By design, it limits itself to a subset of the baseband’s code with this over-approximation. Our work is the first to tackle emulating the UNISOC baseband. More importantly, it is the first to define the concept of peers, needed to drive high-fidelity emulation of the baseband.

Discussion and Future Work

Testing beyond 5G. Our re-host currently targets 5G NR only; LTE, 3G, and GSM depend on a different PHY co-processor we have not modeled to the same depth. This is a testbed limitation more than a methodological one: reaching those generations requires the controlled radio testbed our requirements call for, and we have not yet deployed one that supports LTE. The architecture already anticipates the extension: our LTE PHY peer currently answers only a band-sweep request with a truthful “no cell” response, enough to force the firmware’s NR fallback path, but the same reverseengineering and modeling approach we used for NRPHY applies directly once a suitable testbed is in place, and the same holds for the 3G and GSM co-processors. Generalizing Across UNISOC Basebands. We built and validated this re-host against the UDX710, but UNISOC reuses SoC components and layout across its baseband family, and we expect this effort to extend to other UNISOC devices. We verified this empirically: downloading and comparing firmware images from other

12

Conclusion

We present unislop, the first systematic security analysis of a UNISOC baseband: gaining code execution, bypassing Quectel’s firmware-integrity protection, and instrumenting the running firmware for tracing and introspection. Building on this access, we introduce a peer- and interconnect-driven design for re-hosting the baseband 10

and Mobile Networks. 242–247. [13] Kaspersky. [n. d.]. UNISOC baseband vulnerabilities: from a flawed modem to compromised smartphones and vehicles. https://securelist.com/. Kaspersky Securelist. Accessed: 2026-08-03. VERIFY exact title/URL. [14] Daniel Klischies, Dyon Goos, David Hirsch, Alyssa Milburn, Marius Muench, and Veelasha Moonsamy. 2025. BaseBridge: Bridging the Gap Between Over-the-Air and Emulation Testing for Cellular Baseband Firmware . In 2025 IEEE Symposium on Security and Privacy (SP). IEEE Computer Society, Los Alamitos, CA, USA, 1101–1119. doi:10.1109/SP61157.2025.00142 [15] Daniel Komaromy. 2023. Basebanheimer: Now I Am Become Death, The Destroyer of Chains. Presentation at hardwear.io NL. https://hardwear.io/netherlands-2023/presentation/basebanheimer-nowi-am-become-death-the-destroyer-of-chains.pdf [16] Daniel Komaromy and Lorant Szabo. 2022. [BugTales] Exploiting CSN.1 Bugs in MediaTek Basebands. taszk.io labs. https://labs.taszk.io/articles/post/mtk_ baseband_csn1_exploitation/ Accessed: 2026-08-04. [17] Daniel Komaromy, Lorant Szabo, and Laszlo Szapula. 2024. Unburdened By What Has Been: Exploiting New Attack Surfaces in Radio Layer 2 for Baseband RCE on Samsung Exynos. taszk.io labs. https://labs.taszk.io/articles/post/there_will_ be_bugs/ Accessed: 2026-08-04. [18] Tomasz Piotr Lisowski, Merlin Chlosta, Jinjin Wang, and Marius Muench. 2024. { SIMurai } : Slicing Through the Complexity of { SIM } Card Security Research. In 33rd USENIX Security Symposium (USENIX Security 24). 4481–4498. [19] Shijie Luo, Matheus E. Garbelini, Sudipta Chattopadhyay, and Jianying Zhou. 2025. SNI5GECT: a practical approach to inject aNRchy into 5G NR. In Proceedings of the 34th USENIX Conference on Security Symposium (Seattle, WA, USA) (SEC ’25). USENIX Association, USA, Article 277, 20 pages. [20] Dominik Maier, Lukas Seidel, and Shinjo Park. 2020. Basesafe: Baseband sanitized fuzzing through emulation. In Proceedings of the 13th ACM conference on security and privacy in wireless and mobile networks. 122–132. [21] Slava Makkaveev. 2022. Vulnerability within the UNISOC baseband opens mobile phones communications to remote hacker attacks. Check Point Research. https: //research.checkpoint.com/2022/vulnerability-within-the-unisoc-baseband/ [22] MediaTek Inc. [n. d.]. Dimensity 5G Smartphone Chips. https://www.mediatek. com/products/smartphones/dimensity-5g Accessed: 2025-04-19. [23] Qualcomm. [n. d.]. Snapdragon X70 5G Modem-RF System. https: //www.qualcomm.com/products/technology/modems/snapdragon-x70modem-rf-system Accessed: 2025-04-19. [24] Quectel. [n. d.]. 5G RM500U Series. https://www.quectel.com/product/5grm500u-series/. Accessed: 2026-06-08. [25] Ali Ranjbar, Tianchang Yang, Kai Tu, Saaman Khalilollahi, and Syed Rafiul Hussain. 2025. Stateful Analysis and Fuzzing of Commercial Baseband Firmware . In 2025 IEEE Symposium on Security and Privacy (SP). IEEE Computer Society, Los Alamitos, CA, USA, 1120–1139. doi:10.1109/SP61157.2025.00143 [26] Samsung Electronics. [n. d.]. Exynos Modem 5400. https://semiconductor.samsung. com/processor/modem/exynos-modem-5400/ Accessed: 2025-04-19. [27] Natalie Silvanovich. 2023. How to Hack Shannon Baseband (from a Phone). Presentation at hardwear.io USA. https://hardwear.io/usa-2023/presentation/ how-to-hack-shannon-baseband.pdf [28] Software Radio Systems. [n. d.]. srsRAN Project. https://github.com/srsran/ srsRAN_Project. Accessed: 2026-06-11. [29] Xing Xuan, Rodionov Eugene, Gong Xiling, and Karimi Farzan. 2023. Over-theAir, Under the Radar. Presentation at BlackHat Europe. https://i.blackhat.com/ BH-US-23/Presentations/US-23-Karimi-Over-the-Air-Under-the-Radar.pdf

as a deterministic emulation, reconstructing every SoC component the firmware depends on from real-device introspection rather than approximating it, and define fidelity operationally at the interconnect boundaries those peers communicate across. We demonstrate this fidelity empirically: the re-host reaches the same control-plane state transitions as the real device from the same starting state, and carries genuine, authentic control-plane and data-plane traffic through a full PDU session, evidence we provide as a Wireshark trace alongside this paper. The method already generalizes beyond a single target: static comparison across UNISOC firmware images shows the SoC components we modeled are shared across the baseband family, and the peer-driven design is what makes extending it to further protocol generations, further devices, and systematic fuzzing tractable rather than a rewrite.

A

Peer Trace Comparison

Table 2 lists the NR RRC messages from the Wireshark trace referenced in §9, filtered to the nr-rrc protocol layer. The sequence covers cell camping, RRC connection setup, NAS registration and authentication, security-mode configuration, and PDU session establishment, in the same order and at the same points as on the real device.

References [1] David Bérard and Vincent Fargues. 2020. How to Design a Baseband Debugger. SSTIC. https://www.sstic.org/media/SSTIC2020/SSTICactes/how_to_design_a_baseband_debugger/SSTIC2020-Article-how_to_ design_a_baseband_debugger-berard_fargues.pdf Synacktiv. TrustZone 1-day used to write Shannon memory and install an on-device debugger on a Galaxy S7. [2] Seamus Burke. 2018. A Journey into Hexagon: Dissecting Qualcomm Basebands. Presentation at DEF CON 26. https://media.defcon.org/DEF%20CON%2026/ DEF%20CON%2026%20presentations/DEFCON-26-Seamus-Burke-JourneyInto-Hexagon.pdf [3] Amat Cama. 2018. A Walk with Shannon: A Walkthrough of a PWN2OWN Baseband Exploit. Presentation at Insomni’hack / OPCDE. https: //github.com/msuiche/OPCDE/blob/master/2018/Kenya/Amat%20Cama%20%20A%20Walk%20With%20Shannon-%20A%20walkthrough%20of%20a% 20PWN2OWN%20Baseband%20exploit.pdf [4] Open5GS Contributors. 2025. Open5GS. https://github.com/open5gs/open5gs Accessed: 2025-03-13. [5] Guillaume Delugré. 2011. Reverse Engineering a Qualcomm Baseband. Presentation at 28C3. https://fahrplan.events.ccc.de/congress/2011/Fahrplan/ attachments/2022_11-ccc-qcombbdbg.pdf [6] Nico Golde and Daniel Komaromy. 2016. Breaking Band: Reverse Engineering and Exploiting the Shannon Baseband. Presentation at REcon. https://comsecuris. com/slides/recon2016-breaking_band.pdf [7] Xiling Gong and Peter Pi. 2019. Exploiting Qualcomm WLAN and Modem Over the Air. Presentation at BlackHat USA. https://i.blackhat.com/USA-19/Thursday/ us-19-Pi-Exploiting-Qualcomm-WLAN-And-Modem-Over-The-Air.pdf [8] Xiling Gong and Bo Zhang. 2021. In-Depth Analyzing and Fuzzing for Qualcomm Hexagon Processor. Presentation at BlackHat Asia. https://i.blackhat.com/asia-21/Thursday-Handouts/AS21-In-Depth-AnalyzingFuzzing-Qualcomm-Hexagon-Processor.pdf [9] Marco Grassi and Xingyu Chen. 2020. Exploring the MediaTek Baseband. Presentation at OffensiveCon. https://speakerdeck.com/marcograss/exploring-themediatek-baseband [10] Marco Grassi and Xingyu Chen. 2021. Over-the-Air Baseband Exploit: Gaining Remote Code Execution on 5G Smartphones. Presentation at BlackHat USA. https://i.blackhat.com/USA21/Wednesday-Handouts/us-21-Over-The-AirBaseband-Exploit-Gaining-Remote-Code-Execution-On-5G-Smartphones.pdf [11] Grant Hernandez, Marius Muench, Dominik Maier, Alyssa Milburn, Shinjo Park, Tobias Scharnowski, Tyler Tucker, Patrick Traynor, and Kevin Butler. 2022. FIRMWIRE: Transparent dynamic analysis for cellular baseband firmware. In Network and Distributed Systems Security Symposium (NDSS) 2022. [12] Suhwan Jeong, Beomseok Oh, Kwangmin Kim, Insu Yun, Yongdae Kim, and CheolJun Park. 2025. FirmState: Bringing cellular protocol states to Shannon baseband emulation. In 18th ACM Conference on Security and Privacy in Wireless 11

Table 2: NR RRC messages in the co-simulation peer trace (all_peers.pcap), filtered to the nr-rrc protocol layer with tshark. No.

Time (s)

Src

Dst

Protocol

Info

661 683 685 709 722 739 741 752 754 765 771 833 844 908 970 988

38.877 38.957 38.958 39.034 42.516 42.718 42.870 42.905 43.212 43.244 44.814 44.870 45.171 45.219 45.271 66.836

nrphy cp nrphy cp nrphy cp nrphy cp nrphy cp nrphy cp nrphy cp cp nrphy

cp nrphy cp nrphy cp nrphy cp nrphy cp nrphy cp nrphy cp nrphy nrphy cp

NR RRC NR RRC NR RRC NR RRC/NAS-5GS NR RRC/NAS-5GS NR RRC/NAS-5GS NR RRC/NAS-5GS NR RRC/NAS-5GS/NAS-5GS NR RRC NR RRC NR RRC/NAS-5GS NR RRC/NAS-5GS NR RRC/NAS-5GS NR RRC/NAS-5GS NR RRC/NAS-5GS NR RRC/NAS-5GS

1053 1062

66.886 74.534

cp nrphy

nrphy cp

NR RRC/NAS-5GS NR RRC/NAS-5GS

1135 1201

74.601 79.871

cp cp

nrphy nrphy

NR RRC NR RRC/NAS-5GS

SIB1 RRC Setup Request RRC Setup RRC Setup Complete, Registration request DL Information Transfer, Authentication request [51-bytes] UL Information Transfer, Authentication response DL Information Transfer, Security mode command [24-bytes] UL Information Transfer, Security mode complete, Registration request Security Mode Command [9-bytes] Security Mode Complete DL Information Transfer, Registration accept [60-bytes] UL Information Transfer, Registration complete DL Information Transfer, Configuration update command [20-bytes] UL Information Transfer, Configuration update complete UL Information Transfer, UL NAS transport, PDU session establishment request DL Information Transfer, DL NAS transport, PDU session establishment accept [87bytes] UL Information Transfer, UL NAS transport, PDU session establishment request RRC Reconfiguration, DL NAS transport, PDU session establishment accept [389bytes] RRC Reconfiguration Complete UL Information Transfer, Service request

12

Related documents

• Borderline symphony#952558
• Borderline symphony#952076
• ARIstoteles -- Dissecting Apple's Baseband Interface#138866
• The Talk of the Town, Volume 1 (of 2)#53350
• Cloud-Boosted Low-Compute Multi-Channel Speech Enhancement#440354