针对CoreAudio补丁（CVE-2025-31200）的概念验证，该补丁位于iOS 18.4.1中。文章在此：https://blog.noahhw.dev/posts/cve-2025-31200/

更新 2025/05/27

我已成功将其推进到可控的（即使不是任意）写操作。详细说明即将发布。不过，如果你想自行验证，需要在补丁发布前的 macOS 版本上构建：< 15.4.1。你可以使用 check-mismatch lldb 钩子播放音频（使用一个简单的只是播放音频的测试工具）来观察写入操作。目前还不是一个很好的任意写入，原因如上所述——但主要是因为我还不能 100% 确定在重映射时这些来自帧缓冲区的值处于解码管道的哪个阶段。我暂且停止，以便撰写文章，如果有人想接手。

更新 2025/05/21

我与 @noahhw46（没有 @zhouwei 的这套设置也无法完成）已弄明白（文章即将发布）。不过，还有更多内容需要理解。我在下面添加了调查的第一步，以精确展示该漏洞实际上做了什么。check-mismatch 是另一个 lldb 脚本，可配合有效的概念验证使用，以展示在 APACChannelRemapper::Process（实际上是 APACHOADecoder::DecodeAPACFrame）中 mRemappingArray 与置换映射之间产生的精确不匹配。

mRemappingArray 的大小基于 mChannelLayoutTag 的低两个字节确定。
通过在它们之间制造不匹配，后续在 APACHOADecoder::DecodeAPACFrame 中的处理阶段会被破坏。
当 APACHOADecoder 处理 APAC 帧（根据通道重映射数组进行置换）时，它会使用 mRemappingArray 作为置换映射来进行通道重映射。似乎被重映射的帧数据大小是基于 mTotalComponenets 确定的。

当你播放 output.mp4 音频文件时（例如使用 AVAudioPlayer），APACChannelRemapper::Process 将发生越界读取，然后越界写入。

如果你在 Xcode 中启用 Guard Malloc，可以看到第一次越界读取：

Xcode 显示 APACChannelRemapper::Process 中的崩溃

未启用 Guard Malloc 时，APACHOADecoder::DecodeAPACFrame 稍后会在无效的 memmove 上崩溃：

@zhuowei 之前的 README 如下：

我正在尝试理解 iOS 18.4.1 中的 CoreAudio 补丁（CVE-2025-31200）。

我还没有弄清楚。

目前，在 macOS 15.4.1 上解码 output.mp4 时，我得到不同的错误信息：

error	01:10:26.743480-0400	getaudiolength	<private>:548    Invalid mRemappingArray bitstream in hoa::CodecConfig::Deserialize()
error	01:10:26.743499-0400	getaudiolength	<private>:860    Error in deserializing ASC components

而在 visionOS 2.2 的 Xcode 模拟器中：

error	01:09:21.841805-0400	VisionOSEvaluation	          APACProfile.cpp:424    ERROR: Wrong profile index in GlobalConfig
error	01:09:21.841914-0400	VisionOSEvaluation	     APACGlobalConfig.cpp:894    Profile and level data could not be validated

所以，我确实触发了新的检查，但我不知道如何让它实际覆盖某些内容。

关于变更函数的信息

被更改的函数似乎是 apac::hoa::CodecConfig::Deserialize，位于 /System/Library/Frameworks/AudioToolbox.framework/AudioCodecs。

APAC 是苹果位置音频编解码器

HOA 是高阶环境立体声。

如果你查看 ffmpeg 问题跟踪器中的示例文件：

$ avmediainfo ~/Downloads/clap.MOV 
Asset: /Users/zhuowei/Downloads/clap.MOV
<...>
Track 3: Sound 'soun'
	Enabled: No
	Format Description 1:
		Format: APAC 'apac'
		Channel Layout: High-Order Ambisonics, ACN/SN3D
		Sample rate: 48000.0
		Bytes per packet: 0
		Frames per packet: 1024
		Bytes per frame: 0
		Channels per frame: 4
		Bits per channel: 0
	System support for decoding this track: Yes
	Data size: 43577 bytes
	Media time scale: 48000
	Duration: 0.898 seconds
	Estimated data rate: 363.142 kbit/s
	Extended language tag: und
	1 segment present
	Index   Media Start  Media Duration   Track Start  Track Duration 
	    1  00:00:00.000    00:00:00.898  00:00:00.000    00:00:00.898
	Member of alternate group 0: (2, 3)

你可以使用 afconvert -o sound440.m4a -d apac -f mp4f sound440hz.wav 转换为 APAC。

使用 bindiff 对比 iOS 18.4.1 和 18.4，目前看来读取 mRemappingArray 时会检查偏移 0x58 处的全局 AudioChannelLayout* 中的通道数，而不是偏移 0x78 处的重映射 AudioChannelLayout*。

encodeme.mm 文件用于编码 APAC，一个 LLDB 脚本可以强制向 mRemappingArray 和重映射 AudioChannelLayout 中添加额外元素：

./build_encodeme.sh
./run_encodeme.sh

apple-positional-audio-codec-invalid-header

最受欢迎