图片
图片


苹果设备的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二进制文件:
frida-pull -U /System/Library/CoreServices/AssistiveTouch.app/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余个行业和场景的完整解决方案。
图片