pith. sign in

arxiv: 2604.23457 · v1 · submitted 2026-04-25 · 💻 cs.CR · cs.NI

ARIstoteles -- Dissecting Apple's Baseband Interface

Tobias Kr\"oll , Stephan Kleber , Frank Kargl , Matthias Hollick , Jiska Classen This is my paper

Pith reviewed 2026-05-08 07:47 UTC · model grok-4.3

classification 💻 cs.CR cs.NI
keywords appleiosbasebandarireverse engineeringfuzzingwiresharksecurity
0
0 comments X

The pith

Reverse engineering of Apple's undocumented ARI baseband interface reveals insufficient internal testing.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

This paper reverse-engineers the ARI protocol that lets user-space daemons on iOS talk to the wireless baseband chip through CommCenter. The authors write Ghidra scripts that parse closed-source libraries and automatically emit a Wireshark dissector named ARIstoteles for the previously undocumented protocol. They compare the resulting dissector against fully automated trace-analysis methods and then fuzz the interface. Fuzzing outcomes indicate that ARI has seen almost no public security work and also appears poorly tested by Apple itself. The open-source release of the tool is intended to let others continue baseband research on Apple hardware.

Core claim

We are the first to reverse-engineer and fuzz-test the ARI interface on iOS. Our Ghidra scripts automatically generate a Wireshark dissector, called ARIstoteles, by parsing closed-source iOS libraries for this undocumented protocol. We compare the quality of the dissector to fully-automated approaches based on static trace analysis. Finally, we fuzz the ARI interface based on our reverse-engineering results. The fuzzing results indicate that ARI does not only lack public security research but also has not been well-tested by Apple.

What carries the argument

ARIstoteles, the Wireshark dissector automatically produced by Ghidra scripts that parse closed-source iOS libraries to decode the ARI protocol messages exchanged with CommCenter.

If this is right

  • The ARI protocol presents a remote code execution attack surface because it interacts directly with CommCenter and multiple user-space daemons.
  • Releasing ARIstoteles open source enables other researchers to inspect and extend baseband protocol analysis on Apple devices.
  • The fuzzing campaign supplies concrete evidence that Apple has not performed sufficient internal testing of the ARI interface.
  • The Ghidra-script method for building dissectors can be applied to other undocumented protocols inside iOS libraries.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • The same reverse-engineering pipeline could be rerun on newer iOS versions to track whether ARI attack surface changes over time.
  • Crashes found during fuzzing could be turned into targeted exploits once their root causes are analyzed.
  • Closing the research gap between Android and iOS baseband interfaces may reveal common design patterns that affect wireless security across platforms.

Load-bearing premise

The behavior extracted from the closed-source libraries accurately represents how ARI actually runs on real iPhones.

What would settle it

Capturing live ARI traffic from a running iPhone and finding that the generated ARIstoteles dissector cannot parse it correctly, or running the fuzzer for an extended period and observing no unexpected crashes or anomalies.

Figures

Figures reproduced from arXiv: 2604.23457 by Frank Kargl, Jiska Classen, Matthias Hollick, Stephan Kleber, Tobias Kr\"oll.

Figure 1
Figure 1. Figure 1: The baseband chip processes data, which in turn passes information view at source ↗
Figure 2
Figure 2. Figure 2: ARI header format, 12 B split into according bits with example values. view at source ↗
Figure 3
Figure 3. Figure 3: ARI TLV format with example payloads. As a management protocol, ARI only carries commands and information of a more general nature without large amounts of data. For example, it signals incoming phone calls—but the audio is sent over a different interface. Moreover, network traffic is not handled by ARI. Nonetheless, ARI carries lightweight in￾formation besides connection management, including SMS, locatio… view at source ↗
Figure 4
Figure 4. Figure 4: Heuristic-based analysis results for the ARI header. view at source ↗
Figure 5
Figure 5. Figure 5: Message type classification results showing multiple clusters. view at source ↗
Figure 6
Figure 6. Figure 6: shows one of these message type objects in the net_cell group. Each object contains the group number, which is the same as the array index. This is followed by a unique message type identifier. Moreover, each group definition contains three pointers: a list of mandatory TLVs, a full list including optional TLVs, and a human-readable type name. The first entry in the list of TLVs is shown in view at source ↗
Figure 7
Figure 7. Figure 7: First TLV object in msg101 tlvs, defining the type structure of nInstance t1. The first two variants account for 240 of 290 asString methods and can be automatically extracted with Ghidra. Due to the inconsistent structure of the third variant, we have to extract these definitions manually. It would also be possible to emulate the asString methods. However, their input range is undefined, and without analy… view at source ↗
Figure 8
Figure 8. Figure 8: ARIstoteles dissecting an SMS. Wireshark dissector generation does not only save manual reverse-engineering overhead during initial dissector generation but with every iOS update. This especially applies to TLV types. The similar numbers indicate that the scripts run flawless, independent of slight differences introduced by the different com￾pilation processes. Tracking changes within ARI allows determinin… view at source ↗
Figure 9
Figure 9. Figure 9: Fuzzing results, also affecting various daemons due to XPC. view at source ↗
Figure 10
Figure 10. Figure 10: Crash within reported network cells during a scan. view at source ↗
read the original abstract

