ALEAPP: Android-Extraktionen parsen und Artefakte selbst ergänzen
abrignoni/ALEAPP bietet eine praxistaugliche Open-Source-Implementierung mit stabiler Einsatzbarkeit für reale Anwendungsfälle.
Auf einen Blick
- Was ist das?
- Der Android Logs Events And Protobuf Parser liefert CLI, GUI und ein Plugin-Schema mit Testablauf. Einordnung von Installation, __artifacts_v2__ und den Lücken der README.
- Für wen ist es gedacht?
- ALEAPP richtet sich an Forensik-Praktiker, die Android-Extraktionen regelmäßig auswerten und eigene Artefakt-Module beisteuern wollen; das Schema mit __artifacts_v2__ ist niedrigschwellig genug für einzelne Ergänzungen. Weniger geeignet ist es für Gelegenheitsnutzer, die eine geführte Oberfläche samt Artefaktliste erwarten, denn die README nennt keine unterstützten Artefakte und erklärt die Werte von -t nicht.
- Darf ich es kommerziell nutzen?
- Ja. MIT ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 1 Tag.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Python, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
ALEAPP als Parser für Android-Extraktionen
ALEAPP steht für Android Logs Events And Protobuf Parser und stammt aus der Forensik-Gemeinschaft. Es nimmt eine Extraktion eines Android-Geräts und erzeugt daraus einen Bericht. Das Repository ist in Python geschrieben, steht unter MIT mit dem Copyright von Alexis Brignoni und liegt unter abrignoni/ALEAPP. Mit 890 Sternen, 242 Forks und 46 offenen Issues ist es etabliert, aber von einer überschaubaren Community getragen.
Die README beginnt knapp. Sie verweist auf die Seite des Autors für Beiträge und auf Blogbeiträge unter leapps.org/blog. Eine Liste der unterstützten Artefakte enthält sie nicht. Wer wissen will, was ALEAPP aus einer Extraktion herausholt, muss in den Ordner scripts/artifacts schauen oder das Werkzeug laufen lassen.
Python 3.10, requirements.txt und python3-tk unter Linux
Die Voraussetzungen sind klar benannt: Python 3.10 oder höher. Die Abhängigkeiten liegen in requirements.txt und werden mit py -m pip install -r requirements.txt installiert, alternativ mit pip3 install -r requirements.txt. Die README weist darauf hin, den zur eigenen Umgebung passenden Befehl zu verwenden, also py, python oder python3.
Unter Linux kommt ein Schritt hinzu, der leicht übersehen wird. tkinter gehört nicht zur Standardinstallation und wird mit sudo apt-get install python3-tk nachgezogen. Fehlt das Paket, startet die GUI nicht, während die CLI weiterarbeitet. Für Windows und macOS nennt die README keine entsprechenden Schritte.
CLI-Aufruf von aleapp.py mit -t, -i und -o
Der Kommandozeilen-Aufruf hat drei Pflichtparameter: python aleapp.py -t <zip | tar | fs | gz> -i <path_to_extraction> -o <path_for_report_output>. Über -t wird der Typ der Extraktion angegeben, über -i ihr Pfad und über -o das Verzeichnis, in das der Bericht geschrieben wird.
Was die vier Werte zip, tar, fs und gz im Einzelnen bedeuten und wie sich eine Dateisystem-Extraktion von einem tar-Archiv in der Verarbeitung unterscheidet, steht in der README nicht. Wer weiterkommen will, ruft python aleapp.py --help auf. Die graphische Variante startet mit python aleappGUI.py, und auch zu den Unterschieden im Funktionsumfang schweigt die README.
Für eine einzelne Datenbank ist der Weg über ALEAPP oft unnötig lang. Das Beispiel-Plugin sucht mit dem Muster */com.android.cooldata/databases/database*.db, und eine solche Datei lässt sich auch unmittelbar öffnen. Der Gewinn von ALEAPP entsteht aus der Menge der Artefakte, nicht aus dem einzelnen Fund.
PyInstaller-Specs für aleapp.exe, aleapp.app und Linux-Builds
Für Systeme ohne Python liegen PyInstaller-Spec-Dateien bereit. Auf Windows entsteht mit pyinstaller scripts\pyinstaller\aleapp.spec die Datei aleapp.exe, mit pyinstaller scripts\pyinstaller\aleappGUI.spec entsprechend aleappGUI.exe. macOS nutzt scripts/pyinstaller/aleapp_macOS.spec für ein Programm namens aleapp sowie scripts/pyinstaller/aleappGUI_macOS.spec für ein Anwendungsbündel aleappGUI.app. Für Linux heißen die Specs aleapp_Linux.spec und aleappGUI_Linux.spec.
Die README setzt PyInstaller als vorhanden voraus und beschreibt dessen Installation nicht. Für einen Analyse-Rechner ohne eigene Python-Umgebung ist dieser Weg der praktischere. Für die Arbeit am Quellcode bleibt python aleapp.py die bessere Wahl, weil Änderungen ohne Neubau wirksam werden.
__artifacts_v2__: Aufbau eines Plugins in scripts/artifacts
Ein Artefakt-Plugin ist eine Python-Datei im Ordner scripts/artifacts, den ALEAPP bei jedem Lauf dynamisch lädt. Zwingend ist ein Wörterbuch namens __artifacts_v2__ möglichst am Anfang der Datei. Seine Schlüssel sind Artefakt-IDs, die innerhalb von ALEAPP eindeutig sein müssen. Die Werte sind wiederum Wörterbücher mit den Feldern name, description, author, version, date, requirements, category, notes, paths und function.
Zwei Felder tragen die eigentliche Arbeit. paths ist ein Tupel von Glob-Mustern, über das der Seeker die passenden Dateien findet; das Beispiel im README lautet ('*/com.android.cooldata/databases/database*.db',). function nennt den Namen der Einstiegsfunktion. Diese muss vier Argumente annehmen: die gefundenen Dateien, den Ausgabeordner, den Seeker vom Typ FileSeekerBase und einen Wahrheitswert für den Textumbruch. Im README heißt das Beispiel def get_cool_data1(files_found, report_folder, seeker, wrap_text).
Zur Ausgabe sollen Plugins HTML und TSV erzeugen und können Datensätze an die Timeline geben. Die Hilfsfunktionen dafür liegen in den Modulen artifact_report und ilapfuncs.
Fixture und Snapshot: der Testweg unter admin/test/scripts
Für Beiträge beschreibt die README einen fünfteiligen Ablauf, der ungewöhnlich streng ist. Zuerst wird mit python admin/test/scripts/make_test_data.py <module> --case 1 --input <extraction.zip> eine Testmenge aus einer echten Extraktion geschnitten. Dabei entstehen die Falldatei admin/test/cases/testdata.<module>.json und ein kleines Archiv pro Artefakt unter admin/test/cases/data/<module>/.
Für die Größe gelten feste Regeln: Unter 10 MB kommt das Archiv mit in den Pull Request, zwischen 10 und 25 MB wird die Falldatei eingecheckt und das Archiv als Kommentar angehängt, bei mehr soll man sich im Pull Request melden, damit ein Betreuer die Übergabe regelt.
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 gehört zum Ablauf, weil die Schnappschüsse in UTC liegen und auch die CI in UTC läuft. Mit python admin/test/scripts/run_test_cases.py --module <module> lässt sich derselbe Vergleich lokal fahren, und python admin/scripts/validate_sample_data.py --emit <extraction.zip> --key <image_name> gibt fertige sample_data-Blöcke aus.
Öffentliche Testdaten als Bedingung und der Stand von v2026.3.2
Dieser Aufbau hat eine Begründung, die die README deutlich ausspricht: Alles, was hier eingecheckt wird, wird öffentlich. Erlaubt sind nur Daten, die man teilen darf, also ein selbst bespieltes Testgerät, ein öffentliches Forschungs-Image oder von Hand bereinigte Dateien. Falldaten aus echten Ermittlungen sind ausdrücklich ausgeschlossen. Bei einem Werkzeug für Auswertungen ist das mehr als ein Hinweis am Rand, es entscheidet darüber, ob eine Testmenge überhaupt beigesteuert werden kann.
Zum Versionsstand: Die letzten drei Releases sind v2026.3.0 vom 14. August, v2026.3.1 vom 18. August und v2026.3.2 vom 27. August 2026. Das Schema folgt dem Jahr und nicht der aus Semver bekannten Zählung. Was sich zwischen den Releases geändert hat, sagt die README nicht; diese Angaben stünden auf der Releaseseite.
Zum Schluss nennt das README keine Supportkanäle und keine Sicherheitszusagen. Die MIT-Lizenz schließt Gewährleistung und Haftung aus, wie bei dieser Lizenz üblich.
Redaktionelles Fazit
ALEAPP richtet sich an Forensik-Praktiker, die Android-Extraktionen regelmäßig auswerten und eigene Artefakt-Module beisteuern wollen; das Schema mit __artifacts_v2__ ist niedrigschwellig genug für einzelne Ergänzungen. Weniger geeignet ist es für Gelegenheitsnutzer, die eine geführte Oberfläche samt Artefaktliste erwarten, denn die README nennt keine unterstützten Artefakte und erklärt die Werte von -t nicht. Vor dem ersten Einsatz sollten Python 3.10 und unter Linux python3-tk installiert sein, danach lohnt ein Lauf von python aleapp.py -t fs gegen ein Testgerät, bevor echte Extraktionen verarbeitet werden.
Community-Notizen