#rC3 - Advanced Hexagon Diag

rC3 preroll music

Herald: Our next speaker, Alisa Esage, is
an independent vulnerability researcher

and has a notable record of security
research achievements such as this year,

the initiative Silver Bounty Hunter Awards
2018. Alisa is going to present her latest

research on the Qualcomm DIAG protocol,
which is found abundantly in Qualcomm

Hexagon based cellular modems. Alisa,
we're looking forward to your talk now.

Alisa Esage: This is Alisa Esage, you're
attending my presentation about Advanced

Hexagon DIAG at Chaos Communication
Congress 2020 remote experience. My main

interest as advanced vulnerability
researcher is complex systems and hardened

systems. For the last 10 years I have been
researching various classes of software

such as Windows kernel, browsers,
JavaScript engines. And for the last three

years I was focusing mostly on
Hypervisors. The project that I'm

presenting today was a little side project
that I made for distraction a couple years

ago. The name of this talk Advanced
Hexagon DIAG is a bit of an understatement

in the attempt to keep this talk a little
bit low key in the general internet,

because a big part of the talk will
actually be devoted to a general

vulnerability research in basebands. But
the primary focus of this talk is on the

Hexagon DIAG, also known as QCDM Qualcomm
diagnostic manager. This is a proprietary

protocol developed by Qualcomm for use in
their basebands, and it is included on all

Snapdragon SoCs and modem chips produced
by Qualcomm. More than Qualcomm chips run

on custom silicone with a custom
instruction set architecture and named

QDSP6 Hexagon. This is important because
all the DIAG handlers that we will be

dealing with are written in this
instruction set architecture. As usually

with my talks, I have adjusted the
materials of this presentation for various

audiences, for the full spectrum of
audiences, specifically the first part of

the presentation is mostly specialized for
research directors and high level

technical staff. And the last part is more
deep technical. And it would be mostly

interesting to specialized vulnerability
researchers and low level programmers that

somehow are related to this particular
area. Let's start from the top level

overview of cellular technology. This mind
map presents a simplified view of various

types of entities that we'd have to deal
with with respect to basebands. It's not a

complete diagram, of course, but it only
presents the classes of entities that

exist in this space. Also, this mind map
is specific to the clean site equipment,

the user equipment and it completely omits
any server side considerations which are a

world in their own. There exists quite a
large number of cellular protocols on the

planet. From the user perspective, this is
simple. This is usually the shared name

3G, 4G that you see on the mobile screen.
But in reality, this simple name, that

generation name encodes - may encode
several different distinct technologies.

There are a few key points about cellular
protocols that are crucial to understand

before starting to approach this area. The
first one is the concept of a generation.

This is simple. This is simply 1G, 2G and
so on. The generic name of the family of

protocols that are supported in a
particular generation. Generation is

simply a marketing name, for users. It
doesn't really have any strict technical

meaning. And generations represent the
evolution of cellular protocols in time.

The second most important thing about
cellular protocols is the air interface.

This is.. or the protocol, which actually..
this is the lowest level protocol which

defines how exactly the cellular
signal is digitized and read from the

electromagnetic wave and how exactly the
different players in this field divide the

space. Historically, there existed two
main implementations of this low level

code called TDMA and CDMA. TDMA means time
division multiple access, which basically

divides the entire electromagnetic
spectrum within the radio band into time

slots that are rotated in a round robin
manner by various mobile phones so that

they speak in turns. TDMA was the base for
the GSM technology. And GSM was the main

protocol used on this planet for a long
time. Another low level implementation is

CDMA. It was a little bit more complex
from the beginning. It's decoded as coded

division multiple access. And instead of
dividing the spectrum in time slots and

dividing the protocol in bursts, CDMA uses
random codes that are assigned to mobile

phones so that this code can be used as an
additional randomizing mask against the

modulation protocol. And multiple user
equipments can talk on the same frequency

without interrupting each other. Note here
that CDMA was developed by Qualcomm and it

was mostly used in the United States. So
at the level of 2G, there were two main

protocols, GSM based on the TDMA and the
cdmaOne based on the CDMA. On the third

generation of mobile protocols these two
branches of development were continued. So

GSM evolved into UMTS, while cdmaOne
evolved into CDMA2000. The important point

here is that UMTS has at this point
already adopted the low level air

interface protocol from the CDMA and
eventually at the fourth generation of

protocols these two branches of
development come together to create the

LTE technology and the same for the 5G.
This is a bit important for us as from the

offensive perspective, because first of
all, all of this technologies including

