iLEAPP: iOS-Extraktionen in HTML, TSV, KML und LAVA

iLEAPP: fünf Ausgabeformate aus einer iOS-Extraktion

iLEAPP steht für iOS Logs, Events, And Plists Parser. Das Werkzeug liest forensische Extraktionen von iOS- und iPadOS-Geräten und erzeugt daraus fünf Ausgaben: HTML, TSV, eine Zeitachse, KML für Geodaten sowie LAVA für die Weiterverarbeitung. Nach README werden die Versionen 11 bis zu den jeweils aktuellen unterstützt.

Das Repository ist in Python geschrieben, unter MIT lizenziert mit dem Copyright bei Alexis Brignoni aus dem Jahr 2020 und liegt unter abrignoni/iLEAPP. Mit 1.176 Sternen, 294 Forks und 60 offenen Issues ist es etwas größer als das Android-Gegenstück des gleichen Autors.

Eine vollständige Artefaktliste hält iLEAPP bewusst nicht im Repository. Stattdessen verweist die README auf leapps.org/artifacts, wo sich die Sammlung nach dem jeweiligen LEAPP-Werkzeug filtern lässt.

Vorgefertigte Builds für Windows, macOS und Linux statt Python-Setup

Der empfohlene Einstieg führt über vorgefertigte Releases, für die keine Python-Installation nötig ist. Die README nennt zwei Bezugsquellen: leapps.org/releases für die gesamte LEAPP-Familie sowie die GitHub-Releases direkt. Die Downloads sind nach Plattform und Bedienart getrennt.

Unter Windows heißen die Archive ileappGUI-*-Windows_x64.zip und ileapp-*-Windows_x64.zip. Für macOS mit Apple Silicon gibt es ileappGUI-*-macOS_Apple_Silicon.dmg und ileapp-*-macOS_Apple_Silicon.zip, für Intel-Maschinen ileappGUI-*-macOS_Mac_Intel.dmg und ileapp-*-macOS_Mac_Intel.zip. Linux wird über AppImage bedient, mit ileappGUI-*-Linux_x86_64.AppImage und ileapp-*-Linux_x86_64.AppImage.

In der GUI werden Eingabetyp, Quellpfad, Ausgabeordner und die zu verarbeitenden Module ausgewählt. Für die CLI stellt die README eine Bedingung auf, die leicht übersehen wird: Der Ausgabeordner muss bereits existieren. Der Beispielaufruf lautet ileapp.exe -t zip -i C:\path\to\extraction.zip -o C:\path\to\output\, wobei auf macOS und Linux das Binary ileapp an die Stelle von ileapp.exe tritt.

Sechs Eingabetypen in iLEAPP: fs, zip, tar, gz, itunes, file

Sechs Eingabetypen sind dokumentiert, und die README beschreibt sie alle. fs bezeichnet einen Ordner mit extrahierten Dateien unter normalen Pfaden und Namen. zip ist ein ZIP-Archiv mit normalen Namen, tar ein TAR-Archiv und gz ein gzip-komprimiertes Archiv. Der Typ itunes steht für einen iTunes- oder Finder-Backup-Ordner, in dem Pfade und Namen als Hash vorliegen, file nimmt eine einzelne Datei entgegen.

Verschlüsselte iTunes- und Finder-Backups werden unterstützt. Die GUI fragt das Passwort ab, sobald sie eine Verschlüsselung erkennt; die CLI nimmt es über --itunes_password entgegen. Genau an dieser Stelle ist die README jedoch fehlerhaft: In der Tabelle zu den optionalen Argumenten wird --itunes_password mit dem Beispiel -t 12345 erläutert, was zum Parameter selbst nicht passt. Wer das Passwort übergeben will, sollte die Ausgabe von ileapp --help prüfen, statt sich auf die Tabelle zu verlassen.

CLI-Optionen von --wrap_text bis --custom_artifacts_path

Für einen normalen Lauf sind drei Argumente verpflichtend: -t für den Eingabetyp, -i beziehungsweise --input_path für den Pfad und -o beziehungsweise --output_path für das Ausgabeverzeichnis. Bei --output_path wiederholt die README, dass der Ordner vorhanden sein muss.

Dazu kommen optionale Schalter. -w oder --wrap_text schaltet den Textumbruch in den Ausgabedateien ab, was beim Weiterverarbeiten in einer Tabelle hilft. -m oder --load_profile lädt eine Profildatei mit der Endung .ilprofile und begrenzt damit, welche Module laufen. -d oder --load_case_data lädt Falldaten aus einer .lcasedata-Datei. --custom_output_folder vergibt einen eigenen Namen für den Unterordner des Berichts, und --custom_artifacts_path bindet einen zusätzlichen Ordner mit Artefaktmodulen ein, als Beispiel nennt die README scripts/alternate_artifacts.

