PreprintPDF Available

BaseSAFE: Baseband SAnitized Fuzzing through Emulation

Preprints and early-stage research may not have been peer reviewed yet.

Abstract and Figures

Rogue base stations are an effective attack vector. Cellular basebands represent a critical part of the smartphone's security: they parse large amounts of data even before authentication. They can, therefore, grant an attacker a very stealthy way to gather information about calls placed and even to escalate to the main operating system, over-the-air. In this paper, we discuss a novel cellular fuzzing framework that aims to help security researchers find critical bugs in cellular basebands and similar embedded systems. BaseSAFE allows partial rehosting of cellular basebands for fast instrumented fuzzing off-device, even for closed-source firmware blobs. BaseSAFE's sanitizing drop-in allocator, enables spotting heap-based buffer-overflows quickly. Using our proof-of-concept harness, we fuzzed various parsers of the Nucleus RTOS-based MediaTek cellular baseband that are accessible from rogue base stations. The emulator instrumentation is highly optimized, reaching hundreds of executions per second on each core for our complex test case, around 15k test-cases per second in total. Furthermore, we discuss attack vectors for baseband modems. To the best of our knowledge, this is the first use of emulation-based fuzzing for security testing of commercial cellular basebands. Most of the tooling and approaches of BaseSAFE are also applicable for other low-level kernels and firmware. Using BaseSAFE, we were able to find memory corruptions including heap out-of-bounds writes using our proof-of-concept fuzzing harness in the MediaTek cellular baseband. BaseSAFE, the harness, and a large collection of LTE signaling message test cases will be released open-source upon publication of this paper.
Content may be subject to copyright.
BaseSAFE: Baseband SAnitized Fuzzing through Emulation
Dominik Maier
TU Berlin
Lukas Seidel
TU Berlin
Shinjo Park
TU Berlin
Rogue base stations are an eective attack vector. Cellular base-
bands represent a critical part of the smartphone’s security: they
parse large amounts of data even before authentication. They can,
therefore, grant an attacker a very stealthy way to gather infor-
mation about calls placed and even to escalate to the main oper-
ating system, over-the-air. In this paper, we discuss a novel cellu-
lar fuzzing framework that aims to help security researchers nd
critical bugs in cellular basebands and similar embedded systems.
BaseSAFE allows partial rehosting of cellular basebands for fast
instrumented fuzzing o-device, even for closed-source rmware
blobs. BaseSAFE’s sanitizing drop-in allocator, enables spotting
heap-based buer-overows quickly. Using our proof-of-concept
harness, we fuzzed various parsers of the Nucleus RTOS-based
MediaTek cellular baseband that are accessible from rogue base sta-
tions. The emulator instrumentation is highly optimized, reaching
hundreds of executions per second on each core for our complex
test case, around 15k test-cases per second in total. Furthermore,
we discuss attack vectors for baseband modems. To the best of
our knowledge, this is the rst use of emulation-based fuzzing
for security testing of commercial cellular basebands. Most of the
tooling and approaches of BaseSAFE are also applicable for other
low-level kernels and rmware. Using BaseSAFE, we were able
to nd memory corruptions including heap out-of-bounds writes
using our proof-of-concept fuzzing harness in the MediaTek cel-
lular baseband. BaseSAFE, the harness, and a large collection of
LTE signaling message test cases will be released open-source upon
publication of this paper.
Security and privacy
Software reverse engineering;
bedded systems security.
fuzzing, cellular, security, rehosting
ACM Reference Format:
Dominik Maier, Lukas Seidel, and Shinjo Park. 2020. BaseSAFE: Baseband
SAnitized Fuzzing through Emulation. In 13th ACM Conference on Security
and Privacy in Wireless and Mobile Networks (WiSec ’20), July 8–10, 2020,
Linz (Virtual Event), Austria. ACM, New York, NY, USA, 11 pages. https:
WiSec ’20, July 8–10, 2020, Linz (Virtual Event), Austria
©2020 Copyright held by the owner/author(s). Publication rights licensed to ACM.
This is the author’s version of the work. It is posted here for your personal use. Not for
redistribution. The denitive Version of Record was published in 13th ACM Conference
on Security and Privacy in Wireless and Mobile Networks (WiSec ’20), July 8–10, 2020,
Linz (Virtual Event), Austria,
Attacks on mobile basebands are possible from adjacent base sta-
tions, which are built to work over fairly large distances. The targets
move constantly, carrying their phone with them, so a rogue base
station can potentially attack a large number of phones every day.
Even though operating systems running on the phone’s basebands
are large attack vectors, parsing many dierent types of signaling
messages, even prior to authentication, the systems are obscure and
little research exists. Each larger chipset vendor for smartphones
develops and ships their own stack. Any sort of automated analysis,
if it exists at all, is kept locked away behind the vendor’s doors,
together with documentation and specications of their systems.
This gave us the reason to take a closer look at one of them. Since
the systems are written in C/C
, known to be haunted by memory
corruptions, we set out to build a usable open-source fuzzing envi-
ronment, BaseSAFE. As the initial target, we chose MediaTek, one
of the large vendors. Their chips are common in many sought-after
mid-tier phones like the Xiaomi Redmi Note 8 Pro, with oerings
from most vendors, including Motorola, Nokia, HTC, and others.
The cellular baseband has close ties to the mobile operating system.
Calls and data are routed through it and most of the lower-level
interactions, such as establishing a call and selecting a base station,
are done directly in the baseband but need to be displayed to the
Baseband rmware has one of the widest attack vectors of all
components in modern smartphones. Every cellular network usage
passes through the baseband. Countless high-complexity protocol
parsers are part of the rmware. However, to this date, security
testing of mobile basebands is either performed in a black box
fashion or through manual static analysis. Baseband and device
manufacturers are trying to limit the direct access to the baseband
in various ways, such as blocking JTAG access as well as encrypting
parts of or the entire baseband rmware [
]. The secrecy and
closed-sourceness, sometimes scrambled rmware, and usages of
relatively unknown architectures, such as Qualcomm Hexagon,
increase the barrier to mobile baseband analysis, while at the same
time making it a more interesting and rewarding target.
In this paper we take a novel approach: by rehosting parts of a
memory dump of a major cellular baseband, we are able to run main
event handlers in our analysis platform. We propose BaseSAFE, a
platform combining speedy emulation with fuzzing and heap saniti-
zation. Building on the popular Unicorn engine emulator, BaseSAFE
allows us to perform coverage-guided fuzzing on the MediaTek
baseband. We automatically map signaling messages to their re-
spective functions using coverage feedback, to keep false-positives
low. BaseSAFE implements a custom drop-in sanitizing heap alloca-
tor for Unicorn, which can replace any baseband-internal allocation
mechanism to uncover heap corruptions and use-after-frees with
arXiv:2005.07797v1 [cs.CR] 15 May 2020
WiSec ’20, July 8–10, 2020, Linz (Virtual Event), Austria Maier et al.
The sample harness of BaseSAFE for LTE Radio Resource Control
(RRC) [
] messages ships with thousands of unique, minimized,
valid inputs for a layer 3 parser in the MediaTek baseband, the
function of the rmware. All samples
trigger dierent code paths in the parser and will likely be a good
set to fuzz the same parsers in other baseband rmwares. The
signaling messages can be sent to the phone by a modied base
station unauthenticated.
The key contributions of this paper are summarized as follows:
BaseSAFE is an emulation platform oering zero-overhead
Rust bindings for emulation, sanitizing, and fuzzing,
The developed fuzzing toolkit can be used for any other
baseband or kernel,
We show the viability of automatic test-case inference through
coverage feedback,
We provide insights into a major baseband, MediaTek, and
discuss bugs found with BaseSAFE,
We fuzz layer 3 signaling message handlers, as some layer
3 messages are unencrypted and allow pre-authentication
We provide a proof-of-concept use-case of BaseSAFE fuzzing
RRC signaling messages and Non-Access Stratum (NAS)
EMM messages in MediaTek basebands.
With BaseSAFE, we provide the groundwork for automated fuzz
tests of low-level parsers in closed-source, embedded targets.
BaseSAFE is built on open-source software. Its source code and test
cases are open-sourced at
This paper can be seen as the intersection of two elds: cellular
baseband research and fuzzing. Because of this, we will give a
thorough introduction to both topics, with the goal that the reader
will be able to follow the paper, independent of the background.
2.1 Fuzzing
Fuzzing is a powerful way to detect vulnerabilities, especially in
low-level code. In recent years, fuzzing of desktop software and
parsers using tools like AFL and its fork, AFL
, has become one of
the main tools for automated analysis [
]. The fuzzer reruns the
target with dierent input thousands of times per second, using
heuristics to mutate the test cases. A key factor to a fuzzers’ success
is feedback from the target, usually coverage feedback. Thanks to
coverage feedback the fuzzer knows if the last mutation triggered
a, potentially vulnerable, path in the program [60].
Fuzzing of embedded systems is a challenging task, especially
if feedback should be collected and memory corruptions should
be detected quickly [
]. A few years ago, fuzzing wireless stacks,
rmware or a kernel, required complex setups. They had to resemble
real-world scenarios, like dedicated rogue access points [
] that are
dicult to integrate into feedback-based fuzzing methodologies. In
contrast to user-land software, in bare-metal systems and rmware,
any state change aects the whole system. Recovering from crashes
is oftentimes impossible.
2.2 Unicorn
Unicorn engine (or just Unicorn), a corner stone of BaseSAFE, is a
fork of QEMU [
]. Unicorn extends QEMU with an easy to use API,
exposing functions like reading and writing memory, and hooking
specic addresses and memory accesses with custom callbacks.
Unicorn oers bindings for a range of languages. However to use
Rust in BaseSAFE, we extended the 3rd party unicorn-rs bindings,
as no ocial Rust bindings exist [16].
Unicorn supports a vast range of processor architectures, includ-
ing MediaTek’s baseband architectures, ARM and MIPS [
]. This
makes emulation of arbitrary code, even for embedded architec-
tures, viable.
QEMU, as well as the forked Unicorn engine, work by performing
the following steps for each new code location that needs to be
run [10]:
(1) Check if the translation block (instructions to the next con-
ditional jump) at this location were previously cached.
If not cached, decode and lift the translation block at this ad-
dress from the target platform’s instruction set to Tiny Code
Generator (TCG), the internal intermediate representation.
(3) Translate the TCG to the host platform’s instruction set.
(4) Cache the translated block.
Store a mapping from source program counter to target
program counter in an address lookup table.
(6) Execute the translated block.
(7) Repeat for the next discovered block.
The translation blocks are similar to basic blocks by design [
Leveraging the correspondence between translation blocks and
basic blocks, and because execution is handed back to the emulator
after each run, it is possible to implement an instrumentation similar
to the compile-time instrumentation, using the program counter as
feedback on each new basic block. AFL
oers this instrumentation
with QEMU mode. It leverages a patched version of QEMU that
reports executed branches back to AFL [
]. After a new basic block
is translated, the fork server’s parent is informed that the block has
been translated to ensure every block is translated only once. The
control returns to the emulator after each block, which is extended
with calls to
. This call lls a shared memory section,
passing the instrumentation information to AFL.
We built up instrumentation for BaseSAFE very similar to the
AFL-QEMU instrumentation. Translation blocks are cached in the
parent process of the SafeBASE forkserver to increase the through-
put of future runs. AFL merely has to start the harness and generate
inputs. The forked Unicorn used for BaseSAFE makes use of the
same concepts, tightly.
2.3 Cellular Baseband
Every modern smartphone has multiple types of processors. Apart
from the application processor, which runs the mobile operating
system (OS), modern smartphones use independent baseband pro-
cessors. The baseband processor handles all cellular communication.
Even though the application processor and baseband processor are
physically integrated into a single processor die, they are logically
separate. Baseband processors run a dierent operating system,
usually a real-time OS (RTOS), not a full-featured system like the
BaseSAFE: Baseband SAnitized Fuzzing through Emulation WiSec ’20, July 8–10, 2020, Linz (Virtual Event), Austria
main processor does. Depending on the make, the method for inter-
communication between both processors varies. As smartphones
require faster mobile internet speeds, the internal interconnect
bus requires more bandwidth, so sometimes processors also utilize
shared memory between application and baseband processor. Thus,
in some cases, attacking a smartphone OS via its baseband is also
possible [35].
One of the main tasks of the cellular baseband is to identify the
cellular networks, to authenticate, and to connect to the correct
one. To achieve this, the baseband scans for the radio signal coming
from the cells and decodes network information messages from
System Information Block (SIB) messages to identify the network.
After identifying nearby cells, it will connect to the strongest cell
and perform the registration procedure. Once everything is done,
the cellular services are available. After a connection has been estab-
lished, the baseband provides mobile telephony and data services
to the mobile OS.
As pointed out by Rupprecht et al. [
], various attacks are pos-
sible just with an attacker-controlled rogue base station. One of
the earliest attacks targeting a baseband was presented by Wein-
mann [
]. Since there is no reliable way to identify whether the
base station is genuine or not, an external attacker can set up a
rogue base station (also known as IMSI catchers [
]) and send sig-
naling messages like the legitimate operator, without being noticed
by a user. It is possible for an attacker to inject modied signaling
messages by utilizing the modied open-source software (e.g. Osmo-
com [
] for 2G, OpenBTS-UMTS [
] for 3G, srsLTE [
] for 4G)
or the software of a commercial base station. With the wider avail-
ability of software-dened radio (SDR) devices, the total cost for the
rogue base station setup became feasible to the attacker nowadays.
Broadcasted signaling messages are processed by devices without
explicitly establishing the connection, while dedicated signaling
messages are available only after establishing a connection to the
base station.
To the best of our knowledge, no fuzzing API for basebands exists
so far. This section discusses related work in fuzzing and cellular
3.1 Emulator-Based Fuzzing
Dierent ways to use emulation for snapshot and kernel fuzzing
exist. Notable examples include TriforceAFL [
] by Hertz and New-
sham, as well as kAFL by Schumilo et al., both extending AFL’s
QEMU mode to fuzz whole virtual machines. In both cases, the
fuzz driver communicates with QEMU through additional hyper-
calls [
]. The current state of the art kernel fuzzer for desktops,
Syzkaller, uses VMs as well. A user-land stub inside the VM trig-
gers the kernel via syscalls [
]. Likewise, Unicorefuzz, by Maier
et al., fuzzes kernel functions in a QEMU-based emulator, Unicorn
engine. In contrast to the other kernel fuzzers, Unicorefuzz only
maps memory actively used in the fuzzed function and runs this
single snapshot continuously [
], forwarding each newly accessed
memory from the targets using avatar
]. Schumilo et al. take it
one step further, fuzzing hypervisors instead of kernels, in a similar
fashion inside a custom hypervisor [50].
3.2 Baseband Research
The root cause of previously proposed attacks targeting a cellular
baseband can be traced back to the specication and the implemen-
tation. The errors in the standard allowed various forms of privacy
leakage such as cellular subscriber tracking [
] and data eaves-
dropping [
]. While there had been previous works on individual
baseband bugs [
], we are not aware of a systematized
approach on identifying the baseband bugs based on fuzzing.
Features of a baseband that were proven exploitable in the past
are SMS messages and AT commands. The 3GPP SMS specica-
tion [
] denes more than just a text SMS, and processing of the
SMS had been exploited by previous researchers. Mulliner and
Miller [
] presented the bugs related to the SMS processing of mo-
bile basebands, and Mulliner et al. [
] tested them over-the-air for
multiple types of devices. These bugs are also aecting SMS-based
applications, such as one-time password [
] and SIM toolkit [
While mobile messenger services are replacing SMS, they are part of
the cellular standard and SMS functionality exists in smartphones.
Originally designed for controlling dial-up modems, AT com-
mands are also used in some modern smartphone basebands [
] as
a part of inter-processor communication. As a result, by sending
a malicious AT command it is possible to exlterate information
from it or crash it unknowingly from the mobile operating system.
Example of AT command handler fuzzing includes the work by
Tian et al. [55] and ATFuzzer by Karim et al. [31].
Other work on fuzzing the components of smartphone includes
PeriScope by Song et al. [
] targeting device drivers and Hay [
targeting Android bootloaders.
The analysis of a baseband rmware is not well-researched:
Qualcomm, one of the major baseband manufacturer, uses a cus-
tom in-house architecture named Hexagon. Although Qualcomm
provides SDKs for the Hexagon processor, few well-known dis-
assemblers integrate it, one notable example being GSMK’s IDA
Pro plugin [
]. This further limits the research using other tools.
Nevertheless, most basebands use standard architecture, at least
for the main, (non-DSP) processor. Golde et al. [
] and Miru [
present a baseband rmware disassembly using industry-standard
tools, for basebands using o-the-shelf architectures such as ARM
and MIPS.
There had been attempts on fuzz testing cellular protocol im-
plementations. Johansson et al. [
] proposed a cellular protocol
fuzzing framework, which is integrated into the existing telecommu-
nication testing infrastructure. Similar commercial services exists,
such as P1 Telecom Fuzzer [
]. Hussain et al. proposed LTEIn-
spector [
] and 5GReasoner [
], which utilize formal analysis on
the 3GPP specications to test the implementation of basebands.
Their approach is based on a formal analysis using the cellular
specication, translated into a machine-readable form. LTEFuzz by
Kim et al. [
] uses predened test cases to identify implementa-
tion problems of a baseband. SpikerXG by Hernandez et al. [
fuzz rmware of Android devices and propose an analysis platform
for further rehosting and analysis will be possible, taking a big
step towards automated baseband analysis. Prior publicly known
baseband fuzzing setups fuzzed leaked binaries compiled for host
system [
]. This is a valid approach but only feasible if object les
are available, not for o-the-shelf rmware blobs.
WiSec ’20, July 8–10, 2020, Linz (Virtual Event), Austria Maier et al.
collects &
fn main() {
/* emulator setup */
hook!(…) /heap allocator
caches new
Forked Children
/* emulator runs */
/* crash or start over */
- new blocks
- coverage
execution in
starts off
with the
same state.
The API is
easy to use.
The sanitizer
finds crashes.
Figure 1: BaseSAFE
BaseSAFE is a platform to build baseband fuzzers on. The novel
core components of BaseSAFE are an API to hook up the emulation
toolkit with the maintained AFL fork AFL
] in a very quick
and exible manner, as well as various useful components like a
heap sanitizer. To enable high-speed fuzzing, BaseSAFE uses emula-
tion, built upon Unicorn engine, a popular CPU emulator [
]. This
means, fuzzing of the baseband rmware does not take place on
the phone hardware, but instead interesting functions are fuzzed
directly inside Unicorn engine. The Rust API makes it easy to write
powerful high-performance hooks, abstracting away potential hard-
ware interactions, interrupts, etc. This allows emulation and fuzzing
of the important parts of a rmware blob on fast desktop machines.
Of course, dierent targets do still need manual setup, coding, and
reverse engineering. In the following, we will discuss the usage and
benets of BaseSAFE.
4.1 Fuzz API
In this section, we discuss the BaseSAFE API. Unicorn is extended
with an AFL-specic API to enable easy fuzzing, and an extra API to
hook the operating system’s heap sanitizer. A high-level overview of
the BaseSAFE procedure is depicted in Fig. 1. The API of BaseSAFE
goes beyond previous emulators, such as AFL Unicorn by Voss [
which did not oer interactions with AFL. Interactions with AFL
are required to kick o the fast persistent mode, but simply al-
ways started fuzzing after the rst instruction. As execution left the
emulator after the rst instruction to read AFL input, all Unicorn
translation caches were ushed constantly. On top, it only worked
for harnesses written in the interpreted and garbage collected lan-
guage Python.
The Unicorn engine API includes functions to set page mappings,
read and write memory and registers, add hooks, as well as start and
stop execution with dierent conditions. BaseSAFE makes them
available via Rust.
We extended this part of BaseSAFE with the following methods,
tailored for fuzzing:
.After the initial setup of the test case is
done, the fuzz harness can call
. This kicks
o the forkserver logic. The baseband is kept in the same state in the
parent process, each fuzz test case is executed against a forked copy
of the emulator. So a call to
freezes the current state of prior to fuzzing run and at the same
time tells the attached
process to generate inputs. After
the forkserver started, the harness should read the input for this
run from AFL
and place it into the appropriate location in the
target’s memory. As the fork is copy on write, the test case data will
be reset at the end of the run. Once this happens, the parent process
requests the next test case. Furthermore, the forkserver contains a
caching mechanism for Unicorn’s JIT, inspired by the AFL QEMU
mode: for each uncached basic block the child encounters, the child
Decode the basic block from the target architecture (for MTK,
this is either 32 bit ARM or MIPS).
Add instrumentation to the block, namely register each jump
from one location to the next in a shared map that will be
evaluated by AFL++ to generate further inputs.
Notify the parent process about the current block address
and ags.
(4) Run the basic block.
Continue with the next block. If it is already cached, patch
in a direct jump.
Once notied about a new block address by the child, the par-
ent process will also translate this block. As the parent mirrors
the child’s translation, this block will already be present in the
block cache for the next test case. This concept was carried over
from AFL’s QEMU mode, albeit with speed improvements: whereas
QEMU mode caches inside of the emulator, BaseSAFE patches it
into the translated block itself, reducing the need for indirect jumps,
a method rst proposed by Biondo [11].
.As the
syscall is heavyweight and, therefore, rather
slow, BaseSAFE oers a faster alternative: persistent mode. For tar-
gets like single parsers, for example
a’s persistent mode can greatly improve fuzzing speeds. Instead
of exiting and reforking, the child process resets its state inter-
nally, resets the needed stack, memory, and registers, and then calls
to inform the BaseSAFE parent and a-fuzz about the
end of a single fuzz run. AFL
will then place the next test case
and the child can call the fuzzed target again.
.In contrast to the
function oered by
the core Unicorn emulator,
of BaseSAFE takes mul-
tiple exit addresses. This is required if the target may not always
return at the end of a function, for example if error conditions trig-
ger. On top, it will not clear the translation block cache, containing
the JITted basic blocks after execution, as it is the case with the
emulator function in Unicorn. This allows us to reuse the cache for
BaseSAFE: Baseband SAnitized Fuzzing through Emulation WiSec ’20, July 8–10, 2020, Linz (Virtual Event), Austria
consecutive forks, as discussed in
, as well
as persistent mode, discussed in
. Recompilation of the
basic blocks is therefore not needed. Fuzzing speeds are high once
the emulator has encountered and translated most of the blocks.
.Instead of manually specifying the fuzzing logic, such as
reading AFL’s input, catching Unicorn exceptions, or looping back
to the beginning for persistent mode, the developer may choose to
use the all-in-one function
. After setting up the baseband
inside the emulator, the fuzz function takes over all necessary steps
to fuzz, including all of the functions mentioned above. Its signature
can be seen in Listing 1.
The function afl_fuzz
(1) Loads the current test case input from AFL.
Calls the
, in which the harness should
write the input into the emulator memory at the appropri-
ate position. For persistent mode, the emulator has to reset
additional state changes in this step.
Runs the emulator until execution reaches one of the exits,
a hook crashes execution or an illegal state occurs in the
Checks the Unicorn emulator error conditions and (option-
ally) calls the
, allowing us to
implement custom sanitization routines.
Starts from the top if persistent mode is enabled and the
counter did not expire.
pub fn a f l _ f u z z <F : 's t a t i c , G : 's t a t i c > (
&mut s e l f ,
input_file : &s t r ,
i n p u t _ p l a c e m e n t _ c a l l b a c k : F ,
e x i t s : &[ u64 ] ,
crash_validation_callback : G,
always_validate : bool ,
persistent_iters : u 32 )
>Result < ( ) , A f lR e t >
F : FnMut ( U ni co rn Han dle <D> ,
&[u8 ] , i3 2 )>bool ,
G : FnMut ( U ni co rn Han dle <D> , u c_ er ro r ,
&[u8 ] , i3 2 )>b o ol {
Listing 1: Function Signature of afl_fuzz in Rust.
In the
the harness writes the input
test case to the emulator memory. The callbacks both get pointers
to the input of the current test case, provided by AFL, as well as
the persistent iteration index if it is required. Furthermore, the
will get the exit code from Unicorn,
which will indicate errors caught during emulation, such as out-of-
bounds memory accesses. Depending on its return code, the exit
condition may be considered interesting, e.g., a crash or hitting
sanitization, in which case the AFL process gets the information
forwarded over an Inter-Process Communication (IPC) mechanism.
The fuzz function also takes a list of exits at which emulation will
stop, a ag whether the validation callback should also be called
without a Unicorn error condition and an additional u32 counter,
indicating if—and how often—persistent mode should loop before
forking again.
Nucleus OS
MediaTek Abstraction Layer
Layer 1
(Air Interface)
(2G, 3G)
(2/3G, LTE)
Figure 2: MediaTek Baseband Architecture.
Debug Tracing. While execution has to be as fast as possible for
fuzzing to allow a large amount of test cases to be evaluated, re-
quirements when triaging a crash are vastly dierent. Instead of
high speed, the user wants a good understanding of the execution
path taken and encountered error cases, and hence needs as much
context as possible. For this, BaseSAFE features a debug mode that
will output all disassembled instructions and register values during
execution. As long as debug outputs are enabled, our harness also
prints all output directly generated by the baseband, such as logs
generated by dhl_trace and assert messages.
4.2 The MediaTek Baseband
We chose a MediaTek baseband as a target to implement a proof-
of-concept fuzzing harness, proving the usability and viability of
BaseSAFE. First, we will present an overview over the reverse-
engineered baseband.
For the course of this work, we focus on the HTC One E9+, using
MediaTek’s Helio X10 (MT6795) processor launched in 2015 [
Aside from HTC One E9+ and M9+, this processor is also used in
some smartphones around 2015, including Sony Xperia M5 and
Xiaomi Redmi Note 2 and 3. We were able to access the unencrypted
baseband rmware using the tool from Miru [
], which is target-
ing the same processor but tested in a dierent device. MediaTek’s
baseband rmware consists of two parts: ARM and DSP. The DSP
rmware controls the lower layers, including modulation and de-
modulation of the over-the-air signal. The ARM rmware controls
the upper layers, including the processing of the signaling messages
WiSec ’20, July 8–10, 2020, Linz (Virtual Event), Austria Maier et al.
and interconnection with the application processor. We are focus-
ing on the ARM part of the baseband rmware, as this is the place
where cellular control plane messages are processed and, therefore,
can be controlled by an external attacker.
An overview of the internal structure of the ARM rmware is
depicted in Fig. 2. Most of this MediaTek MTK baseband OS was
likely carried over from their prior feature phone OS, providing
the same task model and IPC mechanisms [
]. The OS is generally
following the layer model of the cellular network. The lowest layer
is a Nucleus RTOS kernel with a MediaTek abstraction layer above
it. Drivers are interacting with external entities used by a baseband,
such as NVRAM, used to store baseband congurations, and SIM
cards. Layer 1 and 2 are not clearly separated within the MediaTek
baseband rmware. Layer 3 consists of multiple protocols related to
the separate functionalities of the cellular network: radio resource
control (RR, RRC), mobility management (MM, GMM, EMM), call
control (CC), and session management (SM, ESM). Above this lies
an application layer, layer 4, whose implementation is MediaTek-
specic. It consists of a command interpreter (ATCI), a control
entity (L4C) and an adaption layer (L4A) and interacts with the
mobile OS running on the device’s application processor.
We are focusing on LTE RRC and EMM messages, as part of
these messages are normally used for identifying a base station and
exchanged upon establishing a connection between smartphone
and network. As such, vulnerabilities in handling these messages
enable a pre-authentication attack.
Imagination Technologies–then owner of MIPS–announced that
MediaTek is adopting MIPS as the architecture for their baseband [
This is a departure from the ARM-based core that we analyzed as
a proof-of-concept for this work. By analyzing the smartphone’s
baseband rmware images by chipset using binwalk opcode anal-
ysis and Ghidra, we also found that MediaTek used ARM in their
basebands released before 2017 (Helio P25, X10, X27) and switched
to MIPS around mid-2017 (Helio P23, P70, P90, X30). Our reverse
engineering indicates that the parsers we are fuzzing are close to
identical in MIPS-based MediaTek basebands. This is to be expected,
as code reuse across architectures minimizes the development costs.
Of course, the proof-of-concept harness of BaseSAFE can easily be
ported to MIPS, as Unicorn itself supports the architecture, although
it might not provide novel insights due to the aforementioned code
reuse. Likewise, the MTK toolkits are rather standardized for both
4.3 Nucleus and MTK Firmware IPC
The ARM rmware we used as an example application for BaseSAFE
is based on the Nucleus RTOS kernel, the libraries indicate a kernel
version of 2.x. The Nucleus RTOS is a non-preemptive realtime
OS with a queue-based IPC mechanism. The main method for the
dierent parts of the MTK rmware to communicate with each
other and forward packages to higher layers are these queues. Mod-
ules can use the
function or its wrappers to send
so-called Inter Layer Messages (ILMs) to the internal or external
queue. The function proceeds to call
in the Kernel
Abstraction Layer, which uses Nucleus primitives to pass the MTK
message representation to the Queue Management Unit (QMU) of
the kernel. On the other end, modules use
, wrapping
, in order to receive
ILMs for further processing. Each queue item, i.e. ILM, contains
an identifying message ID and destination module ID. The MTK
rmware uses this information tuple to route the queue entry in-
ternally and start the correct handler. Message IDs then provide
hints on how to process messages, e.g., parsers handling incoming
(physically external) messages could be informed on which decoder
to use. Additionally, ILMs handle domain-specic manifestations
of local parameters and peer buers, carrying various forms of
information. When an ILM is initially constructed, the functions
be used to allocate and populate the respective buer. As a next step,
wrapper calls into
which communicates with the Nucleus Partition Manager to re-
turn a fresh memory chunk. Both buers have reference counts,
a module currently using one of them would signal its demand
by calling e.g.
and thus increasing the counter.
wrapper functions, namely
, rst check the reference count and free
the corresponding buer only if it is 0, otherwise it is decremented
by 1. The memory layouts of the ILM and local parameter struc-
tures are depicted in the upper part of Fig. 4. The MTK rmware
also implements an own queue management unit for the buer
management of incoming messages and wraps received messages
in metadata, as depicted in the diagram in the lower part of Fig. 4.
4.4 Selective Emulation
Instead of emulating the whole baseband, we selectively emulate
single parsers. The selective emulation is single-threaded and only
spawns one process. This allows us to emulate quickly and with zero
false-positives. However, this way we have to be more selective
about the portion of the baseband we fuzz—as manual eort is
required for each harness.
As illustrated in Fig. 2, we are focusing on layer 3 control plane
signaling messages, in particular, 3G [
] and LTE [
] RRC and NAS
] messages. They are relatively easy to modify with a
fake base station compared to lower layers. Some of these messages,
namely SIBs and Paging messages are not encrypted and decoded
automatically upon knowing the cell even without connecting to
them. Even though these messages have been a target for various
previous works, they still remain valid as a fuzzing target for various
reasons. Signaling messages are encoded in a binary-based format
such as ASN.1 and CSN.1, and correctly implementing a parser for
those protocols can be bug-ridden, while modern ASN parsers are
oftentimes autogenerated, making these parts less of a pressing
issue. Even though there are compliance tests for the standards,
these are developed towards the interoperability among multiple
vendors, not towards the implementation problems of an individual
baseband. The large amount of more than one thousand dierent
signaling messages for LTE RRC alone we were able to deduce
through fuzzing is likely not completely covered by compliance
tests. Hence, it is likely that individual baseband manufacturers
can make individual mistakes, which may not have been ltered
by their internal testing.
To this end, we identify the handling functions of the aforemen-
tioned signaling messages of the baseband rmware structure with
BaseSAFE: Baseband SAnitized Fuzzing through Emulation WiSec ’20, July 8–10, 2020, Linz (Virtual Event), Austria
minimal user input. We start from the downlink RRC messages of
the cellular network, which is categorized as follows:
PCCH: Delivers paging messages. Plaintext message without
BCCH DL-SCH: Delivers SIBs to identify the network. Plain-
text message without authentication, baseband automatically
receives the contents upon cell discovery.
CCCH: Initiates a connection between the phone and the
base station. Plaintext message without authentication.
DCCH: Dedicated channel between the phone and the base
station. Integrity protected and optionally (but usually) en-
In addition to RRC messages, NAS EMM messages manage the
registration of a phone and mobility. Some of the messages are
exchanged without encryption, therefore malicious EMM messages
could be used as pre-authentication attack.
We have collected signaling messages from the real network and
phone using SCAT [
] and use them as seed inputs to potential
signaling message handlers.
The dierent decoders expect input buers to be placed at spe-
cic osets in multiple layers of internal structures. For incoming
signaling messages, new buers are allocated by the MTK-internal
QMU. These buers contain administrative queue metadata as well
as the size of the incoming message and a pointer to the payload
buer. A local parameter struct is populated with a pointer to the
queue buer and is being held by an Inter Layer Message struct.
Finally, the ILM needs to contain the correct message ID, signaling
the higher-level function into which ASN.1 decoder the incoming
message should be passed. Fig. 4 depicts the whole layout using a
PCCH message as an example. Correct placement of buers, point-
ers and length elds can be handled in the
discussed in Sect. 4.1.
4.5 Parser Deduction
ASN1 Decoder
Coverage in afl-showmap Tuples
Packet Type (Size in Bytes)
Noise (36)
PCCH (19)
DL DCCH (38)
DL CCCH (38)
Figure 3: Reported edge coverage of packages for each parser.
The correct packages reaches the highest coverage in each.
BaseSAFE can guide reverse engineers to select good fuzzing
targets with a concept that we call parser deduction. After we collect
signaling messages we are interested in using SCAT, we deduct the
correct parser for the signaling message by evaluating the code cov-
erage of dierent input functions when presented with the signaling
message, compared with code coverage of unrelated packages. For
this, we feed valid signaling messages into all decoders by emulat-
ing valid IPC messages and log the coverage. As shown in Fig. 3, the
correct signaling message always reaches the highest coverage in
the correct parser, as expected. The correlation for PCCH is smaller
than that of the other signaling messages, likely due to the fact that
the valid PCCH message we used was rather small, with only 19
bytes. To introduce a baseline, 30 noise signaling messages with
32 to 42 random bytes and an average length of 36 were generated.
These were fed into the discussed decoders and achieve notably
less coverage than the valid signaling message for each decoder,
the average coverage can be seen in Fig. 3. This method of parser
deduction allows us to select an interesting and correct target to
selectively emulate and fuzz.
4.6 Rehosting the Baseband with Rust
Local Para
Queue Buf
12 3 4 5 6 7 89 BA C D E F
Figure 4: Structure of MTK ILM, encapsulating a PCCH Mes-
sage including pointers needed for correct input placement.
Fuzzing speed depends on various factors. Instrumenting a bi-
nary using a debugger degrades performance. Recent advancements
focus on speed of path nding, but also on sheer execution speed of
the instrumentation through lightweight hardware features [
by leveraging optimized runtimes like QEMU block chaining [
or vectorized virtualization [
]. Faster instrumentation could be
Current research has shown that AFL’s QEMU mode’s perfor-
mance can be improved by re-enabling QEMU’s block chaining,
which merges code blocks if one ends with a direct jump. It is dis-
abled because it interferes with AFL’s instrumentation: Merged
WiSec ’20, July 8–10, 2020, Linz (Virtual Event), Austria Maier et al.
blocks don’t jump back into the emulator after every single con-
tained block, so it eectively disables tracing direct jumps. The
author injects the instrumentation code into the translated code,
and thus can safely enable block chaining. Combined with proper
caching this yields a speedup of 3-4 times the mainline QEMU
mode [
]. This patch could be ported to AFL-Unicorn, and could
signicantly reduce the performance gap to compiler-assisted in-
4.7 Drop-In Heap Sanitizer
Muench et al. classify the results of memory corruptions found
through fuzzing in dierent categories. In their book, only observ-
able crashes and hangs are easy to track. Especially in a fuzzing
scenario, where the same test-case restarts over and over, the cate-
gories they classify as late crashes and malfunctioning are impossible
to spot. Of course, the last class, no eect, is impossible to track
down without address sanitization [
]. A memory corruption itself
and the subsequent use of the corrupted memory may often be far
apart. At this point the fuzzer already stopped the execution of this
run and started the next iteration, removing all traces of the bug.
Thus, even when a crashing input is given, detecting the underlying
memory bug is impossible. We solve this issue by implementing a
drop-in allocator that makes use of the emulator features to provide
4.7.1 How to Drop-In. Usually, a drop-in allocator would be put in
place, either during compilation or linked dynamically when the
program is loaded. Both options are not applicable for our use case:
embedded rmware without source code, tool-chain, or knowledge
about the linker. While binary patching could be considered, simi-
lar to RetroWrite by Dinesh et al. [
], adding functionality in the
emulation layer is less fragile and works for all supported instruc-
tion sets. The hooking functionality of the Unicorn engine inserts
checks for conditions and callbacks directly into the JITted code.
In contrast to the QASan sanitizer for QEMU by Fioraldi, that
patches each memory access in QEMU [
], we add the instru-
mentation on top of the memory access hooks already oered by
Unicorn. With a hook in place, Unicorn engine emits checks for con-
ditions like memory accesses and executed instructions. If the check
triggers, the placed hook is called from the JITted code directly,
without stopping the emulation. Using this feature, we overwrite
the rmware’s internal allocator, i.e.
described in
Sect. 4.3, by hooking its address. Whenever the hook triggers, we
allocate memory in a previously mapped page and pass the location
to the rmware by lling in the correct register. After the hooked
allocation, we increase the program counter to skip the rmware’s
actual allocator function call.
4.7.2 Allocator Implementation. The custom allocator oered by
BaseSAFE itself makes heavy use of Unicorn hooks for sanitization.
Before emulation starts, a memory region large enough to handle
all possible allocations during a single run gets allocated inside the
emulated target. Initially, an access hook is placed on the whole
region. Each time the hook triggers, a memory out-of-bounds access
is detected. The nature of the hook allows us to distinguish between
reads and writes and allows us to log the current instruction pointer.
Allocation. When the baseband’s allocator would be called, the
Unicorn hook calls our allocator instead. The allocation chunk is
allocated by removing our memory hook from a portion of the
memory region of this size. A canary region with varying size,
depending on the size of the allocation, is left hooked between each
allocated chunk. The canary region is, again, protected by hooks.
This way the only heap corruptions we cannot spot are writes
skipping the variable-sized canary regions and accessing another
already allocated chunk. Normally, all out-of-bounds accesses are
Deallocation. The deallocator hook places a new memory access
hook on the previously allocated region. Since the memory region
will never be reused for this single run, all use-after-free bugs are
detected by this hook. In addition, the chunk size, being part of
a bookkeeping structure, gets set to 0. Whenever
is being
called on a chunk with a size of 0, a double-free is detected. The
managing structures are not part of the heap itself and are kept
outside of the emulator and hence cannot be impacted by memory
corruptions. As the forkserver will reset the emulator memory for
each emulation pass by reforking, we do not have to clean the
custom heap manually, unless the persistent mode is in use, in
which case the hooks are replaced completely.
In the following, we will rst discuss results gathered with BaseSAFE,
including memory corruptions. Then, we discuss how BaseSAFE
repackages PCAPs, and how we replay the test cases against a real
MediaTek-based device over-the-air.
5.1 Exhaustive Test Cases From LTE RRC
We ran BaseSAFE on the LTE RRC test case for around one week
with about 15k executions per second. Benchmarking the fuzz case
on an Intel i7-6700 CPU @3.40GHz, the speed uctuated around
1.5k executions per second on a single core. Although no crashes
could be found during the RRC tests, we were able to uncover slow
paths. However, this cannot be abused for denial-of-service because
LTE RRC timers [
] reset the internal parser if signaling messages
were not received within the time limit.
In total, after minimizing millions of test cases using a-cmin on
the corpus and a-tmin on every single corpus-minimized input,
1388 unique test cases, leading to unique paths in the parser, were
found, see Sect. 5.3. They will be released as part of BaseSAFE and
can be reused to test the same message on other baseband rmware
in the future. This number can still go up with longer fuzzing times.
As these signaling messages were eectively outgeneraled by the
parser, all of the messages are relevant for parsing, even if some
behavior may not be specication-compliant, cf. Fig. 5.
5.2 Memory Corruptions in NAS EMM
Higher up in the LTE stack, in the NAS EMM parser, BaseSAFE
was able to uncover out-of-bounds reads and writes. The position
of the bug within the MTK architecture is shown in Fig. 2. Af-
ter fuzzing the parser, the heap sanitizer, discussed in Sect. 4.7,
successfully reported multiple such crashes with the same root
cause. The bug, rst discovered by Grassi and Chen [
], lies in
, a function being called during the
BaseSAFE: Baseband SAnitized Fuzzing through Emulation WiSec ’20, July 8–10, 2020, Linz (Virtual Event), Austria
Figure 5: Wireshark trace of one of the fuzzer-generated sig-
naling messages triggering unique code ow in MTK
handling of Tracking Area Update Accept and Attach Accept mes-
sages, specied in the 3GPP TS 24.008 [
] standard. Here, an attacker-
controlled length-byte is not checked against the correct mes-
sage size, leading to an out-of-bounds read from the received mes-
sage buer while copying it to the internal data structure. As the
oset into the target buer gradually increases by factor 0
an attacker would in addition be able to overow it during the
copying process and achieve an out-of-bounds write on the heap.
i = 0;
do {
in de x = * ec c _n u mb e r_ l is t _s t ru c t ;
cu rr _ i te m = ec c_ n u m be r _ li s t _s t r uc t + ( u i nt ) i n de x * 0 x 2b ;
cu rr _i te m [2 ] = ms g[ i ] - 1;
data_start = i + 2;
cu rr _i te m [1 ] = m sg [i + 1 & 0 x ff ff ] ;
j = 0;
while (i = d a ta _s ta rt & 0 xf fff , j < cu rr _ it em [ 2] ) {
data_start = i + 1;
cu rr _i te m [j + 3 ] = ms g[ i ];
j = (u in t )i nd ex + 1 & 0 xf f;
*e c c _n u m be r _ li s t _s t ru c t = ( b yt e ) j;
}while (i < l en gt h );
dh l _t r a ce ( T R A CE _ G RO U P _1 ,0 , D A T_ 0 0 1b 8 0 20 , PT R _ DA T _ 00 1 b 80 2 4 ,j , le n gt h , m s g_ p t r ) ;
Listing 2: Loop in decodeEmergencyNumberList
5.3 The Red Pill
To nalize the emulation evaluation, we need proof that the mes-
sages produced in the emulator are indeed valid messages for real
basebands. For this, we used two main methods.
5.3.1 AFL Inputs to PCAPs. After running for ve days, the feedback-
driven mutations of AFL generated a large corpus of potential in-
puts, with over 250k queued items. Of course, many of these are
rather similar. As BaseSAFE works together with all AFL
we can use a combination of AFL’s minimization tools to reduce
the amount of test-cases to 1388+ unique tests. To arrive at this
We ran
, which loads the coverage map for each
test case, then removes all test cases that only touch the same
code paths from the list, keeping the smallest for each. This
removes all les that do not reach new code paths, making
sure each test case is actually relevant for the parser.
Figure 6: Base station setup with our test phone HTC One
We ran
multi-processed on all remaining les.
The test case minimization overwrites random chunks of the
input le. If the coverage map stays the same, parts of the
chunk are removed to check if the map also stays unchanged
without these bytes. Similar heuristics are repeated until the
le size is as minimal as possible—while maintaining the
After the minimization process, we are left with a minimal set
of inputs that still cover all possible branches of the original base-
band parser. In contrast to ocial test-cases, they may not be valid
packages—but they will still trigger new conditions in the parser.
See, for example, the dissected packet containing signaling message
in Fig. 5. To arrive at this dissection, and verify our method, we
wrap the minimized test cases in a valid PCAP. For this, BaseSAFE
ships with a custom tool to wrap the test cases into a PCAP le.
The tool writes PCAP headers and then wraps the bytes each min-
imized test case into a GSMTAP packet. The wrapped GSMTAP
packets are decodable as a signaling message in Wireshark. One of
the generated test case decoded in Wireshark is presented in Fig. 5.
5.3.2 Replay Against Real Phones. In order to try out responses
in the real world and vet the behavior of BaseSAFE, we built a
setup able to replay the signaling messages. For this, we put up
a rogue base station capable of injecting the messages at the cor-
rect time during the connection establishment procedure. We are
using a software-dened radio and freely available application
OpenLTE [
], illustrated in Fig. 6. Along with this, we were able
to analyze the baseband log output with the MTKLogger system
application. The application is available on most MediaTek-based
phones, although it is hidden from the user interface and needs to
be accessed using special methods.
BaseSAFE is an important rst step towards fully automated vulner-
ability discovery on cellular basebands. However, it only manages
to cover a small portion, leaving many areas to explore further.
6.1 Fuzzing for Logic Bugs
Currently, our proof-of-concept harness for BaseSAFE mostly de-
tects memory corruptions during parsing, except for the places
WiSec ’20, July 8–10, 2020, Linz (Virtual Event), Austria Maier et al.
where asserts were explicitly inserted by MediaTek into the base-
band. It will not discover any other bugs. Through the insertion of
additional hooks and more elaborately modeled execution ows, a
variety of other bugs could be in the future. For example, nding
traces that disable a timer could lead to sustainable DoS and easier
exploitation of bugs [
]. On top, the parsed message structs, result-
ing from our LTE RRC fuzz test, could be handed to the consuming
functions behind the baseband. This could yield further bugs, as
packages might pass the parser without corruptions, but the con-
sumer could, in turn, blindly trust that input, just as we saw in
Sect. 5.2. Using BaseSAFE hooks, a lot of other logic bugs could also
be modeled. For the baseband authentication, paths that reach an
authenticated state without passing the necessary authentication
functions can be hunted down this way.
6.2 Collision-Free Coverage Tracing
Right now, BaseSAFE uses the instrumentation of AFL QEMU mode.
For each new translation block, it calculates a shift and a XOR
operation to nd the afl_idx oset, see Listing 3.
a f l _ i d x = c u r_ l oc ^ uc >afl_prev_loc
INC_ AFL_AREA ( a f l _ i d x ) ;
uc > a f l _ p r e v _ l o c = c u r _ l o c >> 1
Listing 3: Instrumentation in BaseSAFE
At the position of
then increases a
counter at the shared map used to report feedback to AFL++.
While this hash is good enough to nd almost all paths, our tests
indicate that collisions occasionally occur. This leaves a small num-
ber of branches undetected, negatively aecting feedback-based
mutations. The fuzzer will still eventually reach colliding paths,
but may classify the edge as already taken, putting less weight
on this test case. In the future, BaseSAFE will be extended with
collision-free instrumentation. Initial tests without AFL’s hashing
indicate a higher total number of total paths found.
6.3 Additional Targets
In the course of this paper, we were merely able to highlight a
small portion of a whole operating system. The analyzed MediaTek
rmware for the HTC One in question has 56 calls to
the IPC mechanism to receive messages from the system queue,
alone. As described in 4.3, each of these calls is one specic task.
Each task may contain parsers for multiple dierent network pack-
ets and call one of them, depending on the ILM
(see Fig. 4
for one ILM example). Each such queue read may contain, or de-
pend on, user-provided input and can be an interesting target to
fuzz in itself. Especially 2G functions might be another interesting
target as it is usually old code that may be seldomly used and tested.
Apart from MediaTek, other cellular basebands, base stations, and
even unrelated rmware can be tested with BaseSAFE after some
adaptation. Piece by piece, support for non-standard architectures,
such as Qualcomm’s Hexagon, can be added by porting their exist-
ing open-source QEMU versions [
] to Unicorn engine, thereby
improving the number of testable basebands.
6.4 Further Harness Automation
While the methods and tools presented in this paper will be ap-
plicable to all cellular basebands, hook creation could be further
automated to allow adaption to new platforms with less manual
work. Of course, this will need a deeper automated understanding
of unknown rmware blobs, using heuristics and automated static
BaseSAFE shows good results. It provides fast fuzzing speeds, with
around 15000 executions on a small server for our real-world use-
case, emulating multiple Mediatek baseband parsers. This proves
that emulation is a good t for automated bug discovery in baseband
rmware analysis. BaseSAFE’s snapshot-based fuzzing introduces
a new level of precision and achieves high coverage and execution
speeds, not achievable by classical over-the-air fuzzing approaches.
BaseSAFE is built on top of state-of-the-art open-source tools and
has—in turn—been open-sourced. The API oered by its Rust bind-
ings makes it easy to quickly implement fuzz cases without ad-
ditional overhead. We were able to run high-performance partial
emulations of complex rmware. The introduced drop-in sanitiz-
ing allocator nds memory corruption bugs automatically, solving
a problem considered hard in prior literature [
]. Our proposed
framework found vulnerabilities that are reproducible over-the-air.
We conclude, that with BaseSAFE, fuzzing of embedded rmware
in general, and dierent parts of the MediaTek cellular baseband in
particular, is greatly facilitated and allows for ecient automated
bug discovery in various scenarios.
Responsible disclosure.
All results of this research were com-
municated to MediaTek in a timely fashion.
The authors would like to thank Jiska Classen and Altaf Shaik for
valuable feedback.
3GPP. 2018. AT command set for User Equipment (UE). Technical Specication
(TS) 27.007. 3rd Generation Partnership Project (3GPP). http://www
/DynaReport/27007.htm Version 15.4.0.
3GPP. 2018. Technical realization of the Short Message Service (SMS). Technical
Specication (TS) 23.040. 3rd Generation Partnership Project (3GPP). http:
// .htm
3GPP. 2020. Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Resource
Control (RRC); Protocol specication. Technical Specication (TS) 36.331. 3rd
Generation Partnership Project (3GPP). http://www
3GPP. 2020. Mobile radio interface Layer 3 specication; Core network protocols;
Stage 3. Technical Specication (TS) 24.008. 3rd Generation Partnership Project
(3GPP). .htm
[5] 3GPP. 2020. Non-Access-Stratum (NAS) protocol for Evolved Packet System (EPS);
Stage 3. Technical Specication (TS) 24.301. 3rd Generation Partnership Project
(3GPP). .htm
3GPP. 2020. Radio Resource Control (RRC); Protocol specication. Technical
Specication (TS) 25.331. 3rd Generation Partnership Project (3GPP). http:
// .htm
AFL. 2020. AFL QEMU Mode. https://github
[8] Bogdan Alecu. 2013. SMS fuzzing–SIM toolkit attack. DEF CON 21 (2013).
Fabrice Bellard. 2005. QEMU, a fast and portable dynamic translator.. In USENIX
Annual Technical Conference, FREENIX Track, Vol. 41. 46.
Fabrice Bellard. 2020. Tiny Code Generator. https://git
BaseSAFE: Baseband SAnitized Fuzzing through Emulation WiSec ’20, July 8–10, 2020, Linz (Virtual Event), Austria
Andrea Biondo. 2018. Improving AFL’s QEMU mode performance. 0x41414141
in ?? () (Sep 2018). af l-qemu- mode
Laurent Butti and Julien Tinnes. 2008. Discovering and exploiting 802.11 wireless
driver vulnerabilities. Journal in Computer Virology 4, 1 (2008), 25–37.
Comsecuris. 2020. QEMU with support for QDSP6 user mode emulation. https:
S. Dinesh S. Dinesh, Nathan Burow, Dongyan Xu, and Mathias Payer. 2020.
RetroWrite: Statically Instrumenting COTS Binaries for Fuzzing and Sanitization.
In IEEE S&P 2020.
David Drysdale. 2016. Coverage-guided kernel fuzzing with syzkaller. https:
SÃľbastien Duquette. 2020. Rust bindings for the unicorn CP U emulator. https:
Brandon Falk. 2018. Vectorized Emulation: Hardware accelerated taint tracking
at 2 trillion instructions per second. https://gamozolabs
10/14/vectorizedemulation.html [Online; accessed 11. Nov. 2018].
Andrea Fioraldi. 2019. Sanitized Emulation with QASan. https://andreaorald qasan.html
Nico Golde and Daniel Komaromy. 2016. Breaking Band: reverse engineering
and exploiting the shannon baseband. https://comsecuris
Ismael Gomez-Miguelez, Andres Garcia-Saavedra, Paul D. Sutton, Pablo Serrano,
Cristina Cano, and Douglas J. Leith. 2016. srsLTE: An Open-Source Platform
for LTE Evolution and Experimentation. CoRR abs/1602.04629 (2016). http:
Marco Grassi and Xingyu Chen. 2020. Exploring the MediaTek Baseband. In
Roee Hay. 2017. fastboot OEM vuln: Android bootloader vulnerabilities in vendor
customizations. In 11th USENIX Workshop on Oensive Technologies (WOOT 17).
Willem Hengeveld. 2013. IDA processor module for the hexagon (QDSP6) processor.
Grant Hernandez and Kevin R. B. Butler. 2019. Basebads: Automated Security
Analysis of Baseband Firmware: Poster. (2019), 318âĂŞ319. https://doi
J Hertz and T Newsham. 2016. Project triforce: Run a on everything. NCC
Group, Tech. Rep. (2016).
Marc Heuse, Heiko Eißfeld, Andrea Fioraldi, and Dominik Maier. 2020. american
fuzzy lop plus plus (a++). GitHub. https://github
Syed Hussain, Omar Chowdhury, Shagufta Mehnaz, and Elisa Bertino. 2018.
LTEInspector: A systematic approach for adversarial testing of 4G LTE. In Net-
work and Distributed Systems Security (NDSS) Symposium 2018.
Syed Raul Hussain, Mitziu Echeverria, Imtiaz Karim, Omar Chowdhury, and
Elisa Bertino. 2019. 5GReasoner: A Property-Directed Security and Privacy
Analysis Framework for 5G Cellular Network Protocol. In Proceedings of the
2019 ACM SIGSAC Conference on Computer and Communications Security, CCS
2019, London, UK, November 11-15, 2019, Lorenzo Cavallaro, Johannes Kinder, Xi-
aoFeng Wang, and Jonathan Katz (Eds.). ACM, 669–684. https://doi
Imagination Technologies. 2017. MediaTek selects MIPS for LTE modems. https:
// selects-mips-for- lte-modems/
W. Johansson, M. Svensson, U. E. Larson, M. Almgren, and V. Gulisano. 2014.
T-Fuzz: Model-Based Fuzzing for Robustness Testing of Telecommunication
Protocols. In 2014 IEEE Seventh International Conference on Software Testing,
Verication and Validation. 323–332. .45
Imtiaz Karim, Fabrizio Cicala, Syed Hussain, Omar Chowdhury, and Elisa Bertino.
2019. Opening Pandora’s box through ATFuzzer: dynamic analysis of AT interface
for Android smartphones. 529–543.
Hongil Kim, Jiho Lee, Lee Eunkyu, and Yongdae Kim. 2019. Touching the Un-
touchables: Dynamic Security Analysis of the LTE Control Plane. In 2019 IEEE
Symposium on Security and Privacy (SP). 1153–1168. https://doi
X. Lu, J. He, and J. Li. 2011. A Tibetan input method based on MTK for mo-
bile phone. In 2011 International Conference on Consumer Electronics, Communi-
cations and Networks (CECNet). 3884–3887. https://doi
Dominik Maier, Benedikt Radtke, and Bastian Harren. 2019. Unicorefuzz: On
the Viability of Emulation for Kernelspace Fuzzing. In 13th USENIX Workshop
on Oensive Technologies, WOOT 2019, Santa Clara, CA, USA, August 12-13, 2019,
Alex Gantman and Clémentine Maurice (Eds.). USENIX Association. https:
GyÃűrgy Miru. 2017. Path of Least Resistance: Cellular Baseband to Application
Processor Escalation on Mediatek Devices. https://comsecuris
Marius Muench, Aurélien Francillon, and Davide Balzarotti. 2018. Avatarš: A
multi-target orchestration platform. In BAR 2018, Workshop on Binary Analysis
Research, colocated with NDSS Symposium, 18 February 2018, San Diego, USA. San
Diego, UNITED STATES. http://www .eurecom.f r/publication/5437
Marius Muench, Jan Stijohann, Frank Kargl, Aurélien Francillon, and Davide
Balzarotti. 2018. What you corrupt is not what you crash: Challenges in fuzzing
embedded devices. In Proceedings 2018 Network and Distributed System Security
Symposium, San Diego, CA.
Collin Mulliner, Ravishankar Borgaonkar, Patrick Stewin, and Jean-Pierre Seifert.
2013. SMS-Based One-Time Passwords: Attacks and Defense. In Detection of In-
trusions and Malware, and Vulnerability Assessment, Konrad Rieck, Patrick Stewin,
and Jean-Pierre Seifert (Eds.). Springer Berlin Heidelberg, Berlin, Heidelberg,
Collin Mulliner, Nico Golde, and Jean-Pierre Seifert. 2011. SMS of Death: from
analyzing to attacking mobile phones on a large scale. USENIX Security (2011). ull{˝papers/Mulliner.pdf
Collin Mulliner and Charlie Miller. 2009. Fuzzing the Phone in your Phone.
Black Hat USA 2009 (2009). https://www
09/MILLER/BHUSA09-Miller- FuzzingPhone-PAPER.pdf
Anh Quynh Ngyuen and Hoang Vu Dang. 2020. Unicorn: Next Generation CP U
Emulator Framework. http://www
OpenBTS. 2020. OpenBTS-UMTS. http://openbts
Osmocom Project. 2020. Cellular Network Infrastructure. https://osmocom
P1 Security. 2020. P1 Telecom Fuzzer. https://www
telecom-fuzzer- ptf/
Shinjo Park. 2017. SCAT: Signaling Collection and Analysis Tool. https://github
Shinjo Park, Altaf Shaik, Ravishankar Borgaonkar, and Jean-Pierre Seifert. 2016.
White Rabbit in Mobile: Eect of Unsecured Clock Source in Smartphones. In
Proceedings of the 6th Workshop on Security and Privacy in Smartphones and Mobile
Devices. ACM, 13–21.
David Rupprecht, Adrian Dabrowski, Thorsten Holz, Edgar Weippl, and Christina
Pöpper. 2017. On Security Research Towards Future Mobile Network Generations.
(oct 2017). arXiv:1710.08932
David Rupprecht, Kai Jansen, and Christina Pöpper. 2016. Putting LTE Security
Functions to the Test: A Framework to Evaluate Implementation Correctness. In
10th USENIX Workshop on Oensive Technologies (WOOT 16).
David Rupprecht, Katharina Kohls, Thorsten Holz, and Christina Pöpper. 2019.
Breaking LTE on Layer Two. In 2019 IEEE Symposium on Security and Privacy
Sergej Schumilo, Cornelius Aschermann, Ali Abbasi, Simon Worner, and Thorsten
Holz. 2020. HYPER-CUBE: High-Dimensional Hypervisor Fuzzing. In 27th An-
nual Network and Distributed System Security Symposium, NDSS 2017, San Diego,
California, USA, 2020.
Sergej Schumilo, Cornelius Aschermann, Robert Gawlik, Sebastian Schinzel, and
Thorsten Holz. 2017. kAFL: Hardware-Assisted Feedback Fuzzing for OS Kernels.
In 26th USENIX Security Symposium (USENIX Security 17). USENIX Association,
Vancouver, BC, 167–182.
Altaf Shaik, Ravishankar Borgaonkar, N. Asokan, Valtteri Niemi, and Jean-Pierre
Seifert. 2015. Practical attacks against privacy and availability in 4G/LTE mobile
communication systems. (2015).
Dokyung Song, Felicitas Hetzelt, Dipanjan Das, Chad Spensky, Yeoul Na, Stijn
Volckaert, Giovanni Vigna, Christopher Kruegel, Jean-Pierre Seifert, and Michael
Franz. 2019. PeriScope: An Eective Probing and Fuzzing Framework for the
Hardware-OS Boundary. In 26th Annual Network and Distributed System Security
Symposium, NDSS 2019, San Diego, California, USA, February 24-27, 2019. The
Internet Society. https://www
org/ndss-paper/periscope- an-
effective- probing-and-fuzzing- framework-for- the-hardware- os-boundary/
Daehyun Strobel. 2007. IMSI Catcher. Chair for Communication Security, Ruhr-
Universität Bochum (2007).
Dave Jing Tian, Grant Hernandez, Joseph I Choi, Vanessa Frost, Christie Raules,
Patrick Traynor, Hayawardh Vijayakumar, Lee Harrison, Amir Rahmati, Michael
Grace, et al
2018. ATtention Spanned: Comprehensive Vulnerability Analysis
Commands Within the Android Ecosystem. In 27th USENIX Security
Symposium (USENIX Security 18). 273–290.
Nathan Voss. 2017. a-unicorn: Fuzzing Arbitrary Binary Code. https://hackerno-unicorn-fuzzing- arbitrary-binary- code-563ca28936bf
Ralf-Philipp Weinmann. 2012. Baseband Attacks: Remote Exploitation of Mem-
ory Corruptions in Cellular Protocol Stacks. USENIX Workshop on Oensive
Technologies (2012).
[58] WikiChip. 2020. Helio X10 (MT6795) - MediaTek.
[59] Ben Wojtowicz. [n.d.]. OpenLTE. http://openlte.sourcef
Michael Zalewski. 2016. Technical "whitepaper" for AFL-fuzz. http://lcamtuf
c l/
G. Zhang, X. Zhou, Y. Luo, X. Wu, and E. Min. 2018. PTfuzz: Guided Fuzzing
With Processor Trace Feedback. IEEE Access 6 (2018), 37302–37313. https:
// .2851237
ResearchGate has not been able to resolve any citations for this publication.
Conference Paper
Full-text available
This paper focuses on checking the correctness and robustness of the AT command interface exposed by the cellular baseband processor through Bluetooth and USB. A device's application processor uses this interface for issuing high-level commands (or, AT commands) to the baseband processor for performing cellular network operations (e.g., placing a phone call). Vulnerabilities in this interface can be leveraged by malicious Bluetooth peripherals to launch pernicious attacks including DoS and privacy attacks. To identify such vulnerabilities, we propose ATFuzzer that uses a grammar-guided evolutionary fuzzing approach which mutates production rules of the AT command grammar instead of concrete AT commands. Empirical evaluation with ATFuzzer on 10 Android smartphones from 6 vendors revealed 4 invalid AT command grammars over Bluetooth and 13 over USB with implications ranging from DoS, downgrade of cellular protocol version (e.g., from 4G to 3G/2G) to severe privacy leaks. The vulnerabilities along with the invalid AT command grammars were responsibly disclosed to affected vendors and two of the reported vulnerabilities have been already assigned CVEs (CVE-2019-16400 and CVE-2019-16401).
Conference Paper
Full-text available
The paper proposes 5GReasoner, a framework for property-guided formal verification of control-plane protocols spanning across multiple layers of the 5G protocol stack. The underlying analysis carried out by 5GReasoner can be viewed as an instance of the model checking problem with respect to an adversarial environment. Due to an effective use of behavior-specific abstraction in our manually extracted 5G protocol, 5GReasoner's analysis generalizes prior analyses of cellular protocols by reasoning about properties not only regarding packet payload but also multi-layer protocol interactions. We instantiated 5GReasoner with two model checkers and a cryptographic protocol verifier, lazily combining them through the use of abstraction-refinement principle. Our analysis of the extracted 5G protocol model covering 6 key control-layer protocols spanning across two layers of the 5G protocol stack with 5GReasoner has identified 11 design weaknesses resulting in attacks having both security and privacy implications. Our analysis also discovered 5 previous design weaknesses that 5G inherits from 4G, and can be exploited to violate its security and privacy guarantees.
Conference Paper
Full-text available
Many kinds of memory safety vulnerabilities have been endangering software systems for decades. Amongst other approaches, fuzzing is a promising technique to unveil various software faults. Recently, feedback-guided fuzzing demonstrated its power, producing a steady stream of security-critical software bugs. Most fuzzing efforts-especially feedback fuzzing-are limited to user space components of an operating system (OS), although bugs in kernel components are more severe, because they allow an attacker to gain access to a system with full privileges. Unfortunately, kernel components are difficult to fuzz as feedback mechanisms (i.e., guided code coverage) cannot be easily applied. Additionally, non-determinism due to interrupts, kernel threads, statefulness, and similar mechanisms poses problems. Furthermore, if a process fuzzes its own kernel, a kernel crash highly impacts the performance of the fuzzer as the OS needs to reboot. In this paper, we approach the problem of coverage-guided kernel fuzzing in an OS-independent and hardware-assisted way: We utilize a hypervisor and In-tel's Processor Trace (PT) technology. This allows us to remain independent of the target OS as we just require a small user space component that interacts with the targeted OS. As a result, our approach introduces almost no performance overhead, even in cases where the OS crashes, and performs up to 17,000 executions per second on an off-the-shelf laptop. We developed a framework called kernel-AFL (kAFL) to assess the security of Linux, macOS, and Windows kernel components. Among many crashes, we uncovered several flaws in the ext4 driver for Linux, the HFS and APFS file system of macOS, and the NTFS driver of Windows.
Conference Paper
Mobile devices are more connected than ever before through the use of multiple wireless protocols, including the 2G, 3G, and 4G cellular standards. To manage and interact with cellular networks, phones use dedicated and highly proprietary baseband processors running custom, closed-source firmware. Despite the increasing complexity of modern cellular standards, there is no reference implementation, leading individual baseband manufacturers to create their own in-house versions. The proprietary nature of baseband firmware combined with the complexity of standards has created a barrier for researchers to comprehensively audit the security of these implementations. To address this, we present SpikerXG, an extensible, baseband testing platform that employs firmware instrumentation to intelligently target protocol messages.