LLM解码iOS定位数据：不可靠的分析师，却是好用的工具制造商

当AI遇上逆向工程：一个诱人的想法

移动应用与系统服务之间的数据通信，大多采用 Protobuf 这类紧凑的二进制格式。想搞清楚 iPhone 到底向 Apple 的定位服务发送了什么，就必须逆向这些数据的结构定义（schema）。这项工作技术门槛高、耗时漫长，因此研究者很自然地想到：能不能让大语言模型来帮忙？

一项针对该问题的研究给出了一个相当微妙的答案。研究者选取了 iPhone 与 Apple 定位服务之间的 Protobuf 消息作为分析对象，使用两个前沿模型——Claude Opus 4.8 和 Codex GPT Sol 5.6——直接从 Apple 的二进制文件中重建这些 Protobuf 的 schema。

Protobuf（Protocol Buffers） 是 Google 设计的一种语言中立、平台无关的结构化数据序列化格式。与 JSON 或 XML 这类文本格式不同，Protobuf 将数据编码为紧凑的二进制字节流：字段名不随数据一起传输，而是由发送方和接收方各自持有一份 .proto 结构定义（schema），通过字段编号（field number）和线类型（wire type）来对应。这种设计显著减小了体积并提升了编解码速度，因此在移动应用、gRPC 通信和系统服务间通信中被广泛采用。

代价在于，没有 schema 就无法解读二进制内容——接收到的字节流只包含字段编号和值，不包含字段名称和类型信息。对于逆向工程者而言，这意味着必须先从可执行文件、库文件或流量中恢复出 schema，才能知道某个字段究竟是时间戳、经纬度还是设备标识符。schema 恢复因此成为隐私审计和取证分析的前置步骤，也是本项研究要解决的核心问题。

直接让LLM分析：大部分schema藏着难发现的错误

实验结果并不乐观。研究指出，两个模型生成的绝大多数 schema 都包含实质性错误。更麻烦的是，这些错误极难被察觉——因为模型输出的 schema 内部逻辑自洽，看起来严丝合缝，不会因为自相矛盾而暴露破绽。

这对于取证分析和隐私审计来说是一个危险信号。在这类场景下，一个"看起来对但其实错"的 schema 可能导致对数据含义的误判，进而影响结论的可靠性。研究者的结论很直接：直接将 AI 作为分析师，不适合用于取证和隐私分析。

问题的根源在于，逆向工程本质上是一个需要与真实二进制、真实网络流量反复比对验证的任务。语言模型的训练目标让它善于生成"合理的"结构，但"合理"和"正确"在逆向场景中往往是两回事。

幻觉（hallucination） 在语言模型中指模型生成看似合理但事实错误的内容。在自然语言场景中，幻觉往往表现为编造的事实、引文或事件；而在结构化工件（如代码、schema、配置文件）的场景中，幻觉会呈现出一种更隐蔽的形态——结构自洽但不正确。

原因在于，模型的训练目标是最小化下一个 token 的预测误差，即最大化输出的“似然合理性”，而非保证与外部世界的真实对应关系。当模型被要求生成一个 Protobuf schema 时，它会倾向于产出字段命名规范、类型搭配协调、层级结构清晰的结果，因为这些模式在训练语料中反复出现。但真实二进制中字段的真实含义、编号分配和嵌套关系，模型无从验证，只能“猜得合理”。结果是：错误的字段名、错配的类型、遗漏或虚构的字段都可能存在，而 schema 本身读起来毫无破绽。这就是本研究中“自洽错误”难以被人工审查发现的根本原因。

换一个用法：让AI造工具，而不是当分析师

研究的转折点出现在思路的切换上。既然 AI 直接给答案不靠谱，那能不能让它去写一个能给出可靠答案的工具？

研究者用 Claude 编写了一个名为 Extractor 的 Python 工具，它的功能是从 Apple 的二进制文件中可靠地恢复 Protobuf schema。关键在于，这个工具的产出是可以被验证的——如果工具提取的 schema 有误，可以通过比对来发现并纠正，而不像模型直接输出的"自洽错误"那样难以证伪。

这揭示了一个更普适的原则：当 AI 的输出可以被验证时，它就能写出可靠的工具；当输出无法验证时，它就变成了一台自信的错误制造机。

可验证性（verifiability） 是判断 AI 输出可否被信任的关键维度。一个输出是否可验证，取决于它能否与独立于模型的真实世界信号进行比对。在本文的语境中，模型直接生成的 schema 之所以危险，是因为它只能通过“读起来对不对”来判断，而这恰恰是模型最擅长模仿的能力；而 Extractor 生成的 schema 之所以可用，是因为它可以被放到真实二进制、真实网络流量上运行，用解析成功与否、字段值是否符合物理意义来检验。

这一思路与软件工程中的测试驱动开发和形式化验证一脉相承：不信任生成过程，只信任验证结果。对 AI 辅助的安全与隐私工作而言，这意味着应当优先选择那些能产出“可被证伪的工件”的任务，而非直接产出结论的任务。工具、脚本、解析器、测试用例属于前者，而分析报告、风险评级、意图判断属于后者。

三重验证：Extractor的可靠性从何而来

为了确认 Extractor 真的管用，研究者设计了三个维度的验证：

• 已知答案的二进制文件：用已有明确 schema 的二进制作为测试基准，检验工具能否还原出正确答案；
• 已发表的 schema：与学术文献中公开过的 Protobuf schema 进行比对；
• 网络测量数据：结合实际抓取到的网络流量，验证工具恢复的 schema 能否正确解析真实数据。

三重验证叠加，让 Extractor 的可靠性有了扎实的依据，而不是停留在"看起来没问题"的层面。

实战演示：解码越狱iPhone 8的定位流量

研究最后展示了 Extractor 的实际应用：对一台越狱的 iPhone 8（运行 iOS 16.7.11）的定位服务网络流量进行解码与分析。

这个演示本身具有象征意义——它说明在 AI 辅助下，原本需要大量熟练人力的逆向分析工作，可以在保证可靠性的前提下被大幅加速。前提是 AI 扮演的是"工具制造者"的角色，而不是"最终裁判"。

对AI辅助逆向工程的启示

这项研究为如何看待 AI 在安全与隐私分析中的角色提供了一个清晰的框架。

AI 生成内容的自洽性是一把双刃剑：它让输出读起来可信，却也掩盖了错误。在逆向工程、安全审计、隐私取证这类对准确性要求极高、且验证成本高昂的领域，直接把模型当作权威分析源是危险的。

但另一方面，让 AI 去编写带有自校验机制的工具，则是一种务实的路径。工具的产出可以被测试、被比对、被证伪，错误会在验证环节暴露。这种"AI 造工具、工具出结论"的分工，既利用了模型在代码生成上的能力，又通过可验证性守住了准确性的底线。

对于从事移动安全、隐私研究和逆向工程的团队来说，这或许是一个值得采纳的工作范式：把 AI 用在可以被检验的环节，而不是把它当作不可质疑的答案来源。