the air interfaces represents separate
bits of code with separate parsing

algorithms within the baseband firmware.
And all of them are usually presented in

each baseband, regardless of which one you
actually use. Does your mobile provider

actually support. Another important and
not obvious thing from the offensive

security perspective here is that because
of this, evolutionary development of the..

protocols are not actually completely
distinct. So if you think about LTE, it is

not a completely different protocol from
GSM, but instead it is based largely on

the same internal structures. And in fact,
if you look at the specifications, some of

them are almost directly relevant. The
specifications of the GSM 2G, some of them

are still directly relevant to some extent
to LTE. This is also important when you

start analyzing protocols from the
offensive perspective. The cellular

protocols are structured in a nested
way, in layers. Layers is the official

terminology adopted by the specifications
with the exception of level zero. Here I

just edited it for convenience, but it's
in the specifications layer start from one

and proceed to three. From the offensive
perspective, the most interesting is level

three, as you can see from the screenshot
of the specifications, because it encodes

most of the high level protocol data, such
as handling SMS and GSM. This is the part

of the protocol which actually contains
interesting data structures with TLV

values and so on. When people talk about
attack in basebands, they usually mean

attack in baseband over the air. Their OTA
attack vector, which is definitely one of

the most interesting. But let's take a
step back and consider the entire big

picture of the baseband ecosystem. This
diagram presents a unified view of

generalized architecture of a modern
baseband with attack surfaces. First of

all, there are two separate distinct
processors: the AP, application processor,

and the MP, which is mobile processor. It
may be either a DSP or another CPU.

Usually there are two separate processors
and each one of them runs a separate

operating system. In case of the AP, it
may be Android or iOS and the baseband

processor will draw on some sort of real-
time operating system provided by the

mobile vendor. Important point here that
on modern implementations, baseband

actually protected by some sort of secure
execution environment, maybe TrustZone on

Androids or SEPOS on Apple devices. Which
means that the privilege boundary which is

depicted here on the left side is dual
sided. So even if you have kernel access

to the Android kernel, you still are not
supposed to be able to read the memory of

the baseband or somehow intersect with its
operation, at least on the modern

production smartphones. And the same goes
around to the baseband, which is not

supposed to be able to access to application
processor directly. So these two are

mutually distrusting entities that are
separated from each other. And so there

exists privilege boundary, which is -
which represents attack surface. Within

the real-time operating systems, there are
three large attack surfaces. Starting from

right to left: the rightmost gray box
represents the attack surface of the

cellular stacks. This is the code which
actually parses the cellular protocols.

It's usually runs in several distant real-
time operating system tasks. And this part

of the attack surface handles all the
layers of the protocol. There is a huge

amount of parsing that happens here. The
second box represents the various

management protocols. The simplest one to
think about is the AT command protocol. It

is still widely included in all basebands,
and it's even usually exposed in some way

to the application processor. So you can
actually send some AT commands to the

cellular modem. About a bit more interesting
is the vendor specific management

protocols, one of them is the DIAG
protocol. Because the modern basebands are

very complex. So vendors need some sort of
specialized protocol to enable

configuration and diagnostics for the
OEM's. In case of Qualcomm, for example,

DIAG is just one of the many diagnostic
protocols involved. The third box is what

I call the RTOS core, it is various
core level functionality, such as the

code, which implements that interface to
the application processor. On the side of

the application operating system such as
Android, there are also 2 attack surfaces

that are attackable from the baseband. The
first one is the peripheral drivers,

because the basement is a separate part of
peripherals. So it requires some

specialized drivers that handle I/O and
such things. And the second one is the

dark surface represented with various
interface handlers because the baseband

and the main operating system cannot
communicate directly. They use some sort

of a specialized interface to do that. In
case of Qualcomm this is shared memory.

And so this shared memory implementations
are usually quite complex and they

represent an attack surface on the both
sides. And finally, the third piece of this

diagram is in the lowest part. I have
depicted two grey boxes which are related

to the trusted execution environment.
Because typically a modem runs as a

Trustled in a secure environment. So
technically, the attack surfaces that

exists within TrustZone or related to it
also can be useful for baseband offensive

research. Here we can distinguish at least
two large attack surfaces. The first one

is the secure manager of call handlers,
which is the core interface that

handles calls from the application
processor to the TrustZone. And the second

one are the Trustlets. They are separate
pieces of code which are executed and

protected by the TrustZone. On this
diagram, I have also added some

information about data codex, I'm not sure
if they are supposed to be in the RTOS

core because these things are directly
accessible from the cellular stacks

