- In this talk Alexander and me will show you internals
about Apple's new ultra wide band technology.
Apple built a new chip officially called U1
and internally called Rose.
The chip has been introduced for the iPhone 11
for spatial awareness.
And since IS 14,
some functionality of the U1 chip is exposed
through the the nearby interaction framework.
Even though it's been there for a while,
nobody really knows what ultra wide band is or does.
Ultra wide band is only available
on the latest generation of devices.
So on Apple devices,
Tech med-supported iPhones do not have the U1 chip.
However, the Air-Techs have a U1 chip,
and at $30 they are cheaper
than some ultra wide band development boards.
Another barrier for hackers is
the typical software-define radio setups do not allow it
to intercept ultra wide band signals.
So the bandwidth is way too wide
and the frequency is too high for a typical SDR setup.
So overall,
I guess ultra wide band seems to be hiccup-proof.
Apple's platform security guide
is usually very, very detailed,
but when it comes to ultra wide band security,
there is almost no documentation.
It only states that address
and frame sequences are randomized,
which is fundamental to privacy in wireless systems.
However, this does not tell anything about security features
of ultra wide band on a chip or operating system level.
Ultra wide band is so secure they even put it into vehicles.
And one application is to use it
as a second factor for keys.
Signals are limited by speed of light,
meaning that they travel a constant time
and being sent over the air or through a cable.
This means that an attacker cannot simply replay
or relay a signal from a key to shorten the distance.
Such an attack would introduce a measurable delay.
Using this property as a second factor
is also called distance bonding.
In practice, the direct line of sight path
might not be as strong
because objects are in between.
So in such a case, a non-line of sight path
from a reflection like a wall or the ground can be stronger.
However,
you still want to use your key and open your vehicle.
So Apple does not provide any non-line of sight accuracy
for their ultra wide band chip.
And XP advertises their chip with plus-minus 10 centimeters
non-line of sight accuracy.
And when correlating paths,
the signal strength of the shortest path
might be lower than the indirect reflected
non-line of sight path.
The shortest path is earlier but weaker.
And to compensate for this,
there needs to be a back search window
in that the ultra wide band chip looks for peaks.
Any peak about the noise floor
will be accepted as freeze path.
An attacker can trick this algorithm
by injecting short peaks
that slightly distort a signal in way
that makes four sort of paths appear
within the back search time window.
And as of now,
this attack has only been simulated
because there is no affordable setup
that would allow such an attack in practice.
But considering that ultra wide band's secure ranging
is now being built into the newest generation of devices,
this is still concerning.
And we have this I'm handing over to Alexander
who is now going to show you a bit more
about how ultra wide band is being used on iOS
from a user perspective
but also from a framework perspective.
- Thank you, Jiska, for the introduction.
I will now continue to present the ultra wide band features
that are currently present in iOS
and continue to dive a bit deeper
into the internals of the implementation of iOS.
The first feature that was made available
using ultra wide band is an extension to AirDrop.
This extension mainly changed the user interface
in a way that the device at which the user is pointing
is shown in a circle in the middle.
This helps users to identify the person they want
to send a file to
and could be another hint against malicious actors
trying to steal files.
With iOS 14,
Apple has opened up their ultra wide band interface
to app developers.
Developers are now able to use
the nearby interaction framework to measure the distance
and angle between two iPhones
and to play games with this.
Usage is quite limited
because we cannot access more details than this.
And actually, it requires a quite complicated setup
in which we will detail later.
Also, with the introduction of the AirTag
the Find My app gained support for ultra wide band.
This is used to discover lost devices
and it shows you the distance
and the direction in which your device is placed.
So this is an option to find devices in your place
but it's not feasible for longer distances
as the system has a maximum distance of around 10 meters.
With iOS 15,
Apple is opening up ultra wide band even more.
Now ultra wide band can be added to anything
if the manufacturer is certified by Apple,
and now you can integrate ultra wide band hardware
into your house.
For example,
to unlock it or to have certain smart home features.
You can unlock your car with ultra wide band
using the digital car key,
and also ultra wide band can now be used
for the key to your Tardis.
And now I will dive deeper into
the AirDrop and newer interaction parts of ultra wide band.
In this part,
I will the two protocols in use.
And now we start with AirDrop.
So the first ultra wide band use case
that we're going to look at is AirDrop.
When users open AirDrop,
a lot of things start happening in the background.
The devices will start sending out ultra wide band beacons
and it would also start sharing
Bluetooth low-energy advertisements
to inform user uses nearby about the just-started AirDrop.
The first Bluetooth low-energy advertisement
is the main AirDrop advertisement.
This part is largely known by previous research,
and when an iPhone tries to send something over at drop,
it will send these BLE advertisements.
Those advertisements use a non-resolvable MAC address,
so it cannot be identified even by devices
that have been paired to this iPhone.
The first part here identifies this as an AirDrop message.
Then it just states the length of the whole advertisement
and then we have zero padding here.
Then we get a version number
and this is followed up by four truncated hashes
from email addresses like the Apple ID
and from phone numbers that are also linked
to this Apple account.
Now all devices in the surrounding know
if their potential contact is trying
to send something over AirDrop
as they can compare the hashes here.
They will start with the normal AirDrop protocol
in the background.
And now this ultra wide band part of AirDrop
is clearly separated from the normal AirDrop protocol.
So for the ultra wide band part,
it's also sending a different kind
of second BLE advertisement.
And this one uses, actually, a resolvable MAC address,
and it's often this nearby action type.
This new action type is used for multiple features.
For example, the Wi-Fi password sharing and Air Play.
Then we have nearby action flags.
And then we have a special type.
In this case, it's the action type called point to share.
This is directly linked to ultra wide band
and it's sent every time the device has started AirDrop.
This informs nearby devices that this AirDrop device
has started ultra wide band beaconing
and is awaiting responses by potential other AirDrop users.
Also, only by action messages
contain an authentication tag end yet.
So on the receiver side,
to receive BLE advertisements,
parse to the sharing key.
Then the sharingd is now able to identify
that there's a nearby device
and what this device wants to do.
But also, the sharingd needs to validate
this authentication tag.
This is possible because all previously connected devices
share an identity-resolving key.
So all iOS devices are sharing these keys
and they are stored locally on device.
So for every received message,
their performance up hash algorithm
using the MAC address
and one of those identity-resolving keys.
And then they check if the authentication tag matches.
And if this is the case,
this device has been seen before.
So they know if this is actually a friend device.
According to the brutal specification
in identity-resolving keys, or IRKs,
are used to resolve the actual Bluetooth address
from the randomized address.
Apple repurposes them here
to generate those authentication tags.
Now, the iPhone can be rather sure
that the sending device is a friend's device.
Therefore, it starts forwarding this information
to the nearbyd through the rapportd.
Here, iOS uses a trick to find friendly
devices in ultra wide band.
They use the same randomized MAC address
for ultra wide band as for Bluetooth.
So the nearbyd initializes the U1 chip
and watches the ultra wide band MAC addresses.
Now the device can respond to the ultra wide band beacons
initiated by the AirDrop device
to send out its information about the distance
and angle of nearby iPhones.
This information is used to show the user,
the person they are pointing the device at.
So this is how AirDrop's implementation of
ultra wide band ranging angle of arrival works.
Now we come to the second part.
Nearby interaction framework.
As shown is the nearby interaction framework.
It is possible to range with nearby iPhones
and measure the distance and angle between your devices.
Furthermore, with iOS 15,
Apple allows ranging re-certified
third-party ultra wide band devices.
To perform the ranging with nearby iPhones using
the nearby interaction framework,
both devices need to exchange NI Discovery Tokens.
These tokens have to be exchanged
using an out-of-band channel.
This is left to the developers
to implement it in a secure manner.
The tokens are generated at random
and the device which has a greater token
will act as an initiator
and the other device as a responder.
And after the tokens have been exchanged,
the user has to be confirm the usage of ultra wide band.
Similarly to AirDrop,
both devices will start sending out BLE advertisements.
Those advertisements are different
to the ones sent in AirDrop.
So the advertisements
are solely ultra wide band advertisements
and they contain
as the other ones before,
links and flags,
but also an authentication tag
and ultra wide band conflict.
So only the initiator sending the config
and the responder device
is only sending its authentication tag.
But how are the devices now identifying each other?
Both devices have shared token.
This token is used to find the other devices using BLE.
Those BLE advertisements.
Every token contains a 16 bytes,
randomly-generated identity-resolving key again,
and similarly to AirDrop,
these keys used to generate the authentication tag
from the device's user's MAC address.
They reused the same Bluetooth MAC address
for a ultra wide band again
and this allows them to discover the correct device
when perform ranging.
After the devices have discovered their peer
over Bluetooth low energy,
they can now perform ranging over
ultra wide band and continue.
To secure this ranging,
they use the so-called scramble timestamp sequences.
Scramble timestamp sequences
are used to generate multiple timestamps
from receiving a message.
Those timestamps can then be used
to detect potential attacks on a protocol
and additionally, both devices can authenticate each other
as they share the same STS values.
So to get an extra distance at both sides,
they should perform double-sided ranging.
With this, the initiator sends the first message
and then the responder replies to it,
the responder replies with the time when he replied
and the initiator has the time when this reply
has been received.
And therefore, the initiator can calculate
the time of flight by using the timestamp
when the message has arrived
and the time when the device replied.
And also, they can deduct the processing times needed.
The same procedure is handled on the other side
and both devices have distances and angle
of arrival measurements in the end.
So since the beginning of our research
we wanted to receive actual frames from iOS.
Until now,
the whole system is really closed down.
We do not get any packet logs from iOS
and we only get high-level reports
of their measurements
to nearby demon.
So to receive ultra wide band signals
we first need to know what our hardware
should be capable of.
In the system logs on a jailbroken device
we can unveil a few things.
So from the nearby interaction packet
we see the preambles that I used
and the channels that are supported
and that they are using a hot pattern mask here.
And also, we can see the usage
of the scrambled timestamp sequences.
Many of those integers presented here are just an index in
the list of the supported configurations.
So when we check out those configurations,
we see that ultra wide band here is using 64 megahertz
post-repetition frequency
and iOS ultra wide band users post and transmit data,
it can operate in different frequences.
And if they use the STS radios,
they need to use 64 megahertz,
according to the standard.
So for 64 megahertz we have four preamble codes
and the NDCs is our resulting two, three,
so which is here,
the preamble code number 12.
The channels are also using NDCs,
so the one chip supports channel five and nine,
and here we see that the start channel is channel nine
and channel five is the alternative channel.
So next we need the right hardware.
And we know that the development kits we wanted,
so we were looking for development kits
that support the most recent standard.
And we found the one from Quavo
which also uses the same channels as the U1 chip.
Then Apple actually announced
that they are supporting third-party devices,
and they are also saying
that the Quavo device we actually bought
is one of the third-party development kits
they are supporting,
so we bought the right hardware here.
But to receive frames,
we also need to have the right configuration.
So this needs a set of parameters
and most of them need to match,
otherwise the reception errors would occur
and the frames would not be readable.
Some parameters are clear from the logs,
like the channel and preamble code.
Ours are not known
and they are likely hot-coded and chipped,
so they are basically the same for all transmissions.
So those which are not known here are the STS format
and the STS length.
So why is this important?
Let's take a look at the ultra wide band frame format.
Here we see all frames start with a preamble.
The preamble contains the specific preamble code
and it can be repeated,
so this is why the preamble can have variable lengths.
But with the wrong preamble code
we would never receive any frame.
So the preamble would just not be detected.
Then the preamble is followed
by the start of frame delimiter or SFD.
This start of frame delimiter is used to identify
when the preamble ends,
so it's not really important if you know how long it is.
You just need to check for the SFD.
Then the STS values start.
The STS is used for the secure ranging
and it can also have a better variable length,
so it's quite difficult to identify when STS ends
and when the flight header would start
because it's not followed by something like an SFD.
So we need to know what the actual length is,
otherwise we would not receive any frames.
Then to make this even more complicated,
there is a second mode for the STS
so it can even be after the flight header,
and also here it can have variable lengths.
And then there's a third mode
where the STS is after the SFD again
but no data is shared.
So in this demo I want to show you
how we have started sniffing against an actual
iOS device with a U1 chip,
and for this we start this demo app from Apple
which is using the nearby interaction framework.
And then the two devices start discovering each other
and the user needs to confirm that ultra wide band use
and then they start ranging.
We can see that they are ranging a distance here
and we get a lot of logs on the left side
from the iPhone and basically for every distance
that is measured
we get this one huge log with the angle of arrival
and the distance that's actually measured.
On the right side we have seen the frames
that are received by (speaking softly),
so our sniffer has been attached to (speaking softly)
and we were able to receive some frames here.
But even though it does look very nice on the first slide,
from a closer look we see that it has the couple of issues.
So there are malformed packets everywhere
received in (speaking softly),
and even those packets that look like they're not malformed
have parts of those packet which are malformed
or incorrect and also the data,
which is part of the packets,
looks very scrambled.
So of course,
the scrambled data could be encrypted
but those issues are most likely caused
by a misaligned STS value.
So we tried every combination of length and mode
but no one matched the Apple transmission modes,
so Apple could have employed some custom STS length
which is not supported by our device,
or they could have additional data after the STS
which is not part of the official standardized frame format.
So they could have used a custom frame format, for example,
and I hope we will get more insights on this
when the better software from Quavo gets available
so we can actually
range with iPhones as supported with iOS 15 beta.
So now we covered the two modes of interaction,
AirDrop and nearby interaction
and AirDrop's ultra wide band communication
has been the first that was iOS.
In AirDrop, one device sends ranging beacons
and multiple devices can respond to it.
Only the initiator or AirDrop sender
is able to get the distance information.
For nearby interaction,
the ranging is performed in a peer-to-peer manner.
Every device ranges with another.
And both receive the distance information
as they are performing double-sided ranging.
The devices participating in AirDrop
do not exchange any secrets
and do not secure the actual ranging.
While the nearby interaction and initial
off-band key exchange is necessary.
Even though AirDrop ranging is not secured
by an STS value,
it should not be particularly dangerous to use AirDrop.
The ultra wide band part,
they're just changes to order of how nearby people
are shown in the user interface.
And now I will hand over to Jiska again.
Thank you.
- The nearby demon is the one to start the distance
and angle measurement.
No matter if this has been initiated by AirDrop
or the nearby interactions framework.
For this,
it's using the RoseControllerLib
which then cause functions in our IO kit
to communicate with the U1 chip.
And the chip initialization for the measurement
is only done once,
then later on, in return,
measurement tickets are sent multiple times
containing the measurement data.
The ticket data is not sent directly to other daemons.
Instead, the nearby daemon combines data
with the so-called Rose neural engine sensor fusion
and only forwards combined plausible measurements
to other daemons.
This still looks a bit like magic
and so in the following I will explain how iOS interacts
with the underlying hardware.
The U1 chip actually consists of two main chips.
Both of them are iron.
The application process will implement most functionality
and it's only 32-bit,
and then the signal processor runs on
64-bit iron with ASLI.
It does this more time-critical tasks
as well as the initial packet parsing.
So for example,
the application processor generates the next STS
and forwards it to the digital signal processor,
which needs it for the actual distance
measurement and verification.
The U1 chip has three receive antennas.
This is required to get angular information
and not only distance information.
The three antennas are only required in the sensing,
AKA receiving, direction,
so angles can still be displayed on iPhone
which communicates with an AirTag U1 chip
even though the AirTag only has one receive antenna.
All communication is routed through the always-on processor.
It keeps some basic state of the U1 chip
and only makes up the iOS kernel when needed.
The iOS kernel, in turn,
can set the ultra wide band communications route
to either the applications processor
or the always-on processor.
While the U1 chip in the iPhone's HomePod mini
and watch is very similar,
the U1 chip in the AirTag is a bit different.
It is the only U1 chip that is not powered
by an iOS rewritive
and an always-on processor.
Because of this,
the AirTag U1 application processor
has a few additional features.
More over, since it does not have a display,
it cannot show angular information
and so has one receiver antennae only.
More details about the AirTags
and how to glitch the NRF chip
that can then run custom firmware on them
will be part of Thomas' talk, "Hacking the Apple AirTags."
All the chips I have shown previously run RTKitOS,
which is a real-time operating system.
Even if you have never heard of it,
it runs on almost every embedded device by Apple.
There are some exceptions.
So for example, the NRF chip on the AirTags
does not run RTKitOS.
RTKitOS is very light-weight
and maybe around 100 functions or a bit more.
It is so small that even logging is implemented differently
in every RTKitOS firmware.
Note that there are RTKitOS debug builds
with additional features.
So for the U1 chip there exists debug builds in the wild,
and for example,
the iOS 13.3 on the iPhone 11
as well as the initial AirTag firmware
both are U1 chip debug builds.
You can find RTKitOS in almost every embedded Apple device.
The AirPods two and pro,
the pencil, the Siri and remote second generation,
the magic keyboard variant for the iPens,
the always-on processor and more.
A few more details about RTKitOS
with a focus on AirPods and Apple's own Bluetooth chip
are documented in the next teasers.
The iOS kernel has two drivers for the U1 chip,
the AppleSPURoseDriverUserClient
and the AppleSPUUserClient.
These drivers can be accessed
from user space by IOKit
and IOKit is a driver framework
that takes care of exposing selected methods
from the kernel to user space.
IOKit also validates the parameters that are passed
to through these methods.
The always-on processor has equivalence
to these two drivers,
which are called Rose,
and Rose and Rose-Supervisor.
So when the kernel goes to sleep
and the always-on processor takes over,
they are responsible.
This principle is not unique to ultra wide band,
so you can also find it
for various other chips and features,
such as Siri.
Even Apple's own Bluetooth chip,
which is available in audioOS for your HomePod mini,
is managed by the always-on processor.
In the opposite direction,
our ticket-based chips communicate with an RTBuddy
in the kernel.
This is mainly used for logging.
Note that the RTBuddy is not directly exposed to IOKit.
You can use the IRA command to check the driver hierarchy.
This is very interesting since it does not only show
the IOKit user-client
but also the corresponding interface name
in the always-on processor
and the RTBuddy dependency.
This is very useful to see which chips on an Apple device
actually run RTKitOS.
The nearby daemon can directly send robot commands
to the U1 chip.
It still needs to use the IOKit framework.
To do this,
it caused the function IOConnectCallMethod,
and by setting the proper MAC port,
it selects the AppleSPURoseDriver user-client.
The second argument is five,
which means that the function X Rose takes
is called in the kernel.
Note that there are a lot, a lot, a lot of other functions
in this framework.
So for example,
the properties are being used during
the Rose (speaking softly) to get its unique identifier.
And sending a raw command to the kernel,
it stills passes a few reverse
before eventually being forwarded
to the always-on processor.
In this specific example,
the always-on processor does not handle anything
but forwards the command to the U1 chip.
The application processor in the U1 chip
then finally parses the command.
However, in some situations,
the always-on processor also needs to keep a state
about what is happening in the U1 chip.
In this case,
another driver is called the AppleSPUUserClient.
In this example,
a property is set that affects the always-on processor
state as well as the U1 application processor state.
The AppleSPUUserClient exports fear methods
and they are primarily meant
to get and set such properties
that also affect the always-on processor.
In this example,
the MAC address of the U1 chip is set.
Note that this is simply two serial bytes
concatenated with the Bluetooth address.
So we have the same MAC address for immunization
as for Bluetooth.
The 211 in this example is the MAC address
but there are also various other settings available
for this framework.
Note that you should not switch
the ultra wide band communications route
out of context,
since communication with the U1 chip will no longer work
until we start in the nearby daemon.
The always-on processor also applies these properties
and then also calls a handler
in the U1 application processor
to get these properties set.
You might have noticed that both
the AppleSPURoseDriverUserClient and the AppleSPUUserClient
have a perform command method.
However, in this case of the AppleSPUUserClient,
these commands are not raw.
There are only a few predefined commands.
In our case,
this exclamation mark just means new service request,
and most of these commands also have a few parameters.
The always-on processor then has a handle for these commands
and it will place the settings
and, if needed,
also execute the command in the U1 application processor.
The easiest option to start interaction with the U1 chip
is using AirDrop.
However, as you can see,
as long as the other device is not in the contact list,
spatial information is not displayed in the user interface.
Note that, nonetheless,
some U1 interaction is triggered
but this is not that helpful for debugging.
Instead, you can download
the Peekaboo example application from Apple.
This is much more helpful
and shows distance as well as angle information.
In contrast to AirDrop,
it exchanges a peer token
that is then also used for STS in the U1 chip.
What you can see here is the output of the nearby daemon
while the Peekaboo app is running.
So what you can see here is
that we get regular measurements from the Rose chip
and everything is also sent to this sensor fusion
to get a solution of the actual values.
While the chip is idle,
the host sends a regular AP check-in.
Once we start the Peekaboo app,
it will take a moment
and then the iPhones discover each other,
and what you can see next is the ServiceRequest
and the RangingStart.
However, the measurements are not sent via IOKit
and this is why we do not see them.
If you want to see more IOKit output,
you can change my script and reconfigure it
to debug IOKit.
And with this you will see way more information.
So this was the chip initialization
and now we are starting the Peekaboo app.
And as you can see here,
I will just quit this now.
We got the ServiceRequest
with a lot of information.
On the left-hand side you can see the most relevant
log out-put from the nearby daemon
when using the nearby interactions framework.
A new ServiceRequest is scheduled,
and for this a general ranging packet is built
that defines all transmission parameters.
On the right-hand side you can see the output
of my Frida script.
You can see the new ServiceRequest in detail.
Note that the STS block output format in the original log
is not very helpful.
Apparently, some developer decided to print each byte
in variable length decimal without specifying a separator.
When looking at the syntax hexadecimal,
it becomes clear that the STS is composed of contents
of the nearby interaction peer tokens.
To understand a bit more about the firmware,
we need to understand the format
and load it into a disassembler.
The U1 chip firmware is contained in every IPSW, OTA image,
or peripheral image.
You can simply extract it from the folder /firmware/Rose.
The ftab format is rather simple and well-known,
so there are existing scripts to extract its contents.
As of now,
I have encountered five different hardware variants,
the iPhone 11 versus 12, the Apple Watch 6,
the Homepod mini and the AirTag.
The ftab that you can download from Apple servers
contains an application processor
and digital signal processor image.
Both of them can be statically analyzed
with any reversal rearing tool of your choice.
However, the ftab files stored on an iPhone
after an update differs from the initial ftab file.
It gets appended by a so-called IP ticket.
This is a signature by Apple from the combination
of this firmware and U1 chip.
Each U1 chip has a unique ECID,
so you cannot simply boot a different firmware.
I have not tried if it is possible time-crate
the firmware of the U1 chip yet,
but if it is possible,
then only if you have copied the according ftab file
from a jailbroken iPhone
that is always signed by Apple.
Next I'm going to override the firmware that I have,
moving all the firmware from a different iPhone
with a different iOS version,
but also with a different ECID.
So first of all,
to get the chip into a clean state
I'm resetting it
and now I'm going to inject my firmware by pressing enter.
And now you should see that the chip is no longer starting.
And this is the case multiple times in a row
until I am stopping my script.
So I will now stop my script here
and you can now see that the chip is booting again.
So let's take a close look into this.
So actually, we got some arrows here.
And as you can see,
we see that the Rose boot failed and we did not successfully
boot the secure ROM.
You can also see
that we got some crash logs over here.
A successful chip boot looks quite differently.
So you can see here that we are booting the chip
and it has started including some parameters like this ECID.
So this is not written, this is just read,
so you cannot write this property.
I tried this.
But this is all included in the boot process
and also in the signature that is very fined.
The first thing I mannered
before understanding all the U1 chip internals
was obtaining logs from the chip.
I simply did some static reverse engineering
of nearby daemon,
wondering how I could interact with the firmware.
I found a handler that always allows
to trigger some FatalErrorHandling.
The same handler also contains another command
to switch off the chip.
This can be triggered through the iOS user interface
by enabling flight mode.
So I simply switched the implementation
of switching off the chip and triggering a fatal error.
As a result,
I got full crash logs,
and since this was an iOS 13.3
with a U1 RTKitOS debug build,
I also got packet logs.
Note that in addition to triggering a fatal error,
it is also required to set a few more variables
that make the nearby daemon believe it would be
an internal build.
Once I understood a bit more about the drive structure,
I found a better way to call such functions.
The RoseControllerLib provides lot of abstract
(speaking softly) to you for the mailer daemon.
Since it is a shared library,
it even exports symbols,
and the libRoseBooter,
which is used during the chip start-up,
also uses the RoseControllerLib
and also exports some of those.
It is possible to directly call
\the function trigger crash log in the RoseControllerLib.
And the second argument is the crash type as an integer.
All right, let's actually trigger a crash log.
So for this, let's first of all,
watch that we are getting a new crash log.
So just check this on the right-hand side.
And since we are running in Frida,
we can also just directly enter a command in this interface.
So here I'm triggering the crash log
and now you can already see the firmware is rebooting.
And on the right-hand side,
we even got a new crash log.
So let's check this out.
So the first thing you will notice is that the firmware
logs with the packets are zero bytes
because this is not a debug build,
and depending on the actual crash,
we only get an AP log or also the SP log.
And we can see the crash reason in the summaries,
so this is human readable.
So as you can see here,
this was a coredump trigger that we caused on our own.
And actually, it thinks that the firmware logs are enabled,
so I changed everything correctly with an iOS
but the chip just does not support this feature.
With this, I'm concluding the talk about Apple's new
ultra wide band chip.
First of all, Bluetooth and ultra wide band
are dependent on each other.
They use the same MAC address
and, as of now,
ultra wide band only works after initializing via Bluetooth.
Apple's own RTKit-based wireless chips
are super, super interesting,
and also have a lot of security features.
The always-on processor routing is great for saving energy.
And even though we cannot modify the U1 firmware as of now,
many features in the chip can be instrumented
from user space on a jailbroken device.
Some scripts that enable you to interact
with the U1 chip
will be available on GitHub on our group's page.
Note that Defcon will not have a Q and A session this year,
so if you have further questions,
you can drop us a direct message or write an email.
Thanks for watching.