苹果设备的“锁屏漏洞”：CVE-2025-24200如何被攻击者利用？
苹果设备的“锁屏漏洞”：CVE-2025-24200如何被攻击者利用？
HSCERT 山石网科安全技术研究院 2025-03-08 09:01
苹果设备的USB限制模式被绕过，你的隐私还安全吗？
在当今数字化时代，智能手机的安全性已经成为我们生活中不可或缺的一部分。苹果公司一直以其严格的安全机制著称，但最近一个名为CVE-2025-24200的漏洞却引发了广泛关注。接下来以一篇深度文章[1]，带你深入了解这个漏洞的细节，以及苹果是如何修复它的
。
一、引言
苹果公司近日发布了iOS18.3.1版本（构建号22D72），用于修复由CitizenLab报告、涉及辅助功能框架的漏洞。相关的
漏洞公告可在此处[2]查阅。以下是直接从苹果官网摘录的概述：
– 辅助功能漏洞影响设备：iPhoneXS及后续机型；13英寸iPadPro；第三代及后续12.9英寸iPadPro；第一代及后续11英寸iPadPro；第三代及后续iPadAir；第七代及后续iPad；第五代及后续iPadmini。
-
漏洞影响：物理攻击可能导致锁定设备的USB限制模式被禁用。苹果已获悉一份报道称，该漏洞可能已被利用于针对特定目标的极其复杂的攻击中。
-
漏洞描述：通过改进状态管理机制解决了授权问题。
-
CVE-2025-24200：多伦多大学蒙克学院CitizenLab的BillMarczak
在笔者的文章中，主要是阐述目前从补丁中所了解到的
。
二、USB限制模式
在深入分析补丁之前，笔者先简要回顾USB限制模式的功能及其重要性。
当iPhone启用USB限制模式后，若设备处于锁定状态超过1小时，其端口的数据传输功能将被自动禁用。用户必须解锁设备并明确授权，外部配件才能建立连接：
这一机制的核心目标是抵御高复杂性物理攻击，特别是通过外接设备（如取证提取工具，例如ufed或graykey）。
若攻击者能够从锁屏界面直接绕过USB限制模式，则意味着设备将重新暴露于上述风险中。近期社交媒体上的案例（如此推文[3]）也印证了攻击者对此类绕过能力的迫切需求：
在接下来的章节中，笔者对CVE-2025-24200漏洞进行技术解析。该漏洞允许攻击者在特定条件下绕过USB限制模式。
三、设置
在找到实际补丁之前，第一步是下载修复前后的iOS构建版本：
# pre-patch
ipsw download ipsw --device iPhone14,4 --build 22D63
# post-patch
ipsw download ipsw --device iPhone14,4 --build 22D72
接着，可以从两个版本中提取所有二进制文件和库以调查变更。
四、定位补丁
笔者首先查看了由Blacktop为每个iOS版本生成并发布的ipsw diff
差异报告。
通过此报告，可以检查每个显著变化。值得注意的是，苹果在公告中提到改进了状态管理，这可能涉及额外的检查，并因此引入了新的基础块（basicblocks）。
通过以下（无界面）BinaryNinja脚本，我们可以列出同一二进制文件两个符号化版本的基础块数量差异：
import binaryninja
binaryninja.disable_default_log()
def build_table(bv: binaryninja.BinaryView):
"""Builds a table of function names to their basic block count."""
table = {}
for f in bv.functions:
if not f.name.startswith('sub_'):
table[f.name] = [len(f.basic_blocks)]
return table
def diff_tables(original, patched):
"""Compares two basic block tables and prints changes."""
for fn in original.keys() & patched.keys():
if original[fn] != patched[fn]:
print(f'{fn}: {original[fn]} -> {patched[fn]}')
t1 = build_table(binaryninja.load("/path/to/original"))
t2 = build_table(binaryninja.load("/path/to/patched"))
diff_tables(t1, t2)
在接下来的子章节中，笔者重点分析两个组件中发现的重要变更。
（一）AXSpringBoardServerInstance 的变更
在该框架中，以下函数似乎新增了4个基础块：
-[AXSpringBoardServerHelper _handleDisallowUSBRestrictedModeSCInformativeOnly:]
进一步检查发现，苹果在函数的最开头添加了一个校验，确保设备在显示弹窗前已解锁。该弹窗的标题为本地化字符串sc.disallow.usb.restricted.mode.alert.title
，并仅包含一个可点击的OK
操作。
顾名思义，此函数仅用于信息提示，即仅影响用户界面。我们仍需找到弹窗显示后实际禁用USB限制模式的位置。
（二）profiled的变更
profiled是iOS中一个重要的守护进程，负责处理多项功能，包括辅助功能、远程设备管理（MDM）等，在此次更新中，以下函数被修补并新增了6个基础块：
-[MCProfileServicer setParametersForSettingsByType:configurationUUID:toSystem:user:passcode:credentialSet:completion:]
通过逆向工程两个版本，笔者还原了补丁内容如下：
diff --git a/original.m b/patched.m
index cd2b537..7fe1bd4 100644
--- a/original.m
+++ b/patched.m
@@ -8,6 +8,13 @@ BOOL has_ent = [self
if (has_some_entitlement == NO) {
// Unchanged
} else {
+ NSDict *rb = [settingsByType objectForKeyedSubscript: @"RestrictedBool"];
+ BOOL is_device_locked [[MCDependencyManager sharedManager] isDeviceLocked];
+ BOOL restricted_mode_allowed = [
+ rb objectForKeyedSubscript: @"FeatureUSBRestrictedModeAllowed"
+ ]
+
+ if (restricted_mode_allowed == NO || is_device_locked == NO) {
[[[MCProfileServiceServer sharedServer]]
setParametersForSettingsByType: type
sender: [self remoteProcessBundleID]
completion: completion
]
+
+ } else {
+ NSError *error = [
+ MCErrorWithDomain: _MCSettingsErrorDomain
+ code: 0x6d66
+ descriptionArray: _MCErrorArray
+ errorType: _MCErrorTypeFatal
+ ];
+
+ if (completion) {
+ completion.completionHandler(completion, error);
+ }
+ }
}
正如看到的这样，在调用实际设置目标参数（本例中即限制模式状态）的setParametersForSettingsByType
内部方法前，函数会校验设备是否已解锁。
这似乎是实际修复CVE-2025-24200的补丁。
五、攻击向量分析
跟随笔者，现在我们对补丁有了更深入的理解，需要找到可利用底层漏洞的代码路径。第一步是确定如何通过前述两个修补函数之一来禁用USB限制模式。经研究发现，assistivetouchd
守护进程包含通过以下函数禁用USB限制模式的代码：
-[SCATScannerManager _setUSBRMPreferenceDisabled]
此函数引用了多个AX[…]
类，暗示其可能与前面讨论的第一部分补丁（弹窗提示）相关。
这促使我们更仔细地研究该守护进程。
（一）assistivetouchd守护进程
assistivetouchd
守
护进程位于iOS设备的以下路径：
System/Library/CoreServices/AssistiveTouch.app/assistivetouchd
当设备启用某些辅助功能时，该守护进程会持续在后台运行。最典型的例子是Assistive Touch功能——此功能会在屏幕上常驻一个菜单，允许用户通过菜单执行特定操作：
通过查看assistivetouchd
的交叉引用，我们发现_setUSBRMPreferenceDisabled
可能由以下函数调用：
-[SCATScannerManager handleUSBMFiDeviceConnected]
根据函数名推断，连接经过MFi认证（MadeforiPhone）的外设即可触发此函数。
以下是该函数的逆向代码（可能存在误差）：
@implementation SCATScannerManager
- (void)handleUSBMFiDeviceConnected {
AXSettings btm = [SCATBluetoothManager sharedInstance];
bool did_read_rm_alert = [btm switchControlUserDidReadUSBRestrictedModeAlert];
bool has_disabled_rm = [self userHasDisabledUSBRM];
bool should_disallow_rm = [btm switchControlShouldDisallowUSBRestrictedMode];
if (!did_read_rm_alert && !has_disabled_rm && should_disallow_rm) {
[btm setSwitchControlShouldDisallowUSBRestrictedMode:NO];
// Forwards a call to the AXSettings framework that is responsible
// for showing the alert discussed earlier in the patch section
// The -[SCATScannerManager _setUSBRMPreferenceDisabled] function that
// disables USB restricted mode is passed as the callback handler for
// this alert.
}
}
@end
函数内部会执行基础检查以决定是否显示弹窗。核心逻辑为：若弹窗未展示过且USB限制模式已启用，则触发弹窗。弹窗仅包含“确认”按钮，点击后会执行回调函数——即调用
_setUSBRMPreferenceDisabled
。
（二）手动触发函数测试****
为验证假设，我们尝试在可通过Frida调试的iOS设备上强制调用handleUSBMFiDeviceConnected
方法。
不幸的是，我们无法直接通过Frida的ModuleAPI获取该函数，因此改用以下方式：通过命令从设备提取assistivetouchd
二进制文件：
从二进制文件中，可以手动计算目标函数与可触发函数之间的偏移量。
在这个案例中，笔者选择钩住-[HNDRocker _shakePressed]
方法，是因为可在设备锁定时通过AssistiveTouch菜单触发。
onEnter
处理如下：
onEnter(log, args, state) {
// Following addresses need to be adapted for each build
shakePressedBaseAddr = 0x100042858;
handleUSBMFiDeviceConnectedBaseAddr = 0x1000ad1c8;
off = handleUSBMFiDeviceConnectedBaseAddr - shakePressedBaseAddr
shakePressedAddr = this.context.pc;
log('ShakePressed:', shakePressedAddr)
handleUSBMFiDeviceConnectedAddr = shakePressedAddr.add(off)
log('handleUSBMFiDeviceConnected:', handleUSBMFiDeviceConnectedAddr)
handle = new NativeFunction(handleUSBMFiDeviceConnectedAddr, 'long', []);
handle()
},
追踪命令：
frida-trace -U assistivetouchd -m '-[HNDRocker _shakePressed]'
最终，通过点击“Shake”选项触发了追踪函数。借助钩子，成功调用了handleUSBMFiDeviceConnected
函数并显示弹窗：
如前所述，此时攻击者仅需点击“OK”即可在锁屏界面禁用USB限制模式。
本次测试基于以下设备环境：
iPhoneX（iPhone10,3），运行系统为iOS16.7.10（构建号20H350）。
（三）如何在真实场景中触发****
目前我们仅通过强制调用-[SCATScannerManager handleUSBMFiDeviceConnected]
方法触发弹窗，但尚不清楚其在真实场景中的自然调用方式。
需补充说明的是，AssistiveTouch并非唯一会激活assistivetouchd
守护进程的辅助功能。
另一相关功能是切换控制（SwitchControl）。
该功能允许用户通过外接设备控制iPhone。
从当前分析的类方法命名——均以SC
开头（可能代表SwitchControl）推断，插入通过MFi认证的切换控制设备是合法触发途径。
调研市面上的切换控制设备发现，多数通过蓝牙连接。
但我们发现曾有一款通过Lightning接口操作的设备。
此处是来源于厂商网站的产品展示截图，标注的该产品已停产。
当设备处于USB限制模式时，USB协议完全禁用，但Lightning端口仍支持其他协议，如MFi设备使用的iAP2协议。
因此推测：
在启用切换控制功能的iPhone上插入此类设备，可能直接触发弹窗，从而在iOS18.3.1之前的版本中在锁屏界面绕过USB限制模式
。
六、免责声明
尽管上述推测逻辑可行，但我们目前缺乏硬件设备进行实际验证。
需注意，USB限制模式并非防御物理外设攻击的唯一机制，实际漏洞利用可能更为复杂。
此外，本文仅探讨了该漏洞的一种潜在攻击向量，其他利用方式可能仍存在。强烈建议用户及时更新设备至最新系统版本，即使未启用辅助功能
。
参考文献
[1]
https://blog.quarkslab.com/first-analysis-of-apples-usb-restricted-mode-bypass-cve-2025-24200.html.
[2]https://support.apple.com/en-ca/122174.
[3]https://x.com/zerozenxlabs/status/1889612599727096140.
[4]Activating data connections securely – Apple Support (UK),https://support.apple.com/en-gb/guide/security/sec5044aad1b/1/web/1.
[5]About the security content of iOS 18.3.1 and iPadOS 18.3.1 – Apple Support (CA),https://support.apple.com/en-ca/122174.
[6]Important info about the Blue2 and Hook+ switch interfaces (updated 4/8/24) | OMazing Kids AAC Consulting,https://omazingkidsllc.com/2022/06/30/important-info-about-the-blue2-and-hook-switch-interfaces/.
[7]stacksmashing – Hithackers guide to Apple Lightning and JTAG hacking – V02,https://media.defcon.org/DEF CON 30/DEF CON 30 presentations/stacksmashing – The hitchhackers guide to iPhone Lightning JTAG hacking.pdf.
山石网科是中国网络安全行业的技术创新领导厂商，由一批知名网络安全技术骨干于2007年创立，并以首批网络安全企业的身份，于2019年9月登陆科创板（股票简称：山石网科，股票代码：688030）。
现阶段，山石网科掌握30项自主研发核心技术，申请540多项国内外专利。山石网科于2019年起，积极布局信创领域，致力于推动国内信息技术创新，并于2021年正式启动安全芯片战略。2023年进行自研ASIC安全芯片的技术研发，旨在通过自主创新，为用户提供更高效、更安全的网络安全保障。目前，山石网科已形成了具备“全息、量化、智能、协同”四大技术特点的涉及边界安全、云安全、数据安全、业务安全、内网安全、智能安全运营、安全服务、安全运维等八大类产品服务，50余个行业和场景的完整解决方案。