usually, especially ASN. 1, which I have
seen some bugs reachable from the over the

air interface. On this diagram, I have
shown some example of vulnerabilities. I

will not discuss them in details here
since it's not the point of the

presentation, but at least the ones from
Baodong, you can find the writeups on

the Internet. To discuss baseband
offensive tools and approaches, I have

narrowed down the previous diagram to just
one attack surface, the over the air

attack surface. This is the attack
surface, which is represented by parsing

implementations of various cellular
protocols inside the baseband operating

system. And this is the attack surface
that we can reach from the air interface.

In order to accomplish that, we need a
transceiver such as software defined radio

or a mobile tester, which is able to talk
the specific cellular protocol that we're

planning to attack. The simplest way to
accomplish this is use some sort of a

software defined radio, such as Ettus
research USRP or blade RF and install open

source implementation of a base station
such as OpenBTS or OpenBSC. The thing to

note here is that the software based
implementations actually lagged behind the

development of technologies.
Implementations of GSM base stations are

very well established and popular, such as
OpenBTS. And in fact, when I tried to

establish BTS with my USRP, it was quite
simple. For UMTS and LTE, there exists less

number of software based implementations
and also there are more constraints on the

hardware. For example, my model of the
USRP does not support UMTS due to resource

constraints. And the most interesting
thing here is that there does not exist

any software based implementation on the
CDMA that you can use to establish a base

station. This is a pseudorandom diagram of
one of the Snapdragon chips. There exists

a huge amount of various models of
Snapdragons. This one I have chosen

pseudorandomly when I was searching for
some sort of visual diagram. Qualcomm used

to include some high level diagrams of the
architecture in their marketing materials

previously. But since they don't do this
anymore. And this particular diagram is

from a technical specification of a
particular model 820. Also this particular

model Snapdragon is... a bit interesting
because it is the first one that included

the artificial intelligence agent, which
is also based on Hexagon. For all

purposes, the main interest here are the
processors. Majority of snapdragons

include quite a long list of processors.
There are at least 4 ARM-based Kryo-CPUs

that actually run the Android operating
system. Then there are the Adreno GPUs and

then there are several Hexagons. On the
most recent models there is not just one

Hexagon processing unit, but several of
them. And they are called respectively to

their purposes. Each one of them, each one
of these Hexagon cores is responsible for

handling a specific functionality. For
example, MDSB handles modem and runs the

real-time operating system. The ADSP
handles media and the CDSP handles

compute. So the Hexagons actually
represent around one half of the

processing power, more than Snapdragons.
There are two key points about the Hexagon

architecture from the hardware
perspective. First of all, it is- Hexagon

is specialized to parallel processing. And
so the first concept is variable size

destruction packets. It means that
several instructions can execute

simultaneously in separate execution
units. It also uses hardware

multithreading for the same purposes. On
the right side of the slide here is some

example of the Hexagon assembly. It is
quite funny at times. This curly brackets

should present the instructions that are
executed simultaneously. And these

instructions must be compactable in order
to be able to use that distant processing

slots. And then there is the funny .new
notation which actually enables the

instructions to use both the old and the
new value of a particular register within

the same instruction cycle. This provides
quite a bit of optimization on the lower

level. For more information, I can direct
you to the Hexagon Specification and

programmers reference manual, which is
available from the Qualcomm website. The

concept of production fusing is quite
common. As I said previously, it's a

common practice from mobile device vendors
to lock down the devices before they enter

the market to prevent modifications and
tinkering. And for the purposes of this

locking down, they usually- there are
several ways how this can be accomplished.

Usually various advanced diagnostic and
debugging functionalities are removed from

either software or hardware or both. It is
quite common that this functionalities are

only removed from software while the
hardware remains here. And in such case,

we will- eventually the researchers will
come up with their own software based

implementation. All this functionality as
in case with some custom iOS kernel

debuggers, for example. In case of
Qualcomm, there was at some point a leaked

internal memo which discusses what exactly
they are doing for production fusing the

devices. In addition to our production
fusing in case of modern Androids, the

baseband runs within the trust zone. And
on my implementation, it is already quite

locked down. It uses a separate component.
The baseband uses a separate component

named the MBA this stands for the modem
basic authenticator. And this entire thing

is run by the subsystem of Android kernel
named PILO, the peripheral image loader.

You can open the source code and
investigate how exactly it looks. And the

purpose of the MBA is to authenticate the
modem firmware so that you would not be

able to inject some arbitrary commands
into the modem firmware and flash it. This

