Similar to most Apple embedded devices, the AirTags also seem to run RTKit... And this is where it gets interesting: It's a DEBUG build - debug builds have more functionality, and sometimes more logs & co - this is good news!
Looks like both rkos are identical - maybe a recovery/fallback version?
Ohhh, what do we have here? This looks a lot like it might be an nRF52 firmware, which is the microcontroller used on the AirTag!
Hmm too bad, looks like it's just a reset vector, not actual firmware :)
Also here's the entropy graph of the whole thing, looks like nothing is encrypted :)
I still remember when I first saw this Apple note - in the firmware images of my 3rd generation iPod when I just got started with hardware/firmware reversing 😀
Well hello there, nRF52 firmware🥸
(If someone close to Stuttgart has too many AirTags and can spare one.. hit me up 👀)
Found a SHA256 implementation in the firmware, slowly trying to get an overview
For those playing along at home: Loaded the firmware starting at 0x28D000 into Ghidra, loading offset seems to be 0x1c000 - guessing that there's a bootloader in front of that?!
Then used SVD-Loader to load an nrf52 SVD I found - it's not super detailed but gets the job done
Looks like this is the function that generates the "I found a tag" URL:
Sweet, picking some tags up in an hour, that should be fun😬
That raw talent: Buy something and IMMEDIATELY brick it -.-
And found the SoftDevice firmware used on the AirTag - thanks for the hint that it's at the beginning of the flash @JAlDhalemi :)
As so often I’m stuck in writing tools: this time a dual SPI analyzer that gives me the data in the format I need :)
• • •
Missing some Tweet in this thread? You can try to
force a refresh
Let's talk about some of the security features of the new @Raspberry_Pi RP2350, because they are 🔥🧵
1.) Glitch Detectors
The RP2350 has 4 embedded glitch detectors, with configurable sensitivity. These will respond to voltage & EM fault-injection attempts, and reset the chip.
In our testing we found that they are quite effective at capturing most glitches.
2.) The RCP - Redundancy Coprocessor
The RCP protects the bootrom against fault-injection (and other) attacks by generating randomized stack canaries (in hardware!), providing boolean value validation based on bit-patterns, etc.
So I was trying to sniff the BitLocker TPM key on an old laptop of mine - it has this great debug port that exposes most of the TPM (Low Pin Count Bus) signals, but it’s missing the clock signal.
So I could either hunt for the clock signal on the backside - or build a "clockless" LPC analyzer! And after a bit of coding I built a @saleae LA analyzer that doesn't need a clock signal - and was able to decode the whole TPM communication!
Then I wrote a couple of simple scripts to extract the VMK (Volume Master Key) from my recorded traffic!
This is a (not-so-great😅) die shot of the upper side of an ATECC608A secure element. As you can see, the upper layer looks like it's all metal - but if we zoom in, we get the above pattern
This pattern is there to prevent invasive attacks such as microprobing, and also makes it necessary to delayer the chip to start even seeing any of the actual logic (though you can just look at it from the backside using IR).