DEF CON 29 -Jiska, Alexander Heinrich - Wibbly Wobbly, Timey Wimey Whats Inside Apples U1 chip

00:08 - Apple built a new chip officially called U1 and internally called Rose.

00:12 - The chip has been introduced for the iPhone 11 for spatial awareness.

00:16 - And since IS 14, some functionality of the U1 chip is exposed through the the nearby interaction framework.

00:23 - Even though it’s been there for a while, nobody really knows what ultra wide band is or does.

00:30 - Ultra wide band is only available on the latest generation of devices.

00:34 - So on Apple devices, Tech med-supported iPhones do not have the U1 chip.

00:39 - However, the Air-Techs have a U1 chip, and at $30 they are cheaper than some ultra wide band development boards.

00:48 - Another barrier for hackers is the typical software-define radio setups do not allow it to intercept ultra wide band signals.

00:54 - So the bandwidth is way too wide and the frequency is too high for a typical SDR setup.

01:00 - So overall, I guess ultra wide band seems to be hiccup-proof.

01:08 - Apple’s platform security guide is usually very, very detailed, but when it comes to ultra wide band security, there is almost no documentation.

01:16 - It only states that address and frame sequences are randomized, which is fundamental to privacy in wireless systems.

01:23 - However, this does not tell anything about security features of ultra wide band on a chip or operating system level.

01:32 - Ultra wide band is so secure they even put it into vehicles.

01:35 - And one application is to use it as a second factor for keys.

01:39 - Signals are limited by speed of light, meaning that they travel a constant time and being sent over the air or through a cable.

01:46 - This means that an attacker cannot simply replay or relay a signal from a key to shorten the distance.

01:53 - Such an attack would introduce a measurable delay.

01:56 - Using this property as a second factor is also called distance bonding.

02:03 - In practice, the direct line of sight path might not be as strong because objects are in between.

02:10 - So in such a case, a non-line of sight path from a reflection like a wall or the ground can be stronger.

02:17 - However, you still want to use your key and open your vehicle.

02:24 - So Apple does not provide any non-line of sight accuracy for their ultra wide band chip.

02:29 - And XP advertises their chip with plus-minus 10 centimeters non-line of sight accuracy.

02:34 - And when correlating paths, the signal strength of the shortest path might be lower than the indirect reflected non-line of sight path.

02:42 - 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.

02:52 - Any peak about the noise floor will be accepted as freeze path.

02:57 - 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.

03:08 - And as of now, this attack has only been simulated because there is no affordable setup that would allow such an attack in practice.

03:16 - But considering that ultra wide band’s secure ranging is now being built into the newest generation of devices, this is still concerning.

03:24 - 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.

03:41 - - 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.

03:56 - The first feature that was made available using ultra wide band is an extension to AirDrop.

04:01 - 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.

04:09 - 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.

04:18 - With iOS 14, Apple has opened up their ultra wide band interface to app developers.

04:24 - 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.

04:33 - Usage is quite limited because we cannot access more details than this.

04:40 - And actually, it requires a quite complicated setup in which we will detail later.

04:47 - Also, with the introduction of the AirTag the Find My app gained support for ultra wide band.

04:53 - This is used to discover lost devices and it shows you the distance and the direction in which your device is placed.

05:02 - 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.

05:15 - With iOS 15, Apple is opening up ultra wide band even more.

05:20 - 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.

05:31 - For example, to unlock it or to have certain smart home features.

05:36 - 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.

05:50 - And now I will dive deeper into the AirDrop and newer interaction parts of ultra wide band.

05:55 - In this part, I will the two protocols in use.

05:59 - And now we start with AirDrop. So the first ultra wide band use case that we’re going to look at is AirDrop.

06:09 - When users open AirDrop, a lot of things start happening in the background.

06:13 - 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.

06:28 - The first Bluetooth low-energy advertisement is the main AirDrop advertisement.

06:33 - 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.

06:41 - Those advertisements use a non-resolvable MAC address, so it cannot be identified even by devices that have been paired to this iPhone.

06:50 - The first part here identifies this as an AirDrop message.

06:54 - Then it just states the length of the whole advertisement and then we have zero padding here.

07:01 - 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.

07:13 - 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.

07:20 - They will start with the normal AirDrop protocol in the background.