is another side of the hardening, which
makes it very difficult to inject any

arbitrary code into the baseband.
Basically, the only way to do this is

through a software vulnerability. During
this project I have reverse engineered

partially the Hexagon modem firmware from
my implementation, from my Nexus 6b. The

process of reverse engineering is not very
difficult because all you need is to

download the firmware from the website,
Googles website in this case. Then you

need to find the binary which corresponds
to the modem firmware. This binary is

actually a compound binary that must be
divided into separate binaries that

represent specific sections inside the
firmware. And for that purpose we can use

the unified Trustlet script. After you
have split the baseband firmware into separate

sections, you can load them into IDA Pro.
There are several plugins available for

IDA Pro that support Hexagon. I have tried
one of them. I think it was GSMK and it

works quite good for basic reverse
engineering purposes. Notable here is that

some sections of the modem firmware are
compressed and relocated at runtime, so

you would not be able to reverse engineer
them. And unless you can decompress them,

which is also a bit of a challenge because
the Qualcomm uses some internal

compression algorithm for that. For the
reverse engineering the main approach here

is to get started with some root points,
for example, because this is a real time

operating system, we know that it should
have some task structures and task

structures that we can locate. And from
there we can locate some interesting code.

In case of Hexagon this is a bit non-
trivial because, as I said, it doesn't

have any log strings. So even though you
may locate something that looks like a

task struct, but it's not clear which code
does it actually represent. So the first

step here is to apply the log strings that
were removed from the binary by Qshrink. I

think the only way to do it is by using
that msg_hash.txt file from the leaked

sources. This file is not supposed to be
available neither on the mobile devices

nor in some open ecosystem. And after you
have applied these log strings, you will

be able to rename some functions. And
based on these log strings and because the

log strings often contain the names of the
source file, source module from which the

code was built. So it creates opportunity
to understand what exactly this code is

doing. Debugging was completely
unavailable in my case, and I realized

that it would require some couple of
months more work to make it work and the

only way I think, and the best way is to
create a software based debugger similar

to modkit, the publication that I will be
referencing in the references, based on

software vulnerability in either the modem
itself or in some authenticator or in the

trust zone so that we can inject a
software debugger callbacks into the

baseband and connect it to the GDB stop.
This is how the part of the firmware looks

that has log strings stripped out. Here it
already has some names applied using IDA

script. So of course there was no such
names initially, only the hashes. Each one

of these hashes represent a log string
that you can take in from the message hash

file. And here is what you can get after
you have applied the textual messages and

renamed some functions. In this case, you
would be able to find some hundreds of

procedures that are directly related to
the DIAG subsystem. And in a similar way

you can locate various subsystems related
to over the air vectors as well. But

unfortunately, majority of the OTA vectors
are located in the segments that are not

immediately available in the firmware, the
ones that are compressed and relocated.

Meanwhile, I have tried many different
things during this project. The things

that definitely worked is building the MSM
kernel. There is nothing special about

this, just a regular cross-build. Another
commonly well known offensive approach is

firmware downgrades. When you take some
old firmware that contains a well-known

security vulnerability and flash it and
use the bug to create and exploit to

achieve some additional functionality or
introspection into the system. This part

definitely works, downgrades are trivial
both on the entire firmware and a modem as

well as the trust zone. I did try to build
the Qualcomm firmware from the leaked

source codes. I assigned just a few days
to the task since it's not mission-

critical and I have run out of time,
probably was a different version of sorce

codes. But actually, this is not a
critical project because building leaked

firmware is not directly relevant to
finding new bugs in the production

firmware. So I just said it aside for some
later investigation. I have also

investigated the ramdump's ecosystem a
little bit on the software side at least.

And it seems that it's also fused quite
reliably. This is when I remembered about

the Qualcomm DIAG. During the initial
reconnaisance I stumbled on some

whitepapers and slides that mentioned the
Qualcomm diagnostic protocol. And it

seemed like quite a powerful protocol,
specifically with respect to reconfiguring

the baseband. So I decided to, first of
all, to test it in case that it would

actually provide some advanced
introspection functionality and then

probably to use it.. to use the protocol for
enabling log dumps. Qualcomm DIAG or QCDM

is a proprietary protocol developed by
Qualcomm with the purposes of advanced

baseband software configuration and
diagnostics. It is mostly aimed for OEM

developers, not for users. The Qualcomm
DIAG protocol consists of around 200

commands at least in theory. Some of them
are quite powerful on paper such as

downloader mode and read/write memory.
Initially the DIAG was partially reverse

