## https://sploitus.com/exploit?id=A9507263-E6A3-5DF1-8332-8858B2BCCEDA
In an effort to try and gain root access to my car's head unit, I have researched and compiled everything I have learned so far about the Airplay Exploits CVE-2025-24132 and CVE-2025-30422 (Named Airbourne) discovered by Oligo Security.
https://www.oligo.security/blog/airborne
Everything here is pure guessing, as 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. Unfortunately, I have not been successful yet, but I have learned so much along the way.
It took several months just to obtain a vulnerable and patched copy of a binary to diff, and then another month to actually get them running in an emulator. These 2 files were obtained from the firmware of a Crestron DM-NAX-8ZSA unit (Thank you Crestron for patching the exploit, not encrypting your firmware, and providing old versions for download - https://www.crestron.com/security?advisory=AirPlay%20Audio%20SDK%202.7.1%20and%202.0.10).
## CFCopyCString
A potential buffer overflow in CFCopyCString exists when getting the length of a CFData object.
```len = (size_t)((CFDataGetLength((CFDataRef)inObj) * 2) + 1);```
https://github.com/Amoystyle/hao31.zhang/blob/0fb847a5c7c1bf287ff766210974e2272d0efc22/airplay/AirPlay/AirPlaySDK/AccessorySDK/Support/CFUtils.c#L2093
This was patched by adding an additional check to make sure the returned length is less than what it would take to overflow
```
int32_t length = CFDataGetLength(r7);
{
if (length >= 0x7fffffff) { r4 = 0xffffe5a1; }
else { char* buffer = malloc((length > 0x1f;
if (arg2 != 0x8000100)
{
bool c_2 = arg1 >= 0x20000000;
bool cond:0_1 = ~c_2;
if (r3 - 0 >= r3 && (r3 - 0 != r3 || !c_2)) { return arg1 = arg1;
bool cond:1_1 = ~c;
if (0 - r3 0x7FFFFFFF ). All of them get stopped by the sanity checks for underrun of data.
You would need to get past this size check in order to create a object large enough:
https://github.com/Amoystyle/hao31.zhang/blob/0fb847a5c7c1bf287ff766210974e2272d0efc22/airplay/AirPlay/AirPlaySDK/AccessorySDK/Support/CFLiteBinaryPlist.c#L811
The SDK also has a max body Content-Size limit of 16,000,000
https://github.com/Amoystyle/hao31.zhang/blob/0fb847a5c7c1bf287ff766210974e2272d0efc22/airplay/install/CoreUtils/HTTPMessage.h#L47
so it is not possible to even brute force by sending a ~3.5G bplist (Assuming a speaker even had that much ram...)
As of now, I am convinced that the code exists on all the devices but is not actually exploitable except on a handful of devices running a version of the SDK with another flaw. Oligo Security claims this can lead to RCE and has video evidence, but Apple lists the vulnerability as much less severe with only being able to cause a crash
Thy only other possibility is there is a flaw in the math or size checking for converting data into a propertylist. However none of the sanity checks were updated and the code is identical in the patched binary, so that leaves me to believe there is nothing wrong with the bounds checking.
Hopefully someone smarter than me can figure it out. If it's even possible. If you do please share so we can spread managed democracy upon these speakers!