Android Native Library (.so) Analyzer
Analyze Android .so files online for free. Our native library analyzer parses ELF headers, symbol tables, JNI functions, imports, exports, and section headers. Fast, secure, and no signup required.
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.
Why Use Our Android Native Library (.so) Analyzer?
Complete ELF Header Parsing
The native library analyzer parses the full ELF header structure: identification magic, class (32/64-bit), data encoding (endianness), OS/ABI (Linux, Android, System V), machine type (ARM, AArch64, x86, x86-64), file type, entry point address, and program/section header table locations. All fields are decoded into readable labels with hex values shown alongside.
Comprehensive Symbol Table Analysis
Extract and display all symbols from both .symtab and .dynsym tables with their names, types (FUNC, OBJECT, NOTYPE), bindings (LOCAL, GLOBAL, WEAK), visibility (DEFAULT, HIDDEN, PROTECTED), addresses, sizes, and associated sections. Filter by exports, imports, JNI functions, or all symbols with a searchable interface.
JNI Function Detection & Analysis
Automatically detect Java Native Interface (JNI) functions by their Java_ naming convention. Each JNI function is highlighted with a special badge showing its full JNI-exported name. The analyzer extracts the package, class, and method components from each Java_ name for easy reference during reverse engineering.
Symbol Stripping & Security Analysis
Detect whether the .so file has been stripped of symbol names, a common obfuscation technique used in both legitimate release builds and malware. The analyzer also identifies key security features: GNU_RELRO program headers (relocation read-only), GOT/PLT sections, thread-local storage, exception handling tables, and .init_array constructors.
Common Use Cases for the Android Native Library Analyzer
Android Malware & Spyware Analysis
Reverse engineers analyze .so files from suspicious APKs to detect malicious native code. Malware often uses native libraries for payload execution, anti-analysis techniques, and privilege escalation. The native library analyzer reveals JNI functions with suspicious names, obfuscated symbol tables, and imported system functions that indicate malicious behavior.
App Security Review & Pentesting
Security auditors examine native libraries to verify that release builds are properly stripped, debug symbols are removed, and no sensitive function names are exposed. The analyzer helps identify leftover developer symbols, JNI functions that expose backend API logic, and imported functions that could be exploited for memory corruption.
Third-Party SDK Inspection
Analyze the native components of third-party Android SDKs before integration. The native library analyzer reveals what system functions the SDK imports, what JNI callbacks it registers, and whether it contains any unexpected exports. This is critical for SDKs that handle sensitive data like advertising IDs, device fingerprints, or analytics.
NDK Development & Debugging
Android NDK developers use the analyzer to verify their compiled .so files have the correct architecture (arm64-v8a, armeabi-v7a, x86_64), proper JNI function exports, and expected symbol visibility. It helps debug linkage issues, missing exports, and unintended symbol exposure before release.
Vulnerability Research & Exploit Development
Vulnerability researchers examine .so files for version information, identify specific library builds, and analyze imported functions to understand attack surface. The section header analysis reveals writable+executable segments, missing RELRO protection, and other memory corruption vulnerabilities.
ELF File Format Education
Students learning the ELF (Executable and Linkable Format) specification can see a real parsed ELF file with all headers, sections, and symbols displayed. The analyzer maps each ELF structure field to its specification definition, making it an excellent educational tool for understanding how shared libraries work on Linux and Android.
Understanding Android Native Libraries (.so Files)
What is an Android .so File?
An .so file (Shared Object) is the Android equivalent of a dynamic-link library on Linux. Android apps use native libraries written in C or C++ through the Android NDK (Native Development Kit) for performance-critical code, game engines, cryptography, signal processing, and third-party SDKs. These libraries follow the ELF (Executable and Linkable Format) specification, the same format used by Linux executables and shared libraries. Each .so file contains compiled machine code for a specific CPU architecture - ARM, ARM64, x86, or x86-64 - and is loaded into the app process at runtime via System.loadLibrary(). The native library analyzer parses this ELF structure to reveal headers, sections, symbols, and JNI functions.
How the Android Native Library Analyzer Works
- Upload your .so file: select any Android native library for analysis. The analyzer reads the raw binary ELF data directly in your browser with no server upload - all processing is local.
- ELF parsing: the tool reads the ELF identification magic (\\x7fELF), determines the class (32-bit or 64-bit) and endianness, then parses the entire ELF header including program headers (segments) and section headers. It follows the section header string table to resolve section names like .text, .data, .bss, .dynsym, and .init_array.
- Symbol extraction & analysis: the analyzer parses both the .symtab (symbol table) and .dynsym (dynamic symbol table) sections, resolving symbol names through the corresponding string tables (.strtab and .dynstr). Each symbol is classified by type, binding, and visibility. JNI functions (prefixed with Java_) are automatically detected and tagged, and the library is checked for symbol stripping.
Key ELF Structures You Will See
- ELF Header: the 52-64 byte header at the start of every .so file containing the magic number, class (32/64-bit), byte order, OS/ABI, machine type (ARM, AArch64, x86), and pointers to the program and section header tables.
- Program Headers: describe the segments loaded into memory at runtime. LOAD segments are mapped into the process address space. DYNAMIC contains dynamic linking information. GNU_RELRO makes relocation data read-only after loading. INTERP specifies the dynamic linker/loader path.
- Section Headers: describe the layout of the file at link time, including .text (executable code), .data (initialized data), .bss (uninitialized data), .dynsym/.dynstr (dynamic symbols), .init_array/.fini_array (constructor/destructor functions), .got/.got.plt (global offset table), .plt (procedure linkage table), and .ARM.exidx (ARM exception index).
- Symbol Tables: contain function and variable names with their addresses, sizes, types (FUNC, OBJECT, NOTYPE), and bindings (LOCAL, GLOBAL, WEAK). Dynamic symbols are used for runtime linking while regular symbols are used for debugging and can be stripped in release builds.
Privacy, Security & Usage Notes
The Android Native Library Analyzer processes all files entirely in your browser using JavaScript. No file data is ever uploaded to any server, stored in any database, or shared with any third party. There is no file size limit beyond what your browser can handle - files over 100 MB may take longer to process but will never leave your device. All ELF parsing, symbol table extraction, JNI detection, and section analysis happens locally. Export analysis reports as JSON to share findings with your team or keep for your records.
Related Android & Binary Analysis Tools
Android Manifest Analyzer
Analyze AndroidManifest.xml for permissions, component exposure, dangerous permission combinations, and security issues in app declarations.
Android APK Signing & Certificate Analyzer
Analyze APK signatures: v1/v2/v3, certificate fingerprints, issuer, validity, and detect signature fakery.
ELF Binary Analyzer
Analyze ELF headers, program/section headers, symbol tables, dynamic linking, and detect packed sections.
Binary Entropy Analyzer
Compute Shannon entropy of binary data to detect encryption, compression, and obfuscation in binary files.
Frequently Asked Questions About Android Native Library Analyzer
An .so file (Shared Object) is a native library used by Android apps for performance-critical code written in C or C++. Analyzing .so files reveals the ELF structure, imported and exported functions, JNI methods callable from Java/Kotlin, and potential security issues. Since native code has direct memory access, analyzing .so files is critical for security audits and malware analysis.
Android supports four main CPU architectures for native libraries: arm64-v8a (64-bit ARM, most modern devices), armeabi-v7a (32-bit ARM, older devices), x86_64 (64-bit Intel/AMD emulators and some tablets), and x86 (32-bit x86, older emulators). The Android Native Library Analyzer automatically detects the architecture from the ELF machine type field in the header.
JNI (Java Native Interface) functions are C/C++ functions that can be called from Java or Kotlin code using the Java_packagename_Class_method naming convention. They form the bridge between the Android app and native code. The analyzer detects all JNI functions by their Java_ prefix, making it easy to identify the complete native API surface of any .so file.
A stripped library has had its symbol names removed from the .symtab section while preserving the .dynsym section needed for runtime linking. This is standard for release builds but makes reverse engineering harder because function and variable names are no longer visible. The Android Native Library Analyzer detects stripping by checking whether named symbols exist in the symbol table.
Absolutely. All ELF parsing, symbol table extraction, JNI detection, and section analysis happens locally in your browser using JavaScript. Your .so files are never uploaded to any server, stored in any database, or transmitted over the network. You can safely analyze proprietary native libraries, third-party SDK modules, or sensitive malware samples without any privacy concerns.
The GOT (Global Offset Table) and PLT (Procedure Linkage Table) are ELF sections that enable runtime dynamic linking. The GOT holds addresses of global variables and functions imported from other libraries. The PLT contains stub code that resolves function addresses on first call (lazy binding). Their presence indicates dynamic imports from other system or app libraries.
GNU_RELRO (Relocation Read-Only) is a program header that marks relocation data as read-only after the dynamic linker has resolved it. This prevents attackers from overwriting GOT entries to hijack control flow. If a .so file lacks GNU_RELRO, it may be vulnerable to GOT overwrite attacks. The native library analyzer checks for this security feature.
Yes, the Android Native Library Analyzer provides two export options: Copy Report generates a plain-text summary of the ELF header information, symbol counts, JNI function count, and stripping status. Export JSON creates a structured JSON file with all parsed data including the complete ELF header, program/section header tables, and symbol listings for further analysis in other tools.
The .init_array section contains constructor function pointers that are executed automatically when the library is loaded. Malware often uses .init_array for initialization routines, anti-debugging checks, or payload decryption. The .fini_array section contains destructors called when the library is unloaded. The Android Native Library Analyzer detects the presence of both sections.