---
id: "mb-20261106-e2db20"
kind: "deep"
title: "一张假动图与七万条解压指令：飞马软件如何在苹果系统里手搓微型CPU"
description: "飞马间谍软件通过 iMessage 发送伪装成动图的 PDF 文件，绕过沙箱并利用 CoreGraphics 中古老的 JBIG2 图像解压漏洞。攻击者通过七万多条图像片段指令构建虚拟寄存器、加法器和比较器，在单次图像解析中运行代码接管设备。本文深入拆解这套史上最复杂的零点击入侵机制。"
domain: "software"
domain_label: "软件与工程"
canonical_url: "https://mubeitech.com/deep/mb-20261106-e2db20"
markdown_url: "https://mubeitech.com/deep/mb-20261106-e2db20/markdown"
json_url: "https://mubeitech.com/api/interpretations/mb-20261106-e2db20"
topic: "一张假动图与七万条解压指令：飞马软件如何在苹果系统里手搓微型CPU"
source_type: "generated"
status: "published"
generated_at: "2026-11-06 07:13:14"
frame_type: ["机制"]
legal_anchor_count: 0
transcript_citation_count: 0
---

# 一张假动图与七万条解压指令：飞马软件如何在苹果系统里手搓微型CPU

手机连震动都没震一下，屏幕也没亮，黑客是怎么黑进一台 iPhone 的？
这就是几年前轰动网络安全界的飞马（Pegasus）间谍软件。
在以往的认知里，黑客想黑进一部手机，总得诱导你点个钓鱼链接，或者下载一个带毒的安装包。
但飞马软件用的是零点击攻击。
你什么都不用点，手机甚至还安安静静躺在口袋里，攻击就已经结束了。
后来谷歌零日计划（Google Project Zero）的安全研究员复盘整个攻击过程，看到了计算机漏洞史上最不可思议的一幕：
为了攻破苹果严密的防御体系，黑客仅仅靠一张伪装的动图，在苹果系统的解压引擎里，纯手工拼出了一台微型 CPU。

这套代号为 FORCEDENTRY 的攻击，入口选在了苹果自带的即时通讯软件 iMessage。
很多人不知道，iMessage 有个贴心功能：
当你收到一张图片或者动图时，系统会在后台自动帮你解析并渲染缩略图。
苹果为了防止恶意文件利用这个环节做坏事，专门给 iMessage 搭建了一座隔离沙箱，名字叫 BlastDoor。
所有进来的图片，按理说都要先关在沙箱里跑一遍，就算崩溃也伤不到主系统。
但黑客想了一个非常刁钻的招数。
他们把一个 PDF 文件改了后缀名，伪装成了一张看起来人畜无害的 GIF 动图发了过去。
苹果系统的图片转换进程收到文件后，先扫了一下文件头部的真实格式特征。
系统发现：这根本不是 GIF。这是一个伪装的 PDF 文件。
苹果的代码逻辑在这里出了一个致命疏漏。
系统没有把它当成异常文件扔掉，直接把它从沙箱转交给了底层的图形引擎 CoreGraphics 去处理。
防线就这么被绕开了。

进入图形引擎后，黑客激活了一段埋藏了二十多年的远古代码：JBIG2。
这是上世纪九十年代末推出的一种黑白图像压缩标准。
那时候网络带宽极小，传一份扫描文档或者传真文件都很费劲。
JBIG2 为了极致压缩黑白文字，想了一个聪明的办法：
一页英文文档里，字母 e 和字母 a 会反复出现千百次。
解压引擎不需要把每个像素都存下来，它只需要把这些字母提取成字形字典。
渲染页面的时候，引擎把字典里的字形拿出来，用逻辑运算贴到画布上。
谁能想到，一台二十多年前用来压缩传真机文件的陈旧模块，在 2021 年的顶配 iPhone 里依然默默运行着。
更要命的是，苹果这套 JBIG2 的解析代码里，存在一个整数溢出漏洞。
黑客精心构造了几个异常尺寸参数，让系统在内存里申请了一块过小的缓冲区。
接下来，解压引擎往里写数据的时候直接冲出了边界，造成了内存越界写入。

