御盾Conclusões e condições de decisão
- Registre dependências diretas e transitivas, pontos de entrada de carregamento, timing de inicialização, APIs alvo mínimas e chamadores para cada SO.
- A descoberta estática de nomes JNI e o registro dinâmico via RegisterNatives possuem restrições diferentes; verifique o método de vinculação real antes de processar os nomes.
- arm64-v8a, armeabi-v7a e x86_64 representam artefatos e matrizes de compatibilidade distintos; o sucesso em uma arquitetura não se extrapola para as demais.
- A aceitação da força de proteção e a estabilidade em tempo de execução devem estar vinculadas ao mesmo APK final, assinatura e conjunto de SO.
Mapeie primeiro o Grafo de Dependências ELF e a Linha do Tempo de Carregamento Real
Um aplicativo Android pode compreender bibliotecas principais, bibliotecas de lógica de negócio, bibliotecas de algoritmos, SDKs de terceiros e bibliotecas do sistema. Código Java ou Kotlin pode invocar diretamente System.loadLibrary, enquanto bibliotecas principais podem carregar outras bibliotecas via dependências ELF ou carregamento em tempo de execução. O ponto final de falha pode estar fora da biblioteca protegida, pois a resolução de símbolos e a ordem de inicialização são determinadas por toda a cadeia de dependências.
O grafo de dependências deve registrar arquivos de biblioteca por ABI, relações DT_NEEDED, níveis mínimos de API do sistema, pontos de entrada de carregamento, funções de inicialização, interfaces exportadas e chamadores. Adicionalmente, marque se as bibliotecas são de desenvolvimento próprio, dependências de código aberto ou SDKs de código fechado, pois isso define os limites para modificação e responsabilidade pelos testes de regressão.
A documentação do Android NDK afirma que símbolos nativos são tipicamente resolvidos durante o carregamento da biblioteca. Se o código referenciar uma API ausente no sistema alvo, o dlopen pode falhar imediatamente, mesmo que ramificações em tempo de execução sugiram que o caminho de código não seria executado. Portanto, a versão mínima da API NDK e a versão do sistema do dispositivo devem ser incluídas no grafo de dependências.
| Campo | O que Registrar | Impacto no Endurecimento | Método de Verificação |
|---|---|---|---|
| Biblioteca e Origem | Biblioteca principal, dependências transitivas, terceiros e bibliotecas do sistema | Determina o escopo modificável e a responsabilidade pela regressão | Desempacote e verifique contra cada ABI no APK final |
| Entrada de Carregamento | Dependências estáticas, System.loadLibrary ou dlopen em tempo de execução | Determina o estágio mais cedo de falha e a localização do log | Registre a linha do tempo de inicialização e os resultados de carregamento |
| Versão Mínima da API (API Floor) | APP_PLATFORM de build e símbolos do sistema utilizados | Símbolos ausentes podem ocorrer no momento do carregamento se superiores à API do dispositivo | Inicialização em dispositivo real nos sistemas alvo e verificação de símbolos |
| Ordem de Inicialização | JNI_OnLoad, construtores e inicialização de negócio | Alterações no layout de código ou no timing podem amplificar dependências implícitas | Compare as linhas do tempo entre builds sem proteção e candidatas a lançamento (release candidate) |
| Exceções e Threads | Exceções C++, propriedade de thread, uso de JNIEnv | Erros entre bibliotecas e entre threads frequentemente causam falhas imediatas | CheckJNI, pilhas com símbolos e testes de regressão de negócio |
Registro Estático vs. Dinâmico Define os Limites de Processamento de Símbolos
O JNI pode descobrir métodos nativos via convenções de nomenclatura ou estabelecer mapeamentos entre métodos Java e endereços de função usando RegisterNatives durante a inicialização. O registro estático depende de nomes exportados previsíveis; o registro dinâmico tipicamente requer expor apenas alguns pontos de entrada de inicialização, mas depende da busca de classes, assinaturas de métodos, timing de registro e da thread de carregamento.
Se o endurecimento ou o processamento de símbolos alterar nomes de registro estático, o sistema pode falhar ao localizar a implementação nativa. Da mesma forma, alterações nas assinaturas de métodos, regras de retenção de nomes de classes ou na ordem de inicialização na tabela de registro dinâmico podem causar falhas antes da primeira invocação de função. Apenas verificar a contagem de símbolos exportados não prova que as ligações JNI permanecem corretas.
As diretrizes oficiais de JNI do Android também alertam que JNIEnv possui restrições de thread; exceções pendentes, referências inválidas e uso entre threads podem levar a travamentos. Os testes de regressão pós-endurecimento devem cobrir threads reais e caminhos de exceção, não apenas invocar um método de demonstração sem parâmetros.
| Método de Registro | Dependências | Pontos Sensíveis ao Endurecimento | Verificação Mínima |
|---|---|---|---|
| Descoberta de Nome Estático | Nome da classe Java, nome do método, assinatura e símbolos exportados | Renomeação, símbolos ocultos e incompatibilidades de assinatura | Invocar cada ponto de entrada crítico e verificar erros de vinculação |
| RegisterNatives | Pesquisa de classe, assinaturas de método, tabela de registro e timing de inicialização | Processamento de nome de classe, ordem de registro e alterações no endereço da função | Confirmar conclusão do registro e executar cenários reais de entrada/saída |
| Wrappers de Terceiros | Regras internas de SDK e implementações de código fechado | Autovalidação, exportações implícitas e diferenças de versão | Verificar contra matrizes de suporte do fornecedor e cenários do mundo real |
- Listar mapeamentos chave de Java para Nativo
- Confirmar método de registro estático ou dinâmico
- Manter regras necessárias de nome de classe e assinatura
- Verificar exceções, threads e ciclos de vida de referências
ABI Deve Ser Aceita como Artefatos de Release Independentes
ABI é mais do que um rótulo de diretório. A documentação oficial do NDK Android especifica que a ABI define o conjunto de instruções, endianness, convenções de chamada, uso de pilha e registradores, formato de arquivo executável e name mangling em C++. arm64-v8a e armeabi-v7a diferem em código de máquina e dependências; passar em um emulador x86_64 não representa sucesso em dispositivos ARM reais.
Para cada ABI, confirme que todas as dependências diretas e transitivas existem, que o piso da API da biblioteca é compatível com o sistema alvo e que as ferramentas de empacotamento não excluíram erroneamente arquivos para uma arquitetura específica. Se apenas a biblioteca principal incluir arm64-v8a enquanto uma dependência de terceiro carece do artefato correspondente, a aplicação ainda falhará durante o carregamento.
Se o produto planeja suportar apenas um subconjunto de ABIs, declare isso explicitamente nas notas de release, configurações da loja de aplicativos e escopos de teste. Arquiteturas que não foram construídas, não instaladas ou onde caminhos JNI críticos não foram executados devem ser marcadas como não cobertas; o sucesso da compilação não pode substituir evidências de tempo de execução.
| Item de Verificação | arm64-v8a | armeabi-v7a | x86_64 | Regra de Decisão |
|---|---|---|---|---|
| Todas as Dependências Presentes | Verificar por biblioteca | Verificar por escopo de release | Verificar apenas se necessário | Bloquear se qualquer dependência requerida estiver faltando |
| Carregável no Sistema Mínimo | Dispositivo real com API alvo | Dispositivo real com API alvo | Emulador ou dispositivo | Não validar exclusivamente no sistema mais recente |
| Caminhos JNI Críticos | Entrada/saída real | Entrada/saída real | Não pode substituir resultados ARM | Registrar independentemente para cada ABI liberada |
| Atribuição de Travamento | Manter símbolos correspondentes | Manter símbolos correspondentes | Manter símbolos correspondentes | Os símbolos devem corresponder ao mesmo release candidate |
Quais Condições de Runtime Nativo a Proteção Afeta?
Ocultação de símbolos reduz pistas estáticas, processamento de strings diminui a exposição em texto simples e virtualização de fluxo de controle ou de funções altera a forma de execução do código selecionado. Essas técnicas impactam de forma diferente símbolos exportados, limites de função, desenrolamento de exceções, chamadas indiretas, alinhamento e desempenho. Menos símbolos após o processamento não representam proteção nativa completa, nem a capacidade de ler a biblioteca nega todos os efeitos da proteção.
Inicialização do aplicativo, tratamento de sinais, exceções C++, callbacks, estado local da thread, busca reflexiva de símbolos e autovalidação de SDKs de terceiros são áreas de alta sensibilidade. Ao definir o escopo, priorize funções de negócio com entrada/saída claras, frequência de chamadas mensurável e falhas isoláveis. Evite processar toda a cadeia de inicialização no primeiro PoC.
As configurações de proteção devem registrar a justificativa, fase de chamada, ABI, dependências, orçamento de desempenho e grupo de rollback para cada função ou grupo de funções. O exemplo a seguir demonstra apenas o formato de uma lista de verificação pública e segura, excluindo símbolos internos ou sintaxe de configuração do produto.
native_group: protocol-core-v1
abis: [arm64-v8a, armeabi-v7a]
load_phase: post-authentication
jni_registration: dynamic
execution:
frequency: bounded
main_thread: false
dependencies:
- business-runtime
- system-crypto
acceptance:
- dependency-resolution
- jni-registration
- exception-path
- output-parity
- latency-budget
rollback: native-group-v0Localização de Travamentos Pós-Hardening de SO Usando a Primeira Diferença
Ao solucionar problemas, primeiro fixe a identidade do arquivo, assinatura, dispositivo, sistema, método de instalação e entrada de negócio tanto para a linha de base sem proteção quanto para o release candidate. Em seguida, busque na linha do tempo a primeira diferença: criação do processo, início do Application, carregamento de biblioteca, JNI_OnLoad, conclusão do registro, primeira invocação nativa ou retorno chave de negócio. A última entrada no log de travamento pode ser apenas uma reação em cadeia.
UnsatisfiedLinkError geralmente indica bibliotecas ausentes, incompatibilidades de ABI, problemas de dependência ou falhas na resolução de símbolos; erros de registro podem se manifestar como métodos nativos faltantes; JNIEnv incorreto, referências inválidas ou exceções pendentes podem causar travamentos durante invocações de negócio. Mantenha símbolos nativos correspondentes ao release candidate para atribuição interna, mas não exponha símbolos reais ou endereços em relatórios públicos.
O CheckJNI pode ajudar a detectar alguns usos indevidos de JNI, mas é uma ferramenta de diagnóstico, não uma representação do estado de runtime em produção, e não cobre todos os problemas de memória nativa e concorrência. Após as correções, você deve reexecutar os caminhos críticos sob a configuração de release alvo.
| Primeiro Sintoma | Verificações Prioritárias | Evidência Obrigatória | O Que Não Fazer Primeiro |
|---|---|---|---|
| Falha no dlopen | ABI, DT_NEEDED, piso de API e símbolos | Lista de bibliotecas e erros de carregamento correspondentes ao release candidate | Alternar repetidamente chaves de proteção não relacionadas |
| Método Nativo Não Encontrado | Método de registro, nome da classe, assinatura do método e timing | Tabela de registro, regras de retenção e pontos de entrada de chamada | Olhar apenas para contagens de símbolos exportados |
| Travamento na Primeira Invocação | Parâmetros, referências, threads, exceções e processamento de funções | Stack simbolizada, entradas e comparação com a linha de base | Explicar usando arquivos de símbolos de outra versão |
| Falha em Alguns Dispositivos | API do sistema, diferenças de fornecedor, ABI e bibliotecas de terceiros | Matriz de sistemas de dispositivos e primeiras diferenças | Substituir conclusões de dispositivos reais pelo sucesso em emuladores |
Conclusões de Release Devem Abranger Robustez, Compatibilidade e Manutenibilidade
A observação de robustez estática pode registrar mudanças em símbolos, strings, estrutura de código e superfície de exposição de pontos de entrada chave; a aceitação em runtime verifica carregamento, JNI, lógica de negócio crítica, exceções e ABIs alvo. Esses dois tipos de evidência se complementam; nenhum substitui o outro.
O release candidate final também deve concluir atualizações de instalação, verificação de assinatura, checagens de canal, testes de inicialização, monitoramento de travamentos, arquivamento de símbolos nativos e simulacros de rollback. Os arquivos de símbolos devem permitir encontrar a versão correspondente via identidade do arquivo; caso contrário, travamentos nativos online não poderão ser corretamente simbolizados.
Este artigo fornece um framework de inspeção de engenharia, não conclusões de teste para um SO ou configuração de proteção específica. Sem um pacote alvo, ABI alvo e caminhos de chamada reais, só é possível avaliar se o trabalho de preparação está completo, sem prometer compatibilidade ou desempenho.
- Cada ABI liberada possui evidência de runtime
- Pontos de entrada JNI críticos cobrem caminhos normais e de exceção
- Símbolos nativos correspondem à identidade do candidato final
- Resultados de carregamento, negócio e rollback são reproduzíveis
- Dispositivos e sistemas não cobertos são explicitamente restritos
Evidências e limites de aplicabilidade
Esta seção separa fatos documentados da plataforma, julgamento de engenharia e limites que não podem ser generalizados em declarações de produtos não verificadas.
| Julgamento do artigo | Fato ou base de engenharia | Limite de aplicabilidade |
|---|---|---|
| A ABI deve ser aceita como uma dimensão independente de artefato. | O NDK oficial do Android define a ABI abrangendo conjuntos de instruções, convenções de chamada, registradores, pilha, formato ELF e ofuscação de nomes. | Definições na documentação não provam que o aplicativo inclui dependências completas ou executa com sucesso nos dispositivos alvo. |
| Referências à API nativa superiores ao sistema do dispositivo podem falhar no momento do carregamento. | A documentação de problemas comuns do NDK afirma que os símbolos são tipicamente resolvidos no carregamento da biblioteca; referenciar APIs inexistentes não pode ser contornado por ramificação em tempo de execução. | Falhas específicas ainda devem ser confirmadas via parâmetros de build, dependências e logs do dispositivo. |
| Erros de JNI exigem validação nos níveis de thread, referência e exceção. | As diretrizes de JNI do Android listam problemas como JNIEnv inválido, referências, exceções pendentes e registro de métodos que podem causar travamentos. | O CheckJNI apenas auxilia na detecção de um subconjunto de problemas e não substitui testes abrangentes de lógica de negócio e segurança de memória. |
| Resultados de um único emulador x86_64 não podem ser extrapolados para dispositivos reais ARM. | Diferentes ABIs utilizam conjuntos de instruções e convenções de chamada distintos; as combinações finais de bibliotecas e dependências também podem variar. | Se o produto explicitamente não lançar uma determinada ABI, ela pode ser marcada como não aplicável em vez de testada obrigatoriamente. |
| A força da proteção e a compatibilidade devem ser validadas no mesmo release candidate. | Reconstruir ou substituir arquivos SO altera código, símbolos, dependências e o comportamento potencial em tempo de execução. | Este é um princípio de governança de artefatos e não implica que qualquer nível específico de proteção foi aprovado. |
Perguntas de engenharia
Se houver apenas um SO principal, um grafo de dependências ainda é necessário?
Sim. O SO principal ainda pode depender de bibliotecas do sistema, runtimes C++ ou bibliotecas de terceiros e interagir com a camada Java via JNI. O grafo de dependências confirma o ponto de carregamento mais cedo e os limites de responsabilidade.
Se a arm64-v8a passar, ainda preciso testar a armeabi-v7a?
Se o pacote de lançamento incluir e suportar a armeabi-v7a, verificação independente é necessária. As instruções, convenções de chamada e artefatos de dependência das duas ABIs diferem e não podem substituir umas às outras.
Ocultar todos os símbolos exportados é mais seguro?
Não necessariamente. Pontos de entrada estáticos necessários da JNI, chamadas de terceiros e convenções do sistema podem depender de símbolos exportados. Confirme primeiro os métodos de registro e chamada, então minimize a exposição.
Posso lançar se o CheckJNI não reportar erros?
Não, isso sozinho é insuficiente para o lançamento. Você deve também verificar a configuração real do alvo, entradas de negócio, caminhos de exceção, ABI, escopo do sistema, atualizações de instalação e capacidades de rollback.
Devo desativar toda a proteção imediatamente após um travamento no hardening do SO?
Primeiro fixe a identidade do candidate e encontre a diferença mais antiga. Você pode fazer busca binária em grupos de proteção ou realizar rollback, mas altere apenas uma variável registrável por vez para evitar gerar novos artefatos não atribuíveis.
Quer testar isso em seu próprio aplicativo?
Envie o release candidate, os sistemas de destino e os caminhos críticos de negócios para um Yudun PoC e avaliação de compatibilidade.
Continuar com: Lista de verificação de proteção e compatibilidade nativa SO