Analyseur de bibliothèques natives (.so) Android
Analysez gratuitement en ligne les fichiers .so Android. Notre analyseur de bibliothèques natives lit les en-têtes ELF, les tables de symboles, les fonctions JNI, les importations, les exportations et les en-têtes de section. Rapide, sécurisé et sans inscription.
Upload an Android .so File to Begin
Upload any Android native library (.so file) to analyze its ELF structure, symbol tables, JNI functions, imports and exports, section headers, and detect symbol stripping. All processing is completely local in your browser.
Pourquoi utiliser notre analyseur de bibliothèques natives (.so) Android ?
- Lecture complète de l'en-tête ELF : l'analyseur de bibliothèques natives lit toute la structure de l'en-tête ELF : magie d'identification, classe (32/64 bits), encodage des données (boutisme), OS/ABI (Linux, Android, System V), type de machine (ARM, AArch64, x86, x86-64), type de fichier, adresse du point d'entrée et emplacements des tables d'en-têtes de programme et de section. Tous les champs sont décodés en libellés lisibles, avec les valeurs hexadécimales affichées à côté.
- Analyse exhaustive de la table des symboles : extrayez et affichez tous les symboles des tables .symtab et .dynsym avec leurs noms, types (FUNC, OBJECT, NOTYPE), liaisons (LOCAL, GLOBAL, WEAK), visibilités (DEFAULT, HIDDEN, PROTECTED), adresses, tailles et sections associées. Filtrez par exports, imports, fonctions JNI ou tous les symboles grâce à une interface avec recherche.
- Détection et analyse des fonctions JNI : détectez automatiquement les fonctions JNI (Java Native Interface) grâce à leur convention de nommage Java_. Chaque fonction JNI est mise en évidence par un badge indiquant son nom JNI complet. L'analyseur extrait les composants package, classe et méthode de chaque nom Java_ pour un repérage facile pendant la rétro-ingénierie.
- Analyse du stripping et de la sécurité : détectez si le fichier .so a été privé de ses noms de symboles, une technique d'obfuscation courante dans les versions de production légitimes comme dans les malwares. L'analyseur identifie aussi les protections clés : en-têtes de programme GNU_RELRO (relocation en lecture seule), sections GOT/PLT, stockage local de threads, tables de gestion des exceptions et constructeurs .init_array.
Cas d'usage courants de l'analyseur de bibliothèques natives Android
- Analyse de malwares et spywares Android : les rétro-ingénieurs analysent les fichiers .so d'APK suspects pour détecter du code natif malveillant. Les malwares utilisent souvent des bibliothèques natives pour exécuter des charges utiles, appliquer des techniques anti-analyse et élever leurs privilèges. L'analyseur de bibliothèques natives révèle les fonctions JNI aux noms suspects, les tables de symboles obfusquées et les fonctions système importées qui trahissent un comportement malveillant.
- Audit de sécurité d'applications et tests d'intrusion : les auditeurs de sécurité examinent les bibliothèques natives pour vérifier que les versions de production sont correctement strippées, que les symboles de débogage sont supprimés et qu'aucun nom de fonction sensible n'est exposé. L'analyseur aide à repérer les symboles de développeur oubliés, les fonctions JNI qui exposent la logique d'API du backend et les fonctions importées exploitables pour corrompre la mémoire.
- Inspection de SDK tiers : analysez les composants natifs des SDK Android tiers avant de les intégrer. L'analyseur révèle quelles fonctions système le SDK importe, quels callbacks JNI il enregistre et s'il contient des exports inattendus. C'est essentiel pour les SDK qui traitent des données sensibles comme les identifiants publicitaires, les empreintes d'appareil ou l'analytique.
- Développement et débogage NDK : les développeurs Android NDK utilisent l'analyseur pour vérifier que leurs fichiers .so compilés ont la bonne architecture (arm64-v8a, armeabi-v7a, x86_64), les bons exports de fonctions JNI et la visibilité de symboles attendue. Cela aide à déboguer les problèmes de liaison, les exports manquants et l'exposition involontaire de symboles avant la publication.
- Recherche de vulnérabilités et développement d'exploits : les chercheurs examinent les fichiers .so pour obtenir des informations de version, identifier des builds de bibliothèques précis et analyser les fonctions importées afin de comprendre la surface d'attaque. L'analyse des en-têtes de section révèle les segments inscriptibles et exécutables, l'absence de protection RELRO et d'autres vulnérabilités de corruption de mémoire.
- Apprentissage du format ELF : les étudiants qui découvrent la spécification ELF (Executable and Linkable Format) peuvent voir un véritable fichier ELF analysé, avec tous ses en-têtes, sections et symboles affichés. L'analyseur associe chaque champ de la structure ELF à sa définition dans la spécification, ce qui en fait un excellent outil pédagogique pour comprendre le fonctionnement des bibliothèques partagées sous Linux et Android.
Qu'est-ce qu'un fichier .so Android ?
Un fichier .so (Shared Object) est l'équivalent Android d'une bibliothèque à liaison dynamique sous Linux. Les applications Android utilisent des bibliothèques natives écrites en C ou C++ via l'Android NDK (Native Development Kit) pour le code critique en performance, les moteurs de jeu, la cryptographie, le traitement du signal et les SDK tiers. Ces bibliothèques suivent la spécification ELF (Executable and Linkable Format), le même format que les exécutables et bibliothèques partagées Linux. Chaque fichier .so contient du code machine compilé pour une architecture de processeur donnée - ARM, ARM64, x86 ou x86-64 - et est chargé dans le processus de l'application à l'exécution via System.loadLibrary(). L'analyseur de bibliothèques natives lit cette structure ELF pour révéler en-têtes, sections, symboles et fonctions JNI.
Comment fonctionne l'analyseur de bibliothèques natives Android
- Téléversez votre fichier .so : sélectionnez n'importe quelle bibliothèque native Android à analyser. L'analyseur lit directement les données binaires ELF dans votre navigateur, sans envoi à un serveur - tout le traitement est local.
- Lecture ELF : l'outil lit la magie d'identification ELF (\x7fELF), détermine la classe (32 ou 64 bits) et le boutisme, puis lit l'intégralité de l'en-tête ELF, y compris les en-têtes de programme (segments) et de section. Il suit la table de chaînes des en-têtes de section pour résoudre les noms comme .text, .data, .bss, .dynsym et .init_array.
- Extraction et analyse des symboles : l'analyseur lit à la fois la section .symtab (table des symboles) et la section .dynsym (table des symboles dynamiques), en résolvant les noms via les tables de chaînes correspondantes (.strtab et .dynstr). Chaque symbole est classé par type, liaison et visibilité. Les fonctions JNI (préfixées par Java_) sont détectées et marquées automatiquement, et la bibliothèque est vérifiée pour le stripping.
Structures ELF clés que vous verrez
- En-tête ELF : l'en-tête de 52 à 64 octets au début de chaque fichier .so, contenant le nombre magique, la classe (32/64 bits), l'ordre des octets, l'OS/ABI, le type de machine (ARM, AArch64, x86) et les pointeurs vers les tables d'en-têtes de programme et de section.
- En-têtes de programme : décrivent les segments chargés en mémoire à l'exécution. Les segments LOAD sont mappés dans l'espace d'adressage du processus. DYNAMIC contient les informations de liaison dynamique. GNU_RELRO rend les données de relocation en lecture seule après le chargement. INTERP indique le chemin de l'éditeur de liens/chargeur dynamique.
- En-têtes de section : décrivent la disposition du fichier à l'édition de liens, notamment .text (code exécutable), .data (données initialisées), .bss (données non initialisées), .dynsym/.dynstr (symboles dynamiques), .init_array/.fini_array (fonctions constructrices/destructrices), .got/.got.plt (table d'offsets globaux), .plt (table de liaison de procédures) et .ARM.exidx (index d'exceptions ARM).
- Tables de symboles : contiennent les noms de fonctions et de variables avec leurs adresses, tailles, types (FUNC, OBJECT, NOTYPE) et liaisons (LOCAL, GLOBAL, WEAK). Les symboles dynamiques servent à l'édition de liens à l'exécution, tandis que les symboles ordinaires servent au débogage et peuvent être supprimés dans les versions de production.
Confidentialité, sécurité et notes d'utilisation
L'analyseur de bibliothèques natives Android traite tous les fichiers entièrement dans votre navigateur en JavaScript. Aucune donnée de fichier n'est jamais téléversée sur un serveur, stockée dans une base de données ni partagée avec un tiers. Il n'y a aucune limite de taille au-delà de ce que votre navigateur peut gérer : les fichiers de plus de 100 Mo peuvent prendre plus de temps à traiter, mais ne quitteront jamais votre appareil. Toute l'analyse ELF, l'extraction des tables de symboles, la détection JNI et l'analyse des sections se font localement. Exportez les rapports d'analyse en JSON pour partager vos conclusions avec votre équipe ou les conserver.
Foire aux questions
Un fichier .so (Shared Object) est une bibliothèque native utilisée par les applications Android pour du code critique en termes de performances écrit en C ou C++. Analyser les fichiers .so révèle la structure ELF, les fonctions importées et exportées, les méthodes JNI appelables depuis Java/Kotlin et d'éventuels problèmes de sécurité. Le code natif ayant un accès direct à la mémoire, l'analyse des fichiers .so est essentielle aux audits de sécurité et à l'analyse de malwares.
Android prend en charge quatre architectures principales pour les bibliothèques natives : arm64-v8a (ARM 64 bits, la plupart des appareils modernes), armeabi-v7a (ARM 32 bits, appareils plus anciens), x86_64 (émulateurs Intel/AMD 64 bits et certaines tablettes) et x86 (x86 32 bits, émulateurs anciens). L'analyseur de bibliothèques natives Android détecte automatiquement l'architecture à partir du champ de type de machine de l'en-tête ELF.
Les fonctions JNI (Java Native Interface) sont des fonctions C/C++ appelables depuis Java ou Kotlin selon la convention de nommage Java_packagename_Class_method. Elles font le lien entre l'application Android et le code natif. L'analyseur détecte toutes les fonctions JNI grâce à leur préfixe Java_, ce qui facilite l'identification de la surface d'API native complète d'un fichier .so.
Une bibliothèque strippée a vu ses noms de symboles supprimés de la section .symtab, tout en conservant la section .dynsym pour l'édition de liens à l'exécution. C'est courant pour les versions de production, mais cela complique la rétro-ingénierie. L'analyseur détecte le stripping en vérifiant la présence de symboles nommés dans la table des symboles.
Absolument. Toute l'analyse ELF, l'extraction des tables de symboles, la détection JNI et l'analyse des sections se font localement dans votre navigateur en JavaScript. Vos fichiers .so ne sont jamais téléversés sur un serveur, stockés dans une base de données ni transmis sur le réseau.
La GOT (Global Offset Table) et la PLT (Procedure Linkage Table) sont des sections ELF qui permettent l'édition de liens dynamique à l'exécution. La GOT contient les adresses des variables globales et des fonctions importées d'autres bibliothèques. La PLT contient du code intermédiaire qui résout les adresses de fonctions au premier appel (liaison paresseuse).
GNU_RELRO (Relocation Read-Only) est un en-tête de programme qui rend les données de relocation en lecture seule une fois que l'éditeur de liens dynamique les a résolues. Cela empêche les attaquants de réécrire les entrées de la GOT pour détourner le flux d'exécution. L'analyseur de bibliothèques natives vérifie cette protection de sécurité.
Oui, l'analyseur propose deux options d'export : Copier le rapport génère un résumé en texte brut avec les informations d'en-tête ELF, le nombre de symboles, le nombre de fonctions JNI et le statut de stripping. Exporter en JSON crée un fichier JSON structuré contenant toutes les données analysées pour une analyse approfondie.
La section .init_array contient des pointeurs vers les fonctions constructrices exécutées au chargement de la bibliothèque. Les malwares l'utilisent souvent pour des routines d'initialisation ou le déchiffrement de charges utiles. La section .fini_array contient les destructeurs appelés au déchargement de la bibliothèque. L'analyseur détecte la présence des deux sections.