Wireless chips and interfaces expose a substantial remote attack surface. As of today, most cellular baseband security research is performed on the Android ecosystem, leaving a huge gap on Apple devices. With iOS jailbreaks, last-generation wireless chips become fairly accessible for performance and security research. Yet, iPhones were never intended to be used as a research platform, and chips and interfaces are undocumented. One protocol to interface with such chips is Apple Remote Invocation (ARI), which interacts with the central phone component CommCenter and multiple user-space daemons, thereby posing a Remote Code Execution (RCE) attack surface. We are the first to reverse-engineer and fuzz-test the ARI interface on iOS. Our Ghidra scripts automatically generate a Wireshark dissector, called ARIstoteles, by parsing closed-source iOS libraries for this undocumented protocol. Moreover, we compare the quality of the dissector to fully-automated approaches based on static trace analysis. Finally, we fuzz the ARI interface based on our reverse-engineering results. The fuzzing results indicate that ARI does not only lack public security research but also has not been well-tested by Apple. By releasing ARIstoteles open-source, we also aim to facilitate similar research in the future.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

2 major / 1 minor

Summary. The manuscript presents ARIstoteles, a toolset of Ghidra scripts that reverse-engineers the undocumented Apple Remote Invocation (ARI) protocol from closed-source iOS libraries (CommCenter and related daemons) to automatically generate a Wireshark dissector. It compares the quality of this static-analysis approach against fully-automated trace-based methods, performs fuzz testing of the ARI interface, and concludes that ARI lacks public security research and has not been well-tested by Apple. The work includes an open-source release of the tool to facilitate future research.

Significance. If the reverse-engineering accurately recovers the protocol grammar and the fuzzing results are representative, the paper addresses a notable gap in public analysis of iOS baseband interfaces, where Android has received far more attention. The automated dissector generation, direct comparison to trace methods, and open-source release of the scripts constitute concrete, reusable contributions that lower the barrier for subsequent security work on Apple cellular stacks.

major comments (2)
  1. [Section 3] Section 3 (Reverse Engineering): The central claims rest on Ghidra scripts correctly extracting the full ARI message grammar, field layouts, and command semantics from binary libraries. The manuscript provides no independent validation (e.g., differential testing against live device traffic or manual annotation of a sample of messages) that the extracted model matches runtime behavior. Any incompleteness directly invalidates the generated dissector, the comparison in Section 4, and the fuzzing results used to conclude insufficient Apple testing.
  2. [Section 5] Section 5 (Fuzzing Results): The claim that ARI 'has not been well-tested by Apple' is supported only by the fuzzing outcomes, yet the paper reports no coverage metrics, error bars, specific crash data, or details on the number of messages, mutation strategies, or observed anomalies. Without these, the representativeness of the results cannot be assessed and the conclusion about Apple's internal testing remains unsupported.
minor comments (1)
  1. [Abstract] The abstract and introduction could more explicitly separate the engineering contribution (dissector generation) from the security conclusion (insufficient testing), to avoid conflating the two.

Simulated Author's Rebuttal

2 responses · 0 unresolved

We thank the referee for the constructive feedback on our manuscript. We address each major comment below with clarifications and planned revisions to improve the rigor of the presentation.

read point-by-point responses

  1. Referee: [Section 3] Section 3 (Reverse Engineering): The central claims rest on Ghidra scripts correctly extracting the full ARI message grammar, field layouts, and command semantics from binary libraries. The manuscript provides no independent validation (e.g., differential testing against live device traffic or manual annotation of a sample of messages) that the extracted model matches runtime behavior. Any incompleteness directly invalidates the generated dissector, the comparison in Section 4, and the fuzzing results used to conclude insufficient Apple testing.

    Authors: We acknowledge that explicit independent validation would strengthen the central claims. The comparison in Section 4 to trace-based methods already provides a form of differential assessment by quantifying differences in recovered messages and coverage. To further address the concern, we will revise Section 3 to include a description of manual annotation and verification performed on a sample of extracted messages, cross-referenced against observed runtime behaviors from our fuzzing experiments where possible. We will also add a discussion of the inherent limitations of purely static analysis for protocol recovery. revision: yes

  2. Referee: [Section 5] Section 5 (Fuzzing Results): The claim that ARI 'has not been well-tested by Apple' is supported only by the fuzzing outcomes, yet the paper reports no coverage metrics, error bars, specific crash data, or details on the number of messages, mutation strategies, or observed anomalies. Without these, the representativeness of the results cannot be assessed and the conclusion about Apple's internal testing remains unsupported.

    Authors: We agree that expanded details on the fuzzing campaign are needed for readers to evaluate the results and the strength of the conclusion. In the revised manuscript we will expand Section 5 with specifics on the number of messages tested, the mutation strategies applied, descriptions of observed anomalies, and any coverage metrics collected. The statement regarding Apple's internal testing will be qualified to reflect that the anomalies discovered indicate gaps relative to our testing scope, while acknowledging that our campaign cannot comprehensively represent all possible inputs or Apple's full test suite. revision: yes

