LLM Decoding iOS Location Data: An Unreliable Analyst, but a Useful Toolmaker

When AI Meets Reverse Engineering: A Tempting Idea

Data communication between mobile apps and system services mostly uses compact binary formats like Protobuf. To figure out exactly what an iPhone sends to Apple's location services, you have to reverse-engineer the schema of that data. This work has a high technical barrier and is time-consuming, so researchers naturally wondered: can we get a large language model to help?

A study on this problem gave a rather nuanced answer. The researchers chose the Protobuf messages exchanged between the iPhone and Apple's location services as their object of analysis, using two frontier models—Claude Opus 4.8 and Codex GPT Sol 5.6—to reconstruct these Protobuf schemas directly from Apple's binary files.

Protobuf (Protocol Buffers) is a language-neutral, platform-independent structured data serialization format designed by Google. Unlike text formats such as JSON or XML, Protobuf encodes data into a compact binary byte stream: field names are not transmitted along with the data. Instead, the sender and receiver each hold a .proto schema definition and map fields via field numbers and wire types. This design significantly reduces size and improves encoding/decoding speed, so it is widely used in mobile apps, gRPC communication, and inter-service communication in systems.

The trade-off is that without a schema, you cannot interpret the binary content—the received byte stream only contains field numbers and values, not field names or type information. For reverse engineers, this means they must first recover the schema from executable files, library files, or traffic before they can know whether a given field is a timestamp, a latitude/longitude, or a device identifier. Schema recovery therefore becomes a prerequisite step for privacy auditing and forensic analysis, and it is also the core problem this study aims to solve.

Letting the LLM Analyze Directly: Most Schemas Contain Hard-to-Spot Errors

The experimental results were not encouraging. The study points out that the vast majority of schemas generated by both models contain substantive errors. More troublesome, these errors are extremely hard to detect—because the schemas output by the models are internally logically consistent, they look airtight and do not expose flaws through self-contradiction.

This is a red flag for forensic analysis and privacy auditing. In such scenarios, a schema that "looks right but is actually wrong" can lead to misinterpretation of what the data means, which in turn undermines the reliability of conclusions. The researchers' conclusion is blunt: using AI directly as an analyst is not suitable for forensics and privacy analysis.

The root of the problem is that reverse engineering is fundamentally a task that requires repeated comparison and verification against real binaries and real network traffic. The training objective of language models makes them good at generating "plausible" structures, but "plausible" and "correct" are often two different things in reverse-engineering scenarios.

Hallucination in language models refers to the model generating content that seems plausible but is factually wrong. In natural language scenarios, hallucination often manifests as fabricated facts, citations, or events; in the context of structured artifacts (such as code, schemas, and configuration files), hallucination takes a more insidious form—structurally self-consistent but incorrect.

The reason is that the model's training objective is to minimize the prediction error of the next token, that is, to maximize the "likelihood plausibility" of the output, rather than to guarantee a true correspondence with the external world. When a model is asked to generate a Protobuf schema, it tends to produce results with standardized field naming, coordinated type combinations, and clear hierarchical structure, because these patterns appear repeatedly in the training corpus. But the true meaning of fields, the assignment of numbers, and the nesting relationships in the real binary are things the model cannot verify—it can only "make a reasonable guess." The result is that incorrect field names, mismatched types, missing or fabricated fields may all be present, while the schema itself reads flawlessly. This is the fundamental reason why the "self-consistent errors" in this study are hard to detect by manual review.

A Different Usage: Let AI Build Tools, Not Act as an Analyst

The turning point of the study came from switching the approach. Since AI is unreliable when giving answers directly, can we have it write a tool that can give reliable answers?

The researchers used Claude to write a Python tool called Extractor, whose function is to reliably recover Protobuf schemas from Apple's binary files. The key is that this tool's output can be verified—if the schema extracted by the tool is wrong, it can be discovered and corrected through comparison, unlike the "self-consistent errors" directly output by the model, which are hard to falsify.

