文章总结： FBI从已删除Signal的iPhone中通过苹果内部通知存储恢复出已接收的阅后即焚消息，这并非加密协议被攻破，而是iOS系统级通知数据库（如knowledgec.db或duetexpertcenter）缓存通知内容所致。该取证需物理控制设备且依赖设备解锁状态，用户可通过关闭Signal通知预览提升安全性。 综合评分： 85 文章分类： 数字取证,移动安全,应用安全,终端安全,隐私保护

FBI 从已删除 Signal 的 iPhone 里恢复出消息

原创

独眼情报 独眼情报

独眼情报

2026年4月10日 12:07 湖北

长话短说

2026 年 4 月 9 日,媒体报道 FBI 在 Prairieland ICE 拘留中心案的法庭证据中,披露了一种针对 iPhone 的取证细节:FBI 从被告 Lynette Sharp 的 iPhone 上恢复出了 Signal 收到的消息内容,即使 Signal 已经从设备上被删除,而且其中部分消息原本是被设置为「阅后即焚」、在 Signal App 内已经消失的。法庭出示的 Exhibit 158 证物明确写到,这些消息是通过「Apple 的内部通知存储」恢复的,只能恢复收到的消息,发出的消息没有被捕获。

研判:从技术层面看,这并不是 iOS 出现了什么新的零日漏洞,也不是 Signal 的端到端加密被攻破。这是一条 DFIR(数字取证与事件响应)社区从 iOS 14、15 时代就反复讨论过的老路子——iOS 系统级的通知相关数据库(historically KnowledgeC.db、DuetExpertCenter 下的 userNotificationEvent 流、UserNotifications 目录下的 DeliveredNotifications.plist 等)出于「联合分析、活动还原」的目的,会缓存通知的内容预览,而这些数据库不属于 Signal 的沙盒,Signal 被删除时它们不会被一并清空。本案的特殊价值不在于揭示了新技术,而在于把一条原本只在取证圈和安全研究者之间流通的常识,第一次以联邦法庭证据的形式摆到了普通用户面前。

对用户的关键启示——只是装一个端到端加密的 IM,远远不等于通信内容在自己的手机上是安全的。「应用层安全」和「终端取证抗性」是两件事。Signal 早就提供了「不在通知里显示消息内容」的开关,绝大多数人没有打开。本案中如果 Sharp 把 Signal 通知内容设为「No Name or Content」,Exhibit 158 这条证据链大概率不会被取证。

一、关键事实:法庭披露了什么、没披露什么

把法庭和媒体披露的事实和模糊地带分开列出来。

| 维度 | 已披露 | 未披露 | | — | — | — | | 设备 | iPhone(具体型号未提) | iOS 版本、是否最新、设备状态 | | App 状态 | 取证时 Signal 已被删除 | 删除是在被捕之前还是之后、距取证多久 | | 消息方向 | 仅恢复了收到的消息 | 时间跨度、消息总条数、是否仅一对话 | | 消息状态 | 包括已设置为消失且确实在 Signal 里消失了的消息 | 阅后即焚的具体时长设置 | | 取证方法 | 来自「Apple 的内部通知存储」 | 具体工具(Cellebrite/GrayKey 等)、利用了哪条具体路径 | | 设备解锁状态 | 未说明 | BFU(首次解锁前)、AFU(首次解锁后)还是已解锁状态下取证 | | 用户设置 | 研判 :Signal 通知内容预览没有关 | 没有逐项确认设置截图 |

研判:这张表里缺的几项很重要,尤其是设备解锁状态和取证工具。这两项决定了这次取证是不是普通警察就能复现,还是只有 FBI 这种能用到 GrayKey、Cellebrite Premium 一类商用利用工具的机构才能复现。后面一节会展开这一点。

二、技术研判:「Apple 内部通知存储」到底是什么

这是整篇分析里最需要克制的一节——因为法庭语言「Apple’s internal notification storage」非常宽泛,几乎可以指 iOS 上若干条不同的取证路径中的任意一条。没有任何一手技术细节能让外界精确锁定 FBI 用的是哪条路径。9to5Mac 的报道里也明确承认了这一点:在缺少被告 iPhone 具体状态技术细节的情况下,无法精确判断 FBI 使用的恢复方法;iOS 设备可能处于 BFU、AFU 等多种系统状态,每一种都有不同的安全和数据访问约束;设备解锁后,系统假定用户在场,会允许访问更广范围的受保护数据。

但可以基于公开 DFIR 文献,把候选路径列出来,这本身对理解事件机理是必要的。

候选 1:KnowledgeC.db 的通知使用记录

这是 iOS 上一个很大的 SQLite 数据库,自 iOS 14 起就被取证社区研究,部分商用工具(如 Magnet AXIOM、ArtEx、APOLLO)能解析其中的 notification/usage 数据,但 Cellebrite Physical Analyzer 和 iLEAPP 历史上不解析。这条路径里能拿到「通知是什么时候收到的、用户是不是查看了通知、通知是不是被清除了」这一类信息。

候选 2:DuetExpertCenter 下的 userNotificationEvent 数据流

