Vulnerability within UNISOC baseband opens mobile phone communications to remote hacking attacks

June 2, 2022

Research of: Slava Makkaveev


Remember button phones? Many of them were based on chips from Spreadtrum Communications Inc., a Chinese chip maker founded in 2001. In 2011, more than half of all phones in China were powered by Spreadtrum chips.

In 2018, Spreadtrum rebranded as UNISOC. Today, the manufacturer produces budget chipsets that power 2/3/4 / 5G devices ranging from smartphones to smartphones. UNISOC is extremely popular in Africa and Asia due to their low prices. By the end of 2021, UNISOC was firmly in fourth place among the largest mobile chip makers in the world (after MediaTek, Qualcomm and Apple), with 11% of the global market.

Despite the fact that UNISOC has been on the market for a long time, the UNISOC chip firmware used in Android mobile phones, including the radio modem (baseband), has not been extensively studied. There are no references for any UNISOC baseband vulnerabilities on the Internet.

However, the smartphone modem is a major target for hackers because it can be easily reached remotely via SMS or radio package.

In this study, CPR conducted a quick analysis of the UNISOC baseband to find a way to remotely attack UNISOC devices. We reverse-engineered the implementation of the LTE protocol stack and discovered a vulnerability that could be used to deny modem services and block communications.

LTE background

Where is the smartphone modem on the LTE network?

The Long-Term Evolution (LTE) network consists of a dozen components and protocols. You can easily find a detailed description of the LTE standard on the Internet. Let’s take a look at some basic concepts to understand the modem side of UNISOC.

The 3GPP Telecommunication Standards Group has introduced the concept of the developed packet system (EPS), which is an advanced architecture of the LTE technology. Such an architecture consists of three essential components: the user equipment (UE), the developed UMTS terrestrial radio access network (E-UTRAN), and the developed packet core (EPC), which are all interconnected.

Figure 1: EPS architecture of the LTE network.

The E-UTRAN component has only one stack, the eNodeB station, which controls the radio communications between the EU and the EPC. UE can be connected to one eNodeB at a time.

The EPC component is made up of four stacks, one of which is the mobility management entity (MME). The MME oversees the advanced operations of portable devices in the LTE network. It sends signal messages related to security control, tracks area management, and maintains mobility between the different 3GPP access networks and EPS port management.

For us, the UE is a smartphone with the UNISOC modem. In our research, we focused on the messaging between the MME stack and the UE stack, which occurs through the EPS session management (ESM) and the EPS move management (EMM) protocols.

In Figure 2, you can see the modem protocol stack. The non-access layer (NAS) layer hosts EPS and EMM signal messages.

Figure 2: LTE protocol stacks.

The NAS protocol works with advanced structures. Therefore, for an attacker it does not take much effort to create a malformed EMM packet and send it to a target device. When a new NAS message arrives, the UNISOC modem analyzes it and creates internal objects based on the received data. A bug in the analysis code can be used by the attacker to remotely crash the modem, which could lead to Neo Service (DoS) or Remote Code Execution (RCE).

Messaging between the modem and the MME

You can find the full technical specification of the NAS protocol in the 3GPP TS 24,301 document. For an idea of ​​the protocol, let’s look at the procedure for adding a device to the LTE network. It covers the most common EMM messages. In Figure 3, you can see a snippet of NAS traffic as a smartphone joins the LTE network.

Picture 3: Network confluence.

In the example, the IP of the modem is and the IP of the MME is The communication flow follows the pattern in Figure 4.

Picture 4: Message exchange scheme.

As you can see, when a device joins an LTE network, the MME server takes care of the device authentication, establishing the carrier, and more. To connect to the network, the smartphone modem must support (provide handlers for) dozens of NAS messages. We want to analyze these handlers for errors.

Before we explore the implementation of the NAS message handlers in the UNISOC modem, we will look at these handles in a popular open source LTE project such as srsRAN, as it is easier to handle source code than with disassembly. The EU stack has not changed in a long time and all its implementations are very similar to each other. In addition, some of the NAS care features implemented in the srsRAN project are vulnerable, and these vulnerabilities could theoretically be replicated in the smartphone modem.

Open source EU stack

La srsRAN is the most popular open source implementation of EPS components, including the EU stack we are interested in. La srsue/src/stack/upper/ module represents the NAS level. There you can find features that handle NAS messages.

Each handler function receives the message in the form of a database that must be analyzed in internal structures before the system can respond to it. The analytical functions are carried out in the lib/src/asn1/ module.

In Figure 5, you can see an example of the ATTACH_ACCEPT EMM message. This message contains a list of trace area identifiers, a GPRS timer, an ESM message, and a dozen optional items such as cell phone identity, emergency numbers, protocol configuration options, and more.

Picture 5: Select an acceptance message.

That is why we have a large amount of various information that needs to be deserialized. La module contains a separate unpacking (analysis) function for each content type. The UNISOC modem code has similar functions.

