BaseMirror: Automatic Reverse Engineering of Baseband Commands from Android’s Radio Interface Layer

Considering the availability of RIL firmware and open architecture, this paper focuses on Android RIL (Android, 2022). We assume the smartphone vendors have followed the official RIL architecture, which allows us to identify and extract the proprietary vendor RIL libraries from the phone’s factory images. We assume our targeted vendor RIL libraries can be disassembled and decompiled, and they are stripped and not obfuscated (which is true at this time of writing). As RIL resides at the native layer of Android, the associated libraries are developed with C++ language for ARM architecture that is widely adopted by most commodity smartphones.

A mobile device vendor usually defines hundreds of specific baseband commands for various radio functionalities, leading to very complicated implementations. For instance, a vendor RIL library we collected typically occupies a few megabytes of binary code with more than 15K functions. Therefore, manual analysis is extremely inefficient, and thus an automated and systematic approach is highly desired. Such a binary analysis approach should precisely locate the baseband commands and correctly extract their syntax. Simply relying on program heuristics (e.g., function and variable symbols) is not scalable and lacks generality, as it will likely introduce errors when encountering different firmware.

To address this challenge, we observe that the baseband commands within the RIL are issued through standard Linux system calls, such as write and read as in the running example in Figure 2. Therefore, we design a unified static taint analysis approach (Allen, 1970; Yang and Yang, 2012) to precisely track how baseband commands are constructed from these system calls. Note that we favor a static program analysis approach over dynamic analysis due to scalability concerns, as dynamic analysis requires real devices or emulation capabilities. As a static analysis approach, we only require the RIL binary code, which is readily available from the mobile device firmware.

The first critical step of static taint analysis is to construct a complete Inter-Procedural Call Graph (CG) (Ming et al., 2012). An incomplete CG will interrupt the correct program control flow and thus prevent our taint analysis from reaching the desired command locations. In particular, virtual function calls (or vcalls) are the major roadblocks as current off-the-shelf program analysis frameworks (NSA, 2024; Rays, 2024; Shoshitaishvili et al., 2016) cannot resolve vcalls by default during call graph construction. These vcalls are ubiquitous in our problem domain due to the flexibility of programming (e.g., various command handlers invoked from a single statement). For example, in Figure 2, the backward command propagation will break at IoChannel::Write if we miss the desired virtual function call (IpcModem::DoIoChannelRoutingTx to IoChannel::Write) from the function call graph.

There have been a handful of program analysis techniques for analyzing virtual function calls at source code level (Bacon and Sweeney, 1996) and recovering virtual inheritance at binary level (Erinfolami and Prakash, 2020; Pawlowski et al., 2017; Elsabagh et al., 2017). Our challenge differs in that we are directly solving the concrete vcalls instead of the virtual inheritance. More specifically, when encountering a virtual call site during taint analysis, we need to find the possible callees to propagate the control flow. To this end, we devise a lightweight vcall recovery algorithm that combines class type analysis and offset computation to identify the possible vcall targets and extend the program’s control flow.

After identifying the possible baseband commands using static taint analysis, we still need to filter these results since there could be many false positives. This is due to the generic static analysis sources and sinks (e.g., the write system call function) that are not only used for baseband commands but also other undesired purposes. For instance, we notice that some RIL implementations use read and write over a local file to achieve asynchronous communications. Therefore, we must accurately filter out undesired commands from our results.

Our key insight comes from the general RIL architecture design in §2 that actual interactions between AP and CP are through the Linux-mounted device interfaces, which are distinguished from other types of operations. For example, we notice that both Samsung and Google devices’ RIL implementations leverage the mounted devices under the /dev/ folder. Those devices represent the communication channels to the peripheral devices, including the baseband. Based on this insight, we leverage the command channel represented by the file descriptor (FD) parameters in the read and write system calls to perform filtering. At a high level, we use backward static analysis to track how the channel FD is initialized and further resolve its path in the system.

