- 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 stacksmashing 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 of all,
the texts that you will see are local attacks 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 maybe get something small wrong or so.
And so the devil is always in the details and SI don't have
access to the source.
Everything is really based on reverse engineering
and this one.
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 O'Flynn,
who's one of the persons that nuts sniped me with the out
texts in the first place.
Second of all, Lennart Wouters and Plonk,
who I did a lot of reverse engineering with and who I did a
lot of experiments with and so on, Jiska Classen,
who gave me a lot of information on the Apple U1 Chip.
And helped me build with some articles details,
David Hulton,
who provided very in-depth images of chips and provided the
layering of the PCB and so on,
and also limited results with how
to a lot of the work you're about to see would not be
possible because he found the actual vulnerability Indiana
52 last year.
Now, before we jump in, let's talk about the AirTags itself.
Now the AirTag 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 AirTag is that it contains
Ultra-Wideband, that if we are 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 Air-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 SDR sensor 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 AirTag,
any iPhone that carries into the Bluetooth range of it will
report the location of your AirTag 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 AirTag in France,
you'd be able to locate it from Germany as long as any
iPhone walks past.
I also think it's funny cause we can PDSS that it's a key
finder, but you know,
it doesn't actually attach to a key without a separate
accessories.
Now, given all this,
I was pretty on interested in the AirTags 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 AirTags
and attached to that message was a dump of the SPI-Flash
of the AirTags.
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 are,
they basically spell out things such as,
firm root or NVRAM root,
CILG 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-Type
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 ftab-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 U1 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_fstorage_init.nrf_storage_write.nrf_storage_
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, you know, analyze the U1,
play with U1 firmware.
I have a look at the nRF firmware and so on.
I was nerd sniped, and I knew that I need to buy AirTag.
So I went to the Apple store and I grabbed a couple of
AirTags.
And I tried to open one up by, you know, 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 notch 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 of which
is actually the speaker of the AirTag and nothing really
interesting except the 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, cause 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, you know, 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-Whiteband 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 also.
Not really in a price range where, you know,
you can buy 10 sold out of the U1 then experiment with it.
But now with the AirTags,
we have a new 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 U1
chip from the Apple AirTags.
To the left off the U1 chip, we have the SPI-Flash,
and this is the SPI-Flash that I got the dump to that next
slide me towards the AirTags in the first place.
To the left of the SPI-Flash,
we have the nRF 52 aquatics and microcontroller.
Now, this microcontroller is super common in any IOT device
nowadays.
And so it was clear that this chip will tend to the
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 float
injection, as you will see in a bit.
And so at this point in time,
having the AirTag open and seeing the nRF52,
the plan for me at least was clear,
find the testpads and pins to connect an SWD programmer to
the device, unlocked 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 nRF52 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 nRF52.
Now, normally when you open a new device,
you have to prove all those pins and so on and figure out
which one is actually the SWD interface.
And you have to solar of components because the nRF,
for example, doesn't really have any contacts you can probe
and so on.
But luckily for me, Colin O'Flyn
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 testpads on the backside of the
AirTag are the paths 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
NRF 52 and found out that indeed, Apple had locked down the
debugging interface.
Now,
this numbering scheme that Collin created kind of became
standard in the AirTag hacking scene.
And so if you are looking for some info on the AirTags,
as 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 program as such as a J-LINK or chip ST-LINK
or so, and via those pins,
we will be able to reprogram the Air-Tag.
Now as mentioned,
the debugging interface on the AirTag is unfortunately
locked down using a feature called APPROTECT.
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,
you know, put our own firmware on it,
at this point in time 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,
adjust this moment in time,
we might be able to trick the chip so that the chip will
enable the debug_hardware, because we skipped,
for example, where 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 .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.
And 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 not really 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 width 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 we, if we open the switch again,
we re-enable the power.
Now obviously with a manual switch,
we can't get the precision and the timing that we required
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 FPJ 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
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 made,
they even put a testpad 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 it a hundred times or a thousand
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 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 contexts 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 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
can watch 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
lever shifters and so on to make life easier.
And also with the glitcher on board.
Now, as you can imagine, the boot of the nRF52
takes quite a long time.
And so finding just the right spot and time where we dropped
the power to attack it is pretty difficult.
Luckily for us, LimitedResults documented pretty well the,
with a power trace,
at which point in time of the boot of the chip,
we need to glitch.
And so in his block posts that you should check out
on limitedresult.com,
he precisely describes at which point in time,
you 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 with that I
knew is successful from the past, we are ready to go.
Now, if we look at this on our silo scope,
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, you know,
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 jupiter-script
that basically just sensed the delay
and trace a range of delays,
trace the range of pulse with basically for the glitch
and then just checks whether J-Tech 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 J-Tech was really enabled.
The test J-Tech functions in the Jupiter 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 had the flash dump, the BPROT rangers,
FICR, UICR and so on,
all the interesting ranges that are in a chip.
And so I started analyzing the AirTag 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 corecrypto,
which is Apple's crypto library on the AirTags.
And the next thing that jumped to my eye was this URL found
at apple.com/airtag.
This is the URL that you get when you NFC scan an AirTag,
it will lead you to a URL with the PID and so on included 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 try to modify the URL in hex editor and refresh
the firmware to the Air-Tag.
And then I got this.
And what do you do when you, you know,
can change the URL of something to whatever you like.
(upbeat lively music)
Obviously you try to regrow people with an AirTag.
Now you might wonder, well,
why would you go through all of that effort to regrow
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 AirTag.
And so it turns out that we can also freely edit the serial
number of the AirTag, and so, for example, mine is now,
stacksmashing.
And this is pretty interesting because I personally expected
the configuration to be in the U1 or on the SPI-Flash
also, but apparently all the configuration details off the
AirTag assort in the nRF52 internal flash.
And that brought up a pretty interesting question because
after pairing, for example, you can also see your censored
email address and son on, all in the AirTag firmware,
basically.
And this product, the question,
will I not and meet whether we can actually clone an
AirTag?
And so our idea was that I would dump a configured AirTag,
sent the flash dump over to Lennart.
He would flash his AirTag and we would check whether,
you know, my AirTag would be discovered in bedroom where
then it lifts.
And so we set this all up.
I had my AirTag nicely set up at my home place.
I dumped the AirTag, I removed the battery.
I sent them over to Lennart.
And what do you know, a couple of minutes later,
my AirTag 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 AirTag,
all data that is required for cloning an Air Tag is in the
nRF52 flash.
And this is pretty interesting because this also means that
if you, for example, find an AirTag or steal an AirTag,
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 SPI-Flash nor the U1 seem to be really
involved in the pairing of the AirTag.
And so that was pretty interesting, 'cause 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 for 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 Air-Tags 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 attack 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 AirTag.
And one thing that got a lot of buzz surrounding the
AirTags was it's privacy protections.
A lot of people were very afraid about getting tracked by an
AirTag.
Now, while I get the idea of
being tracked,
I personally think that the AirTag is a terrible tracking
device.
It doesn't have a microphone with a real microphone.
It doesn't have GPS, doesn't have a GSM.
The only thing that you have is the Bluetooth and the
location of an iPhone that walks by.
And even 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 AirTag.
And it's not like an AirTag is particularly small or
particulary well to height.
And so what I'm about to show is I don't think it's really
an issue because I don't think the AirTags are great
tracking device,
but basically the AirTag has a couple of privacy protections
to prevent people from just, you know,
putting an AirTag in your backpack and being able to track
you.
If you have an iPhone and an AirTag moves with you for an
extended period of time, your iPhone will give you an alert.
And so you will get a popup saying, hey,
an AirTag has been following you.
And then you can get that AirTag to play a sound.
And from my research,
this seems to be based on the idea that is broadcasted by
the AirTag that changes regularly.
Now, knowing that this idea is generated in the nRF52 code.
And knowing that I can, you know,
modify the original phone where I wondered what if we make
our AirTag have multiple identities.
And so basically instead of having, you know,
one identity on my AirTag that would change its ID every,
I dunno, 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 AirTag,
and it wouldn't detect that the AirTag 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 and 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 AirTag 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 canaries and so on.
And so if you find it 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 have my custom firmware ready.
It did not trigger any privacy warnings in our testing on
iOS 14.5 tests were 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 AirTags 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 AirTag, I got a lot of emails like this asking me
whether it's possible to bypass the warnings and a lot of
people that actually offered me money to bypass those
protections.
And so given that there seems to, even though I, and
so you and I think the AirTag is not a great tracker.
I don't wanna be the person that enables people to track
others using the AirTag.
But another thing that a lot of people wanted was changing
the sound of the AirTag, that the AirTag 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 Radare 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 symbols contained in it.
And if you look into the Audacity menu,
you can find that it has this point called import raw data.
And then 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,
(playful music)
you can see that this sounds a lot like the noises that the
AirTag makes just the bit shuffled around and so on.
And it turns out that the audio player is kind of the small,
simple 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 sweet set up ready.
And by the way, at this point again,
thank you to Colin O'Flynn and Lennart 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 song that the AirTag makes
(playful music)
And here is my AirTag.
(upbeat lively music)
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 AirTag 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 Rick rolling device that you
can put in somebody's pocket and Rick rolled them.
And so I hope to release some tools for modifying the
firmware to do that soon-ish.
Now, another question that a lot of people had towards me is
can we use the AirTag 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 AirTag, unfortunately
or, well, not unfortunately,
but luckily, basically, between the microcontroller and the
actual speaker, that'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, you know, 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 will be a fun experiment to try to use
the accelerometer as a microphone on the AirTags.
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 BMA280,
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 AirTag.
And so this device,
which is totally not irregular Pringles can,
is my very sophisticated audio chamber for testing the
AirTag and using it as a microphone.
And so you basically put the AirTag 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 sampler rate that we only can get the low end of the
spectrum basically.
And after a couple of tries at ton of, you know,
post-processing all the signal,
this is the sound that I got out of the AirTags.
(mumbling music)
I don't know if you wanna call that a success.
So I personally think that the Apple AirTags
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 AirTags and its
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 really cheap price or well
cheap-ish price.
And it seems that during pairing,
the firmware is transferred
from the iPhone towards the SPI-Flash of the AirTag,
and then the U1 firmware is loaded on demand towards it.
And what's really cool on the AirTag is that you can
downgrade it.
We have full code execution on the AirTag.
You don't need a jailbreak, you don't need to have,
you know, an up-to-date iPhone exploit.
No matter what updates are coming to the AirTag,
because the fault-injection attack is unfixable,
we will always be able to inspect what's going on with the
U1 on the AirTag and we can create breakout boards for it
and so on.
I'm really excited to finally have cheap U1
and Ultra-Wideband research for the Apple Ultra-Whiteband
ecosystem.
And if you wanna learn more about the U1, checkout
Jiska's and Alexander Heinrich's DEFCON talk this year,
we're talking about the U1.
Now we also were able to create a full diagram of the Apple
AirTag.
David Hulton polished each layer of the AirTag PCBs.
And then we reassembled it in an image processing software,
and now we have each layout of the PCB.
And so this makes it really easy to trace, for example,
the connections towards U1 and so on.
It makes life much easier when you just wanna, you know,
sniffer certain lines, and so on and so forth.
If you wanna learn more about all of these things,
the glitcher is open source on my github.
And 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 hope you enjoy DEFCON.
Thank you.