La ATTACH_ACCEPT srsRAN project message handler has several vulnerabilities. Let’s look at one of them as an example.

La liblte_mme_unpack_emergency_number_list_ie function extracts emergency numbers from the message data.

The maximum length of the emergency list is 12. However, the check that the idx value is less than 12 was omitted. The MME can set the sent_length value large enough to cause more than 12 cycles of the while loop and thus replace the emerg_num_list->emerg_num an array with arbitrary values. This problem leads to stack overflow.

A similar vulnerability exists in the liblte_mme_unpack_protocol_config_options_ie a function that analyzes the protocol configuration options used to transmit additional information about the network. The maximum number of supported options is 83, but there is no check that the number of options submitted by the MME does not exceed this maximum. Overflow of the option table results in stack overflow.

We know what the analytics functions of NAS messages are, and we also have code for references. Now we need to find the NAS data analysis features in the UNISOC modem firmware.

UNISOC modem firmware

In our research, we used the Motorola Moto G20 (XT2128-2) with the Android January 2022 update (RTAS31.68.29) as a test device. The device is based on the UNISOC T700 chip.

The factory update of Moto G20 can be downloaded from the Internet, which eliminates the need to root the device. In the update file, the modem firmware is represented by the SC9600_sharkl5pro_pubcp_modem.dat picture.

The image has a proprietary structure, but can be easily reconstructed. It starts with magic, followed by data block headers. The block head has the following structure:

La offset value is the offset in bytes of the beginning of the block in the image file, and the length is the block size.

In Figure 6, you can see that the modem image of our test device contains two blocks of data. The first block is of type 0x402, which is supposed to mean “analytics library”. The second block is type 0x301, which is the binary modem.

Picture 6: Modem header.

We can easily cut both blocks of the image. The analysis library block is a 7-zip archive that contains libraries for testing (analyzing and tracking) an email from an external machine. For example, the lteps_air_msg_dll.dll library (compiled for x86) implements functions for packing and unpacking NAS messages.

The modem binary block is a file with a proprietary format. The head size is 0x600 bytes. After the header, the modem code (ARM instructions) begins. We wrapped this code with an ELF32 header, and specified 0x8B000600 as the base address of the code segment. In addition, we have added a blank data segment since 0x8D0C0000. The resulting binary can be easily decompiled.

Log messages executed in the modem firmware contain the name of the current source module. This gives us the ability to quickly find the NAS message handlers. NAS-related module names begin with “lnas_air_msg”. For example, the PS/stack/nas/emm/msg_codec/msg_emm/lnas_air_msg_emm_att_acc.c module analyzes the ATTACH_ACCEPT message.

Looking for vulnerabilities in the NAS tractors

The vast majority of NAS message analyzers have three arguments: an output buffer that is the object of the appropriate message structure, the NAS message database to decode, and the current offset in the message bubble. The unified function format allows us to easily implement the harness to fuse the analytical functions of NAS. In our research, we used the classic combination of AFL and QEMU to fuse the modem binary on a computer. We patched the modem binary to redirect malloc calls to the libc equivalent. The fuzzer swapped the NAS message data and passed it as an input buffer to the analysis function.

One of the optional ATTACH_ACCEPT fields are the mobile identity. The modem firmware performs a unpacking function like the liblte_mme_unpack_mobile_id_ie of the srsRAN to extract the mobile identity of the NAS message. The identity block starts with the length of the identity. If the device is represented by International Mobile Phone Identity (IMSI), length-2 bytes of the message data are copied to the output buffer as the IMSI number.

The control to ensure that the provided length value is greater than one is dropped. Therefore, it is there length field value is zero 0-2 = 0xFFFFFFFE bytes are copied from the NAS message to the mass storage, which leads to DoS.

In Figure 7, you can see the ATTACH_ACCEPT message that causes the overflow.

Picture 7: Malformed NAS message.

The highlighted 0x23 value indicates that the following data is the message block where the first 0x01 is the length and the second 0x01 is the IMSI type.

UNISOC has assigned CVE-2022-20210 to this vulnerability. In addition, we encountered several off-reading problems when the functions of a NAS processor read data from outside the NAS message.


In this study, we first looked at the UNISOC base band as an attack target. We scanned NAS messaging processors within a short period of time and found a vulnerability that could be used to disrupt the device’s radio communication with a malformed package. A hacker or military unit can take advantage of such vulnerability to neutralize communications in a specific location.

CPR responsibly disclosed these findings to UNISOC in May 2022, which acknowledged the vulnerability, giving it a 9.4 score (critical). UNISOC later patched the vulnerability CVE-2022-20210 in May 2022.

Check Point customers remain fully protected from such threats while using them Harmony Mobile Security.

We recommend that mobile phone users always update their phone’s OS to the latest version.

Google has announced that they will release the patch in the next Android Security Bulletin.

Leave a Reply

Your email address will not be published.