iPhone手机加密钱包里的钱也可能被盗， 未来我们该如何防范

一直以来我们对iPhone的安全都很认可：

只要我不越狱、不乱装 App、我的iPhone就是安全的。

过去，这个判断大体没错。

但最近曝光的一类iOS攻击，感觉事情变得麻烦了。

一个被攻击者注入恶意代码的App，甚至一个恶意的网页，就可能让你的手机被攻击。

更值得警惕的是，这种原本用于国家之间间谍行为的技术，现在已经被“下放“到偷窃加密货币行为中：进入设备、快速拿走高价值数据，然后尽可能减少痕迹。

那么，它究竟是怎么做到的？

一、先理解iPhone最重要的一堵墙：沙盒

正常情况下，iPhone上的每个App都像住在一间独立的房子里。

微信住微信的房间，支付宝住支付宝的房间，钱包App也有自己的房间；苹果把大家都锁在自己的房间里，不允许互相串门。

这些房间叫做：Sandbox，沙盒。

简单理解就是：

各个App在自己的沙盒里管好自己的东西，不能跑到别的App的沙盒里乱看。

因此，即使你打开了一个恶意的App（或者网页），正常情况下，这个这个App（或者网页）能够活动的范围也应该被限制在自己的“小房间”里。

理论上它不能说：“我去看看你的钱包App里面存了什么。”

这正是 iOS 安全体系的重要基础。

问题来了：

如果攻击者能够从这个房间里跑出去呢？

这就是所谓的Sandbox Escape——沙盒逃逸。

二、这次攻击不是一个漏洞，而是一串漏洞接力

这里也是网上最容易被误解的地方。

有人把它简单描述成：

JavaScript可以直接拿到手机的root权限。

这样说不完全对。

事实是，攻击者把多个漏洞像多米诺骨牌一样串了起来。

Google Threat Intelligence Group披露的这套攻击链被称为DarkSword，一共涉及6个漏洞，覆盖WebKit/JavaScriptCore、GPU/媒体相关组件、动态链接机制以及XNU内核等多个层面。

我们以DarkSword描述的网页攻击为例，跳出复杂的技术逻辑，可以把整个过程抽象成这样：

第一步：骗门卫开门。

你在Safari打开恶意网页，网页中的代码利用浏览器漏洞，在原本不应该拥有的环境中执行代码。

第二步：逃出房间。

攻击者继续利用漏洞突破Safari的沙盒。

本来只能待在浏览器里的代码，现在开始突破iOS给它划定的边界。

第三步：拿到大楼的高级权限。

攻击链进一步攻击系统底层，最终获得非常强的内核级能力。

到了这里，问题已经不再只是：Safari 被黑了。

而是：iOS原本用来隔离不同App的安全边界被突破。

第四步：开始翻东西。

攻击者可以寻找设备上的高价值数据。

这其中当然包括：加密钱包。

这也是为什么这次事件会在币圈引起这么大的关注。

所以把整个体系理解成三层会比较准确：

• 入口漏洞解决“我怎么进去”；
• 沙盒逃逸解决“我怎么离开自己的房间”；
• 提权/内核漏洞解决“我怎么拿到整栋楼的万能钥匙”。

而“钱包 App 本地密钥被读走”，其实已经是攻击链后半段的结果，不是最初那个漏洞本身。

有同学会问了，我常用的是Chrome，也受影响吗？

这个问题很好。

之前的攻击针对的是Safari，Chrome不受影响。 Google GTIG甚至观察到：当受害者用Chrome打开恶意页面时，攻击代码会尝试通过 x-safari-https把页面重新拉到 Safari 里。Google据此判断，当时这批攻击者并没有针对Chrome的对应 exploit chain。

但这里有一个很重要的点：iPhone上的 Chrome、Edge、Firefox底层网页渲染引擎实际上都受苹果限制，主要使用WebKit。所以不能简单理解成“Chrome就天然不受 WebKit 漏洞影响”。

要分两层看：

第一层：具体DarkSword攻击。

它利用的是JavaScriptCore/WebKit/Safari相关漏洞，而且整条利用链对Safari的进程结构和沙盒进行了针对性设计，比如WebContent → GPU process → mediaplaybackd。因此它不是“任何使用WebKit的浏览器把同一个JS打开就一定能成功”。

第二层：Chrome有没有可能被类似攻击。