Alle diese Optionen gelten ausschließlich für die CLI. Die GUI stellt dieselben Einstellungen über ihre Oberfläche bereit, statt sie als Flags entgegenzunehmen.

Die Hilfsmodi -p und -c in ileapp

Zwei Modi arbeiten ohne die Pflichtargumente und dürfen ausdrücklich nicht mit -t, -i oder -o kombiniert werden. Der Aufruf ileapp -p oder --artifact_paths schreibt alle Artefaktsuchpfade in die Datei path_list.txt im aktuellen Verzeichnis. Das hilft, wenn vor einer Extraktion klar sein soll, welche Dateien überhaupt gesucht werden, oder wenn die Vollständigkeit einer bereits vorliegenden Extraktion geprüft wird.

Der zweite Modus ist ileapp -c oder --create_profile_casedata, ein interaktiver Assistent, der im angegebenen Ordner eine .ilprofile- oder .lcasedata-Datei anlegt. Damit lässt sich ein wiederkehrender Auswertungsumfang festhalten, statt ihn bei jedem Lauf neu zusammenzuklicken. Für wiederholte Fälle mit gleichem Artefaktumfang ist dieser Weg die eigentliche Arbeitsersparnis.

Module unter scripts/artifacts und der Testweg mit TZ=UTC

Eigene Artefaktmodule liegen in scripts/artifacts/ und werden zur Laufzeit dynamisch geladen. Für neue Module verweist die README auf eine Schritt-für-Schritt-Anleitung unter leapps.org sowie auf vier Dokumente im Repository: admin/docs/artifact_info_block.md zur Struktur des Artefakt-Informationsblocks, admin/docs/module_updates.md zur automatischen Ausgabeerzeugung, admin/docs/module_updates_advanced.md zur LAVA-Ausgabe komplexer Module und admin/docs/testing/readme.md zum Testen.

Der Testablauf für einen Pull Request ist fünfschrittig und deckt sich mit dem des Android-Pendants. Aus einer echten Extraktion wird mit python admin/test/scripts/make_test_data.py <module> --case 1 --input <extraction.zip> eine Testmenge geschnitten. Für die Größe gelten feste Regeln: unter 10 MB kommt das Archiv in den Pull Request, zwischen 10 und 25 MB wird die Falldatei eingecheckt und das Archiv als Kommentar angehängt, darüber soll man sich melden.

Danach erzeugt TZ=UTC python admin/test/scripts/test_module.py <module> -a all -c all einen Schnappschuss unter admin/test/results/<module>/, der künftig als Vergleichsgrundlage dient. Die Zeitzone ist Pflicht, weil Schnappschüsse und CI in UTC laufen.

Öffentliche Fixtures, MIT von 2020 und der Stand v2026.3.2

Zur Weitergabe von Testdaten ist die README unmissverständlich: Alles Eingecheckte wird öffentlich. Erlaubt sind ein selbst bespieltes Testgerät, ein öffentliches Forschungs-Image oder von Hand bereinigte Dateien, Falldaten aus echten Ermittlungen nicht. Gleichzeitig öffnet das Projekt eine Hintertür: Lässt sich eine Extraktion nicht teilen, soll der Pull Request trotzdem gestellt und der Umstand genannt werden, damit ein Fixture aus einem öffentlichen Bild geschnitten oder die Datei bereinigt wird.

Zum Versionsstand: v2026.3.0 vom 14. August, v2026.3.1 vom 18. August und v2026.3.2 vom 27. August 2026. Damit laufen Android- und iOS-Variante im gleichen Versionsrhythmus, was den Austausch von Modulen zwischen beiden Projekten erleichtert.

Die MIT-Lizenz schließt Gewährleistung und Haftung aus. Formelle Supportkanäle nennt die README nicht, und Sicherheitszusagen sind nicht dokumentiert.

Redaktionelles Fazit

iLEAPP passt für Auswertende, die iOS- und iPadOS-Extraktionen ab Version 11 regelmäßig aufbereiten und HTML, TSV, KML oder LAVA benötigen. Wer Android-Material hat, greift zum Schwesterprojekt ALEAPP, das denselben Unterbau nutzt, aber eine eigene Artefaktsammlung mitbringt. Für den schnellen Blick in eine einzelne Datei ist der Aufbau mit vorgefertigtem Build und Modulauswahl zu schwerfällig. Vor dem ersten Fall sollten zwei Dinge geklärt sein: ob der Ausgabeordner für -o bereits existiert, und ob die Zielmodule unter leapps.org/artifacts tatsächlich geführt werden.

Offizielle Quellen

1. Official README
2. Project repository
3. Release notes