Algorithm 1 takes the control flow graph $\mathbb{G}=(V,E)$ of the vendor RIL library as input, and expands the set of edge $E$ with virtual calls. Since our analysis involves taint analysis that may traverse $\mathbb{G}$ in a backward order, $E$ must be complete to ensure the coverage of analysis (while in forward taint analysis, we can solve only encountered virtual calls). Line 1 to Line 1 describes the initial steps to identify virtual call instructions of our interest. Fundamentally, virtual calls in disassembly code are of similar structures as indirect calls (Lu and Hu, 2019; Van Der Veen et al., 2016; Pawlowski et al., 2017), as shown in the Figure 4 example. Based on this observation, the algorithm traverses the instructions of each basic block in $V$. It leverages the Ghidra’s P-Code Intermediate Representation (IR) lifter to convert the disassembly into unified P-Code IR syntax as the binaries of interest are cross-architecture (Ghidra, 2024). Based on the P-Code instruction syntax, we consider each instruction $i$ represents a potential virtual function call if it is an indirect call instruction (i.e., with CALLIND opcode in P-Code (Ghidra, 2024)), and if so we add it to the list $I$.

Line 1 to Line 1 illustrates the steps to resolve the virtual calls for each shortlisted instruction $i$. First, it obtains the corresponding P-Code representation of the vcall. In our running example Figure 4, the vcall at line 4 of the IpcTxCallGetCallList function is represented by ((this+0x10)+0x30)), which is described by an abstract syntax tree (AST) structure in P-Code (Ghidra, 2024). It then parses this representation to extract the vcall table base $v_{t}$ (e.g., (this+0x10) and the vcall table offset $v_{o}$ (e.g., 0x30). Since we notice that a Class may reuse its vcalls, we maintain a set $S$ to store and query all vcalls that have already been resolved. To uniquely identify a vcall as a query key, we construct a tuple ($v_{c}$, $v_{t}$, $v_{o}$) using the concrete Class and vcall representation through the following two steps:

• •

  Virtual Table Analysis. The first step in our analysis is to identify the concrete Class for a virtual call (vcall) target, determining its virtual table base. This task is challenging in C++ due to difficulties in locating the Class member variable’s data definition, which may not be in the same function using the variable. Fortunately, we find that this problem can be solved by limiting the search scope to a list of search functions ($F$) including all (parent) constructors as well as member functions of the current Class $v_{c}$, which may initialize the target through the shard this pointer. For example, in Figure 4, the list $F$ includes the parent constructor IpcProtocol of the current Class IpcProtocol41, which involves the exact definition of this+0x10. To implement this searching procedure, we use the abstract syntax tree (AST) representation for P-Code variables (Ghidra, 2024). It allows us to find the corresponding data definition by matching the AST representations (e.g., this+0x10). Based on the data definition, a class_inference procedure (Line 1-Line 1) is introduced to further infer the concrete Class $c$. Particularly, if the data definition is a function parameter, the corresponding parameter type will be used as the Class type, such as this+0x10 in Figure 4 is assigned an IpcModem type of param2. Due to the virtual inheritance in C++, such a Class type can indicate all child Classes (e.g., all Classes that inherit from IpcModem). Therefore, it considers the Class hierarchy and returns all possible Classes, which can be inferred from constructors (Fokin et al., 2011).

• •

  Virtual Function Computation. Based on the inferred Class of the vcall target, the corresponding virtual function table $c_{vt}$ can be looked up from the static memory region, which includes a list of virtual functions within that Class. By adding the base address of the virtual table $c_{vt}$ with the previously resolved offset $v_{o}$, the concrete vcall function $c_{vf}$ is resolved. Ultimately, the vcall represented by $(i,c_{vf})$ is added to the control flow $E$.

As shown in our previous running example in Figure 2, solicited baseband commands are delivered by system call APIs such as write from user space to the kernel space. These Write-related APIs are thus the boundary of the data flow that we can trace within the vendor RIL library. Other APIs that represent similar write semantics are also included in Table 1, such as ioctl that manipulates device-specific operations. Therefore, the backward taint analysis algorithm starts from these APIs as sources and traces the data flow or the desired API arguments (e.g., the buffer that carries the command payload). Figure 2 highlights the inter-procedural data flow for such an example starting from the write API. During the backward control flow transfer across functions, it will query the CG to return both the direct and virtual function calls, to ensure the completeness of our results. To define the ending criterion for the backward taint analysis, we consider the command payload to be either a constant value (for ioctl related functions) or a byte array (for Read and Write-related functions) based on our focused APIs in Table 1. The command shown in Figure 2 is a byte array local variable, which is stored on the function’s stack frame. To handle this case, the algorithm emulates the function’s execution to recover the stack frame values, thereby obtaining the command value based on its length.

In contrast to backward taint analysis, unsolicited commands originating from the CP requires forward taint analysis. To explain this problem, we provide a motivating example in Figure 5, in which the AP processes the unsolicited baseband command and invokes different handlers according to the command syntax. Similar to the solicited commands, the unsolicited commands are acquired from the system call API read. They are then stored in a buffer and passed along various processing functions. Eventually, they reach a dispatcher function Nv::ProcessRfsPacket that invokes different handler functions based on the command value. From the descriptions, unsolicited commands are propagated forward after they are read by the vendor RIL. Hence, we define the taint sources to be corresponding Read-related system calls, and the sinks to be comparison instructions (e.g., INT_EQUAL in P-Code) that represent different branches to dispatch the command. The forward data flow propagation also considers the virtual function calls recovered in the previous step.

Our evaluation involves 28 firmware images, which were rigorously tested on a Ubuntu 20.04 laptop equipped with an Intel i7-10710U processor and 16GB of RAM. BaseMirror ran on top of Ghidra 9.2.2 and OpenJDK 11.0.2, providing a stable and efficient environment for our analysis. This setup was carefully chosen to optimize the performance and accuracy of our firmware evaluation process. With respect to the running time, it took BaseMirror 4.2 hours to complete the analysis for the firmware we analyzed. Note that we enabled three threads so that it can process three binaries in parallel, and ensure optimal memory utilization efficiency. On average, it took BaseMirror nine minutes to finish analyzing a single binary.

Based on the concrete command values, we eventually obtained 873 unique baseband commands from the 28 firmware. These statistics indicate that Samsung heavily reuses these protocol-specific commands among the devices to implement communication between AP and CP. However, we also notice diversified discrepancies among the firmware we have evaluated, which are discussed later in §A in the Appendix. In Table 2, we break down the command statistics according to the taint sources defined in Table 1. Note that we have aggregated the results of __write_chk with write as they are both considered the write system call, which is also applied to __read_chk and read. The table indicates that write and read significantly contribute to the commands compared to Ioctl and Sendto. Among these two major categories, BaseMirror discovers more Write-related baseband commands than Read-related ones, indicating the developers tend to integrate more diverse functionalities for AP to CP communication than the opposite direction.

Utilizing the aforementioned methodology, we categorized distinct commands into corresponding functional modules. Then, we conducted a comprehensive analysis of the command frequencies within these modules, with select results presented in Table 3, which delineates the top-10 modules for Write and Read-related commands in Ipc41 and Ipc41X, and provide the respective command counts and percentages within each module. Upon comparing the numerical counts and proportions, it becomes evident that, despite the version discrepancies between Ipc41 and Ipc41X, the fundamental functionalities remain largely consistent, aligning with our expectations.

By semantically clustering commands, we can contrast different command values within the same category, thereby gaining insights into specific bytes of command values. For instance, through comparing command values under the Sim and Domestic modules, we observed that the fifth byte, 0x05 and 0x20 respectively, serves as the identifier for their modules. By cross-validating with other modules, we found a consistent pattern where the fifth byte across all commands is utilized to denote the command group. This analysis allows us to reverse engineer the proprietary RIL command format in Figure 7. Such information further provides meaningful guidance for dynamic testing such as attack payload discovery discussed later in §6.1. Additionally, the segmentation of command functionalities facilitates a more streamlined analysis, allowing us to focus on modules characterized by a higher command volume and complex functionalities. It optimizes the identification of vulnerable points and potential security issues. In §6, we will expound upon the security issues and potential attacks discovered in Samsung firmware based on our comprehension of command semantics.

We first visualize the evolution of baseband command quantities in Figure 8, where the devices are ordered chronologically per their release date (ranging from 2015 to 2022). The figure shows a growing trend in the number of commands over time, indicating that Samsung has continuously integrated new features into the baseband. Notably, we notice a substantial increase (over 20%) of command numbers after Note 9 was released since the devices afterward have evolved to the Ipc41X protocol that brings in significant new commands. More specifically, we found that the new Ipc41X protocol splits the original functions in Ipc41 into more subdivided functional areas, such as IpcProtocol41Call and IpcProtocol41Sms. This also implies the architecture of CP firmware is likely to have been refactored. Additionally, 5G device models tend to include more baseband functions than non-5G devices, and there is also one interesting exception (Note 10+) in which BaseMirror only reported less than 600 commands, far less than other devices released in its time frame due to the legacy Ipc41 implementation in the 4G version.

We further provide a different perspective regarding the device series in Figure 9. The figure categorizes the results into three device series, namely series A (15 models), series Note (4 models), and series S (8 models). The J series model is excluded since there is only one such firmware in our dataset. Our visualization suggests obvious discrepancies in the number of commands among these three series. Specifically, series A models tend to involve more commands since all of them have evolved to the latest Ipc41X protocol. In contrast, the Note series and S series involve many legacy models that use the old Ipc41 protocol.

The States Checking Module quires the telephony.registry interface’s return value, specifically mServiceState. This process determines whether the modem is affected by the command, and assesses the extent of impact. After injecting a command to CP, it checks the state of the modem immediately. If the modem recovers shortly after a transient OUT_OF_SERVICE state, it categorizes the command as a Temporary Crash Command, indicating that it could at least disrupt the modem’s service shortly. Subsequently, the device is rebooted, and the modem state is queried again. If the modem has returned to an IN_SERVICE state, the module labels this command as a Recoverable Crash Command, indicating that manual intervention can restore service. However, if the modem remains in an OUT_OF_SERVICE state, indicating that the command has permanently damaged the firmware’s functionality, it is classified as a Permanent Crash Command.

For hybrid commands, we port AFL++ ’s seed mutation mechanism (Fioraldi et al., 2020) to mutate their corresponding parameter bytes. Additionally, we utilize response values and modem states as guidance to indicate interesting mutation results.

Table 4 summarizes the 7 commands that can be leveraged to compromise a Samsung Galaxy A53 baseband, which leads to different degrees of impact based on our repeated experimentation. Among them, 3 commands can cause Temporary Crashes to the baseband, which recovers after a few seconds. In order to persist the attacks, one can constantly replay these attack payloads to cause service disruption. In addition, we found one command that causes Recoverable Crash, and the victim will have to reboot the device to obtain cellular service. In extreme cases, we found three commands that trigger Permanent Crashes, which requires a complete firmware re-flash to recover the baseband. We provide the exploit details in §B.1 of Appendix.

We speculate the root causes for the aforementioned attacks are two-fold. First, static RIL commands are essentially abused for malicious purposes as they represent inherent baseband functionalities. For instance, in Table 4, we list the corresponding command semantics extracted from the symbols, including two static commands that reset and power off the baseband. Moreover, for hybrid RIL commands, we speculate that the CP-side parameter checks for command parameters are insufficient, leading to crashes (e.g., segmentation faults) on the CP. Based on the command structures and semantics, these hybrid commands tend to encapsulate complex parameters (e.g., APDU and SMS payloads) that require sophisticated decoding logic to handle them properly.

Typically, due to the invocation of vendor RIL libraries by the RILD process, which possesses high system privileges, read and write operations are granted to the attacker on the majority of files. In an existing exploit demonstration by the Replicant project (K, 2014), it is shown that an attacker can inject malicious logic to the modem kernel driver (equivalent to an attacker CP), which is capable of opening and reading a user file located under the AP’s /data/ folder. To exploit this vulnerability further, our new finding shows that a malicious symbolic link could be provided as input to enable arbitrary file access on the AP. We provide additional details about this vulnerability in §B.2 of Appendix.

The unsolicited commands within the Nv module are possibly designed for the CP to read and write certain logs to the AP’s file system, such as dumping the baseband logs. However, since the command allows to specify the file paths within the AP, it enables arbitrary file system access from a malicious CP. Moreover, we also explored the possibility of using ../ for directory traversal attacks (to escape the prefix paths) and found that the firmware has eliminated them with corresponding sanitizer logic.