engineered around 2010 and included in the
open source project named Modem Manager.

And then it was also exposed in a
presentation at the Chaos Communication

Congress 2011 by Guillaume Delugré. I
think this presentation popularized it and

this is the one that introduced me to this
protocol. Unfortunately, that presentation

is not really relevant - majority of it -
to modern production phones, but it does

provide a high level overview and a
general expectation of what you will have

to deal with. From the offensive
perspective, the DIAG protocol represents

a local attack vector from the application
processor to the baseband. A common

scenario of how it can be useful is
unlocking mobile phones which are locked

to a particular mobile carrier. If we find
a memory corruption vulnerability in DIAG

protocol, it may be possible to execute a
call directly on the baseband and change

some internal settings. This is usually
accomplished historically through the IT

common handlers, but internal proprietary
protocols are also very convenient for

that. The second scenario how that diag
offensive can be useful is using it for

injecting a software based debugger. If
you can find a bug in DIAG that enables

read/write capability on the baseband, you
can inject some debugging hooks and

eventually connect it to a GDB stop. So it
enables to create a software based

debugger even when GTAG is not available.
What has changed in DIAG in 10 years based

on some cursory investigation that I did.
First of all, the original publication

mentioned Qualcomm baseband based on ARM
and with a Rex operating system. All modern

Qualcomm basements are based on
Hexagon as opposed to ARM. And the Rex

operating system was replaced with Kirt,
which I think is still has some bits of

Rex, but in general it's a different
operating system. Majority of super

powerful commands of DIAG such as
downloader mode and memory read/write were

removed, at least on my device. And also
it does not expose any immediately

available interfaces such as USB channel.
I hear that it's possible to enable the

USB DIAG channel by adding some special
boot properties, but usually it's not, it

wouldn't be available. It shouldn't be
expected to be available on all devices.

So this observations are based on my test
device, Nexus 6b. And this this should be

around medium level of hardening. More
modern devices such as Google pixels, the

modern ones should be expected to be even
more hardened than that. Especially on the

Google side, because they take hardening
very seriously. As opposed to it on the

other side of the spectrum if you think
about some no name modem sticks, these

things can be more open and more easy to
investigate. The DIAG implementation

architecture is relatively simple. This
diagram is based roughly on the same

diagram that I presented in the beginning
of talk. On the left side there is the

Android kernel and on the right side there
is the baseband operating system. DIAG

protocol actually it works in both sides.
It's not only commands that can be sent by

the application processor to the baseband,
but it's also the messages that can be

sent by the baseband to the application
processor. So DIAG comments are not really

comments - they're more like tokens that
also can be used to encode messages. The

green arrows on this slide represents an
example of call flow, of the data flow

originating from the baseband and going to
the application processor. So obviously,

in case of commands there would be a
reverse call flow or data flow. The main

entity inside the operating system,
baseband operating system responsible for

DIAG is the DIAG task. It has a separate
task which handles specifically various

operations related to the DIAG protocol.
The exchange of data between the DIAG task

and other tasks are done through the ring
buffer. So, for example, if some tasks

needs to log something through the DIAG,
it will use specialized logging APIs that

will in turn put logging data into the
ring buffer. The ring buffer will be

drained either on timer or on a software
based interrupt from the caller. And at

this point the data will be wrapped into
DIAG protocol and from there it will go to

sI/O task, this Serial I/O which is
responsible to send in the output to a

specific interface. This is based on the
modem, on the baseband configuration. The

main interface that I was dealing with is
the shared memory, which ends up in the

DIAG shared driver inside the Android
kernel. So in case of sending the commands

from the Android kernel to the baseband,
it will be the reverse flow. First, you

will need to send some- to craft the DIAG
protocol data, send it through the DIAG

shared driver that will write to the
shared memory interface. From there, it

will go to the specialized task in the
basement and eventually end up in the DIAG

task and potentially other responsible
task. On the Android side, DIAG is

represented with the /dev/diag device,
which is implemented with the diagchar,

and diagfwd kernel drivers in the MSM
kernel. The purpose of the DIAG shared

driver is to support the DIAG interface.
It is quite complex in code, but

functionally it's quite simple. It
contains some basic minimum of DIAG

commands that enable configuration of the
interface on the baseband side. And then

it would be able to multiplex the DIAG
channel to either USB or a memory device.

It also contains some IOCTLs for
configuration that can be accessed from

the Android user land. And finally, the
IOCTL filters various DIAG commands that

it considers unnecessary. This is a bit
important because when you will start,