07:24 - And now this ultra wide band part of AirDrop is clearly separated from the normal AirDrop protocol.

07:31 - So for the ultra wide band part, it’s also sending a different kind of second BLE advertisement.

07:38 - And this one uses, actually, a resolvable MAC address, and it’s often this nearby action type.

07:46 - This new action type is used for multiple features.

07:48 - For example, the Wi-Fi password sharing and Air Play.

07:52 - Then we have nearby action flags. And then we have a special type.

07:58 - In this case, it’s the action type called point to share.

08:02 - This is directly linked to ultra wide band and it’s sent every time the device has started AirDrop.

08:08 - This informs nearby devices that this AirDrop device has started ultra wide band beaconing and is awaiting responses by potential other AirDrop users.

08:20 - Also, only by action messages contain an authentication tag end yet.

08:27 - So on the receiver side, to receive BLE advertisements, parse to the sharing key.

08:34 - Then the sharingd is now able to identify that there’s a nearby device and what this device wants to do.

08:43 - But also, the sharingd needs to validate this authentication tag.

08:48 - This is possible because all previously connected devices share an identity-resolving key.

08:55 - So all iOS devices are sharing these keys and they are stored locally on device.

09:01 - So for every received message, their performance up hash algorithm using the MAC address and one of those identity-resolving keys.

09:08 - And then they check if the authentication tag matches.

09:11 - And if this is the case, this device has been seen before.

09:16 - So they know if this is actually a friend device.

09:20 - According to the brutal specification in identity-resolving keys, or IRKs, are used to resolve the actual Bluetooth address from the randomized address.

09:29 - Apple repurposes them here to generate those authentication tags.

09:40 - Now, the iPhone can be rather sure that the sending device is a friend’s device.

09:44 - Therefore, it starts forwarding this information to the nearbyd through the rapportd.

09:49 - Here, iOS uses a trick to find friendly devices in ultra wide band.

09:54 - They use the same randomized MAC address for ultra wide band as for Bluetooth.

09:59 - So the nearbyd initializes the U1 chip and watches the ultra wide band MAC addresses.

10:08 - 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.

10:20 - This information is used to show the user, the person they are pointing the device at.

10:26 - So this is how AirDrop’s implementation of ultra wide band ranging angle of arrival works.

10:33 - Now we come to the second part. Nearby interaction framework.

10:37 - As shown is the nearby interaction framework.

10:39 - It is possible to range with nearby iPhones and measure the distance and angle between your devices.

10:46 - Furthermore, with iOS 15, Apple allows ranging re-certified third-party ultra wide band devices.

10:52 - To perform the ranging with nearby iPhones using the nearby interaction framework, both devices need to exchange NI Discovery Tokens.

11:01 - These tokens have to be exchanged using an out-of-band channel.

11:05 - This is left to the developers to implement it in a secure manner.

11:09 - 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.

11:19 - And after the tokens have been exchanged, the user has to be confirm the usage of ultra wide band.

11:27 - Similarly to AirDrop, both devices will start sending out BLE advertisements.

11:33 - Those advertisements are different to the ones sent in AirDrop.

11:37 - 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.

11:52 - So only the initiator sending the config and the responder device is only sending its authentication tag.

12:02 - But how are the devices now identifying each other? Both devices have shared token.

12:07 - This token is used to find the other devices using BLE.

12:11 - 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.

12:25 - 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.

12:34 - After the devices have discovered their peer over Bluetooth low energy, they can now perform ranging over ultra wide band and continue.

12:45 - To secure this ranging, they use the so-called scramble timestamp sequences.

12:52 - Scramble timestamp sequences are used to generate multiple timestamps from receiving a message.

12:58 - 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.

13:12 - So to get an extra distance at both sides, they should perform double-sided ranging.

13:19 - 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.

13:33 - 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.

13:42 - And also, they can deduct the processing times needed.

13:46 - The same procedure is handled on the other side and both devices have distances and angle of arrival measurements in the end.

13:58 - So since the beginning of our research we wanted to receive actual frames from iOS.

14:02 - Until now, the whole system is really closed down.

14:05 - We do not get any packet logs from iOS and we only get high-level reports of their measurements to nearby demon.

