thegaminggallifreyan/liberationplay-cve-2025-24132-airbourne-pocPOC for CVE-2025-24132 (AirBourne). Currently just triggers the overflow and causes a crash
POC for CVE-2025-24132 (AirBourne). Currently just triggers the overflow and causes a crash
In an effort to try and gain root access to my car's head unit, I have researched and compiled everything I have learned about the Airplay Exploit CVE-2025-24132 (Named Airbourne) discovered by Oligo Security.
https://www.oligo.security/blog/airborne
This is my first reverse-engineering project. I jumped into this having never used a debugger, having very little Linux and coding experience, and having never touched MacOS until halfway through this project. Maybe I should have started with some CTF... Oh well. I have worked on this on and off for the past few months just to see if I could do it.
It took several months to obtain a vulnerable and patched copy of a binary to diff, and then another month to actually get them running in an emulator.
But as it turns out, the vulnerable code is impossible to reach in an emulator, as it requires communication with a physical MFi chip on the logic board. After struggling for 2 months wondering why I couldn't reach the overflow and then realizing the problem, I was able to cannibalize the binary enough by patching out checks for the MFi chip responses and filling what it would have returned with garbage. This allowed me to finally reach the overflow and understand enough of it to cause a crash on a real system.
The overflow exists within the AES CTR encryption handling. The size of the encryption key passed in a SETUP packet is not checked and assumed to be 16, and a buffer of 16 is created.
These crashes are barely noticeable, as the server usually immediately restarts and reconnects, which just results in a brief loss of audio or a few seconds of black screen on a CarPlay system. I have not managed to figure out how they are leaking memory yet, so this is currently only viable on devices with stack protections disabled.
Find a way to leak memory to bypass stack protections.
This works against CarPlay units or AirPlay units that do not require any type of authorization. If a PIN is required to pair first this will not work as there are more pairing steps involved that are not implemented.
For Bluetooth based devices, in order to avoid having to do all the BS of figure out Bluetooth pairing, you can instead just download an app like Pyto and run the script directly from the phone like I did. Much easier.
I will add known patched devices here as I discover them.
All Onyko AV receivers that support Airplay should be vulnerable to this. My test unit has been a TX-NR656 which does not have any stack protection whatsoever. Creston DM-NAX-8ZSA units before firmware 3.1 are vulnerable and do not have canaries, but the Airplay process runs in a container. Kia CCNC head units have proper stack protection and so far I have not managed to defeat it, but according to system logs, the carplayserver runs as root.
