ALEAPP : analyseur de journaux, événements et protobuf Android

Android Logs Events And Protobuf Parser : le nom et le but

ALEAPP signifie Android Logs Events And Protobuf Parser. Le README commence par ce nom et un lien vers le Twitter de l'auteur (abrignoni), suivi d'un article de blog sur leapps.org. Le dépôt comporte 890 étoiles, 242 forks et 46 issues ouvertes selon les métadonnées. Le projet est écrit en Python et distribué sous licence MIT. Bien que le nom suggère un analyseur pour investigateurs numériques, le README ne précise pas l'usage prévu (forensique, débogage, ingénierie inverse) ni ne décrit les archéfacts analysés au-delà de mentionner les journaux, événements et protobuf.

Exigence Python 3.10 et installation des dépendances

ALEAPP nécessite Python 3.10 ou plus. Les dépendances Python listées dans requirements.txt s'installent avec `py -m pip install -r requirements.txt` ou `pip3 install -r requirements.txt`, selon la version de Python dans votre environnement (utiliser `py`, `python` ou `python3` selon votre configuration). Sur Linux, tkinter doit être installé séparément avec `sudo apt-get install python3-tk` car la GUI l'exige. Le README ne donne pas d'instructions équivalentes pour Windows ou macOS concernant les dépendances système autres que Python.

Interface de ligne de commande et interface graphique

L'interface en ligne de commande se lance avec `python aleapp.py -t <zip | tar | fs | gz> -i <path_to_extraction> -o <path_for_report_output>`. Les types d'extraction supportés sont zip, tar, fs (fichiers système) et gz, mais le README ne précise pas ce qui distingue ces formats au-delà de l'extension de fichier. L'interface graphique se lance avec `python aleappGUI.py`, sans arguments. Pour l'aide de la CLI, exécutez `python aleapp.py --help`. Le README ne décrit pas les différences de sortie entre la GUI et la CLI, ni les options avancées accessibles via --help.

Compilation en exécutables autonomes via PyInstaller

Des fichiers spec PyInstaller sont fournis pour créer des exécutables autonomes sur les systèmes sans installation Python. Sous Windows, exécutez `pyinstaller scripts\pyinstaller\aleapp.spec` pour créer aleapp.exe, et `pyinstaller scripts\pyinstaller\aleappGUI.spec` pour créer aleappGUI.exe (chemins backslash). Sous macOS, les fichiers spec sont `scripts/pyinstaller/aleapp_macOS.spec` (produit aleapp) et `scripts/pyinstaller/aleappGUI_macOS.spec` (produit aleappGUI.app). Sous Linux, utilisez `aleapp_Linux.spec` et `aleappGUI_Linux.spec` pour aleapp et aleappGUI respectivement. Le README suppose que PyInstaller est déjà installé dans votre environnement Python.

Système de plugins avec dictionnaire __artifacts_v2__

Les plugins sont des modules Python stockés dans `scripts/artifacts/` et chargés dynamiquement chaque fois qu'ALEAPP s'exécute. Chaque fichier de plugin doit définir un dictionnaire `__artifacts_v2__` au début du module. Les clés sont des identifiants uniques et les valeurs sont des dictionnaires contenant : name (nom), description, author, version, date, requirements, category, notes, paths (tuple de motifs glob), et function (nom de la fonction d'entrée). Par exemple, un plugin nommé cool_artifact_1 énumère les chemins comme `('*/com.android.cooldata/databases/database*.db',)` et pointe la fonction get_cool_data1 comme entrée.

Signature de fonction d'entrée et modules utilitaires

La fonction d'entrée du plugin reçoit quatre paramètres : files_found (itérable de chemins en chaînes), report_folder (chemin du dossier de sortie en chaîne), seeker (objet FileSeekerBase qui a trouvé les fichiers), et wrap_text (booléen indiquant si le retour à la ligne doit être appliqué). L'exemple get_cool_data1 déclare `def get_cool_data1(files_found, report_folder, seeker, wrap_text):` et passe le reste du traitement. Les plugins utilisent les modules `artifact_report` et `ilapfuncs` pour générer une sortie HTML au format ALEAPP, TSV, et optionnellement soumettre des enregistrements à la timeline. Le README fournit un exemple de haut niveau utilisant ArtifactHtmlReport et les fonctions tsv() et timeline().

Test et validation des modules de plugins

Le README inclut un workflow de test pour les contributeurs. Pour créer des données de test, exécutez `python admin/test/scripts/make_test_data.py <module> --case 1 --input <extraction.zip>` qui extrait les fichiers correspondant aux motifs paths du module et crée un fichier case JSON plus des zips d'artefacts. Pour enregistrer la sortie attendue, exécutez `TZ=UTC python admin/test/scripts/test_module.py <module> -a all -c all`. Pour exécuter les mêmes tests que CI, lancez `python admin/test/scripts/run_test_cases.py --module <module>`. Pour générer les valeurs sample_data, utilisez `python admin/scripts/validate_sample_data.py --emit <extraction.zip> --key <image_name>`. Tout doit être commité ensemble dans une PR, avec une limite de 10 Mo par zip de fixture.

Licence MIT et crédit d'auteur

ALEAPP est distribué sous licence MIT, copyright Alexis Brignoni. La licence accorde la permission d'utiliser, copier, modifier, fusionner, publier, distribuer, sous-licencier et vendre des copies du logiciel à condition que l'avis de droit d'auteur et d'autorisation soit inclus. Le logiciel est fourni « tel quel », sans garantie, et la licence exclut toute responsabilité pour les dommages. Le README crédite la communauté DFIR pour la collaboration et Derek Eiri pour le logo ALEAPP. Le dépôt se concentre sur la technologie plutôt que sur les canaux de support commerciaux ; l'auteur accepte les contributions via son site personnel.

Conclusion éditoriale

ALEAPP réunit une interface en ligne de commande Python, une interface graphique, des fichiers de construction PyInstaller pour les exécutables autonomes, et un système de plugins chargés dynamiquement depuis scripts/artifacts. Pour évaluer son utilité, testez d'abord la GUI avec python aleappGUI.py sur une extraction Android (zip, tar ou fs), observez les artefacts détectés et comparez le rapport HTML généré avec une autre approche de parsing. Consultez le code source ou les exemples de plugins pour comprendre la structure exacte des rapports ; le README ne décrit pas les détails des formats de sortie au-delà de HTML et TSV.

Sources officielles

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