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/1521 Thanks!
the digital distributed online chaos
will now present you no POC no fix a sad
story about Bluetooth security so uh PC
here stands for proof of
concept and not people of color it's
about
technology uh it's uh just a brok M Copy
in the Bluetooth stack and do we really
need to fix that so that's probably what
the Bluetooth developer thought and Jan
wer is talking about what he found about
what he found out about
it so to
Yan hi uh my name is Jan Ruger and uh as
lyom said before my talk is no PO no fix
and I want to present some additional um
it security findings that we had in the
Bluetooth
deck and I want to uh tell you something
about the vulnerabilities as well as our
methodology and also something about the
disclosure process that we had with
those
windows so first of all my motivation
why I want to do this um during my time
at University there was a next one
firmware patching project as Yar
mentioned before and it was targeting uh
broadcom Wi-Fi controllers so the main
idea was that we can implement the
monitor mode on the Nexus 5 what wasn't
possible before so they built this whole
patching framework um around it so that
we have access to the firmware and can
modify it and as a consequence uh others
use this knowledge um to build exploits
against uh those Wi-Fi controllers most
prominent is the broad pone exploit by
Google project zero and other one was by
quar SL in April April uh
2019 so this is always uh something you
have to keep keep in mind if you do uh
reverse engineering and make your
knowledge public um others might you
will use it to to write exploits and
those are of course only the the public
uh known exploits there might be even
others um that we don't know
about So currently uh at simu there is a
lot of research going on regarding
broadcom Bluetooth controllers as you
heard before um there's a internal grw
project that uh adds debugging
capabilities to the uh to to those
Bluetooth controllers and we are
currently having there the same problem
that we have making lots of knowledge
about the controllers publicly available
um and so we wanted to have a look um
before others do um if there are some um
obvious
vulnerabilities so first of all a little
bit of background so um most of you
already heard of Bluetooth it's a radio
protocol operates at 2.4 GHz and it's us
us used for communication between two
devices or more devices so for example
your mobile phone communicating with a
headset and what some people uh might
not know is that when you have a a
mobile device with bluetooth just
enabled um you can connect to it per
default so for example you can can run
L2 ping what will open up an L2 cup
connection and run P ping commands over
it and this is of course a huge attack
surface if you can interact with nearby
devices without them even
noticing um so yeah and in addition
there are some protocols that are hidden
or terminated in the firmware so they
are not accessible from the host and
those are quite poorly documented and
the implementation is not PL so and
those are also prone to
errors and the plat platform that we use
I guess this already showed it to you um
is this uh Cypress development board and
if you say Cypress or broadcom um I use
the terms basically as the same vendor
because uh Cypress has acquired a
broadcom wireless um stuff A couple of
years ago so um the copyright in The
Firm is also
broadcom and yeah as I said we used
those um Bluetooth low energy um
development
boards um because you can run C code on
then so you have the wiwis uh
development environment and can execute
your C code on the controller and most
interesting here is that there is no
separation between the application that
runs on the um on the controller and the
uh firmware so you can read all memory
regions you can um read the ram you can
read with the ROM and even interact with
it uh in addition uh the firmware
somehow has to link the C code against
the code that is stored in the ROM so
that you can use Primitives from uh from
the already existing
firmware and so the development
environment basically leaks function
names Global variables and Hardware
register names for everything and what
made our reverse engineering progress uh
a lot lot
faster so now uh a little bit about the
Bluetooth protocols that are relevant
here so on the right we have a diagram
um on the top there is a host on the
bottom here this big thing is the uh is
the
firmware and uh here you can see there's
the L2 car protocol I mentioned before
it's are basically the lowest layer that
can be uh used to communicate between
two
devices and this uh two car protocol is
then wrapped into HCI whereas HCI is a
communication protocol used for the host
to speak to the
firmware and uh for the firmware itself
uh you have here on top the um Hardware
registers for the serial interface and
then this blue stuff over here is uh the
multi-threaded firmware so there runs a
real-time operating system on the
firmware uh imple implementing multiple
threats and here on the top there's a BD
transport threat what is responsible for
pausing HCI
messages and yeah this uh then we have
here the link manager that processes
those uh HCI messages and also Al
implements the link manager protocol
what is the protocol I mentioned before
that is already terminated in the primma
and not accessible to uh to the
host and this uh link manager also
controls something that is called a
Bluetooth corul and this is an
additional component uh developed by
broadcom so it's a custom
schul um and this schedular is involved
for each Bluetooth clock cycle what is
around about 300 microc so this um
interrupt Handler here on the bottom is
invoked 3,00 uh 3,000 times a second and
this uh Bluetooth corul implements all
the time critical tasks um for the
Bluetooth
protocol and now I'm a little bit more
of background so as I mentioned before
there's the internal Blue Project
um uh they that you can use for
debugging the the firmware and as the uh
project was developed first
they were working on the Nexus 5 so they
didn't had any symbols and they're just
doing it by plain reverse engineering
and even though they were able to get
access to the link manager protocol and
extract uh those messages and also send
arbitrary
messages and in this talk I want to talk
you uh talk about Frankenstein which is
an emulating and C patching framework
and this is also what was used to reveal
the Bluetooth core
schu and why is is important um because
if you have a look at a Bluetooth packet
this is how it looks on the physical
layer um in the beginning you have the
um Channel access code what is basically
a link identifier between two devices
then you have the packet
header um that describes basically the
type of the packet this is a management
packet this is a data packet and then
there is a payload header what describes
some flow control stuff and a length
field and in the end you have finally
the payload so if you have no or don't
know about the Bluetooth crcular you
only have access to the payload for
example if you're coming from the host
you can set arbitrary L2 cup packets and
if you can send LMP packets you can send
um management packets uh with arbitrary
payload but as we now have also access
to those um packet and payload header uh
we can basically send arbitrary package
uh packets and in this talk U most the
Halo header will be most important
because and this um triggered some
interesting
bugs so um main technique that we uh
used um was uh hooking so as I said
before we can uh execute code on the
controller so we um built an custom
hooking ALG um hooking mechanism so we
can easily debug the firmware for
example we can trace function calls
extract the um the arguments um that are
used to call this function and in
addition we used it to implement some
Texs because we needed to modify the um
protocol behavior on the link manager
protocol level and also Implement use it
for
fuzzing and yeah what we um did pretty
early in the process was we found the
function that uh is responsible to copy
the payload data to to the send buffer
to the hardware send buffer and so we
send uh uh basically set a hook on this
function and in this point we can modify
the packet and payload header and even
the payload and therefore Implement
fuzzing and this is how it uh looks like
in in practice so this is actually the
code here uh we have this function here
BCS DMR TX and a
eir um what is basically the the
function that copies extended inquiry
response packets to the to the send
buffer and standard inquiry response
packets are the response if you're doing
a device inquiry so if you are scanning
two devices and this is uh the response
packet it has round about 240 bytes of
data so it was quite interesting because
there fits a lot of data into it and
this here on the bottom is the actual
fuzzing function that is invoked prior
to this copy and all it does is
randomize the Bluetooth address so um
the scan results are not uh as fast or
not
discarded and here we are simply just
flipping random bits in the in the
payload header and yeah that's it so I
um flashed the code on the controller I
um yeah set it to discoverable and
started scanning with my with my laptop
and boom it crashed actually the
controller of my old TV uh
T430 and okay so uh the problem here is
that it's uh the T430 is a very old
laptop um the firmware is from round
about 2010 we are not actually that sure
because it has no build date in
it um we tried the same technique
against newer devices and newer is Nexus
5 so even quite old devices and they see
not seem not to be
affected so I thought uh yeah well it's
probably not worth the effort but J said
may maybe you should have a look anyway
so okay I looked at it and yeah I had no
symbols for the firmware so it was quite
hard time to figure out what's going on
at some point I had done had the full
firmware image had an image of the crash
and it looks like um that that it was a
heap corruption because we can look from
where we come from and as you see um
that there are some function involved
that are relevant for the Heap and this
is quite problematic because um on the
on this particular Heap implementation
if you have a buffer overflow you
basically corrupting some point or
somewhere and then you free the buffer
and everything is fine and somewhere
later you are trying to access those
corrupted data and then it crashes so
the it is basically impossible to
correlate the crash with the cause of of
the crash um yeah so we had no luck with
uh with this one so we gave up and
focused more on the emulation part of
the
uh of the our
research and yeah the basic idea here is
that well the fir is just arm
code and we can maybe we can just
extract a well-defined firmware state
that contains all the registers all the
memory um and just restore the registers
and try to reexecute it maybe and this
is here on the right is a code how we
did this so we have this xmit state
function that can be also invoked as a
hook as a hook
and all it does is it saves the
registers to the stack and stores the
stack pointer at a fixed location in
memory and then we are calling the xmit
memory function that will actually uh
disable all the interrup so we have no
um other code running in the meantime
and then we are sending all the um
memory regions that we want to the host
and this is important that we uh do not
use uh functions that that use threading
for example invoking the BT transport
thread so we just directly use the
hardware registers to uh send out the
the memory
dump and if we have now the memory dump
on the host we can basically call the
continue function and this will uh
restore first of all the stack pointer
and load the registers and continue
execution and yeah let's see how how far
we can get with
it but first of all um yeah we have the
memory dump and of course we have don't
have the hardware registers anymore we
have no Ur the radio front isn't
implemented so we have to do some
modifications to the um to the fir f
first of all and here is how we did this
so we just wanted to use plain qmo arm
um so not we didn't want to implement or
to mess up with
qmo and so first of all we have here the
firmware where we extract our memory
dumps and those are then converted to to
object
files and as I said we need to do some
modifications we uh want to write C code
the C code um lives in the same memory
um as the same address space as the
filmare so we also can compile this to
um to an object file and as I said
before we have a full list of all
functions of all uh Global variables Etc
so what we can do is we can link our C
code against the firmware image that is
stored in the
that we extracted from the chip so um we
can basically write C code in the same
address bace so we can invoke functions
we can pass data structures and and so
on and in the end we are after we have
compiled everything we can link it to a
new EF file and the EF file uh then
describes the the memory layout of
course um of the of the firmware and
down here here is an exer page where our
C code list and the C code first of all
does some modifications to the to the
ROM and to the RAM and then secondly it
calls the continue function and restores
those
registers
and uh yeah first of all what we did is
we added a lot of debug messages so that
we can trace function calls um which are
invoked in order to understand what is
going on and in the end we were able to
implement U the spring Behavior we were
able to inject and extract HCI messages
and we are also able to uh inject and
extract raw Wireless frames so what we
can do right now is um as we can make
use of HCI we can try to attach it to a
running operating system and feed
basically data to standard in that are
then processed by by the FMA as it were
valid Wireless frames and then see how
the um firmware behaves together with
the operating system and see what's
going on and this is what I want to
quickly show you in in a demo I hope it
works so I have here an
Ubuntu and as you can see here I have
the let me
make C let yeah that's better um I have
here the um bluetooth settings of a want
to open there's currently no adapter
uh here I have the um bton running so we
can see what's going on on the HCI level
and here is a watch on HCI config and
there currently there's no adapter and
here on the top there is the magic
happening so uh this HCI attached binary
is actually the compiled firmare that we
can uh run and it will automatically
attached to the Bluetooth
stack and we now pass uh pass random
data into the um compiled firmware and
see how theem system behaves and as soon
as I execute it we can first of all see
that we've got a lot of logs here's uh
activity going on in the BT one we have
new new adapter here that is now up and
running and sooner or later um The Firm
actually starts a device inquiry and
scans for devices and we get actually
valid scan results so the random data
that we are passing to the firmer are
interpreted as Wireless frame and if we
have a look here in Bon we can see here
event device found another device
found
and yeah of course we get also uh a lot
of locks and I
[Music]
hopefully damn it demo time uh doesn't
work but um anyways
um yeah
um let me start it
again scanning for
[Music]
devices
yeah no matter
um yeah as you can see uh we get a lot
of locks um and what I also told you
with that uh that we can reexecute a
firm EST State
and uh so in this case we have here also
a web front andw can execute the firware
and get even more insights into it
and um
so here I have a a compiled firmware
state that will just execute the
firmware and um until it's enter enter
idle set so here we have the debug
output
um and as you can see we have here uh
information about the contact switches
and memory allocations and so on uh we
can
also uh get here a a view of the memory
where we can see what um what memory
regions are are modified and also all
the symbols and on the bottom uh we have
a um we have a activity map of the of
the
memory um where we can see what memory
regions are executed what which are read
which are written and you can uh zoom
into here and there are also symbol
annotations um for the
firmware so
um yeah sorry that the demo didn't work
quite out because what what actually
happened is uh this here um because uh
in the device inquiry there's um there's
actually a bug and uh so there's a a
heap corruption and the Firma should
actually crash at some point with a heap
corruption
detected and this here is the um is what
you would see on the console so
um yeah we have added a heap sanitizer
to it and
somewhere get
[Music]
received
um and yeah okay here's it uh we can see
that we here have a memory allocation
with hex 109 bytes and it's returned
this address here and later we are doing
a M Copy into uh this actual buffer with
a length that is uh Way Long longer than
the um 6 and or longer than the 109 N
bytes and this is then detected by by
the Heap sanitizer and gives us
information actually where the um Heap
overflow happened uh with all the link
register so we can actually debug the
the um uh the
firmware and this was an actual cve that
we have
reported and it is Heap as I said a heap
corruption during the r inquiry
and as we had a closer look to it it was
actually the same bug as on the
T430 so the problem here
is that we have a a buck within the
firmware um that we can observe on the
firmware from
2010 and on a firmware that is from 2018
so it was at least for 8 to 10 years um
in
production um this buck and most
interesting here is that the bu is
actually located in two different
locations one is uh inside the Bluetooth
cor scheduler and the other is in the
link manager and if you have a look at
the source code what is happening here
um we are first of all extracting the um
the the packet length from the payload
header uh by discarding the lower three
bits and then masking out the length
field and in the link manager thread we
are allocating at 264 bytes of memory
and then we are doing a M Copy into this
buffer with a previously computer length
and what you might ask is here okay
first of all a a length check is missing
uh what happens if we send a data that
is or a packet that is longer than the
expected 240 bytes and the answer is
actually uh nothing will
happening uh because the maximum packet
size is limited on the on the physical
layer but was uh the actually the um the
deadly Buck here is that the bit mask
over here is uh is wrong it's uh 13 bits
not 10 bits as it should be so the
packet length also incl includes the
reserve for future uh use field and this
field is normally normally set to zero
and as soon as you uh set a single bit
into the field to one um you greatly
exceed the maximum packet size and
therefore uh trigger above
overflow okay so um you might ask um I
can uh have a M Copy with um that causes
overflow but I can't actually control
the data that I'm overflowing with so
what's the point here but uh in fact if
we have a closer look at the firmware uh
what we did is we uh set the used the
pattern for the for the payload data
that we could easily recognize in memory
so here on the bottom you can see uh the
blue part is a um is the actual packet
that we sent and for some reason we
don't know even why um the some part of
the packet is actually duplicated in the
end so even though we only settings 240
bytes of memory uh we can get an
controlled overflow
here and this is pretty dangerous on the
uh on the SE implementation because if
you have a look here um this is how the
he looks like it's basically just a
management of of buffers with fixed size
so we have have here a free list of or a
linked list of uh all the free buffers
and if we have a overflow we can corrupt
one of those pointers and basically
redirect the link list to an AR
arbitrary location
memory so what we can then do is uh you
can uh treat any arbitrary memory
location uh as AEL buffer if we are able
to uh allocate three buffers in a row
and then therefore we can override
arbitrary
data and um as there are no exploit
mitigations at all so the complete
memory is writable and
executable um we have a rightware gadget
uh we can basically overwrite a function
in Ram and therefore gain code execution
and if you think about asrr um forget
about it it's all static layout and so
really no um exploit mitigations at all
so we built a full proof of concept for
this and then um disclosed it to
broadcom so on April um last year we um
informed them finally and after two
weeks we uh requested a status update
and ask U what's going on and they said
um that they have found this bug in
February 2018 and they had a complete
fix informed all all their customers and
there's a soft software upgrade
available and and so everything is
fine and this is a pretty strong Poker
Face here because well our latest
snapshop from the fmer was January
January 2018 and they stated that the
buck that was for at least eight years
within the in the firmware uh was fixed
two weeks later so we had a closer look
on this because um I was pretty sure
that I have tested uh the Samsung Galaxy
A3 with a um patch level that was after
after February 2018 and later we also um
tested the Samsung Galaxy S8 um what has
a uh patch level from March 2019 what
was quite recent at that point in time
and in fact uh we tested even more
devices and we couldn't find any device
that uh actually was not vulnerable so
even some Fitness tracker were
vulnerable and so we asked what's going
on and they said yeah we normally
provide fixes to our customers and yeah
it's at their discretion if they want to
fix a buck or
not so um yeah as I said we couldn't
find any device that uh was patched um
until Yar bought the s10e and here's a a
relevant part of the code so here's the
M Copy again and they have indeed added
a length check so they are checking here
if the length is greater than expected
24 bites and if it's the case there are
trun in it it and this firmware has a
build date from April 2018 so they
indeed found the buck in February so
this is for uh this is leged but
uh yeah well um in the end we had to uh
escalated it to the vendors so we
contacted um um Google and we contacted
Apple because they are using or at least
apple is using broadcom Bluetooth ships
and the Samsung um Al of course using
Android as well and so uh Android
supplied uh fixed or firmware images
with this fix in August 2019 and also
Apple um provided fixes and gave us
public
recognition and yeah this was um pretty
pretty stressful disclosure as we had to
really um ask the renters please could
you supply a fix um to finally um for a
remote code execution that is in the
firmware for over 10 years um that's not
the way how it should
be so now I want to talk a little bit
about um ACL or asynchronous connection
list what is the term for Bluetooth
connections so fuzzing ACL is
um is of course an interesting Target
because it's the most complex task um or
the most complex yeah
thing in the firmware because uh this
also includes the link manager protocol
implementation uh in the link manager so
we really expected some bucks here
especially because Yar already found a
missing length check in the um in this
Handler
table um so we tried actually a lot so
we tried coverage guided fuzzing um with
the Bluetooth stack attach we tried
coverage gu of fing uh on ACL packets
but this wasn't um didn't yield any
results because the ACL packets are
directly passed to the BT transport
threat and therefore um they do not uh
they are not processed by the link
manager and we also tried the same uh
like for the inquiry packets where
we um mutated the packets before they
are written to the hardware
registers and none of of those um
approaches yielded any useful bugs so we
were not able to crash the F what was
quite surprising to us but except and
there was one crash we could observe on
the Nexus
5 and this was during my thesis but the
problem here was a it wasn't in scope
because I I wrote my thesis on Dynamic
uh firmware analysis and therefore um
the Android operating system was not was
not in the scope I hadn't really time to
debug this in addition uh our build here
had no symbols what make it even makes
it even worse and then we are in a
heavily threaded process as you can see
here we are crashing in in threat number
19 um so I gave up on this and stated in
the in the uh in my thesis that's
probably the fragmentation exploit
described by
blueone um but later we um actually
retest tested it and throw the same F
against the um
s10e and actually yeah we could um there
also observe a crash um what we yeah
basically forgot about it and as you can
see we have here um finally also symbols
so we are crashing in a M Copy what
looks good on the first hand but if you
have a look here on x2 what is was
during invocation the length parameter
of the M Copy it looks pretty much like
a negative
number and the fault address here with a
lot of zeros um in the end also
indicates or is a strong indication that
we are having here A M Copy with a
negative number what is an infinite me
copy so we are run running at the end of
a page and therefore crash and if you
have a look at this reassemble and dis
dispatch function
um we can uh we can see here that there
is indeed a M Copy with a difference in
the uh in the length argument and if you
have a um if you roll the numbers
there's indeed an an edge case where you
can uh cause a M Copy with a negative
length U what is caused by uh this if
statement what is actually above a
overflow protection so okay this is a
valid case but uh as we tried further
fing fuzzing and see what crashes we
could generate um there are some crashes
that we couldn't really explain for
example this one um where theault
address looks looks really odd like um
even um as we have overwritten it with
uh some
asky and it's a completely different
code location and all those crashes are
um R not rep
reproducible
and so yeah we might expect there's
something uh else going on but first of
all um the relevant code look location
here um is for the
um L2 cup
defragmentation so and it works like
this if you have a a packet that or want
to send an L2 cup message that is longer
than you can send on the physical layer
for example you have to FR fragment it
in in some
way and
um so if you um send the packet you'll
say I here is a packet that or L2 packet
that is ,000 by lungs and here you have
the first 500 or so and then the um host
operating system will then allocate the
full 1,000 bytes and if and keeps the uh
keeps track of the offset where the
packet or the current packet ends and
then if the next packet arrives is then
copies the payload in the end of the
packet and then tries to reassemble it
and the problem here is that the men
copy on a prior Android 10 is really
weird when it comes to negative uh
numbers we haven't done full disclosure
on this but um it was indeed possible to
um to exploit this bug at least for nro
10 and here's what uh how it looks in
the end so you end up with a basically
reverse shell with the same privileges
as a Bluetooth um demon on on
Android um and as we then roll our write
up um to report it to Google um we
actually had a second look um at the
master branch because I am had um
bookmarked for myself the source code
for the Android 9 Branch because this is
what running on my test device and then
I had a look at the master branch and as
you can see here and there already was a
commit um that fixes actually fixes this
bug and it also says uh directly wrong
packet L length leading to memory
corruption and this uh Buck uh this
commit was actually from April 2018 so
it was a quite um quite old bug and it
was visible for for a couple of month
publicly in the in the mastera branch
but for some reason it wasn't um applied
to any um
releases um
yeah so yeah as as I said before we
buildt a PO for this and at the point it
was fixed what was in in February um it
affected U round about 60% of the
Android devices so round about 1 5
billions and um yeah we did is the
disclosure on November on the third
November 2019 and the fix finally came
out on February uh 2020 so uh even
Google requires a full 90 days to to um
basically um apply a commit that is
already there in the master branch and
we here also have here the problem that
there are a lot of devices that only
receive quot updates so only receive
updates every every 90 days and there
are still still a lot of devices that
will not receive uh updates at all
because um the phone is older than uh 2
years and then we were also contacted by
um some Automotive vendors um where I
not even sure how their patch cycle
looks like so um this is a always the
problem if you have a chain of of
different companies if you report back
to the first company
they require 90 days to fix it and then
the next company also need need 90 days
to fix it and and so on so um disclosure
of such vulnerabilities can can take a
long
time and yeah finally to my conclusion
um exploding is quite exhausting
exhausting so I would like to see if
renders would directly fix um memory
corruption vulnerabilities without
requiring a full remote code execution
proof uh like for example in the
broadcom case they found the buck
previously but they didn't Supply any
patches same for for Android the buck
was known but no patches were
supplied and we still have the problem
with um with patch supplies so there are
always unfixable devices it takes a long
time for for the patch to reach the
customers and we have finally released
our um our tool that we've used here
what didn't work quite AIT well in this
live demo but uh if you are interested
here's a source code it also uh
describes how we um exploited the uh the
broadcom vulnerability and the device
inquiry and also some additional
information and that was it from my side
and I would be open for
[Music]
questions
[Music]
yep C of stream reg oh let go so um
which Heap sanitizer has been used to
detect the inquiry buum and this was our
own Heap uh Heap sanitizer
implementation so they are using the
Heap implementation from
threx and we basically reverse
engineered the the Heap and it's
actually quite easy to run some uh basic
checks if the Heap is still intact and
then we set hooks on uh the most
interesting functions that will re um
will basically te test if the Heap is
still intact and will throw an error
message if there or something
[Music]
wrong
um I guess um aslr is not possible on on
the arm cortex M3 I guess they are using
and it's asrr is something that you
really can't use on embedded devices um
I guess that D so data execution
prevention could be possible but they
have to have to write the the updates
into into the run so it has to be
executable at some point and they should
lock it afterwards but I'm not sure if
they will implement it it at some point
and broadcom also now has implemented
some sort of Heap check
so and this is I guess also why they
found the buck yet uh
yet but it's not really an exploit
mitigation in respon to
this
um that
what um so I we just counted it I guess
it's run
about uh one or 200 hooks that we are
using uh there are a lot of um debugging
hooks um and the the number of functions
that are needed to be replaced are
actually not that much
um most um important are those functions
like writing to an Ur reg and this a
simple function it gets a a pointer to a
buffer and a length and it writes those
sta to you out and you can basically uh
just replace it with a with a right same
for your
read um
and yeah uh there are some functions
that do not make any sense on uh in the
in the user space for example enabling
and disabling interrupts so this are
functions that we uh disabled right
away
[Music]
and let me think and yeah there are all
those um uh like Hardware relevant
functions that will for example do a
read on a hardware register and write on
a hardware register
and if as long as I can write to a valid
memory location it's probably fine and
if you have this memory State um you
also have pretty good default values so
it turned out to work
okayish um for which one I for the
broadcom exploit it's in the Gio um so
Simo minus labf
Frankenstein uh the Android proof of
concept is not released
yet