Android Native Library (.so) Analyzer
Analysieren Sie Android-.so-Dateien online kostenlos. Unser Native-Library-Analyzer liest ELF-Header, Symboltabellen, JNI-Funktionen, Importe, Exporte und Section-Header. Schnell, sicher und ohne Anmeldung.
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.
Warum unseren Android Native Library (.so) Analyzer verwenden?
- Vollständige ELF-Header-Analyse: Der Native-Library-Analyzer liest die komplette ELF-Header-Struktur: Identifikations-Magic, Klasse (32/64-Bit), Datenkodierung (Endianness), OS/ABI (Linux, Android, System V), Maschinentyp (ARM, AArch64, x86, x86-64), Dateityp, Einstiegspunktadresse sowie Positionen der Programm- und Section-Header-Tabellen. Alle Felder werden in lesbare Bezeichnungen dekodiert, Hex-Werte werden daneben angezeigt.
- Umfassende Symboltabellen-Analyse: Extrahieren und anzeigen aller Symbole aus den Tabellen .symtab und .dynsym mit Namen, Typen (FUNC, OBJECT, NOTYPE), Bindungen (LOCAL, GLOBAL, WEAK), Sichtbarkeiten (DEFAULT, HIDDEN, PROTECTED), Adressen, Größen und zugehörigen Abschnitten. Filtern Sie nach Exporten, Importen, JNI-Funktionen oder allen Symbolen in einer durchsuchbaren Oberfläche.
- Erkennung und Analyse von JNI-Funktionen: Automatische Erkennung von JNI-Funktionen (Java Native Interface) anhand ihrer Namenskonvention Java_. Jede JNI-Funktion wird mit einem speziellen Badge hervorgehoben, das ihren vollständigen JNI-exportierten Namen zeigt. Der Analyzer extrahiert Paket-, Klassen- und Methodenkomponenten aus jedem Java_-Namen, damit sie beim Reverse Engineering leicht nachgeschlagen werden können.
- Stripping- und Sicherheitsanalyse: Erkennen Sie, ob die .so-Datei von Symbolnamen befreit wurde - eine gängige Obfuskationstechnik in legitimen Release-Builds ebenso wie in Malware. Der Analyzer identifiziert außerdem wichtige Sicherheitsfunktionen: GNU_RELRO-Programm-Header (Relocation Read-Only), GOT/PLT-Abschnitte, Thread-lokalen Speicher, Ausnahmebehandlungstabellen und .init_array-Konstruktoren.
Typische Anwendungsfälle des Android Native Library Analyzers
- Analyse von Android-Malware und Spyware: Reverse Engineers analysieren .so-Dateien verdächtiger APKs, um bösartigen nativen Code zu erkennen. Malware nutzt native Bibliotheken oft zur Payload-Ausführung, für Anti-Analyse-Techniken und zur Rechteausweitung. Der Native-Library-Analyzer zeigt JNI-Funktionen mit verdächtigen Namen, obfuskierte Symboltabellen und importierte Systemfunktionen, die auf bösartiges Verhalten hinweisen.
- App-Sicherheitsprüfung und Pentesting: Sicherheitsauditoren prüfen native Bibliotheken, um zu bestätigen, dass Release-Builds korrekt gestrippt sind, Debug-Symbole entfernt wurden und keine sensiblen Funktionsnamen offenliegen. Der Analyzer hilft, übrig gebliebene Entwickler-Symbole, JNI-Funktionen, die Backend-API-Logik offenlegen, und importierte Funktionen zu identifizieren, die für Speichermanipulation ausgenutzt werden könnten.
- Prüfung von SDKs Dritter: Analysieren Sie native Komponenten von Android-SDKs Dritter vor der Integration. Der Native-Library-Analyzer zeigt, welche Systemfunktionen das SDK importiert, welche JNI-Callbacks es registriert und ob es unerwartete Exporte enthält. Das ist entscheidend für SDKs, die sensible Daten wie Werbe-IDs, Geräte-Fingerabdrücke oder Analysedaten verarbeiten.
- NDK-Entwicklung und Debugging: Android-NDK-Entwickler nutzen den Analyzer, um zu prüfen, dass ihre kompilierten .so-Dateien die richtige Architektur (arm64-v8a, armeabi-v7a, x86_64), passende JNI-Exporte und die erwartete Symbol-Sichtbarkeit haben. Er hilft beim Debuggen von Link-Problemen, fehlenden Exporten und unbeabsichtigter Symbol-Offenlegung vor dem Release.
- Schwachstellenforschung und Exploit-Entwicklung: Sicherheitsforscher untersuchen .so-Dateien auf Versionsinformationen, identifizieren bestimmte Bibliotheks-Builds und analysieren importierte Funktionen, um die Angriffsfläche zu verstehen. Die Section-Header-Analyse zeigt beschreibbare und ausführbare Segmente, fehlenden RELRO-Schutz und andere Anfälligkeiten für Speichermanipulation.
- Lernen des ELF-Dateiformats: Studierende, die die ELF-Spezifikation (Executable and Linkable Format) lernen, sehen eine real analysierte ELF-Datei mit allen Headern, Abschnitten und Symbolen. Der Analyzer ordnet jedes Strukturfeld seiner Definition in der Spezifikation zu und ist damit ein hervorragendes Lehrwerkzeug, um zu verstehen, wie Shared Libraries unter Linux und Android funktionieren.
Was ist eine Android-.so-Datei?
Eine .so-Datei (Shared Object) ist das Android-Äquivalent zu einer dynamischen Bibliothek unter Linux. Android-Apps verwenden native Bibliotheken in C oder C++ über das Android NDK (Native Development Kit) für performancekritischen Code, Game-Engines, Kryptografie, Signalverarbeitung und SDKs Dritter. Diese Bibliotheken folgen der ELF-Spezifikation (Executable and Linkable Format), demselben Format wie Linux-Programme und Shared Libraries. Jede .so-Datei enthält für eine bestimmte CPU-Architektur kompilierten Maschinencode - ARM, ARM64, x86 oder x86-64 - und wird zur Laufzeit über System.loadLibrary() in den App-Prozess geladen. Der Native-Library-Analyzer liest diese ELF-Struktur und zeigt Header, Abschnitte, Symbole und JNI-Funktionen.
So funktioniert der Android Native Library Analyzer
- Laden Sie Ihre .so-Datei hoch: Wählen Sie eine beliebige native Android-Bibliothek zur Analyse. Der Analyzer liest die rohen ELF-Binärdaten direkt in Ihrem Browser, ohne Upload zu einem Server - die gesamte Verarbeitung ist lokal.
- ELF-Analyse: Das Tool liest die ELF-Identifikations-Magic (\x7fELF), bestimmt Klasse (32 oder 64 Bit) und Endianness und liest dann den vollständigen ELF-Header inklusive Programm-Headern (Segmente) und Section-Headern. Es folgt der Section-Header-Stringtabelle, um Namen wie .text, .data, .bss, .dynsym und .init_array aufzulösen.
- Symbol-Extraktion und -Analyse: Der Analyzer liest sowohl den Abschnitt .symtab (Symboltabelle) als auch .dynsym (dynamische Symboltabelle) und löst Symbolnamen über die zugehörigen Stringtabellen (.strtab und .dynstr) auf. Jedes Symbol wird nach Typ, Bindung und Sichtbarkeit klassifiziert. JNI-Funktionen (mit Präfix Java_) werden automatisch erkannt und markiert, und die Bibliothek wird auf Symbol-Stripping geprüft.
Wichtige ELF-Strukturen, die Sie sehen werden
- ELF-Header: Der 52-64 Byte große Header am Anfang jeder .so-Datei mit Magic Number, Klasse (32/64-Bit), Byte-Reihenfolge, OS/ABI, Maschinentyp (ARM, AArch64, x86) und Zeigern auf Programm- und Section-Header-Tabellen.
- Programm-Header: beschreiben die zur Laufzeit in den Speicher geladenen Segmente. LOAD-Segmente werden in den Adressraum des Prozesses abgebildet. DYNAMIC enthält Informationen zum dynamischen Linking. GNU_RELRO macht Relocation-Daten nach dem Laden nur lesbar. INTERP gibt den Pfad des dynamischen Linkers/Loaders an.
- Section-Header: beschreiben das Dateilayout zur Linkzeit, darunter .text (ausführbarer Code), .data (initialisierte Daten), .bss (nicht initialisierte Daten), .dynsym/.dynstr (dynamische Symbole), .init_array/.fini_array (Konstruktor-/Destruktorfunktionen), .got/.got.plt (Global Offset Table), .plt (Procedure Linkage Table) und .ARM.exidx (ARM Exception Index).
- Symboltabellen: enthalten Funktions- und Variablennamen mit Adressen, Größen, Typen (FUNC, OBJECT, NOTYPE) und Bindungen (LOCAL, GLOBAL, WEAK). Dynamische Symbole werden für das Laufzeit-Linking verwendet, reguläre Symbole dienen dem Debugging und können in Release-Builds entfernt werden.
Datenschutz, Sicherheit und Hinweise zur Nutzung
Der Android Native Library Analyzer verarbeitet alle Dateien vollständig in Ihrem Browser mit JavaScript. Es werden niemals Dateidaten auf einen Server hochgeladen, in einer Datenbank gespeichert oder an Dritte weitergegeben. Es gibt keine Größenbeschränkung außer dem, was Ihr Browser verarbeiten kann: Dateien über 100 MB brauchen länger, verlassen aber niemals Ihr Gerät. Die gesamte ELF-Analyse, die Extraktion der Symboltabellen, die JNI-Erkennung und die Abschnittsanalyse erfolgen lokal. Exportieren Sie Analyseberichte als JSON, um Ergebnisse mit Ihrem Team zu teilen oder zu archivieren.
Häufig gestellte Fragen
Eine .so-Datei (Shared Object) ist eine native Bibliothek, die Android-Apps für performancekritischen Code in C oder C++ verwenden. Die Analyse von .so-Dateien zeigt die ELF-Struktur, importierte und exportierte Funktionen, aus Java/Kotlin aufrufbare JNI-Methoden und mögliche Sicherheitsprobleme. Da nativer Code direkten Speicherzugriff hat, ist die Analyse von .so-Dateien für Sicherheitsaudits und Malware-Analysen entscheidend.
Android unterstützt vier Hauptarchitekturen für native Bibliotheken: arm64-v8a (64-Bit-ARM, die meisten modernen Geräte), armeabi-v7a (32-Bit-ARM, ältere Geräte), x86_64 (64-Bit-Intel/AMD-Emulatoren und einige Tablets) und x86 (32-Bit-x86, ältere Emulatoren). Der Android Native Library Analyzer erkennt die Architektur automatisch anhand des Maschinentyp-Felds im ELF-Header.
JNI-Funktionen (Java Native Interface) sind C/C++-Funktionen, die aus Java oder Kotlin über die Namenskonvention Java_packagename_Class_method aufgerufen werden können. Sie verbinden die Android-App mit nativem Code. Der Analyzer erkennt alle JNI-Funktionen am Präfix Java_ und macht so die vollständige native API-Oberfläche jeder .so-Datei sichtbar.
Bei einer gestrippten Bibliothek wurden die Symbolnamen aus dem Abschnitt .symtab entfernt, während der Abschnitt .dynsym für das Laufzeit-Linking erhalten bleibt. Das ist bei Release-Builds üblich, erschwert aber das Reverse Engineering. Der Analyzer erkennt Stripping daran, ob benannte Symbole in der Symboltabelle vorhanden sind.
Absolut. Die gesamte ELF-Analyse, die Extraktion der Symboltabellen, die JNI-Erkennung und die Abschnittsanalyse erfolgen lokal in Ihrem Browser mit JavaScript. Ihre .so-Dateien werden nie auf einen Server hochgeladen, in einer Datenbank gespeichert oder über das Netzwerk übertragen.
Die GOT (Global Offset Table) und die PLT (Procedure Linkage Table) sind ELF-Abschnitte, die dynamisches Linking zur Laufzeit ermöglichen. Die GOT enthält Adressen globaler Variablen und aus anderen Bibliotheken importierter Funktionen. Die PLT enthält Stub-Code, der Funktionsadressen beim ersten Aufruf auflöst (Lazy Binding).
GNU_RELRO (Relocation Read-Only) ist ein Programm-Header, der Relocation-Daten als nur lesbar markiert, nachdem der dynamische Linker sie aufgelöst hat. Dadurch können Angreifer GOT-Einträge nicht überschreiben, um den Kontrollfluss zu übernehmen. Der Native-Library-Analyzer prüft diese Sicherheitsfunktion.
Ja, der Analyzer bietet zwei Exportoptionen: Bericht kopieren erzeugt eine Zusammenfassung als Klartext mit ELF-Header-Informationen, Symbolzahlen, Anzahl der JNI-Funktionen und Stripping-Status. JSON exportieren erstellt eine strukturierte JSON-Datei mit allen analysierten Daten für die weitere Auswertung.
Der Abschnitt .init_array enthält Zeiger auf Konstruktorfunktionen, die beim Laden der Bibliothek ausgeführt werden. Malware nutzt .init_array oft für Initialisierungsroutinen oder die Entschlüsselung von Payloads. Der Abschnitt .fini_array enthält Destruktoren, die beim Entladen der Bibliothek aufgerufen werden. Der Analyzer erkennt das Vorhandensein beider Abschnitte.