CVE 2025 31200

Summary

Background On April 16, 2025, Apple released a patch for a bug in CoreAudio which they said was “Actively exploited in the wild.” This flew under the radar a bit. Epsilon’s blog has a great writeup of the other bug that was presumably exploited in this chain: a bug in RPAC. The only thing out there that I am aware of about the CoreAudio side of the bug is a video by Billy Ellis (it’s great. I’m featured. You should watch…you’re probably here from that anyways). As he mentioned in the video, “Another security researcher by the name of ‘Noah’ was able to tweak the values such that when it was played on MacOS, it actually did lead to a crash.” I think it’s still worth it to write about that ‘tweaking’ process in more detail. I had just finished another project and ended up on a spreadsheet maintained by Project Zero which tracks zero days that have been actively exploited in the wild. It just so happened that that day there had been another addition: CVE-2025-31200. I couldn’t find any writeups on it, or really any information other than the fact that it was a “memory corruption in CoreAudio” so I decided to have a look myself. How hard could it be? There was a bit of a rocky start. I don’t have IDA Pro so my options for binary diffing are limited. Billy mentions Diaphora in his video, and that does seem like the industry standard. Apparently it also has a Ghidra plugin, but I don’t want that Java stink on my laptop. So I had to do things the old-fashioned way. Luckily there is an awesome tool called ipsw maintained by Blacktop. One of its primary use cases is diffing between different versions of iOS. There is even a repo where markdown versions of the diffs are posted, so it was trivial for me to have a look at that. There were a relatively small number of updates, and it was clear that the ones related to this bug were in AudioCodecs. A 20 byte increase in the __text section is exactly the kind of change you’d expect from a memory corruption like this, so I thought ...