在 iOS 15 及之后,/mobile/Library/DuetExpertCenter/streams/userNotificationEvent/local 路径下保存了通知事件流,DFIR 研究者(Geraldine Blay 在 Magnet/DFRWS 的演讲)早就公开了如何解析这一区域。这是 iOS 系统为了「联合活动建议、Spotlight、Siri 智能预测」做的本地行为缓存——它本身是个 Biome 数据流文件,里面可以包含通知的标题和正文。

候选 3:UserNotifications 目录下的 DeliveredNotifications.plist

这是 iOS 12 时代就被记录的路径:/private/var/mobile/Library/UserNotifications/ 下,每个有通知权限的应用按 BundleID 列目录,目录里的 DeliveredNotifications.plist(NSKeyedArchiver 风格)能保留通知正文和时间戳。

候选 4:Biome 与文件系统事件流

取证厂商 MSAB 的工程师 Eric Arnoux 写过,Biome 数据文件被设计为 KnowledgeC 的更高效安全替代品,目的类似——记录大量应用与系统活动数据;这些数据通常嵌套在 plist 或 protobuf 中,需要全文件系统提取(FFS)才能拿到。也就是说,相关数据不能从普通 iCloud / iTunes 备份里直接捞出来,需要更深的提取等级。

研判:这条证据更可能出自 Biome / DuetExpertCenter 而不是简单的 plist

主要依据有三点:

1. Sharp 的 iPhone 是删过 Signal 的。Signal 的 BundleID 一旦被卸载,应用沙盒会被系统清掉——这是 iOS 的标准行为,MSAB 的文章也确认了这一点(删除应用时,沙盒数据会随之消失)。UserNotifications/<Signal-BundleID>/ 这个目录在 Signal 卸载之后,理论上也应该被清掉(因为它是按 BundleID 组织的)。如果这条路径仍然有效,说明 iOS 在卸载流程上对这一目录的清理并不彻底,或者这部分数据被预先索引到了系统级数据库中,卸载并不影响。
2. KnowledgeC.db、DuetExpertCenter 这一类系统活动追踪数据库,从设计上就是「长期、跨应用」的——它们把事件按时间序列写入,即使生成事件的应用消失了,事件本身的记录仍然保留。这恰好解释了「Signal 已经卸载,但收到的消息依然能取到」这种现象。
3. Exhibit 158 的描述用了「internal memory」「internal notification storage」这种系统级措辞,而不是 Signal 自家的数据库,语义更接近 KnowledgeC / Biome 这一类系统聚合层。

但这只是研判,不是结论。具体到底是哪一条路径,要等更详细的法庭技术证词或独立 DFIR 复现才能定。

为什么只有「收到的消息」被恢复

这一点反而是最容易解释的:只有收到的消息才会触发本机的本地通知。Sharp 自己发出去的消息,在 Signal 内部走端到端加密通道直接送达对端,不会在 Sharp 这台 iPhone 上以「通知」的形式呈现给系统。系统通知数据库本来就只可能记录到「这台设备从外面收到了什么」,不可能记录到「这台设备发出去了什么」。

这一不对称特征反过来成为本研判的有力佐证——如果 FBI 用的是另一条路径(比如某种 iCloud 协同层泄露、密钥导出、或 Signal 自身数据库残留),发出和收到的消息都会被恢复。只有「单向恢复」这一点,精确指向「数据来自系统通知层」。

三、Signal 的防御机制:开关一直在,只是没人开

Signal 内部其实一直给用户提供了对应的设置项:

Signal 在 Notifications 菜单下提供了三档 Notification Content 设置:Name, Content, and Actions(显示发送方与消息内容)、Name Only(只显示发送方)、No Name or Content(完全不显示)。

研判:Sharp 大概率把通知设为了第一档(显示发送方+消息内容),否则系统通知数据库里根本没有可被恢复的明文。这一推断是基于:

• Exhibit 158 描述说恢复的消息有「detailed messages」可以在法庭出示
• 只有第一档设置会让 iOS 拿到完整的明文消息内容
• 没有任何报道说 FBI 解密了 Signal 通知内的占位符

对应的防御逻辑链是:

Signal 收到消息
  ↓
Signal 调用 iOS 推送/本地通知 API,把要显示的内容交给系统
  ↓ ← 如果 Signal 设置为「No Name or Content」,这一步只交「You have a new message」之类占位符
  ↓
iOS 把通知交给 NotificationCenter 显示,并把事件记录入系统通知数据库
  ↓
取证人员从系统通知数据库恢复内容

关键节点是「交给系统」那一步。Signal 的端到端加密只保证消息从发送方到接收方设备的传输路径上是密文,一旦解密成明文进入接收方设备,Signal 怎么处理这份明文就是 Signal 的事。一旦它把明文交给系统通知 API,就相当于把这份明文从 Signal 的可控范围扔进了 iOS 的可控范围。iOS 之后做了什么——缓存、索引、写数据库——Signal 完全无能为力。

