Transcription

Hey, welcome to my talk, Hacking the Apple AirTags. My name is Thomas Roth. I'm a security researcher from Germany, and I also run a YouTube channel called Stack Smashing, where I talk about reverse engineering, hardware hacking, and all that kind of stuff. If you want to contact me, you can find me on Twitter at GDRAWNINJA, and hope you enjoy this presentation. Now, before we start, let's quickly talk about what I will talk about in the next few minutes. So first off, all the tags that you will see are local tags, and they all require hardware access. And so, I will not show any drive-by exploits or anything that can be exploited over Bluetooth or so. Second of all, a lot of the info in this talk is based on reverse engineering. And so, there might be minor mistakes. I may get something small wrong or so. And so, the devil is always in the details, and as I don't have access to the source, everything is really based on reverse engineering and so on. And my real goal with this is to just have some fun with hardware hacking and explore a device in a fun way. Now, as always, this kind of work is not possible without a lot of other people. And so, there are a couple of people that I want to thank. First off, Colin O'Flynn, who's one of the persons that nerd-sniped me with the ad tags in the first place. Second of all, Leonard Vouchers and Plonk, who I did a lot of reverse engineering with and who I did a lot of experiments with and so on. Jiska Klaassen, who gave me a lot of information on the Apple U1 chip and helped me a bit with some RTKit details. David Hulten, who provided very in-depth images of chips and provided de-layering of the PCB and so on. And also limited results without whom a lot of the work you're about to see would not be possible because he found the actual vulnerability in the NRF52 last year. Now, before we jump in, let's talk about the ad tags itself. Now, the ad tag is a Bluetooth key finder. So really nothing too special, at least I thought so when I first saw it. But what's unique about the ad tag is that it contains ultra wideband via the so-called U1 chip. Ultra wideband is a technology that can allow, for example, iPhones that have ultra wideband to very precisely locate the ad tag. And we're talking like centimeter precise, including direction finding and so on here. So this is something really neat. And ultra wideband works in, like I think the five to six gigahertz range. And so it's really high frequency and very difficult to analyze using cheap equipment. And so you really need very high end SDRs and so on to analyze it. But now we have a very cheap device that contains this U1 chip that we can potentially use for research on ultra wideband. The second cool feature is the find my network. And so basically when you use the Apple ad tag, any iPhone that goes into the Bluetooth range of it will report the location of your ad tag to Apple servers. And this is all done with privacy in mind. I don't really know too much about it, but it's a really cool feature because if you, let's say, lose your ad tag in France, you'll be able to locate it from Germany as long as any iPhone walks past. I also think it's funny because Wikipedia says that it's a key finder, but it doesn't actually attach to a key without separate accessories. Now, given all this, I was pretty uninterested in the ad tags and I didn't buy any and so on and I really had zero interest in them. That is until one morning I wake up and I get a message, hey, here are the flash contents of the ad tags. And attached to that message was a dump of the spy flash of the ad tags. Now, being a hardware hacker, I obviously at least had to peek inside of this dump. And so I ran hex dump on it and I immediately saw this. And so you might see those strings on the right side here. And if you read them backwards, you might see that they basically spell out things such as firm root or nvram root, crlg root and so on and so forth. And if you've worked with Apple embedded devices, you might immediately recognize this as being the FTAP of an RTKit firmware. RTKit is the embedded operating system that Apple uses in a lot of very small devices such as the AirPods. And if you ever see such a firmware and you wanna extract it, you can use a tool called FTAP dump, which makes it really, really easy. Now, knowing that this runs RTKit already made it slightly more interesting to me. But after digging into this for a bit, it turns out that this firmware is actually the E1 firmware. And so that's pretty interesting. Then scrolling further through the hex dump, I also discovered a couple of function names such as nrf underscore fstorage init, nrf fstorage write, nrf fstorage erase and so on and so forth. And that is nrf52 code. Now nrf52 is a very common microcontroller family that you can basically find in any, almost any key finder device. And so I'm very familiar with this chip. And so I thought that was kind of interesting. And so after realizing that maybe the AirTags are a good platform to analyze the E1, play with E1 firmware, have a look at the NF firmware and so on, I was nerd snarked and I knew that I need to buy an AirTag. So I went to the Apple store and I grabbed a couple of AirTags and I tried to open one up by prying open the backside and I immediately broke it. Like I somehow ripped off this inductor because the AirTags are really, really sensitive when you try to open them. They have a very thin PCB and if you nudge on the wrong side of it, you will destroy it. So if you try to open up an AirTag at home, always try to use these three points. It's basically where the battery compartment screws into the backside of the device and there it's relatively safe to open up the AirTags. And so after destroying my first AirTag in literally the first minute that I unpacked it, I managed to open a second one and this is basically what you see. You have a device with a ton of test points and so on, a couple of passives such as capacitors, the battery contacts and the big coil in the middle, which is actually the speaker of the AirTag and nothing really interesting except this small chip on the bottom right here. This is the accelerometer and we will have some fun with that one later on. If you remove the PCB, which is really annoying because you basically have to pry it out because it's all glued very tightly into the AirTags, you will get to see this and this is the interesting side because this is where all the integrated circuits, controllers and so on are. Let's start with the biggest one. This big silver chip here is the Apple U1 chip, the ultra wide band chip and if you look next to it, we have the nice antenna connector. Now, what's interesting about the U1 chip is that so far it was only available in very expensive devices such as the iPhone or the Apple Watch or so, not really in a price range where you can buy 10, solder out the U1 and then experiment with it. But now with the AirTags, we have an U1 available for like 30 or 40 bucks and so this is, I think, really going to be interesting and I think we will see a lot of research with the U1 chip from the Apple AirTags. To the left of the U1 chip, we have the SpyFlash and this is the SpyFlash that I got the dump to that nutsniped me towards the AirTags in the first place. To the left of the SpyFlash, we have the NIF-52, a Cortex-M microcontroller. Now, this microcontroller is super common in any IoT device nowadays and so it was clear that this chip would handle Bluetooth, most probably the iPhone communication, NFC and it's also known to be vulnerable to a fault injection attack and so basically, this chip can be locked down so you can prevent people from debugging it but there's a known vulnerability found by limited results that allows us to resurrect the debug interface using fault injection, as you will see in a bit. And so at this point in time, having the AirTag open and seeing the NIF-52, the plan for me, at least, was clear. Find the test pads and pins to connect an SWD programmer to the device, unlock the chip using fault injection and then hopefully gain access to the firmware to be able to analyze it and see how does the AirTag work. Is all the logic in the NIF-52? Is all the logic maybe done in the U1 and the NIF just acts as kind of a modem or so and so I was really curious at this point in time to see what is actually running on the NIF-52. Now, normally, when you open a new device, now, normally, when you open a new device, you have to probe all those pins and so on and figure out which one is actually the SWD interface and you have to solder off components because the NIF, for example, doesn't really have any contacts you can probe and so on but luckily for me, Colin O'Flynn already did all that work and so on his Twitter, you can see that he created this nicely annotated version of the AirTag and he also found out which test pads on the backside of the AirTag are the pads that we need to connect our debugger to and he also already tried to program the debugger and he also already tried to program the, and he also already tried to program the NIF-52 and found out that indeed, Apple had locked down the debugging interface. Now, this numbering scheme that Colin created kind of became standard in the AirTag hacking scene and so if you are looking for some info on the AirTags and you see like some pin numbers also somewhere, this is probably the numbering scheme that everyone is referencing to and thanks to Colin, we know that pin 35 and 36 are the pins to which we can connect an SWD programmer such as a J-Link or a cheap ST-Link or so and via those pins, we will be able to reprogram the AirTag. Now, as mentioned, the debugging interface on the AirTag is unfortunately locked down using a feature called AP Protect and this one will basically lock down the control access point for debugging and you can still erase the chip which will re-enable debugging and you can program it but then you lose the firmware and so while we could put our own firmware on it, at this point in time, it was much more interesting to dump the firmware than to put our own on it and luckily, thanks to limited results, great work, we can just use fault injection to re-enable it. Now, what is fault injection? Basically, when you take the power supply to a chip and you drop the power for a very, very short amount of time you can cause a kind of memory corruption in the chip and sometimes this will allow you to skip over instructions, sometimes it will allow you to corrupt memory reads and so on and so it's kind of difficult to understand really what it does in the chip because you can't really look into it while you drop the power for a couple of nanoseconds but you can get a relatively stable attack using this kind of approach and so the basic idea would be that during the start of the processor, at some point in time, the processor will check whether the debugging is disabled and if so, it will skip the step of enabling the debug hardware. Now, if we manage to perform a fault injection attack at just this moment in time, we might be able to trick the chip so that the chip will enable the debug hardware because we skip, for example, with the check instruction. Now, how do we do this on the NRF52? In general, most microcontrollers have an external power supply and then an internal power supply that is derived from that external supply and so, for example, in the case of the NRF52, the chip normally runs at 1.8 volts but then on the inside of the chip, those 1.8 volts are converted to different voltages for different peripherals and so, for example, the CPU core might run at 0.9 volts or Bluetooth might run at 1.2 volts and the problem is, we only really wanna attack the CPU core. We only wanna attack the actual instruction. We don't really care about Bluetooth and so on and we wanna be careful to not disrupt other parts of the chip too much because then it might happen that something else fails and resets the chip and so on and so, we wanna target only the CPU core if possible. Now, these regulators tend to be quite noisy and so, to reduce noise, often, the chip has an external connection for what's called a bypass capacitor. A bypass capacitor is a small capacitor that is directly connected to this internal voltage rail to stabilize the voltage towards the CPU core and you might already notice but one side of the capacitor gives us direct access to the voltage supply of the CPU core. Now, if we attach, for example, a switch towards ground to it and we press that switch, we will create a short circuit that will disable the regulator. We basically suck all power out of the regulator and by that, we can interrupt the power supply towards the CPU core. Then, if we open the switch again, we re-enable power. Now, obviously, with a manual switch, we can't get the precision and the timing that we require to hit just the right instruction. If we, however, connect a MOSFET to it, which is just an electronic switch, basically, we can digitally control the CPU core power supply and now we can use, you know, something like an FPGA to control the power supply and time it very precisely. Now, I like to go cheap on these kinds of attacks and always show, like, just how easy, for example, fault injection is and so I decided to use a Raspberry Pi Pico to perform this glitching attack and so basically, I connected the MOSFET to a Raspberry Pi Pico and now if the Raspberry Pi Pico enables one of its IOs, it will interrupt the power supply to the CPU core and then if you turn it off again, the CPU core will start again. And so, if we hook this up to the AirTag, we basically first need to find that bypass capacitor. Now, Apple was nice enough to put that capacitor on the backside and so the easily accessible side of the AirTag and even better, they even put a test pad right on that core power supply pin and so we can just solder on a cable there, connect our MOSFET to it and we are almost ready to go. Now, fault injection, in most cases, is not something that you just try once and are successful but in most cases, you wanna try a ton of times and eventually, you are successful and because each attempt is really short, like, let's say, 100 milliseconds, we can try 10 times per second and so even though we try 100 times or 1,000 times, we still get our desired results pretty quickly. Now, to be able to restart the AirTag and to also get a signal when the AirTag is actually booted, we also wanna connect the nRF52 power supply towards the Pico because basically, the AirTag runs at three volts from a battery and it takes a couple of milliseconds for the power supply to reach the nRF52 and so we wanna make sure that we get a signal on our Raspberry Pi Pico once the chip starts booting so that we can time our fault injection attack just right. To do this, we basically use a level shifter to convert the 1.8 volts from the nRF52 to the 3.3 volts that the Raspberry Pi Pico expects on input and then all we have to do now is power up the AirTag and you can do that by just connecting an IO directly to the battery contacts of the AirTag and so what we can do now is we can turn on the AirTag from the Raspberry Pi Pico, then we wait until the power supply to the nRF52 is enabled, which is basically the point in time at which the nRF52 boots and then we can perform our fault injection attack using the MOSFET connected to an IO. Now, all we need to do is also connect an SWD programmer that we will then use to check if our attack was successful and so basically we start by just turning everything off, then we turn on the power supply towards the nRF52, we wait for the signal from the nRF52 power supply and then we wait a short amount of time and then we enable the MOSFET which will drop the CPU core power for a very short amount of time and then we re-enable it and then we use our SWD programmer to check whether we are successful. Now, this sounds like a lot of complexity and a lot of work, but it's really, really easy and so for example, the code on the Raspberry Pi Pico is just these couple of lines. Basically, we power cycle the target and we wait for the nRF power to boot up, then we wait for a configurable amount of time and then we glitch for a configurable amount of time and if you set this up on a real AirTag, it will look something like this and so we have our AirTag in this case in kind of a breakout state to make life a bit easier, then we have a debugger which is basically the programmer that we use to check whether our glitch was successful and then we have this breakout board that I designed which is really just a Raspberry Pi Pico with a couple of level shifters and so on to make life easier and also with the Glitcher on board. Now, as you can imagine, the boot of the nRF32 takes quite a long time and so finding just the right spot in time where we drop the power to attack it is pretty difficult. Luckily for us, limited results documented pretty well with the power trace at which point in time of the boot of the chip we need to glitch and so in his blog post that you should check out on limitedresults.com, he precisely describes at which point in time we need to drop the power for a very short amount of time to re-enable the debugging interface and after setting this all up and using a glitch width that I knew is successful from the past, we are ready to go. Now, if we look at this on oscilloscope, you can see that our glitch is not really precise. This is because the code that I'm using to glitch it is very unprecise but as it turns out, this is enough. You will get lucky eventually just because the likelihood is that if you try often enough, you will hit the right point in time. To control the Glitcher, I wrote a simple Jupyter script that basically just sends the delay and tries a range of delays, tries a range of pulse width basically for the glitch and then just checks whether JTAG is enabled and so I let this run for a bit and after like a couple of minutes, I got lucky and I got this success and success means that basically JTAG was re-enabled. The test JTAG function in the Jupyter notebook tests whether it can connect via SWD to the chip and in this case, that was successful and suddenly on my hard drive, I found this. My script automatically dumped all the interesting areas of the chip and so we have the flash dump, the BP, ROT ranges, FICR, UICR and so on. All the interesting ranges that are in a chip and so I started analyzing the RTAG firmware. I started by just running strings on the firmware and I immediately recognized these strings here. This is an indication that they actually run core crypto which is Apple's crypto library on the RTAGs and the next thing that jumped to my eye was this URL found.apple.com slash RTAG. This is the URL that you get when you NFC scan an RTAG. It will lead you to a URL with like the PID and so on encoded in the URL. Now, I was really curious to see whether the firmware had any additional validations that I didn't know about and so I tried to modify the URL in a hex editor and reflash the firmware to the RTAG and then I got this. And so what do you do when you can change the URL of something to whatever you like? Let's see. Obviously, you try to rickroll people with an RTAG. Now, you might wonder, well, why would you go through all of that effort to rickroll people and I had a ton of YouTube comments asking exactly that question. Hey, why aren't you just using an NFC sticker and so on? But the goal with this was really just to see whether the firmware has any additional verification methods and this was the easiest way to check whether we can just modify something because it's very visual. You just tap it with your iPhone and you know whether you are successful. But continuing analysis of the strings output, I found this line here and I recognized these letters because in the iPhone, this is exactly the serial number that I saw in the Find My application for this RTAG and so it turns out that we can also freely edit the serial number of the RTAG and so for example, mine is now stack smashing. And this is pretty interesting because I personally expected the configuration to be in the U1 or on the SpyFlash or so but apparently, all the configuration details of the RTAG are stored in the NRF52 internal flash and that brought up a pretty interesting question because after pairing, for example, you can also see your sensor email address and so on all in the RTAG firmware basically and this brought up the question to Leonard and me whether we can actually clone an RTAG and so our idea was that I would dump a configured RTAG, send the flash dump over to Leonard, he would flash his RTAG and we would check whether my RTAG would be discovered in Belgium where Leonard lives and so we set this all up, I had my RTAG nicely set up at my home place, I dumped the RTAG, I removed the battery, I sent the firmware over to Leonard and what do you know, a couple of minutes later, my RTAG was suddenly in Belgium and so it somehow in a couple of minutes traveled a couple of hundred kilometers and so it works, we can clone an RTAG. All data that is required for cloning an RTAG is in the NRF52 flash and this is pretty interesting because this also means that if you, for example, find an RTAG or steal an RTAG, you can actually reset it and set it up with a new serial number, bypassing the lost function and so on and so forth and neither the spy flash nor the U1 seem to be really involved in the pairing of the RTAG and so that was pretty interesting because we all were pretty sure that Apple would do some crazy stuff with the U1 or so to make life of cloning and stealing and so on a bit harder and I'm curious what this will mean for, for example, bikes that have the Find My technology integrated. Now, with this information, we also started comparing our two dumps and so we basically started comparing what is different between different RTAGs and what changes with the pairing and for example, here in the hex dump, you can see my email address, the censored version that is shown when you find the tag and so on and overall, the information that is part of the pairing is relatively low and you still have a bit of room in the firmware to, for example, integrate your own custom payload into the RTAG and one thing that got a lot of buzz surrounding the RTAGs was its privacy protections. A lot of people were very afraid about getting tracked by an RTAG. Now, while I get the idea of being tracked, I personally think that the RTAG is a terrible tracking device. It doesn't have a microphone, well, a real microphone. It doesn't have GPS, it doesn't have GSM. The only thing that you have is Bluetooth and the location of an iPhone that walks by and even there, there are some limitations and I mean, if you go onto Alibaba also, you can get a decent tracker with like, all of these features like GPS, GSM, microphone and so on for $20 so it's even cheaper than an RTAG and it's not like an RTAG is particularly small or particularly well to hide and so what I'm about to show is, I don't think it's really an issue because I don't think the RTAGs are a great tracking device but basically, the RTAG has a couple of privacy protections to prevent people from just, you know, putting an RTAG in your backpack and being able to track you. If you have an iPhone and an RTAG moves with you for an extended period of time, your iPhone will give you an alert and so you will get a pop-up saying, hey, an RTAG has been following you and then you can get that RTAG to play a sound and from my research, this seems to be based on the idea that is broadcasted by the RTAG that changes regularly. Now, knowing that this ID is generated in the NRF52 code and knowing that I can, you know, modify the original firmware, I wondered what if we make our RTAG have multiple identities and so basically, instead of having, you know, one identity on my RTAG that would change its ID every, I don't know, 24 hours, what if I have a lot of identities and I would basically cycle through them relatively often and the iPhone would think every time that this is a different RTAG and it wouldn't detect that the RTAG is following me basically and so to implement this, I needed to do some firmware modifications but for that, we first had to actually analyze the firmware and so I started loading the firmware into Ghidra and found that it's really standard NRF52 code. It uses the normal NRF52 SDK functions and so that is pretty cool because it allows you to create signatures from the original NRF52 SDK and then apply them to the RTAG firmware, making your life much easier and you don't have to reverse engineer everything. Also, what was interesting was that no runtime mitigations or, you know, hardening was found and so for example, there are no stack canneries and so on and so if you find something like a buffer overflow, it's most probably relatively easy to exploit. But overall, the firmware was relatively straightforward to reverse engineer and so on and so the idea of building these privacy protection bypasses was relatively easy and unfortunately, and so after a couple of experiments, I had my custom firmware ready. It did not trigger any privacy warnings in our testing on iOS 14.5, tested this with a couple of iPhones with a couple of people walking around but it also has very limited usability because to manage those identities is kind of difficult because, you know, the Find My app only supports 16 RTAGs at once and so on and so forth and I also decided to not publish the details on this firmware yet until this is fixed one way or the other and the reason for that is that after publishing my first YouTube video about the attacks on the RTAG, I got a lot of emails like this asking me whether it's possible to bypass the warnings and a lot of people actually offered me money to bypass those protections and so given that there seems to, even though I, and so even though I think the RTAG is not a great tracker, I don't wanna be the person that enables people to track others using the RTAG. But another thing that a lot of people wanted was changing the sound of the RTAG that the RTAG makes when you search for it. Now, sound reverse engineering is kind of fun because normally when you reverse engineer something in a firmware, you need to use, you know, IDA Pro, Ghidra, Binary Ninja or Radar or so but for audio, it's really nice to just load it into Audacity because in most cases, the firmware will have raw sound samples contained in it and if you look into the Audacity menu, you can find that it has this point called import raw data and there you can just experiment with different encodings, byte orders, channels, sample rates and so on and eventually, you might see something like this and if you look at the center here, that looks a lot like valid audio and indeed, if we play it back, just this part in the middle, you can see that this sounds a lot like the noises that the RTAG makes, just a bit shuffled around and so on and it turns out that the audio player is kind of the small sample player where you have multiple samples that create one sound and so on and it was kind of a surprising amount of work to reverse engineer it and get it working nicely but after a while, I had this suite set up ready and by the way, at this point, again, thank you to Colin O'Flynn and Leonard who did a ton of reverse engineering on this and again, without whom, this would not have been possible and so, this is the regular sound that the RTAG makes. And here's my RTAG. And here's my RTAG. Now, you might be surprised by the sudden stop of the sound here. This is not just because I clicked stop but also because the RTAG just crashes at this point in time. I'm not entirely sure why but probably the reverse engineering of the sampler was not yet good enough but hey, we now have an Apple branded rig rolling device that you can put in somebody's pocket and rig roll them and so, I hope to release some tools for modifying the firmware to do that soonish. Now, another question that a lot of people had towards me is can we use the RTAG as a bug? And the main idea of a lot of people was that, hey, it has a speaker, right? And a speaker is always also a microphone. Well, on the RTAG, unfortunately, the, oh, well, not unfortunately, but luckily, basically, between the microcontroller and the actual speaker, there's an amplifier and that amplifier has no way to provide feedback to the CPU and so, we can't really measure anything that goes on in the speaker. However, what we do have is another tiny device over here which seems to be a Bosch accelerometer and an accelerometer can measure vibrations and I mean, what is sound if not just vibrations? And this is something that is very well known to be possible with accelerometers but I had never done it and so, I thought this would be a fun experiment to try to use the accelerometer as a microphone on the RTAGs. Now, unfortunately, I could not really get a high-speed signal, like not, I don't know, 12 kilohertz accelerometer signal from the accelerometer and it's also a custom part. Like a lot of websites claim that it's a BMA 280 but I don't think it's a 100% match. So, for example, the footprint is different and so on. It seems to be a different, it seems to be a custom chip which wouldn't be the first time that Bosch has created a custom accelerometer for Apple. Now, the problem is the accelerometer is not really sensitive to sound and so, even if you yell against it, you will only get very slight signals and so, I built a very specialized audio chamber for audio testing the RTAG and so, this device, which is totally not a regular Pringles cam, is my very sophisticated audio chamber for testing the RTAG and using it as microphone and so, you basically put the RTAG on the bottom of the chamber because that's where especially the deep vibrations will be very, very significant and that's needed because we have such a low sample rate that we only can get the low end of the spectrum basically and after a couple of tries, a ton of post-processing on the signal, this is the sound that I got out of the RTAGs. I don't know if you want to call that a success. So, I personally think that the Apple RTAGs are not really a great microphone but I can tell you that I had a ton of fun trying to get this working and trying to use the RTAGs and its accelerometer as a mic. Now, last but not least, let's talk about the V1. Now, as mentioned, V1 so far was only available on high-end devices such as the Apple Watch and the iPhone but now it's available for a really cheap price or well, cheapish price and it seems that during pairing, the firmware is transferred from the iPhone towards the SPI flash of the RTAG and then the U1 firmware is loaded on demand towards it and what's really cool on the RTAG is that you can downgrade it. We have full code execution on the RTAG. You don't need a jailbreak, you don't need to have an up-to-date iPhone exploit. No matter what updates are coming to the RTAG, because the fault injection attack is unfixable, we will always be able to inspect what's going on with the U1 on the RTAG and we can create breakup boards for it and so on and I'm really excited to finally have cheap U1 and ultra-wideband research for the Apple ultra-wideband ecosystem and if you wanna learn more about the U1, check out Yiskas and Alexander Heinrich's DEF CON talk this year. We're talking about the U1. Now, we also were able to create a full diagram of the Apple RTAG. David Halton polished each layer of the RTAG PCBs and then we reassembled it in an image processing software and now we have each layer of the PCB and so this makes it really easy to trace, for example, the connections towards the U1 and so on and makes life much easier when you just wanna sniff a certain line and so on and so forth. If you wanna learn more about all of these things, the Glitcher is open source on my GitHub. The reverse engineering details from Colin are published on his GitHub and I also have a repository with all the hardware pictures and the high-resolution PCB pictures that allow you to very easily see what communicates with what and how does everything work. I hope you enjoyed this presentation and if you have any questions or comments, please don't hesitate to contact me on Twitter or via email or whatever and I hope you enjoy DEF CON. Thank you.