when you'll try to do some tests and send
some arbitrary DIAG comments with the DIAG

interface, you would be required to
rebuild the actual driver to remove this

masking, otherwise your commands will not
make it to the baseband side. At the core,

the DIAG shared driver is based on the SMD
shared memory device interface, which is a

core interface specific to Qualcomm modem.
So this is where DIAG is, diagchar

is on the diagram. The diagchar
driver itself is located in the

application OS's vendor specific drivers.
And then there is some shared memory

implementation in the baseband that
handles this and the DIAG implementation

itself. diagchar driver is quite complex
in code, but the functionality is quite

simple. It does implement a handful of
CTLs that enables some configuration. I

didn't check what exactly this IOCTLs are
responsible for. It exposes the /dev/diag

device which is available for it in the
writing. However, by default, you are not

able to access the DIAG channel based
on- for this device, because in order to

access it, there is diag_switch_logging
function, which switches the channel that

is used for DIAG communications. On the
screen there are several modes listed, but

in practice only two of them are
supported. The USB mode and the memory

device mode. USB mode is the default, so
which is why if you just open, the

/dev/diag driver, dev/diag device and try
to read something from it, it won't work,

is tied to USB. And in order to
reconfigure it to use the memory device,

you need to send a special IOCTL code.
Notice the procedure named

mask_request_validate, which employs a
quite strict filtering on the DIAG commands

that you try to send through this
interface. So it filters out basically

everything with the exception of some
basic configuration requests. At the core,

DIAG shared driver use the shared memory
device to communicate with the baseband.

The SMD implementation is quite complex.
It exposes SMD Read API, which is used by

DIAG share for reading the data from the
shared memory, one of the APIs. Shared

memory also operates on the abstraction of
channels which are accessed through the

API named smd_named_open_on_edge. So you
can notice here that there are some DIAG

specific channels that can be opened.
Now, let's take a look at the SMD

implementation. This is a bit important
because a shared memory device represents

a part of the attack surface for
escalation from the modem to the

application processor. This is a very
important attack surface because if you

just achieve code execution on the
baseband, it's mostly useless because it

cannot access the main operating system.
And in order to make it useful, you'll

need to create and exploit chain and add
one more exploit based on that bug with

privilege escalation from the modem to the
application processor. So shared memory

device is one of the attack surfaces for
this. The shared memory device is

implemented as exposed memory region
exposed by the Qualcomm peripheral. The

specialized MSM driver will map it and
here it's the name is smem_ram_phys, the

base of the shared memory region. The
shared memory region operates on the

concept of entries and channels, so it's
partitioned in distant parts that can be

accessed through the procedure,
smem_get_entry and one of these entries is

SMEM_CHANNEL_ALLOC_TBL, which contains the
list of available channels that can be

opened. From there, we can actually open
the channels and use the shared memory

interface. During this initial research
project, it wasn't my goal to research the

entire Qualcomm ecosystem, so while I was
preparing for this talk, I have noticed

some more interesting things in the source
codes, such as, for example, the

specialized driver that handles GTAG
memory region, which is presumably exposed

by some Qualcomm system of chips. In the
drivers this is mostly used read only, and

I suppose that will not really work for
writing, but it's worth checking probably.

And now, finally, let's take a look at the
DIAG protocol itself. One of the first

things that I noticed when researching the
DIAG protocol is that it's actually used

in a few places, not only in libqcdm. A
popular tool named SnoopSnitch can enable

protocol dumps, so there are protocol
dumps on rooted devices. And in order to

accomplish this, it's SnoopSnitch sends an
opaque blob of the commands to the mobile

device through the DIAG interface. This is
blob is not documented. So it got me

curious what exactly these commands are
doing. But before we can look at the dump,

let's understand the protocol. The DIAG
protocol consists of around 200 of commands

or tokens. Some of them are documented in
the open source, but not all of them. So

you can notice on the screenshots, some of
the commands are missing. And one of the

missing commands is actually the token 0x92
hexadecimal, which represents an encoded hash log

message. The common format is quite
simple. The best pritimitive here is the

DIAG token number 0x7E, it's not really a
delimiter, it's a separate DIAG command

126. It's missing in the open source, as
you can see here. So the DIAG command is

nested. The outer layer consists of this
wrapper of 0x7e hexadecimal bytes. Then

there is the main command and then there
is some variable length data that can

contain even more subcommands. This entire
thing is verified using the CRC and some

bytes are escaped. Specifically, as you
can see on the snippet. One interesting

thing about the DIAG protocol is that it
supports subsystem extensions. Basically,