14:13 - So to receive ultra wide band signals we first need to know what our hardware should be capable of.

14:20 - In the system logs on a jailbroken device we can unveil a few things.

14:24 - 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.

14:36 - And also, we can see the usage of the scrambled timestamp sequences.

14:41 - Many of those integers presented here are just an index in the list of the supported configurations.

14:47 - 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.

15:04 - And if they use the STS radios, they need to use 64 megahertz, according to the standard.

15:10 - 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.

15:21 - 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.

15:36 - 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.

15:48 - And we found the one from Quavo which also uses the same channels as the U1 chip.

15:55 - 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.

16:10 - But to receive frames, we also need to have the right configuration.

16:13 - 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.

16:23 - Some parameters are clear from the logs, like the channel and preamble code.

16:26 - Ours are not known and they are likely hot-coded and chipped, so they are basically the same for all transmissions.

16:33 - So those which are not known here are the STS format and the STS length.

16:39 - So why is this important? Let’s take a look at the ultra wide band frame format.

16:44 - Here we see all frames start with a preamble.

16:47 - The preamble contains the specific preamble code and it can be repeated, so this is why the preamble can have variable lengths.

16:54 - But with the wrong preamble code we would never receive any frame.

16:59 - So the preamble would just not be detected.

17:03 - Then the preamble is followed by the start of frame delimiter or SFD.

17:09 - 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.

17:20 - You just need to check for the SFD. Then the STS values start.

17:26 - 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.

17:49 - So we need to know what the actual length is, otherwise we would not receive any frames.

17:55 - 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.

18:05 - And then there’s a third mode where the STS is after the SFD again but no data is shared.

18:15 - 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.

18:35 - 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.

18:42 - 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.

18:58 - 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.

19:12 - 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.

19:20 - 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.

19:39 - So of course, the scrambled data could be encrypted but those issues are most likely caused by a misaligned STS value.

19:47 - 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.

20:07 - 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.

20:25 - 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.

20:35 - In AirDrop, one device sends ranging beacons and multiple devices can respond to it.

20:41 - Only the initiator or AirDrop sender is able to get the distance information.

20:46 - For nearby interaction, the ranging is performed in a peer-to-peer manner.

20:50 - Every device ranges with another. And both receive the distance information as they are performing double-sided ranging.

20:59 - The devices participating in AirDrop do not exchange any secrets and do not secure the actual ranging.

21:05 - While the nearby interaction and initial off-band key exchange is necessary.

21:09 - Even though AirDrop ranging is not secured by an STS value, it should not be particularly dangerous to use AirDrop.

21:16 - The ultra wide band part, they’re just changes to order of how nearby people are shown in the user interface.

21:25 - And now I will hand over to Jiska again. Thank you.

21:32 - - The nearby demon is the one to start the distance and angle measurement.

21:36 - No matter if this has been initiated by AirDrop or the nearby interactions framework.

21:41 - For this, it’s using the RoseControllerLib which then cause functions in our IO kit to communicate with the U1 chip.

21:47 - 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.

21:58 - The ticket data is not sent directly to other daemons.

22:01 - Instead, the nearby daemon combines data with the so-called Rose neural engine sensor fusion and only forwards combined plausible measurements to other daemons.

22:13 - This still looks a bit like magic and so in the following I will explain how iOS interacts with the underlying hardware.

22:23 - The U1 chip actually consists of two main chips.

22:26 - 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.

22:37 - It does this more time-critical tasks as well as the initial packet parsing.

22:43 - 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.

22:55 - The U1 chip has three receive antennas. This is required to get angular information and not only distance information.

23:02 - 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.

23:18 - All communication is routed through the always-on processor.

23:21 - It keeps some basic state of the U1 chip and only makes up the iOS kernel when needed.

23:29 - The iOS kernel, in turn, can set the ultra wide band communications route to either the applications processor or the always-on processor.

23:39 - 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.

23:46 - It is the only U1 chip that is not powered by an iOS rewritive and an always-on processor.

23:51 - Because of this, the AirTag U1 application processor has a few additional features.

23:56 - More over, since it does not have a display, it cannot show angular information and so has one receiver antennae only.

24:04 - 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.

24:21 - Even if you have never heard of it, it runs on almost every embedded device by Apple.

