 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 wanna contact me, you can find me on Twitter at GhidraNinja 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 might maybe get something 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 wanna thank. First off, Colin Oflin, who is one of the persons that not sniped me with the air tags in the first place. Second of all, Leonard Vauters and Plunk, who I did a lot of reverse engineering with and who I did a lot of experiments with and so on. Jeska Klassen, who gave me a lot of information on the Apple U1 chip and helped me a bit with some artiquette details. David Halton, who provided very in-depth images of chips and provided the 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 NRI-52 last year. Now, before we jump in, let's talk about the air tags itself. Now, the air 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 air tag is that it contains ultra white band via the so-called U1 chip. Ultra white band is a technology that can allow, for example, iPhones that have ultra white band to very precisely locate the air tag. And we're talking like centimeter precise, including direction finding and so on here. So this is something really neat. And ultra white band 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 white band. The second cool feature is the find my network. And so basically when you use the Apple air tag, any iPhone that carries into the Bluetooth range of it will report the location of your air 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 air 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 air 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 air tags and attached to that message was a dump of the spy flash of the air 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 NV RAM 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 F tab 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 F tab 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 really interesting. Then scrolling further through the hex dump, I also discovered a couple of function names such as nif underscore f-storage in it, nif f-storage write, nif f-storage erase and so on and so forth. And that is nif 52 code. Now nif 52 is a very common microcontroller family that you can basically find in almost any keyfinder 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 RTX are a good platform to analyze the E1, play with E1 firmware, I have a look at the nif firmware and so on, I was nerd sniped 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. 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 compartments 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 white 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 know, 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 spy flash. And this is the spy flash that I got the dump to that nerd snipe me towards the AirTags in the first place. To the left of the spy flash, we have the NI-52, the Quartex 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 NI-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 NI-52, is all the logic may be done in the U1 and the NRF 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 NI-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 NI-F, 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 NI-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 NIF-52? 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 NIF-52, 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 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 just how easy, for example, fault injection is. 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 attack, 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 attack. 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 attack and to also get a signal when the attack is actually booted, we also wanna connect the NI-52 power supply towards the Pico. Because basically, the attack runs at three volts from a battery and it takes a couple of milliseconds for the power supply to reach the NI-52. 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 NI-52 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 attack. And you can do that by just connecting an IO directly to the battery contacts of the attack. And so, what we can do now is we can turn on the attack from the Raspberry Pi Pico. Then we wait until the power supply to the NI-52 is enabled, which is basically the point in time at which the NI-52 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 NI-52. We wait for the signal from the NI-52 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 NIF 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 attack, it will look something like this. And so, we have our attack, 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 used 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 NIF-32 takes quite a long time. And so, finding just the right spot and time where we drop the power to attack it is pretty difficult. Luckily for us, limited results documented pretty well with a 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 our 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 pulls width basically for the glitch and then just checks where the 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 functions and 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 LTCH 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 LTCHs. And the next thing that jumped to my eye was this URL, found.apple.com slash LTCH. This is the URL that you get when you NFC scan an LTCH. It will lead you to a URL with like the PID and SWAN 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 LTCH. And then I got this. And so what do you do when you, you know, can change the URL of something to whatever you like? Obviously you try to rig role people with an LTCH. Now you might wonder, well, why would you go through all of that effort to rig role people? And I had a ton of YouTube comments ask 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. Cause 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 recognize these letters because in the iPhone, this is exactly the serial number that I saw in the find my application for this LTCH. And so it turns out that we can also freely edit the serial number of the LTCH. And so for example, minus now stacks machine. And this is pretty interesting because I personally expected the configuration to be in the U1 or on the spy flash or so. But apparently all the configuration details of the LTCH are stored in the NIF 52 internal flash. And that brought up a pretty interesting question because after pairing, for example, you can also see a sensor email address and so on all in the LTCH firmware basically. And this brought up the question to Leonard and me whether we can actually clone an LTCH. And so our idea was that I would dump a configured LTCH send the flash dump over to Leonard. He would flash his LTCH and we would check whether, you know, my LTCH would be discovered in Belgium where Leonard lives. And so we set this all up. I had my LTCH nicely set up at my home place. I dumped the LTCH, I removed the battery, I sent the firmware over to Leonard and what do you know, a couple of minutes later my LTCH was suddenly in Belgium. And so it's somehow in a couple of minutes traveled a couple of hundred kilometers. And so it works, we can clone an LTCH. All data that is required for cloning an LTCH is in the NIF 52 flash. And this is pretty interesting because this also means that if you, for example, find an LTCH or steal an LTCH you can actually reset it and create 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 LTCH. 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 LTCHs and what changes with the pairing. And for example, here in the HEX dump you can see my email address, the sensor 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 LTCH. And one thing that got a lot of buzz surrounding the LTCHs was its privacy protections. A lot of people were very afraid about getting tracked by an LTCH. Now, while I get the idea of being tracked I personally think that the LTCH is a terrible tracking device. It doesn't have a microphone, well, a real microphone. It doesn't have GPS, it doesn't have a GSM. The only thing that you have is Bluetooth and the location of an iPhone that walks by. And even there are some limitations. And I mean, if you go on to Alibaba or so you can get a decent tracker with all of these features like GPS, GSM, microphone and so on for $20. So it's even cheaper than an LTCH. And it's not like an LTCH 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 LTCHs are a great tracking device. But basically the LTCH has a couple of privacy protections to prevent people from just putting an LTCH in your backpack and being able to track you. If you have an iPhone and an LTCH 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 LTCH has been following you and then you can get that LTCH to play a sound. And from my research this seems to be based on the ID that is broadcasted by the LTCH that changes regularly. Now knowing that this ID is generated in the NI-52 code and knowing that I can modify the original firmware I wondered what if we make our LTCH have multiple identities. And so basically instead of having one identity on my LTCH that would change its ID every 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 LTCH and it wouldn't detect that the LTCH is following me basically. And so to implement this I needed to do some further 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 NI-52 code. It uses the normal NI-52 SDK functions and so that is pretty cool because it allows you to create signatures from the original NI-52 SDK and then apply them to the LTCH 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 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 attacks 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 attack 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 think the attack is not a great tracker I don't want to be the person that enables people to track others using the attack. But another thing that a lot of people wanted was changing the sound of the attack that the attack 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 either Pro, Gidra, 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 attack 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. 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 weed set up ready. And by the way at this point again thank you to Colin Oflin 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 attack makes. And here's my attack. 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 attack 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 attack 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 attack unfortunately the or 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 attacks. 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 attack. And so this device which is totally not a regular Pringles can is my very sophisticated audio chamber for testing the attack and using it as a microphone. And so you basically put the attack on the bottom of the chamber because that's where especially the deep vibrations will be 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 of the signal this is the sound that I got out of the R-Tex. I don't know if you wanna call that a success. So I personally think that the Apple R-Tex 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 R-Tex. And it's accelerometer as a mic. Now, last but not least, let's talk about the U1. Now, as mentioned, the U1 so far was only available on higher end devices such as the Apple Watch and the iPhone. But now it's available for a really cheap price or well, cheap Pish price. And it seems that during pairing the firmware is transferred from the iPhone towards the spy flash of the attack. And then the U1 firmware is loaded on demand towards it. And what's really cool on the R-Tex is that you can downgrade it. We have full code execution on the R-Tex. 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 R-Tex because the fault injection attack is unfixable. We will always be able to inspect what's going on with the U1 on the R-Tex. 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 who are talking about the U1. Now, we also were able to create a full diagram of the Apple R-Tex. David Halton polished each layer of the R-Tex 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. It makes life much easier when you just wanna, you know, 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, you know, 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 enjoyed DEF CON. Thank you.