Analisador de Bibliotecas Nativas (.so) Android
Analise ficheiros .so do Android online e grátis. O nosso analisador de bibliotecas nativas lê cabeçalhos ELF, tabelas de símbolos, funções JNI, importações, exportações e cabeçalhos de secção. Rápido, seguro e sem cadastro.
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.
Por que usar o nosso Analisador de Bibliotecas Nativas (.so) Android?
- Leitura completa do cabeçalho ELF: o analisador de bibliotecas nativas lê toda a estrutura do cabeçalho ELF: magia de identificação, classe (32/64 bits), codificação de dados (endianness), SO/ABI (Linux, Android, System V), tipo de máquina (ARM, AArch64, x86, x86-64), tipo de ficheiro, endereço do ponto de entrada e localização das tabelas de cabeçalhos de programa e de secção. Todos os campos são descodificados em etiquetas legíveis, com os valores hexadecimais apresentados ao lado.
- Análise abrangente da tabela de símbolos: extraia e mostre todos os símbolos das tabelas .symtab e .dynsym com os seus nomes, tipos (FUNC, OBJECT, NOTYPE), ligações (LOCAL, GLOBAL, WEAK), visibilidades (DEFAULT, HIDDEN, PROTECTED), endereços, tamanhos e secções associadas. Filtre por exportações, importações, funções JNI ou todos os símbolos numa interface com pesquisa.
- Deteção e análise de funções JNI: deteta automaticamente as funções JNI (Java Native Interface) pela sua convenção de nomes Java_. Cada função JNI é destacada com um selo especial que mostra o seu nome JNI completo. O analisador extrai os componentes de pacote, classe e método de cada nome Java_ para fácil consulta durante a engenharia reversa.
- Análise de stripping e segurança: deteta se o ficheiro .so teve os nomes de símbolos removidos, uma técnica de ofuscação comum tanto em compilações de lançamento legítimas como em malware. O analisador também identifica funcionalidades de segurança essenciais: cabeçalhos de programa GNU_RELRO (relocalização apenas de leitura), secções GOT/PLT, armazenamento local de threads, tabelas de tratamento de exceções e construtores .init_array.
Casos de uso comuns do Analisador de Bibliotecas Nativas Android
- Análise de malware e spyware Android: os engenheiros reversos analisam ficheiros .so de APK suspeitos para detetar código nativo malicioso. O malware usa frequentemente bibliotecas nativas para executar payloads, aplicar técnicas anti-análise e escalar privilégios. O analisador de bibliotecas nativas revela funções JNI com nomes suspeitos, tabelas de símbolos ofuscadas e funções de sistema importadas que indicam comportamento malicioso.
- Revisão de segurança de aplicações e pentesting: os auditores de segurança examinam bibliotecas nativas para verificar que as compilações de lançamento estão devidamente stripped, que os símbolos de depuração foram removidos e que não ficaram nomes de funções sensíveis expostos. O analisador ajuda a identificar símbolos de programador esquecidos, funções JNI que expõem lógica de API do backend e funções importadas que podem ser exploradas para corromper memória.
- Inspeção de SDK de terceiros: analise os componentes nativos de SDK Android de terceiros antes de os integrar. O analisador de bibliotecas nativas revela que funções de sistema o SDK importa, que callbacks JNI regista e se contém exportações inesperadas. Isto é essencial para SDK que tratam dados sensíveis como identificadores publicitários, impressões digitais de dispositivos ou analítica.
- Desenvolvimento e depuração com NDK: os programadores de Android NDK usam o analisador para verificar que os seus ficheiros .so compilados têm a arquitetura correta (arm64-v8a, armeabi-v7a, x86_64), as exportações de funções JNI adequadas e a visibilidade de símbolos esperada. Ajuda a depurar problemas de ligação, exportações em falta e exposição acidental de símbolos antes do lançamento.
- Investigação de vulnerabilidades e desenvolvimento de exploits: os investigadores examinam ficheiros .so para obter informação de versão, identificar compilações específicas de bibliotecas e analisar funções importadas para compreender a superfície de ataque. A análise dos cabeçalhos de secção revela segmentos graváveis e executáveis, ausência de proteção RELRO e outras vulnerabilidades de corrupção de memória.
- Aprendizagem do formato ELF: os estudantes que aprendem a especificação ELF (Executable and Linkable Format) podem ver um ficheiro ELF real analisado, com todos os cabeçalhos, secções e símbolos apresentados. O analisador associa cada campo da estrutura ELF à sua definição na especificação, tornando-o numa excelente ferramenta didática para compreender como funcionam as bibliotecas partilhadas em Linux e Android.
O que é um ficheiro .so do Android?
Um ficheiro .so (Shared Object) é o equivalente Android de uma biblioteca de ligação dinâmica no Linux. As aplicações Android usam bibliotecas nativas escritas em C ou C++ através do Android NDK (Native Development Kit) para código crítico de desempenho, motores de jogos, criptografia, processamento de sinal e SDK de terceiros. Estas bibliotecas seguem a especificação ELF (Executable and Linkable Format), o mesmo formato usado pelos executáveis e bibliotecas partilhadas do Linux. Cada ficheiro .so contém código máquina compilado para uma arquitetura de CPU específica - ARM, ARM64, x86 ou x86-64 - e é carregado no processo da aplicação em tempo de execução através de System.loadLibrary(). O analisador de bibliotecas nativas lê esta estrutura ELF para revelar cabeçalhos, secções, símbolos e funções JNI.
Como funciona o Analisador de Bibliotecas Nativas Android
- Carregue o seu ficheiro .so: selecione qualquer biblioteca nativa Android para análise. O analisador lê os dados binários ELF diretamente no seu navegador, sem envio para servidores - todo o processamento é local.
- Leitura ELF: a ferramenta lê a magia de identificação ELF (\x7fELF), determina a classe (32 ou 64 bits) e o endianness e depois lê todo o cabeçalho ELF, incluindo os cabeçalhos de programa (segmentos) e de secção. Segue a tabela de cadeias dos cabeçalhos de secção para resolver nomes como .text, .data, .bss, .dynsym e .init_array.
- Extração e análise de símbolos: o analisador lê tanto a secção .symtab (tabela de símbolos) como a .dynsym (tabela de símbolos dinâmicos), resolvendo os nomes através das tabelas de cadeias correspondentes (.strtab e .dynstr). Cada símbolo é classificado por tipo, ligação e visibilidade. As funções JNI (com prefixo Java_) são detetadas e etiquetadas automaticamente, e a biblioteca é verificada quanto à remoção de símbolos.
Estruturas ELF essenciais que vai ver
- Cabeçalho ELF: o cabeçalho de 52-64 bytes no início de cada ficheiro .so, que contém o número mágico, a classe (32/64 bits), a ordem dos bytes, o SO/ABI, o tipo de máquina (ARM, AArch64, x86) e os ponteiros para as tabelas de cabeçalhos de programa e de secção.
- Cabeçalhos de programa: descrevem os segmentos carregados em memória em tempo de execução. Os segmentos LOAD são mapeados no espaço de endereçamento do processo. DYNAMIC contém informação de ligação dinâmica. GNU_RELRO torna os dados de relocalização apenas de leitura depois do carregamento. INTERP especifica o caminho do linker/carregador dinâmico.
- Cabeçalhos de secção: descrevem a disposição do ficheiro em tempo de ligação, incluindo .text (código executável), .data (dados inicializados), .bss (dados não inicializados), .dynsym/.dynstr (símbolos dinâmicos), .init_array/.fini_array (funções construtoras/destruidoras), .got/.got.plt (tabela de deslocamento global), .plt (tabela de ligação de procedimentos) e .ARM.exidx (índice de exceções ARM).
- Tabelas de símbolos: contêm nomes de funções e variáveis com os seus endereços, tamanhos, tipos (FUNC, OBJECT, NOTYPE) e ligações (LOCAL, GLOBAL, WEAK). Os símbolos dinâmicos são usados na ligação em tempo de execução, enquanto os símbolos normais servem para depuração e podem ser removidos em compilações de lançamento.
Privacidade, segurança e notas de utilização
O Analisador de Bibliotecas Nativas Android processa todos os ficheiros inteiramente no seu navegador com JavaScript. Nenhum dado de ficheiro é carregado para qualquer servidor, guardado em qualquer base de dados ou partilhado com terceiros. Não há limite de tamanho além do que o seu navegador consegue processar: ficheiros com mais de 100 MB podem demorar mais a processar, mas nunca sairão do seu dispositivo. Toda a análise ELF, a extração das tabelas de símbolos, a deteção de JNI e a análise de secções acontece localmente. Exporte os relatórios de análise em JSON para partilhar conclusões com a sua equipa ou guardar para registo.
Perguntas frequentes
Um ficheiro .so (Shared Object) é uma biblioteca nativa usada por aplicações Android para código crítico de desempenho escrito em C ou C++. Analisar ficheiros .so revela a estrutura ELF, as funções importadas e exportadas, os métodos JNI chamáveis a partir de Java/Kotlin e potenciais problemas de segurança. Como o código nativo tem acesso direto à memória, analisar ficheiros .so é essencial para auditorias de segurança e análise de malware.
O Android suporta quatro arquiteturas principais para bibliotecas nativas: arm64-v8a (ARM de 64 bits, a maioria dos dispositivos modernos), armeabi-v7a (ARM de 32 bits, dispositivos mais antigos), x86_64 (emuladores Intel/AMD de 64 bits e alguns tablets) e x86 (x86 de 32 bits, emuladores antigos). O Analisador de Bibliotecas Nativas Android deteta automaticamente a arquitetura a partir do campo de tipo de máquina do cabeçalho ELF.
As funções JNI (Java Native Interface) são funções C/C++ chamáveis a partir de Java ou Kotlin usando a convenção de nomes Java_packagename_Class_method. Fazem a ponte entre a aplicação Android e o código nativo. O analisador deteta todas as funções JNI pelo prefixo Java_, o que facilita identificar a superfície completa de API nativa de qualquer ficheiro .so.
Uma biblioteca stripped teve os nomes dos símbolos removidos da secção .symtab, mantendo a secção .dynsym para a ligação em tempo de execução. É comum em compilações de lançamento, mas dificulta a engenharia reversa. O analisador deteta o stripping verificando se existem símbolos com nome na tabela de símbolos.
Absolutamente. Toda a análise ELF, a extração das tabelas de símbolos, a deteção de JNI e a análise de secções acontece localmente no seu navegador com JavaScript. Os seus ficheiros .so nunca são carregados para nenhum servidor, guardados em qualquer base de dados ou transmitidos pela rede.
A GOT (Global Offset Table) e a PLT (Procedure Linkage Table) são secções ELF que permitem a ligação dinâmica em tempo de execução. A GOT contém os endereços de variáveis globais e funções importadas de outras bibliotecas. A PLT contém código auxiliar que resolve os endereços das funções na primeira chamada (ligação preguiçosa).
GNU_RELRO (Relocation Read-Only) é um cabeçalho de programa que marca os dados de relocalização como apenas de leitura depois de o linker dinâmico os ter resolvido. Isto impede que os atacantes sobrescrevam entradas da GOT para sequestrar o fluxo de controlo. O analisador de bibliotecas nativas verifica esta funcionalidade de segurança.
Sim, o analisador oferece duas opções de exportação: Copiar relatório gera um resumo em texto simples com a informação do cabeçalho ELF, as contagens de símbolos, o número de funções JNI e o estado de stripping. Exportar JSON cria um ficheiro JSON estruturado com todos os dados analisados para análise posterior.
A secção .init_array contém ponteiros para funções construtoras executadas quando a biblioteca é carregada. O malware usa frequentemente .init_array para rotinas de inicialização ou desencriptação de payloads. A secção .fini_array contém destrutores chamados ao descarregar a biblioteca. O analisador deteta a presença de ambas as secções.