This reveals a more general principle: when AI's output can be verified, it can write reliable tools; when the output cannot be verified, it becomes a confident error-making machine.

Verifiability is a key dimension for judging whether AI output can be trusted. Whether an output is verifiable depends on whether it can be compared against real-world signals independent of the model. In the context of this article, the reason a schema directly generated by the model is dangerous is that it can only be judged by "whether it reads correctly," and that is exactly the ability the model is best at imitating; the reason the schema generated by Extractor is usable is that it can be run against real binaries and real network traffic, and tested by whether parsing succeeds and whether field values match physical meaning.

This line of thinking is in the same vein as test-driven development and formal verification in software engineering: do not trust the generation process, only trust the verification result. For AI-assisted security and privacy work, this means prioritizing tasks that can produce "falsifiable artifacts" rather than tasks that directly produce conclusions. Tools, scripts, parsers, and test cases belong to the former, while analysis reports, risk ratings, and intent judgments belong to the latter.

Triple Verification: Where Does Extractor's Reliability Come From?

To confirm that Extractor really works, the researchers designed verification along three dimensions:

• Binaries with known answers: using binaries with already clear schemas as a test benchmark to check whether the tool can recover the correct answer;
• Published schemas: comparing against Protobuf schemas that have been made public in academic literature;
• Network measurement data: combining actual captured network traffic to verify whether the schema recovered by the tool can correctly parse real data.

With these three layers of verification, Extractor's reliability has a solid basis, rather than remaining at the level of "it looks fine."

Live Demonstration: Decoding Location Traffic from a Jailbroken iPhone 8

At the end, the study demonstrated a practical application of Extractor: decoding and analyzing the location services network traffic of a jailbroken iPhone 8 (running iOS 16.7.11).

This demonstration is symbolic in itself—it shows that with AI assistance, reverse-engineering work that originally required a large amount of skilled human labor can be greatly accelerated while ensuring reliability. The premise is that AI plays the role of "toolmaker," not "final judge."

Implications for AI-Assisted Reverse Engineering

This study provides a clear framework for how to view AI's role in security and privacy analysis.

The self-consistency of AI-generated content is a double-edged sword: it makes the output look credible, but it also masks errors. In fields such as reverse engineering, security auditing, and privacy forensics—where accuracy requirements are extremely high and verification costs are high—treating the model directly as an authoritative source of analysis is dangerous.

On the other hand, having AI write tools with self-checking mechanisms is a pragmatic path. The output of tools can be tested, compared, and falsified, and errors will be exposed during verification. This division of labor—"AI builds tools, tools produce conclusions"—both leverages the model's ability in code generation and safeguards the bottom line of accuracy through verifiability.

For teams engaged in mobile security, privacy research, and reverse engineering, this may be a work paradigm worth adopting: use AI in steps that can be checked, rather than treating it as an unquestionable source of answers.

One-line Summary

LLMs directly reverse-engineering Protobuf schemas produce many hard-to-detect errors, but having them write verifiable tools is reliable.

Paragraph Summary

The study took Protobuf messages between the iPhone and Apple's location services as its object and tested the ability of Claude Opus 4.8 and Codex GPT Sol 5.6 to reconstruct schemas directly from Apple's binary files. The results showed that the vast majority of schemas generated by both models contained substantive errors, and because they were internally self-consistent they were extremely hard to detect, making them unsuitable for direct use in forensics and privacy analysis. The study then turned to having Claude write a Python tool called Extractor to reliably recover schemas from binaries, and verified its reliability through triple validation: binaries with known answers, published schemas, and network measurement data. Finally, the tool was used to decode the location services traffic of a jailbroken iPhone 8 (iOS 16.7.11), proving that the division of labor in which "AI builds tools and tools produce conclusions" can both accelerate reverse engineering and safeguard the bottom line of accuracy through verifiability.