24:26 - There are some exceptions. So for example, the NRF chip on the AirTags does not run RTKitOS.

24:33 - RTKitOS is very light-weight and maybe around 100 functions or a bit more.

24:38 - It is so small that even logging is implemented differently in every RTKitOS firmware.

24:44 - Note that there are RTKitOS debug builds with additional features.

24:48 - 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.

25:03 - You can find RTKitOS in almost every embedded Apple device.

25:07 - 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.

25:17 - A few more details about RTKitOS with a focus on AirPods and Apple’s own Bluetooth chip are documented in the next teasers.

25:26 - The iOS kernel has two drivers for the U1 chip, the AppleSPURoseDriverUserClient and the AppleSPUUserClient.

25:35 - 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.

25:45 - IOKit also validates the parameters that are passed to through these methods.

25:52 - The always-on processor has equivalence to these two drivers, which are called Rose, and Rose and Rose-Supervisor.

25:58 - So when the kernel goes to sleep and the always-on processor takes over, they are responsible.

26:04 - This principle is not unique to ultra wide band, so you can also find it for various other chips and features, such as Siri.

26:11 - Even Apple’s own Bluetooth chip, which is available in audioOS for your HomePod mini, is managed by the always-on processor.

26:18 - In the opposite direction, our ticket-based chips communicate with an RTBuddy in the kernel.

26:23 - This is mainly used for logging. Note that the RTBuddy is not directly exposed to IOKit.

26:34 - You can use the IRA command to check the driver hierarchy.

26:37 - 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.

26:49 - This is very useful to see which chips on an Apple device actually run RTKitOS.

26:57 - The nearby daemon can directly send robot commands to the U1 chip.

27:01 - 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.

27:13 - The second argument is five, which means that the function X Rose takes is called in the kernel.

27:20 - Note that there are a lot, a lot, a lot of other functions in this framework.

27:24 - So for example, the properties are being used during the Rose (speaking softly) to get its unique identifier.

27:32 - And sending a raw command to the kernel, it stills passes a few reverse before eventually being forwarded to the always-on processor.

27:41 - In this specific example, the always-on processor does not handle anything but forwards the command to the U1 chip.

27:48 - The application processor in the U1 chip then finally parses the command.

27:54 - However, in some situations, the always-on processor also needs to keep a state about what is happening in the U1 chip.

28:00 - In this case, another driver is called the AppleSPUUserClient.

28:05 - In this example, a property is set that affects the always-on processor state as well as the U1 application processor state.

28:13 - The AppleSPUUserClient exports fear methods and they are primarily meant to get and set such properties that also affect the always-on processor.

28:23 - In this example, the MAC address of the U1 chip is set.

28:28 - Note that this is simply two serial bytes concatenated with the Bluetooth address.

28:33 - So we have the same MAC address for immunization as for Bluetooth.

28:38 - The 211 in this example is the MAC address but there are also various other settings available for this framework.

28:45 - 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.

28:57 - The always-on processor also applies these properties and then also calls a handler in the U1 application processor to get these properties set.

29:07 - You might have noticed that both the AppleSPURoseDriverUserClient and the AppleSPUUserClient have a perform command method.

29:16 - However, in this case of the AppleSPUUserClient, these commands are not raw.

29:22 - 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.

29:33 - 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.

29:44 - The easiest option to start interaction with the U1 chip is using AirDrop.

29:47 - 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.

29:55 - Note that, nonetheless, some U1 interaction is triggered but this is not that helpful for debugging.

30:01 - Instead, you can download the Peekaboo example application from Apple.

30:06 - This is much more helpful and shows distance as well as angle information.

30:11 - In contrast to AirDrop, it exchanges a peer token that is then also used for STS in the U1 chip.

30:19 - What you can see here is the output of the nearby daemon while the Peekaboo app is running.

30:25 - 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.

30:40 - While the chip is idle, the host sends a regular AP check-in.

30:47 - 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.

31:02 - However, the measurements are not sent via IOKit and this is why we do not see them.

31:11 - If you want to see more IOKit output, you can change my script and reconfigure it to debug IOKit.

31:21 - And with this you will see way more information.

31:30 - So this was the chip initialization and now we are starting the Peekaboo app.

31:46 - And as you can see here, I will just quit this now.