这就是「应用层安全」和「终端取证抗性」之间的根本断层。哪怕你用的是当今公认最严谨的 IM(Signal 的端到端加密协议至今没有被证伪),你的手机操作系统仍然有自己的逻辑、自己的缓存、自己的取证表面。这两套安全模型不在同一个层次上。

四、取证前置条件:物理控制权 + 设备状态

这一节是给一般读者校准恐慌等级用的——这种恢复不能远程做到。

先决条件 1:物理控制权。媒体报道明确强调,这里展示的是物理接触式取证(forensic extraction),不是通过法律命令拿走的远程数据;同样在 6 月,相关媒体也曾报道过 Apple 向政府交出了数千条推送通知的元数据,但那是另一码事——是法律命令。换句话说:

• 远端取证(法律命令、APNs 元数据交出):需要的是请求 Apple、Google 这一类「中转方」交数据
• 本案的本地取证:需要的是把你的实物手机拿到手

Sharp 的情况是后者。她作为合作证人交出了手机,FBI 才能跑取证工具。

先决条件 2:设备状态。iPhone 在 BFU(首次解锁前)、AFU(首次解锁后)以及完全解锁状态下,有非常不同的安全和数据访问边界;解锁状态下,系统会假定用户在场,允许访问更广范围的受保护数据。

这意味着,这次取证的实际门槛取决于 Sharp 交出手机时它处在哪个状态:

• 如果是已解锁交出 → 工具门槛非常低
• 如果是 AFU(解过一次锁但当前锁屏)→ 商用工具(Cellebrite Premium、GrayKey)能拿到大量受 Data Protection Class C/D 保护的数据
• 如果是 BFU(从来没解过锁)→ 难度最高,大量数据(包括很多系统数据库)处于密钥未派生状态,不可读

研判:本案大概率是 AFU 或更宽松的状态。理由是 Sharp 是合作证人,主动交出手机的概率很高,而合作交出的设备通常是「在使用中、可解锁、甚至直接解锁」的状态,而不是抓捕时关机后扣押的状态。这一点对其他读者的复现风险评估很重要——如果你的手机是被强制扣押而非自愿交出,且你有在被扣押前关机的纪律,所处的取证抗性会显著强于本案。

先决条件 3:取证工具。9to5Mac 推测,FBI 也可能是从设备备份里提取了相关信息;市面上有多款面向执法的商用工具利用 iOS 漏洞来提取此类数据。这指的就是 Cellebrite、GrayKey 这一类工具。这些工具的能力门槛非常高,价格通常是六位数美元起步,FBI、HSI、DEA 这一级别的联邦机构有,地方警察未必有。

五、这件事到底意味着什么:对几类读者的实际启示

对一般用户——你不需要换 IM。你需要做的是这两件事:

1. 打开 Signal → Settings → Notifications → Notification Content,选择 No Name or Content。在 WhatsApp、Telegram、Wire 等其他 IM 上做同样的事。这是一次性的、收益巨大的设置变更。
2. 理解一个心智模型:你的手机操作系统拥有比你的 IM 更高的特权。任何信任系统通知层的应用,都把一份明文交到了系统手里。系统怎么处理这份明文,应用本身控制不了。想要更高强度的保密,需要的是「不让明文出现在通知里」,而不是「指望应用更努力」。

对记者、活动人士、维权律师等高威胁模型用户——如果你的工作让你处于物理设备可能被合法或非法接触的风险中,以下几条是低成本但显著拉高门槛的:

• 关闭通知预览(以及锁屏 Siri、锁屏小组件、锁屏控制中心)
• 经常重启手机:重启后设备进入 BFU 状态,大量受 Data Protection Class A/B 保护的数据在再次解锁前不可读,这对取证工具是显著门槛
• 定期清理对话:Signal 的「消失消息」对 Signal 自己的数据库有效,但对系统通知层的缓存无效——所以更彻底的做法是,关闭通知预览的同时使用消失消息
• 不要假设删除应用就等于擦除痕迹:系统级的活动追踪数据库通常不在应用沙盒里

对取证从业者和安全研究者——本案的实际新意有限,但提供了一份可以拿出去给普通客户解释「为什么应用层加密不等于终端安全」的高质量案例素材。建议关注后续是否有更详细的法庭技术披露(尤其是 Wiethorn 探员的完整证词、Exhibit 158 的完整描述),以及是否有 DFIR 研究者在 iOS 26.x 上做出独立复现,精确锁定路径。

对策略层面——这件事让一个长期存在的紧张关系再次显形:「执法可见性」与「公民通信安全」之间的平衡,实际上被很多用户不知道的产品默认设置悄悄决定了。Signal 把通知预览的开关交给了用户,默认是「显示」(因为多数用户希望通知里有内容,这是 UX 取舍),但绝大多数用户不会意识到这个开关在威胁模型变化时会变成最大的破绽。这不是 Signal 一家的问题——端到端加密 IM 与移动 OS 通知系统之间,结构性地存在这个矛盾,而当下没有一种主流解决方案让二者都满意。

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：独眼情报 独眼情报 独眼情报《FBI 从已删除 Signal 的 iPhone 里恢复出消息》