Circularity Check

0 steps flagged

No circularity: empirical reverse-engineering and fuzzing with no derivations or self-referential claims

full rationale

The paper's contribution consists of static analysis of closed-source iOS libraries via Ghidra scripts to extract ARI protocol details, generation of a Wireshark dissector, comparison to trace-based methods, and fuzzing. No equations, fitted parameters, predictions, or mathematical derivations appear in the abstract or described content. Claims rest on the empirical outputs of the tools and experiments rather than any self-definition, imported uniqueness theorems, or renamings of prior results. No self-citations are invoked as load-bearing justification for core premises. The work is self-contained as tool-building and analysis.

Axiom & Free-Parameter Ledger

0 free parameters · 0 axioms · 0 invented entities

This is a systems-security reverse-engineering paper; it introduces no free parameters, mathematical axioms, or invented entities. All claims rest on analysis of existing closed-source iOS binaries and standard fuzzing techniques.

pith-pipeline@v0.9.0 · 5534 in / 1157 out tokens · 60754 ms · 2026-05-08T07:47:29.267204+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

28 extracted references · 28 canonical work pages

  1. [1]

    Afek, J.: Simplifying iOS Research: Booting the iOS Kernel to an Interactive Bash Shell on QEMU.https://www.offensivecon.org/speakers/2020/jonathan-afe k.html(Feb 2020)

    work page 2020

  2. [2]

    Android Open Source Project: RIL Refactoring.https://source.android.com/ devices/tech/connect/ril(May 2021)

    work page 2021

  3. [3]

    Apple: Profiles and Logs - Bug Reporting - Apple Developer.https://develope r.apple.com/bug-reporting/profiles-and-logs/(May 2021)

    work page 2021

  4. [4]

    Corellium: Introduction to iOS Devices.https://support.corellium.com/hc/e n-us/articles/360053569554-Introduction-to-iOS-Devices(May 2021)

    work page arXiv 2021

  5. [5]

    Golde, N.: There’s Life in the Old Dog Yet: Tearing New Holes into Intel/iPhone Cellular Modems.https://comsecuris.com/blog/posts/theres_life_in_the_ old_dog_yet_tearing_new_holes_into_inteliphone_cellular_modems/(Apr 2018)

    work page 2018

  6. [6]

    Guy: Burned in Ashes: Baseband Fairy Tale Stories.https://cfp.recon.cx/re conmtl2019/talk/7A7TBA/(Jun 2019)

    work page 2019

  7. [7]

    Heinze, D.: fpicker.https://github.com/ttdennis/fpicker(May 2021)

    work page 2021

  8. [8]

    In: 14th USENIX Workshop on Offensive Technologies (WOOT 20)

    Heinze, D., Classen, J., Hollick, M.: ToothPicker: Apple Picking in the iOS Blue- tooth Stack. In: 14th USENIX Workshop on Offensive Technologies (WOOT 20). USENIX Association (Aug 2020),https://www.usenix.org/conference/woot20 /presentation/heinze

    work page 2020

  9. [9]

    BlackHat USA 2020 (Aug 2020)

    Hernandez, G., Muench, M.: Emulating Samsung’s Baseband for Security Testing. BlackHat USA 2020 (Aug 2020)

    work page 2020

  10. [10]

    In: IEEE INFOCOM 2020 - IEEE Conference on Computer Communications

    Kleber, S., van der Heijden, R.W., Kargl, F.: Message Type Identification of Binary Network Protocols using Continuous Segment Similarity. In: IEEE INFOCOM 2020 - IEEE Conference on Computer Communications. pp. 2243–2252 (2020). https://doi.org/10.1109/INFOCOM41043.2020.9155275

    work page doi:10.1109/infocom41043.2020.9155275 2020

  11. [11]

    In: 12th USENIX Workshop on Offensive Technologies (WOOT 18)

    Kleber, S., Kopp, H., Kargl, F.: NEMESYS: Network Message Syntax Reverse Engineering by Analysis of the Intrinsic Structure of Individual Messages. In: 12th USENIX Workshop on Offensive Technologies (WOOT 18). USENIX Association, Baltimore, MD (Aug 2018)

    work page 2018

  12. [12]

    libqmi Developers: QMI modem protocol helper library.https://github.com/fr eedesktop/libqmi(May 2021)

    work page 2021

  13. [13]

    In: 29th USENIX Security Symposium (USENIX Security 20)

    Liu, B., Zhang, C., Gong, G., Zeng, Y., Ruan, H., Zhuge, J.: FANS: Fuzzing An- droid Native System Services via Automated Interface Analysis. In: 29th USENIX Security Symposium (USENIX Security 20). pp. 307–323. USENIX Association (Aug 2020),https://www.usenix.org/conference/usenixsecurity20/present ation/liu ARIstoteles – Dissecting Apple’s Baseband Interface 19

    work page 2020

  14. [14]

    The 13th ACM Conference on Security and Privacy in Wireless and Mobile Networks (WiSec ’20) (Jul 2020)

    Maier, D., Seidel, L., Park, S.: BaseSAFE: Baseband SAnitized Fuzzing through Emulation. The 13th ACM Conference on Security and Privacy in Wireless and Mobile Networks (WiSec ’20) (Jul 2020)

    work page 2020

  15. [15]

    In: The 17th Annual International Conference on Mobile Systems, Applications, and Services (MobiSys ’19) (Jun 2019)

    Mantz, D., Classen, J., Schulz, M., Hollick, M.: InternalBlue - Bluetooth Binary Patching and Experimentation Framework. In: The 17th Annual International Conference on Mobile Systems, Applications, and Services (MobiSys ’19) (Jun 2019). https://doi.org/10.1145/3307334.3326089

    work page doi:10.1145/3307334.3326089 2019

  16. [16]

    In: 25th Annual Network and Distributed System Security Symposium (NDSS 2018)

    Muench, M., Stijohann, J., Kargl, F., Francillon, A., Balzarotti, D.: What you corrupt is not what you crash: Challenges in fuzzing embedded devices. In: 25th Annual Network and Distributed System Security Symposium (NDSS 2018). The Internet Society (2018)

    work page 2018

  17. [17]

    Mulliner, C.: Fuzzing the Phone in your Phone.https://media.ccc.de/v/26c3- 3507-de-fuzzing_the_phone_in_your_phone

    work page

  18. [18]

    Mulliner, C., Miller, C.: Fuzzing the Phone in your Phone.https: //www.blackhat.com/presentations/bh-usa-09/MILLER/BHUSA09-Miller- FuzzingPhone-PAPER.pdf

    work page

  19. [19]

    National Security Agency: Ghidra.https://ghidra-sre.org/(May 2021)

    work page 2021

  20. [20]

    Ravn˚ as, O.A.V.: Frida - a world-class dynamic instrumentation framework.https: //frida.re/(2020)

    work page 2020

  21. [21]

    Ravn˚ as, O.A.V.: Frida - stalker.https://frida.re/docs/stalker/(2021)

    work page 2021

  22. [22]

    In: 29th USENIX Security Symposium (USENIX Security 19)

    Ruge, J., Classen, J., Gringoli, F., Hollick, M.: Frankenstein: Advanced Wireless Fuzzing to Exploit New Bluetooth Escalation Targets. In: 29th USENIX Security Symposium (USENIX Security 19). USENIX Association (Aug 2020)

    work page 2020

  23. [23]

    Schulz, M., Wegemer, D., Hollick, M.: Nexmon: The C-based Firmware Patching Framework.https://nexmon.org(2017)

    work page 2017

  24. [24]

    https://scikit-learn.org/stable/modules/generated/sklearn.manifold

    scikit-learn Developers: sklearn.mainfold.MDS – scikit-learn 0.24.2 documentation. https://scikit-learn.org/stable/modules/generated/sklearn.manifold. MDS.html(May 2021)

    work page 2021

  25. [25]

    Silvanovich, N.: iOS Messaging Tools.https://github.com/googleprojectzero/ iOS-messaging-tools(Aug 2019)

    work page 2019

  26. [26]

    Stone, M.: Bad Binder: Android In-The-Wild Exploit.https://googleprojectze ro.blogspot.com/2019/11/bad-binder-android-in-wild-exploit.html(Nov 2019)

    work page 2019

  27. [27]

    In: 28th USENIX Security Symposium (USENIX Security 19)

    Stute, M., Narain, S., Mariotto, A., Heinrich, A., Kreitschmann, D., Noubir, G., Hollick, M.: A Billion Open Interfaces for Eve and Mallory: MitM, DoS, and Track- ing Attacks on iOS and macOS Through Apple Wireless Direct Link. In: 28th USENIX Security Symposium (USENIX Security 19). pp. 37–54. USENIX Asso- ciation, Santa Clara, CA (Aug 2019)

    work page 2019

  28. [28]

    Wireshark Foundation: Wireshark.https://www.wireshark.org/(May 2021)

    work page 2021