当然能。Chrome自己也可能存在漏洞，而且即使共享部分系统组件，攻击者也可以专门构造针对Chrome进程环境的利用链。但这需要重新适配，并不是把Safari的exploit原封不动扔进Chrome就一定有效。

不过还有一个现在越来越重要的例外：苹果已经允许部分地区的浏览器使用非 WebKit引擎。例如欧盟，符合条件的浏览器可以申请使用自己的替代浏览器引擎。

所以一句话回答上面的问题：这次已披露的攻击主要瞄准Safari，用 Chrome打开同一个恶意网址，不保证这条攻击链能成功；事实上，研究人员发现攻击者还会特意把Chrome用户重新导向Safari。但这并不代表 Chrome永远安全——浏览器只是攻击入口，真正决定风险的是具体漏洞、浏览器引擎、iOS 版本和整条提权链是否匹配。

那打开一个恶意的App，手机是怎么被攻破的？

正常情况下，一个App即使装在手机上，也只能访问自己的沙盒目录，以及系统明确授权给它的数据。所谓“App 漏洞”，通常不是指“这个App天生就能拿root”，而是App里某个组件存在内存安全、解析、IPC 或权限校验问题，让攻击者先获得 App 进程内执行代码的能力。

例如，一个恶意或被攻陷的App可以通过这些入口开始攻击：

解析恶意图片、视频、PDF、字体、压缩包或网络数据时触发漏洞；使用 WebView/JavaScriptCore时触发内存漏洞；调用系统 XPC/IPC 服务时利用参数校验缺陷；或者利用系统驱动、GPU、内核组件中的漏洞。

之后的逻辑和网页入口其实很像：

App内执行代码 → 突破App Sandbox → 利用系统漏洞获得更高权限 → 访问其他 App 本来隔离的数据。

举个更直观的例子。假设某个聊天App有一个图片解析漏洞。攻击者发给你一张特制图片，App 打开图片时，解析器发生内存破坏。攻击者因此获得了这个聊天 App 进程里的代码执行能力。

这时他仍然只是：“控制了聊天App这个房间”，还不能直接去钱包App的房间。

所以还需要第二个漏洞，比如沙盒逃逸或系统服务漏洞，让它从这个App 的沙盒出去；再利用内核漏洞获得更高权限。

完整链变成：恶意图片 → App RCE → sandbox escape → kernel exploit → 跨App读取 → 钱包数据。

和Safari的区别主要只是第一扇门不同。

Safari场景通常是：网页/JavaScript → WebKit漏洞。

App场景则是：图片/文件/网络包/消息 → App或系统框架漏洞，比如

• 内核漏洞：App调用系统接口时，触发XNU内核里的use-after-free、race condition、整数溢出、越界访问等问题，从普通App权限升级到 kernel read/write。
• 系统服务漏洞：App可以通过XPC/Mach IPC调用很多系统服务。如果某个高权限服务错误处理了App传入的数据，就可能被App利用，从低权限进程跳到高权限进程。
• 权限校验错误：某个daemon本来应该检查“这个App有没有资格做这件事”，结果检查不严，App就可能直接获得不该有的文件、Keychain或系统能力。
• 驱动/GPU/媒体漏洞：App本身也能合法调用GPU、视频解码、图片解析、字体等系统组件。如果这些组件存在内存漏洞，也可以成为提权入口。

三、为什么攻击者拿到一个“钱包文件”，币就可能危险了？

最后一个问题：

我的钱包有密码啊。就算黑客拿到了文件，他也不知道我的密码，有什么用？

这就涉及一个非常重要的概念：

在线猜密码，和离线猜密码，是完全不同的两回事。

举个简单例子。

假设你的手机银行输错 5 次密码就锁定。

攻击者想猜你的密码：

• 123456？错。
• 生日？错。
• 手机号？错。

猜不了几次，系统就不让试了。、

这叫在线攻击。

但是，如果某个钱包把一个经过密码保护的加密数据文件保存在本地，而攻击者成功把这个文件完整复制走，情况就可能发生变化。

因为文件已经到了攻击者自己的电脑里。

你的手机已经管不到它了。

攻击者可以使用自己的计算资源进行大量尝试：

• 12345678  
• 姓名+生日  
• 手机号  
• 常用密码  
• 历史泄露密码  
• 各种字典组合……

这就是所谓的：

Offline Brute Force——离线暴力破解。

当然，拿到加密文件 ≠ 一定能够破解私钥。

最终能不能破解，取决于钱包具体采用什么密钥保存方式、KDF强度、密码复杂度、Keychain/Secure Enclave的使用方式等。