different subsystems in the baseband can
register their own DIAG system handlers,

arbitrary ones. And there is a special DIAG
command number 75, which simply forwards..

instructs the DIAG system to forward this
command to the respective subsystem. And

then it will be parsed there. There exists
quite a large number of subsystems. Not

all of them are documented, and when I
started investigating this, I noticed that

there actually exists a DIAG subsystem-
subsystem and debugging subsystem. The

later one immediately interested me
because I was hoping that it would enable

some more advanced introspection through
this debugging subsystem. But it turned

out that the debugging subsystem is quite
simple. It only supported one command:

inject crash. So you can send a special
DIAG comment that will inject the crash

into the baseband. I will talk later about
this. Now, let's take a look at specific

examples of the DIAG protocol. This is the
annotated snippet of the blob of commands

from SnoopSnitch. This blob actually
consists of three large logical parts. The

first part is largely irrelevant. It's a
bunch of commands that request various

informations from the baseband, such as
timestamp, version info, build id and so

on. The second batch of commands starts
with a command Number 0x73 hexadecimal.

This is DIAG common log config. This is the
command which enables protocol dumps and

configures them. And third part of this
blob starts with the command number 0x7D

hexadecimal. This is the
CMD_EXT_MESSAGE_CONFIG. This is actually

the command that is supposed to enable
textual message logging, except that in

case of SnoopSnitch it disables all of the
logging altogether. So how do you actually

cellular protocol dumps work? In order to
enable the cellular product dumps, we need

DIAG_CMD_LOG_CONFIG, number 0x73
hexadecimal. It is partially documented in

the libqcdm. The structure of the packet
would contain the code and the subcommand,

that would be set mask in this case. It
also needs an equipment ID, which

corresponds to the specific protocol that
we want to dump. And finally, the masks

that are applied to filter some
parts of the dump. This is relatively

straightforward. And now the second command, DIAG_CMD_EXT_MESSAGE_CONFIG. This

is the one which is supposed to enable
textual message logs. The command format

is undocumented. So let's take a closer
look at it. The command consists of a

subcommand. In this case, it's subcommand
number 4, the set mask. And then there are

two 16 bit integers. SSID start and end.
SSID is subsystem ID, which is not the

same as DIAG subsystems. And the last one
is the mask, so subsystem IDs are used to

filter the messages based on a specific
subsystem, because there is a huge amount

of subsystems in the baseband. And if all
of them start logging, this is a huge

amount of data. So DIAG provides this
capability to filter a little bit, to a

specific subsystem that you're interested
in. The snippet of Python code here is an

example how to enable textual message logging
for all subsystems. You need to set the

mask to all 1s. And this is quite a lot of
logging in my experience. Now for parsing

the incoming log messages, there are two
types of DIAG tokens, both of them are

undocumented. The first one is a legacy
message number 0x79 hexadecimal. This is a

simple ASCII based message that arrives
through the DIAG interface so you can

parse it quite straightforwardly. The
second one is I called it

DIAG_CMD_LOG_HASH, it's number 0x92
hexadecimal. This is the token which

encodes the log messages that contain only
the hashes. This is the one that if you

have the msg_hash.txt file, you can
correspond the hash that was arrived to

this command to the messages provided in
the text file. And you can get the textual

logs. On the lower part of the slide there
are two examples of hexdumps from both

commands. Both of them have a similar
structure. First, there are 4 bytes

that are essential. The first one is the
command itself. And the third byte is

quite interesting is the number of
arguments included. Next there is 64 bit

value of timestamp. Next there is the SSID
value, 16 bit. Some line number, and I'm

not sure what is the next argument. And
finally, after that, there is either ASCII

encoded log string in plain text or hash
of the log string. And optionally there

may be included some arguments, though, in
case of the first legacy command. The

arguments are included before the log
message and in case of the second command

they are included after the MD5 hash in
the log message, at least in my version of

this implementation. And this is the DIAG
packet that enables you to inject a crash

into the baseband, at least in theory.
Because in my case it did not work. And by

not working, I mean that it did simply not
enter the baseband. Normally, I would

expect that on production device it should
just reset the baseband. You will not get

a crash dump or anything like that, just a
reset. So I suppose that it still should

be working on some other devices. So it's
worth of checking. There are a few types of

crashes that you can request in this way.
In order to accomplish this, I needed a

very simple tool with basically two
functions. first, direct easy access to

the DIAG interface, ideally through some
sort of python shell. And second is the

ability to read and parse data with
advanced log strings. For that purpose. I

