Dear viewer, these subtitles were generated by a machine via the service YouTube and therefore are (very) buggy. If you are capable, please help us to create good quality subtitles: https://c3subtitles.de/talk/2564 Thanks!
[Music]
good morning everybody I'm Dominic U
this is Marius Domino NSR we're going to
talk about um how to analyze cellular
Bas bands um and how to find bucks in
them and about our tool which is called
filwire which helps you do this so yeah
now that we have slides set up good
morning also from my side I'm Nar or
Marius so before we start we just want
to properly acknowledge the full team
the two FM wire has been a multi-year
effort between a lot of different people
a lot of different academic institutions
and it's really a really really a
massive team effort and we really want
to shout out to all the people here on
the slide now
yeah now without further Ado let's talk
about what will be the next 55 minutes
or 45 minutes of our and your life uh if
you decide to stay here so we will talk
about Bas BS in specific cellular Bas BS
we will look into uh how to emulate them
and why we emulate them um using this
emulation we will look into different
exploration capabilities we have with
our F wire tool to then start doing the
fun stuff we will look into fuzzing um
which ultimately will lead to crashes
which we will talk a lot a bit and then
lastly we will talk about how we used
our tool to scale up uh what we we got
on
crashes yeah so what is this basement I
mean you all found your way here so you
must know at least that is interesting
uh but just to give a short introduction
um I in the beginning before I started
this project with all these fine people
didn't know that a baseband in the
smartphone the thing that actually talks
to the cell tower is its own dedicated
uh processor um so it's completely
independent of the application processor
the thing that runs your apps right like
Android or iOS uh it has its own
operating system usually like a
proprietary real-time operating system
that just runs we're going to go into
details of course during the talk um but
um the interesting thing is that it
speaks all the cellular protocols from
way back in the early '90s that you know
like you know if you if you're an in
Anger that you still have Edge somewhere
then it's probably still this basement
processor that runs all of the
communication and it's millions of of
millions of or Millions at least of
lines of C code um that are not really
looked into by anybody on the outside
world like us um and this is what we set
out to change and Basin are super juicy
um as I said you know they go back way
to the '90s where SEC when security was
not really a big thing yet you know um
we were not really we didn't know that
you could run random stuff when you had
a stack Overflow I guess people knew but
didn't I mean I was a kid but um the the
nice thing is that if you think of some
um complex spec it's probably
implemented in the basement U and it's
implemented you know in a proprietary
way and hasn't been looked at much like
you know XML parsers DNS parsers TS yeah
there's a whole TCP stack of course in
it because um who doesn't want a whole
TCP stack there's a lot of a and one
decoding and if you know a and one it's
like this binary format that breaks a
lot um used to break a lot at least um
and it's a tempting initial point of
entry on the smartphones just because
you know it's right there it's the first
thing that um receives every message
over the air um and they have been
multiple bucks if you follow you know
the security stuff recently on bigger
conferences um there was this amazing
talk by natal who um found bucks in um
smartphone basements and they were not
only exploitable from if you're like
next to it with an SDR but they were
exploitable over like the real air like
over the Internet so you needed a phone
number to exploit the phone and run code
on it um there was this talk by Amad who
was also looking into as1 and how it was
broken in the past and then there was
this talk by the Android uh red team um
about how to they try to um secure the
base Ben and about how um other bugs
they found as well and all of these
talks were just this year so there must
be something about the basements right
which is interesting so let's start from
the basic principles and look a little
bit about what are these realtime
operating systems running on there um in
a nutshell it's an operating system and
it has all the things you would expect
from operating system to have right it
has a schedulers timer some interrupts
it has some notion of processes and atur
usually called tasks and these tasks can
interact with each other we are messages
so that's a core operating system in
itself
the band AOS is responsible for mainly
two things one is to interact with the
hardware peripherals which most of the
time will trigger some over theair uh
interaction so from digital signature
processors and similar but also it has
uh for instance a shared memory region
with the application processor so with
the Android or iOS side of things um
basically yeah to forward messages and
do all the fancy thing we need to do for
calling have mobile internet and so on
what's interesting is that that um the
cellular stack so it's a lot of
specifications but usually the different
parts of the cellular Stacks Maps pretty
much one to one to the different tasks
and we have here one let's say heavily
simplified tasks for a demonstration
demonstration purposes all right so the
interesting pieces of course are all
stubbed out and this this would not
compile or run uh but just to give you
an in in in information this is like
every single task that runs in a
basement and there are many um would you
know initialize at boot or whenever the
task starts and then it'll just run
forever it'll just Loop and this message
receive function you see here dis blocks
um and waits for a new message that it
will receive from somewhere you know
down the stack or up the stack and then
it'll do something with it so if it
would be an as and one parser it would
you know parse the message and then um
have some outgoing message afterwards
potentially or multiple and send these
to other tasks in the basement and then
the message is owned so it has to free
it um and the the thing that I found
interesting or that is very true across
at least all basement we looked at is
that every single the spec in the
cellular um modem is Big um the cellular
spec is big and in the modem you have um
almost a one to one mapping because
between some of the at least all of the
different parts of the spec and a task
on the other side and there is multiple
layers in a cellular um spec and the
lower layer task will forward stuff up
the spec uh the stack oh my God sorry
good morning it's early um and then at
some point it'll reach the application
processor via
APC so now if we want to set up and find
box in the basement right there are
multiple approaches and um initially
when considering this work we were
mostly looking in three which we over
the air testing static analysis and
emulation there's also a hidden Force
One which is just reading the specs uh
some people are good at it and doing it
and finding bucks by just reading it we
are not these people we are not these
people and we don't have the endurance
to read hundreds and hundreds and
hundreds of pages like these specs are
really big so yeah one common approach
was just over the air testing right like
set up the phone idy in some uh airf
Shield environment and send all sorts of
fun messages to it um we discarded this
because most of the time we will not see
what's going on right we sent a message
the phone crash May not crash and we
have basically no introspection without
really digging deeper into hacking the
phone to be able to extract those um
another approach would be static
analyzis so taking the Bas band binary
and just using some static analysis
tools or symbolic execution you name it
um the issue here is that these firmware
the the cell basement firmware is really
really complex it has a lot of different
code in directions lot of
initializations and our experience was
that why static analysis may work for
some part like their specific task or
decoders like for looking at the
basement in a hole it doesn't scale
enough without giving too many false
positives or other problems so we
decided to go for emulation so trying to
basically take the full basement
firmware and start it from the first
instruction where it should be executed
and then execut it all the way to
wherever we want to
go and um that's why we created firmware
um it is the first open source basement
emulator full system basement emulator
sorry yes there it's a fine distin the
first one that is able to run and boot a
Bas band from scratch basically so you
can drop in a binary only Bas band you
don't need Source you don't need symbols
drop it in there and it'll boot well um
for those that are supported um we
support but we did try it on over 200
firmware images across nine different
phone models and two Basin vendors so
the phone vendors themselves may be
different but there's only like five or
so um actual baseband vendors the ones
that we looked at are mediatech and
Samsung exos there's other notable ones
uh such as uh uniso Qualcomm and then
there used to be Intel but it got bought
by Apple and then there is also huawei's
own high silicon stuff um that people
also looked at in the
past um sorry for if I forgot any
baseband
vendors um yeah let's let's let's see
how this looks like how our emulator
looks like with um an actual Bas band so
we pre-recorded all the demos just to
make it you know easier for us I guess
the demo gots um I hope it's somewhat
visible today it's not too sunny so it
should be fine right so we we start
firmware which is our emulator we give
it a modem. bin the modem. bin file um
is a you know Samsung in this case
Shannon Basin that we downloaded from
somewhere in the internet so we
downloaded the whole Android image and
then we extracted the modem file from
there this was not encrypted which makes
it of course nice for you know benign
firmware analysis like ours um and then
you see here that it boots and it locks
a ton of stuff on the very left you see
the time stamp then you see the task um
including you know what the original uh
name was and then um you see uh even the
C file where this originated so this is
you know present somewhere in the in the
firmware we need to reverse engineer it
to even get these locks and first place
um and then you saw that this BTL tasks
kept um popping up and the last few
executions look the same this is because
we were in the main Loop so the firmware
has fully booted at this point and then
just loops around and waits for things
to happen so waits for some
communication from you know the network
which never comes because it is not
really connected to anything at this
point okay very cool so under the hood
um how does f wire work to enable these
uh yeah millions of lock messes just
flying by so we split the framework in
two parts one are the W plugins and the
other are is the emulation core and the
wendor plugins is basically as the name
suggests specific for every of the
basement vendors we looked at so we have
one for mediatech one for uh Samsung
Shannon exos and basically the W plugin
takes this firmware binary and does a
full lot of pre-processing it tries to
figure out uh where are the memory
mappings it uses some magic called
pattern DB to resolve uh symbols uh
which we will need later on and yeah
once it gathered all this information it
passes on to the emulation core which
then well does the emulation so it tries
to run the code and it also emulates uh
the peripheral it needs to interact to a
point where well the basement runs so
it's not a full truthful emulation but
it helps us to get it running and it
provides us a lot of different
introspection capabilities uh which
we'll talk about in a bit I think right
right so the vendor plugins um are a
firmware loader then we have different
CPU architecture support uh things in
there um so Media Tech is usually weird
the one that we support is MIP 16 E2 uh
the latest 5G ones switch to nanomips
which is also weird but needs extra work
to get going um then for Shannon we
support arm cortex R stuff which is also
one generation older the latest one
switched to Cortex a so actually
application processor so next to your
application processor you now have an
application processor um there yeah
there's um some s so specific you know
as Mario said memory mappings Etc
peripherals that you know the basement
tries to talk to like there would be I
don't know an antenna or something or um
that anyway that we just usually stop
out we just want the thing to boot and
think there's something we don't care if
it looks real or not just real enough
for the basement to boot um and then we
have you know functionalities for each
vendor to recover the basement internal
logs so they're not actually logging all
of this necessarily they just do some
propriety stuff and then have their logs
somewhere else um and we like show them
which is nice and then we have this
pattern DB which is used um to basically
find so we don't want to hard Cod
everything so we have this pattern DB
this is how one pattern definition would
look like we have you know a pattern it
looks a bit like a regex it's has
similar functionalities it's like these
bites look for these bites and then
these are like wild card bites um
there's um other options in this pattern
like for example is it required that
this pattern exists would the is it a
fatal error if it doesn't exist so like
you know the entry entry point or
something like that like the main map of
all tasks if this doesn't exist then we
just don't want to boot it doesn't work
um and then we can run some some code as
well um and there's not too many
patterns needed to get a firmware uh
booting actually so Samsung we used 18
and medatech only nine to get the thing
running
and yeah now we have this uh
pre-processed image uh from the window
plugin and plug it into the emulation
core um the emulation core I mean as we
saw allows us to see all those locks uh
then flying by during runtime it allows
us also to just play around with a
firware we are GDB and interactive
console and it also enables us to do
fast testing we built the emulation core
using two Frameworks one is Panda which
is a qemu based um emulator which was
originally designed for record and
replay and reverse engineering but what
it has it's a lot of nice features to
hook into the different parts of the
emulation and also it comes by now as a
Pyon Library so we can uh easily plug it
and the second framework we used was
avatat which is uh basically a framework
for orchestrating so basically to tell
Panda how to run and similar and it also
allows us to basically stop and
implement the peripherals we
need one other functionality provided by
the emulation core which we heavily use
is the mod kit or the modification kit
which allows us to inject custom tasks
so we can extend the functionality of
the emulated Bas Band by yeah writing
our own code writing our own air toss
task for the Bas band and put it into
the emulated version of the firmware
there's a list of all tasks basically in
the Bas band and we just at boot time or
at any time and we slot another one in
there like in the end that's our own
task then yeah and then we use patn DB
again to find the symbols the task needs
so we can use uh actual functionality
which is already there in the base band
like we can use the debug uh debug lock
functions or we can use uh different
hooks for allocating memory and so on so
we can really use this modkit to do a a
full bunch of interesting
things um so now let's look at how to
explore this exactly so I briefly
mentioned before we have the console
which is
I think what at least I use uh the most
when playing with film wire and it's
basically a python console which
directly hooks US during the running
emulation into the emulating process so
we have a reference to the in this case
the Shannon machine object so this is
the FM wire machine which allows us to
control the emulation like we can start
and stop emulation we can do break
points we can read or write memory and
all of this is built on top of uh jupa
notebooks not notebooks sorry and
another cool thing on the on top of
these um consoles or integrated in the
console is we have our own task that
gets injected as well like you can write
your own task but we inject um this
g-link task which is the guest link task
um it's a custom task that we created
that basically forwards things from this
python console inside um the baseband so
you are on the host you're playing with
your python you can do as you can see on
the right you can you know get this
g-link um handle to this g-link task on
the inside and then you can call things
on this g-link so you can create blocks
um so you can basically allocate um
chunks of memory inside the basement you
can send messages from inside the
basement to other tasks inside the
basement again you can set events which
is a thing that you know is internal to
the basement as well you can do like hey
there's something happening um and then
you can also get values out so you don't
need to recompile your your task and
re-inject your task every time you can
basically play around with it from a
python jupy console which is really
handy and then um another thing that we
use heavily um now in the next demo is
basically uh we have we can snapshot the
whole thing at any point in time so
after let's say the boot takes a bit we
don't want to or we we are looking at
one specific thing we don't want to
reset the whole thing and reboot to the
SP place every time um and we can take a
snapshot it uses the qimo internal
snapshots and it um has enrichment with
like these peripheral that we write for
example like if they have a specific
State we can also snapshot this which is
Handy um yeah and let's see how this
looks
like yeah so here first of all we start
a tar session which we don't see right
now but we basically need uh two windows
because in one we will have fil wire
running and in the other our console so
we ReStore in the very first or we say
that we want to restore uh snapshot
which is the one for this demo and that
we want to enable the console so now we
see F wire boot up and can attach on our
second terminal which we will start here
um to um well to firm wire to our
console and once we're in here we yeah
we're typing uh we can see we have the
self object which is the Shen machine
and we can just say hey let's emulate
for I don't know one second and we see
here some of the messages flying by so
we emulated a bit and now we want to
show a little bit about G link or guest
link oh the demo is broken nice nice Dem
thank you yeah anyhow we got a reference
to the g-link peripheral and um we try
to do create block so we want
to yeah think it's resolutions from the
projector and so it worked yday yeah
anyhow we create a memory block and we
run again because this is an interactive
task so it needs to run to all allocate
the block uh which we have now at this
address down here and um this is a
freshly uh allocated block so we just
use the read memory functionality to
read 40 bytes the amount of what we
allocated and we see this is all zeros
for now which makes sense it's a freshly
allocated block so let's change this a
bit and write some memory in a very
broken up way and uh yeah eventually we
write 40 a to this
location and here we are it's zero for
now as we turn and if we read it we have
40 a there so this should show a little
bit how F wire works under the
hood right
okay sweet so what can we do with you
know we can now interact with things in
the basement what what does that mean
like what is a thing in the basement as
I said earlier you know the every single
cellular specification is somewhat
reflected in one of these tasks um so
there is you know this is like how for
example the 2G protocol stti would look
like 2G of course is still relevant
because it's still enabled everywhere
especially here in Germany you should
know this um and um well there's you can
turn it off in more modern phones but
it's it's uncommon that people do that
um so you have these different layers in
the in the specification and then there
is different tasks so there is for
example um in this case a cc which is s
for call control task and the call
control task would give you control like
it doesn't really matter what all of
these abbreviations are if you have no
idea what any of these are you can go to
3gpp doguru which is the most amazing
website for these sort of things just
type in the abbreviation it'll tell you
at least the location the spec you will
still probably have to ask jet GPT for
what the spec actually means but that's
a different story um anyway this um CC
task this call control task um it is for
the task that does everything for
circuit switched calling so in the more
modern spec if you call somebody it's
actually just a voice over IP or LTE
voice over LTE call so like it's only
bites and packets flying around back in
the day was circuit switch it was
already byes but it was uh circuit
switched um and there's still bites sent
over the air um and then there is
different messages that this CC task
will basically eat and do something with
it um so there's the CC setup a message
that is sent from the network over the
air in bites uh to the mobile device so
to our basement um and then the packet
is made up you know if you want to know
more like about what bites we're going
to send in the next demo um they're
aligned with this spec um and then we
can actually call ourselves which is
kind of
cool right yeah let's see let's do this
and hope that it works Dem let's go so
again t- marks we are starting again
from the shot and um attach again to the
console now here we prepared already the
bites we want to send for this call
setup message just uh to yeah basically
have it ready so it's what we call here
a call init payload or call setup and
these are the magical bites we got by
reading the spec and doing a little bit
of reverse engineering um we're getting
the guestlink task again or the
guestling peripheral and one little
thing we will do here before uh actually
sending the setup message is sending an
another message to the CC task which
will trigger initialization of the CC
task because by default it just spin up
it's booted but it still would wait for
the basement to complete other tasks
before uh being ready to process overthe
a messages and yes finding this was
painful reverse engineering yeah and
yeah the magic uh message for it is uh
just being typed magically in here um
the and yeah we send it and we can see
here uh if we look a little bit like
that there are a lot of initial
happened uh and we saw here that uh yeah
like initialization
functionality is going
on okay with this we can now move on and
try to send the
um send a um call setup message um which
requires a slightly different header so
these are headers for the message is
being changed down here and then we put
the actual
payload and run the emulation again and
uh we can see here already here down
here there's radio message call
confirmed written and we can also see a
lot of other CC uh functionality flying
by and being used so we basically now in
quotation mark called our emulated Bas
band or gave with a signaling message
like hey here is a call
incoming yeah so there's like you know
the some logs that indicate that the Bas
band has actually received our call and
thinks that there's an incoming call
yeah so this is what we do when or what
happens to the emulated Bas band if we
send a B9 input which conforms to spec
but what happens if we don't do so yeah
so um what do you want to do if you want
to send something that doesn't conform
with you know the thing that something
wants to receive um you use fuzzing
these days everybody probably or most
people would have heard about fuzzing
it's basically you know throwing tons of
input in a somewhat smart way into an a
Target until you find some side
conditions that the original author of
the The Thing didn't think about you
know you want to find something like an
off by one or some unchecked something
where if you just read it maybe it's too
much code and you will never find this
but if you just randomly throw stuff at
it you'll find it um and how do we do
fuzzing in firmware um well it is so we
can do normal if a Plus+ fuzzing
basically but we do it against the full
system emulated basement which is kind
of cool for this we have another task so
we had the g-link task earlier where you
can type things in Python and interact
with the basement but of course this is
slow um for fuzzing we injected a fuz
task um using our modkit it um then will
send messages around um in that come
directly from the fuzzer so basically it
eats something from the fuzer and then
sends it to some task that we want to
take a look at um and we have custom
hyper cods to get this you know work so
to get a new fuzzing message and we have
the the hyper calls will also turn on
coverage collection so the um the fuzer
will know if it found new branches in
the Target task and for coverage
collection we had to hack kumu a bit and
we injected basically um this on the TCG
level if you know how commu works it
lifts every single so during um run time
it lifts every block it hasn't yet seen
into its Intermediate Language and then
compiles it back down or SM or whatever
emits it back down into the target
architecture and if when we have this
lifted Block in our hands it's basically
all of the code and it's one it's not
one basic block but it's one translation
block so it's one code unit and we can
use this to basically um give give
feedback to the fuzer that we found
something new so we jumped from some
place to some new place and this Edge
will be you know reported back to the
fuzer so that it can store input that
found new coverage and then uh do some
mutations in a smarter way for the
future um and then we send the message
that we received um you know from the
smart mutation to this Bas fent um task
internally for this we also created
multiple proof concept harnesses else
you know we wouldn't have found bugs
which would have been sad so let's put
this a little bit more into practice and
look into how would we write our own
harness or our own fast task for a
protocol of our choice in this example
we will basically walk slowly through
our CC further and for creating your own
harness so call control what we just saw
before and for creating our harness one
world first to create a new mod for the
modkit set up the further using a
special fast single setup function and
specify what needs to be done during
each fuzzing iteration so for each
fuzzing test case we get out of AFL ++
um so creating a new mod is kind of
straightforward on the one side you will
need uh the template in this case for GS
MCC just using some includes and setting
a task name and then we need to adjust
the make file to uh basically add the CC
further in there so that will be
compiled as mod which then gets injected
during boot time um so CC again was call
control so this is actually the fuzzer
that will you know fuzz this call setup
that we saw earlier exactly and what the
fuzz signal setup does is sending the
init messages we just saw before in the
demo right like recall that basically
the task at boot stage is not ready yet
to receive over there input so we need
to send one magical reverse engineered
message before which is what we doing
here with a fast single setup um
function first we get the Q ID for cc
then we allocate a block using the P Moc
function so this is recovered we pattern
DB from the modkit uh we pattern DB and
called from the injected task directly
in the firm U yeah in the basement
firmware and then we set up like once we
have the block we set up the message so
we basically set the um the op we set
the message group and so on and then use
Paul message sem2 to send this message
we just created to the CC task easy now
this will be received and the CC Tas
would be ready so we can continue and
specify what needs to be done in a
fuzzing iteration here again we start
with getting a small block from the uh
Bas band was using power Moc and this
time we will need some space for the
fuzzing input we get so we just say okay
let's leave some space for whatever AFL
wants to give us and then we call
getwork getwork is one of our hyper
calls which we use to communicate
between uh Panda or firm wire and the
and getwork will just get an input
writes it into this uh shared buffer and
reports back the input size and the
input size variable now that we have our
fuzzing input we need to continue and
give it somehow um to the Target task to
the CC task before doing so we set again
uh up the how the message look like
right like we set the different header
fields and so on and then copy over over
the payload we just got from the fer
into the message so that we can send it
and this is what we doing no first we do
call start work another hyper call which
will enable the coverage collection uh
Dominic just explained in this case we
want to collect coverage from address
zero to address Ox FF FF FF FF which is
basically all of the memory in a 32-bit
space so we want to collect all coverage
and then we call pile message sent to
again to send it over to the Target task
and one thing to note here is that we um
modify our or we compile our um f task
to have a very low priority in the
operating system so when we call PM
sentu it will actually or the Schuler
will actually schedule our task out and
send it to the CC task which has a
higher priority so this call would
basically block and we only return two
our uh fuzzing task once the CC message
was processed and once we are back we
call done work another hyper call which
basically says stop coverage collection
we're done here for now and we can start
again in the next fuzzing iteration
right cool so let's see some fuzzing in
action um what we're going to do now is
so I'm going to show this is probably
going to be let's see let's see this may
be
broken well you know you think command
line tools would just work but you know
it's uh okay yeah well we
can yeah anyway we so what what you
should see is um basically a normal AFL
Plus+ command line um and then you
should see um can you switch back anyway
okay um yeah we we give it basically the
F task so the F the task that we want to
inject when we give it a snapshot um
that we also want to load from and then
we give it um add add for you know add
at yeah that's the add at um for um
which is if people have used A++ before
it's it's the basic command line that
tells the fuzer give me input to this
place like under the hood we actually
get the input via shared memory from the
fuzer but it doesn't matter and then um
we're going to start
A++ um this is without persistent mode
uh so that means that every after every
execution the the target quits and then
we restart the Target or we refor the
target so that's why it's pretty slow
but the stability is 100% we can also
use persistent mode which will make the
fast Tas basically just loop around and
ask the for the next input and then we
get up to like almost 2,000 XX on a
single core which is decently fast but
of course then other tasks in the Bas
May jump in it sometime so it's not as
stable but of course it's a pretty good
trade-off um so yeah so it fuzzing works
woo and then
[Applause]
um if you leave this Sky running for a
short
while actually you can also find crashes
so this CC task found one critical bug
um that was uh zero day at the time uh
we found uh we also looked into LTE RFC
which is another pre-authentication
message but in the LTE so in 4G um where
we also found two critical and one high
rated zero day and then we used SM um
which is another test that has been
explored in the past um as a ground
truth so in total we had seven CR
crashes D duplicated over all of our
fuzzing and four of them uh yeah were
unknown at this point in time and we
reported them to the window
maybe yeah but exactly so let's do the
next demo and just uh look in how it
looks like if we would replay such a
crash we
found right um so we're going to um
start filmare wire again and we we're
going to restore the same snapshot that
we would have seen in the last demo and
then we uh use the fuz triage mode which
is like fuzzing but it has more logging
enabled like we use usually disable
logging during fuzzing because it's slow
um and then we give it the input that
the fuzer found so the fuzer
conveniently named it no we named it
crash. bin and then we run it against
the same modem bin we renamed it to V
modem in this case um and then you see
in the end that there's a prefetch abort
so it's faulting at a PC it tries to
fetch a PC that doesn't have executable
code which is usually a good like a bad
sign from security perspective or a good
if you want to find bugs that maybe
exploitable fathers will like it
developers not so much
yes um okay cool and um this so to show
that these crashes actually work uh we
also replayed them over the air so we
used you know some uh bts's for GSM we
used yate for LTE RC we used open LTE so
you know you can talk to a little SDR
and the SDR will then send our input
like we patched them to send our inputs
that we uh found that are crashing and
then actually all of these free
authentication um messages also caused
you know a crash in the actual modem so
you see down here uh real restart which
means you know the radio layer just died
and I'm going to restart it um yeah so
which is I mean this is probably the
good case because this means that it's
just crashed and restarted which is
better than other things that you know
there's no code being run in this case
yeah and I mean that's all what it means
to crash basement in that sense it's not
that the phone like dies and reboots it
just the connectivity symbol on the top
right will disappear come back you will
get a little popup in the best case um
but from attackers view uh they could go
from there and probably exploit the Bas
band and uh yeah take it from there and
we were not interested in that instead
we were looking more into the different
bucks we have in a large large scale
context so we collected a lot of
different firmwares and oops oops sorry
yeah and um the idea is we have some
ground TR is crashing or some crashes
which work on the modem ref how does it
look in the full ecosystem so if we take
other modem images and replay the same
crashes what would happen so with the
intuition we could get insights about
patching timelines and similar and we
collected for this like uh I think over
200 different uh firmware images from uh
mirror which has the full Android update
and extracted the basement modem image
file from
there right and um overall we we collect
360 firmwares from you know between 2016
and
2021 um of these 31s were duplicates so
we downloaded a new new Android image
but it had didn't have an update on the
modem image which you know happens they
don't update the modem as often as the
main operating system um and then uh of
these we were able to boot 23 so six of
them failed to boot and you know in the
large scale study you don't really want
to look into everything so probably they
just like hanged in something waiting
for some data that we didn't provide in
the right way in this case um so and
these are the models that we looked at
so a lot of Samsung's um S7 to S10 and
then uh a41 and a10s so these are also
Samsung phones but using a mediate Tech
basement shift yeah yeah yeah um as well
and then uh on codo you can find
actually the whole data set if you're
interested and want to replicate our
study exactly and here are
at our study again I guess any here are
our results and don't be afraid this
figure is overly convoluted and
complicated but we will walk you through
it so first of all each dot in here is
uh one firmware image which we
downloaded and on the bottom we have the
timeline so this is firmware images over
time and on the left we split up for the
different phone models we tested and
this Graphics is just the uh Shannon
based ones and these here are the
different crash ing inputs right so the
ones we found during fuzzing and in this
figure we see uh when there is a green
background behind the dot it means there
was no crash or we didn't observe a
crash when we playing the crash when it
was a red uh background it is we saw a
crash happening and the grade out ones
is okay we had some emulation errors and
or couldn't access whether there was a
crash but as we were large scale we just
didn't care we just looked into what
does crash what does not crash and I
think there are a couple of interesting
things to see first of all the SM bug we
used as ground Tru testing um we uh yeah
we basically saw that it was indeed
patched for good it never came back
later on any phone uh after it was
initially patched um the CC1 crash we
found really affected all the phones so
it was indeed quite a critical
vulnerability and we also happily see
that it was patched and didn't occure
again um for RC bucks we see that they
are not affecting all bu so there are
not all phones sorry so there are quite
some differences which I think is also
quite interesting and we also see which
I think is one real good outcome of this
large scale study that sometimes there's
missing patch propagation right we found
this rc1 Buck uh on the St in the F we
reported it and only one year later we
did the large scale analysis and we saw
oh no another phone this bug is actually
still active and not patched so we went
again and reported it and uh got it
fixed in the very end
eventually um so yeah these are some
interesting insights but let's wrap up
the talk yeah yeah thank you all for
your um for your time uh so we as uh
said in the beginning we um built the
first uh public for system basan
emulation platform we have cool
introspection stuff and instrumentation
capabilities that you looked at
including like fuzzing and you know
looking around in a basan uh we have
support for mtk and Shannon from back
then uh we found multiple bucks and
there's um probably a lot more so we
basically writing a fast task um is a
manual effort you have to reverse a ton
um and then build your task and there's
probably a lot more um if you want to
look at it um you can go check out our
source code on firmware firmware on
GitHub um we have you know a stalker so
you can easily set it up and we have
documentation which is a big plus for
open source project I
[Laughter]
think
Y and with that we want to conclude our
talk um you can reach us via email and
you can you know go to our repo and ask
questions starting now thank you so
[Applause]
much
well you mentioned the cortex a already
as a application processor on top of the
application process are there any plans
to add support support for the cortex
a plans yes time
no yeah PR welome we we're basically
tiing back to this every half a year
doing a little bit more but never it's
by now just in the state of a hobby
project for us we uh yeah take but that
being said we welcome contributions um
so they are still we tried that's why I
ask oh okay I mean we can sink and try
to make it happen
right and uh second question don't know
if it's allowed um how did you get
started on this did you first read the
specs did you first try to reverse did
you for me it was first starting the
reverse engineering and yeah yeah I have
no idea about specs I I learned specs
during looking at binary inputs I think
so did somebody else on the team have a
lot of time to read the specs or yes in
the end we had some people in the team
which were really knowledgeable about
the um about the specs and also when we
were stuck we were looking at things
together and then they can just up with
oh hey that could be this and this
according to that and that spec and yeah
I mean and the main main question which
is interesting and can only be solved by
looking at the spec is which tasks are
actually accessible over the a right
without authentication or which are more
critical than others for this you need
some knowledge about you know spec
specification thank
you thanks for the talk um I'd like I'd
love to have some insights about how
much time and effort went into all of
this work like how much how many years
have you all been working on this and uh
uh yes so I so I I I think I start so
Grant I think started working on this
mid 2009 and I joined in in around
winter 2019 and um then it took I think
until early 2022 before we had the
public release of the tool um by I say
2020 I I think we had a proof of concept
uh kind of working only for Shannon very
rough but at least it was running and
emulating which was cool and I think the
uh main mild Stone but then yeah fuzzing
and increasing on this took also
considerable amount of time and then I
started also looking independently into
mediat Tech stuff in 2019 as well or 18
even though it definitely there was some
way to go um don't start this from
scratch I guess but
uh mean by now there are probably also
uh like better full system emul Tools
around um that make may make it easier
to you know like all of the fuzzing
stuff at least is kind of solved now
yeah and also yeah for perspective early
2022 we released the framework and just
yesterday we pushed version Wii
1.1.0
[Applause]
he um thank you for the talk uh could
you tell us sort of roughly what typical
firmware security looks like on these
bband uh processors like you mentioned
encrypt encrypted firmware but I imagine
there's signatures and things of this
sort so yes um some Wenders do encrypt
the firmware almost all Wenders sign the
firmware so that you cannot just modify
it and so on but beyond this runtime
defenses I don't by the way I don't
think encryption would be a security
feature right but it's just
me yeah um so signature checking for
preventing you from running your own
basement firmware which I guess makes
sense and uh then runtime uh security
protections are I would say a bit laging
behind for what we know from desktops We
have basically no
aslr like we have uh some some sort of
Heap cookies which are always in the
Shannon example which wear just one
static string similar with AOS stack so
not function stack cookies but cookies
for the full stack which we startic
initialized to one value so it's a bit
uh stuck in the past but I hear there
are great efforts to improving it if you
look at the Android red team talk on
blackhead you see that the U you know at
least on Pixel they're working on
getting this
improved but yeah back back when we
looked into it there was basically
none um how do you reverse engineer the
format of the IPC is that easy or
um how do you go from a crash to the
actual radio message so you have the
different tasks but do they actually
just send the the content of the next
layer to the corresponding task or is
there something more complicated going
on yeah usually uh task takes in a
message does some unwrapping and maybe a
little bit processing and then takes the
rest which needs to go more up and
fenses on up and it all uses I mean in
most case it uses the same or at least
very similar function for doing the
message sending and then for processing
you basically see how this message is
processed and you can use this to infer
uh the C structure which this method
should have had and once you created
your types for that it gets all a little
bit more easy to see the task that we
looked at were all you know accessible
over the air with bites so it was not
that hard and they would forward it
internally to other tasks as well during
fuzzing because it's a full system um
framework so that makes it a bit easier
yeah but of course if you look into an
internal task and then you will have to
craft some message that would probably
be be more you know harder than what we
did yeah thank
you um is there any work to extending
this to other base bands like the
qualcom or other vendors yeah so with a
Qualcomm there's one main road block at
the moment that qualcom basements use a
custom instruction set architecture and
the tooling for this is a bit laging
behind right so without having a full
system emulator for qualco basebands we
cannot uh or not a full system emulator
for hexagon in general we cannot build
on top of it with our tooling um the
only thing you can do with qualcom right
now is um use lip AFL qemu to do
basically a single task in users users
user mode cimu user mode kuu there's a
public um implementation in you know qim
Upstream um and then Li lq U can
actually F these single tasks but then
of course you don't have all of the
flashy full system interaction between
tasks and
things how do you interface with your
simulated Hardware do you intercept the
API calls or emulate the register level
access we emulate the register level
access and yeah and and I mean we stop a
lot right in some cases like when
peripherals need to initialize we don't
really care what's going on most of the
time the F will just check like it
writes something we discard it in our
emulator and then it will check is this
bit set to one which indicates uh uh
that it was initialized so we are we're
lazy and just created a cyclic bit
peripheral which on every read AIS would
return another bit set and eventually
like once we had this simple approach we
booted I think 90% of the different
peripherals and yeah some of course
needed a bit more work and more uh more
reverse engineer and specifically timers
I still have nightmares about reverse
engineering
timers
um from the demos it looked like you
always use a specific snapshot has there
been like selection process of of
selecting snapshots that you want to use
and because it was perceived as runtime
and fuzzing on the runtime but um did
you prepare a specific snapshot so the
snapshot theistic we used was quite
simple we saw in the first demo that at
some point it was looping and scheduling
the same task we took this address which
from the BTL task which is not important
but we saw this just say okay here's a
modem will expect things to happen so
let's snapshot there and then yeah we
went from there so it's main need to
skip over the initialization for this
like you could use snapshots deeper in
the stack somewhere where some side
conditions have already been met but we
didn't do that yet yeah I was curious in
in the combination with fuzzing I mean
if you can proactively like you have
discovered a new Branch you make a
snapshot right it's a very powerful
mechanism to just start from uh
something where you have done most of
the work and you're just looking and
then you're saying like Okay this Branch
I want to get here and set out the fuz
to to get towards their target with
solvers or something yeah I mean you
could do this right you create could
create a manual harness which first does
this and then snapshot or yeah like you
could automate it we we haven't done it
yet pandas is a good
choice great that we have so uh many
questions unfortunately I have to give
the last question
now hi uh the trick where you're like
scheduling your fuzzing T task with a
low priority is C cool but did you run
into cases where essentially you're
stopping too early or like the thing
you're triggering is very synchronous
but like your fast task has already
stopped and it doesn't get executed
anymore not to not we're not aware of
that I don't think that happened because
we're really like we're the lowest
possible priority and every call control
stuff is higher priority so the schedule
will always just schedule everything
higher than us and also another thing is
the persistent mode right we implemented
this persistent lock at some point so
basically persistent mode the work would
be done and then the next fuss iteration
like the basement continues the F task
gets scheduled in send the next input by
then maybe side condition happens uh
triaging gets a bit messy at this point
but uh could in theory be done right so
essentially every message is like always
processed instantly and there's not like
a queue where something task checks it
periodically or something like that not
in the stuff we looked at probably that
can happen but then you will have to
find some way to yeah I mean one one
thing to say is also we specifically
looked into pre-authentication messages
because this is uh I like one of the
most lucrative attack targets right as
are just taking as this and usually
pre-authentication there's not a lot of
state yet yeah and you don't I mean the
cool thing about preo stuff is that it's
it's simple and you don't need any um
like
yeah you can just send this as a rogue
base station you don't need to be uh in
any case like um a proper benign um
cellular person or uh yeah any v um
anyway you see my brain is already fried
uh thank you so much for your
[Applause]
time