如果钱包的密钥保护设计得足够好，同时用户使用的是高强度密码，离线破解成本可能极高。

反过来，如果用户使用的是很短、很常见、可预测的密码，那么攻击者一旦拿到了能够离线验证密码的数据，风险就会明显上升。

四、更麻烦的是：攻击者未必需要“破解”

这也是这次事件中比“偷文件然后爆破”更加值得注意的地方。

近期安全团队对相关攻击代码的分析显示，攻击模块不仅可以搜索App container和App Groups中的文件，还能够针对iOS的Keychain数据，并且出现了针对键盘输入的监控能力。

公开分析中特别提到了imToken、TokenPocket、TronLink等钱包在前台运行时的输入捕获逻辑。

这意味着攻击思路可能不只有：

偷走加密钱包文件 → 回去慢慢破解。

还可能包括：读取敏感数据、寻找 Keychain 凭据，甚至等待用户自己输入重要信息。

这就像一个小偷发现保险柜打不开。

他有两个办法。

第一个办法：

把保险柜整个搬走，回家慢慢撬。

第二个办法：

躲在旁边，看主人下一次自己输入密码。

有时候后者反而更危险。

五、最反常识的一点：你可能什么都没有“安装”

过去我们教育普通用户防病毒，经常会说：

• “不要安装陌生 App。”
• “不要安装来历不明的描述文件。”
• “不要给陌生App权限。”

这些建议当然仍然正确。

但这次攻击最可怕的地方在于：

攻击入口除了App外，还可以网页。

 六、那是不是说明“iPhone已经不安全了”？

也不是。

任何复杂操作系统都不存在绝对安全。

苹果设计了很多层保护：

浏览器沙盒是一层；

App Sandbox 是一层；

Keychain 是一层；

Data Protection 是一层；

系统内核又是一层。

正常情况下，攻击者突破其中一层，后面还有其他防线。

DarkSword厉害的地方是，攻击者找到了多个漏洞，并把它们组合起来：

第一扇门开了，再打开第二扇门，再突破第三扇门。最后形成了一条完整攻击链。

Google的调查显示，DarkSword至少从2025年11月开始就已经被多个攻击者使用，攻击目标涉及沙特、土耳其、马来西亚和乌克兰等地区；其中部分漏洞在被实际利用时还是苹果尚未修复的0-day。

但是最近，“原本这种非常高级的iPhone攻击能力，正在出现扩散”，这也是为什么我们最近才关注到这件事。

我们再梳理一下时间线：

• 2025年末：攻击者掌握DarkSword，其中多个漏洞属于真正的0-day。
• 2026年初：Apple陆续修复。
• 2026年3月：Google GTIG、Lookout等公开披露DarkSword。Google表示全部相关漏洞最终都已经在iOS 26.3中得到修复。
• 2026年9月（本月）：SlowMist等发现攻击者又把这套东西拿出来，针对仍运行iOS 18.4～18.6.2的设备投放，并把重点转向加密钱包资产。

所以对于我们这些普通用户：请把iPhone更新到设备能够安装的最新正式版iOS。

尤其是手机里装有加密钱包、交易所、银行App，并且存放较大资产的人，不要为了所谓的“续航”“旧版本更流畅”长期停留在旧系统。

此外，不要在装有大额热钱包的手机上随意打开陌生链接；钱包密码不要使用生日、手机号、简单数字或者其他已经在互联网泄露过的密码；大额长期资产也不应该全部依赖一部日常浏览网页、收邮件、点社交媒体链接的手机。

最后：我们的安全假设，需要改变了

过去很多人的安全模型是：

我没有泄露助记词，所以我的币就是安全的。

现在应该升级成：

保护助记词只是最后一道防线，运行钱包的设备本身同样是安全边界。

一个加密钱包可以有非常漂亮的密码学设计，但钱包最终还是运行在手机操作系统之上。

如果攻击者能够从一个App/网页开始，突破权限、逃出沙盒，再一路进入系统更深层，那么问题就已经从

“钱包密码够不够复杂？”

变成了：

“你还相信这台设备吗？”

不要因为听到iPhone被攻破就陷入恐慌，也不要迷信苹果绝对安全。

安全真正依靠的从来不是一道永远不会倒的墙，而是很多道墙，以及——

在其中一堵墙出现裂缝以后，尽快把它补上。

Tag：iPhone   加密钱包