31:52 - We got the ServiceRequest with a lot of information.

32:00 - On the left-hand side you can see the most relevant log out-put from the nearby daemon when using the nearby interactions framework.

32:07 - A new ServiceRequest is scheduled, and for this a general ranging packet is built that defines all transmission parameters.

32:15 - On the right-hand side you can see the output of my Frida script.

32:19 - You can see the new ServiceRequest in detail.

32:22 - Note that the STS block output format in the original log is not very helpful.

32:27 - Apparently, some developer decided to print each byte in variable length decimal without specifying a separator.

32:35 - When looking at the syntax hexadecimal, it becomes clear that the STS is composed of contents of the nearby interaction peer tokens.

32:46 - To understand a bit more about the firmware, we need to understand the format and load it into a disassembler.

32:54 - The U1 chip firmware is contained in every IPSW, OTA image, or peripheral image.

33:00 - You can simply extract it from the folder /firmware/Rose.

33:04 - The ftab format is rather simple and well-known, so there are existing scripts to extract its contents.

33:11 - 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.

33:23 - The ftab that you can download from Apple servers contains an application processor and digital signal processor image.

33:30 - Both of them can be statically analyzed with any reversal rearing tool of your choice.

33:36 - However, the ftab files stored on an iPhone after an update differs from the initial ftab file.

33:42 - It gets appended by a so-called IP ticket. This is a signature by Apple from the combination of this firmware and U1 chip.

33:52 - Each U1 chip has a unique ECID, so you cannot simply boot a different firmware.

33:58 - 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.

34:12 - 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.

34:23 - 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.

34:34 - And now you should see that the chip is no longer starting.

34:38 - And this is the case multiple times in a row until I am stopping my script.

34:44 - So I will now stop my script here and you can now see that the chip is booting again.

34:50 - So let’s take a close look into this. So actually, we got some arrows here.

35:04 - And as you can see, we see that the Rose boot failed and we did not successfully boot the secure ROM.

35:13 - You can also see that we got some crash logs over here.

35:19 - A successful chip boot looks quite differently.

35:22 - So you can see here that we are booting the chip and it has started including some parameters like this ECID.

35:31 - So this is not written, this is just read, so you cannot write this property.

35:35 - I tried this. But this is all included in the boot process and also in the signature that is very fined.

35:47 - The first thing I mannered before understanding all the U1 chip internals was obtaining logs from the chip.

35:55 - I simply did some static reverse engineering of nearby daemon, wondering how I could interact with the firmware.

36:01 - I found a handler that always allows to trigger some FatalErrorHandling.

36:09 - The same handler also contains another command to switch off the chip.

36:13 - This can be triggered through the iOS user interface by enabling flight mode.

36:17 - So I simply switched the implementation of switching off the chip and triggering a fatal error.

36:23 - 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.

36:33 - 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.

36:45 - Once I understood a bit more about the drive structure, I found a better way to call such functions.

36:51 - The RoseControllerLib provides lot of abstract (speaking softly) to you for the mailer daemon.

36:57 - 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.

37:09 - It is possible to directly call \the function trigger crash log in the RoseControllerLib.

37:14 - And the second argument is the crash type as an integer.

37:21 - All right, let’s actually trigger a crash log.

37:23 - So for this, let’s first of all, watch that we are getting a new crash log.

37:29 - 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.

37:41 - So here I’m triggering the crash log and now you can already see the firmware is rebooting.

37:47 - And on the right-hand side, we even got a new crash log.

37:52 - 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.

38:15 - And we can see the crash reason in the summaries, so this is human readable.

38:22 - So as you can see here, this was a coredump trigger that we caused on our own.

38:28 - 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.

38:43 - With this, I’m concluding the talk about Apple’s new ultra wide band chip.

38:48 - First of all, Bluetooth and ultra wide band are dependent on each other.

38:52 - They use the same MAC address and, as of now, ultra wide band only works after initializing via Bluetooth.

39:00 - Apple’s own RTKit-based wireless chips are super, super interesting, and also have a lot of security features.

39:06 - The always-on processor routing is great for saving energy.

39:11 - 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.

39:20 - Some scripts that enable you to interact with the U1 chip will be available on GitHub on our group’s page.

39:25 - 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.

39:33 - Thanks for watching. .