换作二十年前，黑客只要能冲破内存边界，直接往内存里塞一段二进制代码，让程序跳转过去执行就行了。
但在现代智能手机上，这条路早就被彻底堵死了。
苹果在 iOS 里筑起了多道硬件和系统级的铜墙铁壁：
内存地址随机化让所有程序的存放位置随机打乱，黑客根本不知道自己的数据被存放在哪里；
数据执行保护规定能写数据的内存绝对不能执行代码；
最新的芯片还给关键指针加上了加密签名。
更绝望的是：JBIG2 只是一个解压黑白图片的格式，它根本不是编程语言。
它没有脚本引擎，没有变量，没有循环，也没有条件判断语句。
你手里只有一个只会解压像素的古老引擎，以及一段乱掉的内存。
在两眼一抹黑的内存迷宫里，怎么可能去执行攻击代码？

开发飞马软件的以色列 NSO 集团，在这里拿出了堪称妖孽级别的工程脑洞。
他们退回到了计算机硬件的最底层原理：
任何现代芯片，不管架构多复杂，底层都是由与门、或门、异或门这些逻辑门搭建起来的。
只要有逻辑门，就能拼出寄存器；
能拼出寄存器，就能组合出能做算术的加法器，以及能判断大小的比较器；
有了加法器和比较器，就能实现数学运算、条件分支和代码循环。
那么，JBIG2 解压引擎在干什么呢？
当它把字形字典渲染到画布上时，执行的刚好是与、或、异或这些位运算。
攻击者在那个伪装文件里，一口气塞进了整整七万多个 JBIG2 片段指令。
这七万多个指令在解压引擎内部相互咬合，每一个指令都把前一个指令的输出作为输入。
他们硬生生用图片解压的数学指令，在苹果的内存里模拟出了一套完整的逻辑电路。
一套拥有虚拟寄存器、64 位加法器和比较器的微型计算机体系，就这么在图像解压的过程中凭空运转了起来。

这台微型 CPU 启动之后，开始在受害者的 iPhone 内存里执行真正的攻击程序。
它像一台微型雷达，用 64 位加法器不断计算偏移量，在内存里循环搜索关键数据结构。
它找到了关键对象的内存指针，绕过了内存随机化保护，随后一步步修改系统权限，为最终的间谍软件铺平道路。
整个过程全发生在一个单次图像解压的动作里。
受害者没有收到任何来电，屏幕没有亮起，手机甚至没有发出半点提示音。
在手机决定要不要弹出通知之前，设备就已经被完全接管了。

直到 2021 年下半年，公民实验室（Citizen Lab）在一位活动人士的手机里提取到了异常样本，并将数据共享给苹果和谷歌。
谷歌零日计划的两位资深研究员伊恩·比尔（Ian Beer）和萨穆埃尔·格罗斯（Samuel Groß）花了几个星期逆向分析这七万多个指令，确认这是业内见过的工程复杂度最高的攻击样本之一。
苹果随后在 2021 年 9 月紧急发布了 iOS 14.8 更新，修复了这个编号为 CVE-2021-30860 的漏洞，并彻底重构了相关解析流程。
这也让人看清了一个极其魔幻的软件工程现实：
我们每天揣在兜里、算力堪比超级电脑的现代 iPhone，底层一直跑着几十年前给传真机用的老模块。
撕开最坚固防线的，往往不是什么未知的黑科技，恰恰是二十多年前写在传真机标准里的一行老代码。

_Canonical: <https://mubeitech.com/deep/mb-20261106-e2db20> · Source: 墓碑科技 MUBEITECH (mubeitech.com)_
_Rendered by mubei-terminal._