wrote a simple framework that I named
diagtalk, which is based directly on the

diag interface in the Android kernel and
or with a Python harness. So on the left

side, here is the example of some advanced
parsing with some leaked values. And on

the right side, here is the example of the
advanced message log, which includes the

log strings that were extracted.. that were
stripped out from the firmware. The log is

quite fun, as I expected it to be, it has
a lot of detailed data, such as, for

example, GPS coordinates and various
attempts of the basement to connect to

different channels. And I think it's quite
useful for offensive research purposes,

it's even contained sometimes raw pointers
as you can notice on the screenshot. So in

this project, my conclusion was that
indeed I was reassured that it was the

right choice and Hexagon seems to be a
quite a challenging target, and it would

probably need several more months of work
to even begin to do some serious offensive

work. I also started to think about
writing a software debugger because it

seems to be the most.. probably the most
reliable way to achieve debugging

introspection. And also, I noticed some
blank spaces in the field that may require

future work. For Qualcomm Hexagon
specifically, there is a lot of things

that can be done. For example, you can
take a look at other Qualcomm proprietary

diagnostic protocols of which there are a
few, such as QMI for example, I think they

are lesser known than DIAG protocol. And
then there is a requirement to create a

full system emulation based on QEMU at
least for some chips. And a big problem

about the decompiler, which is a major
obstacle to any serious static analysis in

the code and for the offensive research,
there are 3 large directions. First one is

enabling debugging. There are different
ways for that. For example, software based

debugging or bypassing JTAG fusing, on the
other hand. Next, there are explorations

of the over the air attack vectors. And
the 3rd one is escalation from the baseband

to the application processor. These are
the 3 large offensive research vectors.

And for the basebands in general, there
also exists some interesting directions of

future work. First of all, the OsmocommBB.
It definitely deserves some update a

little bit. It is the only one open source
implementation of a baseband. And it is so

outdated. And there is, and it is based on
some real obscure hardwares. Another

problem here is that there doesn't exist
any software based CDMA implementation.

No sound

Herald: Alisa, thank you very much for
this nice talk. Um, there are some

questions from the audience. So basically
the first one is a little bit of an

icebreaker: Do you use a mobile phone?
And do you trust it?

Alisa: No, I don't try to use a mobile
phone only for Twitter. Does anyone still

use mobile phones nowadays?
H: laughs Well, no idea. Another

question concerns the other Qualcomm
chips. Did you have a look at the Qualcom

Wi-Fi chips sets?
A: As I mentioned during the talk, I had

only one month. It was like a short
reconnaissance project, so I didn't really

have time to investigate everything. I did
notice that Qualcomm socks have a Wi-Fi

chip, which is also based on Hexagon. And
more than that, it also shares some of the

same low level technical primitives. So
it's definitely worth looking, but I didn't

investigate it in details.
H: OK, OK, thanks. There is also a pretty

technical question here, so instead of
having to go through the rigorous command

checking for the DIAG card driver,
wouldn't it be possible to nmap /dev/mem

into userspace process and send over
commands directly so. Depends a little bit

on what the goal is.
A: OK, so it really depends on your

previous background and your goals. The
point here is that by default, the DIAG

shared ecosystem does not allow to send
arbitrary DIAG commands. So either way,

you will have to hack something. One way
to hack this is to rebuild the actual

driver. So you would be able to send the
commands directly through that DIAG

interface. Another way would be to access
the shared memory directly, for example.

But I think it would be more complex
because the Qualcomm shared memory

implementation is quite complex. So I
think that the easiest way would be

actually to hack the DIAG shared driver
and use the deb. DIAG interface for this.

H: OK, thanks. Thanks. There is one
question which I'm going to read out,

maybe you can make sense of it: is this
typically [unclear] security fall mobile phones?

A: This level of hardening that I
presented, I think is around medium level.

So usually production falls are even more
hardened. If you take a look at things

like Google Pixel5 or the latest iPhones,
they will be even better, hardened than

the one that I discussed.
H: Oh, OK. Yeah, thanks. Thanks then. So it

doesn't look like we have any more
questions left. Anyway, so if you want to

get in contact with Alisa, no problem.
There is the feedback tab below your

video now at the moment, just drop your
questions over there. And that's a way to

get in touch with Alisa. Other than that I
would say we're done for today for this

session. Thank you very, very much Alisa
for this really nice presentation once

again. Applause And I'll transfer now over
to the Herald News Show.

postroll music

Subtitles created by c3subtitles.de
in the year 2021. Join, and help us!