- Você trabalha em uma **empresa de segurança cibernética**? Você quer ver sua **empresa anunciada no HackTricks**? ou você quer ter acesso à **última versão do PEASS ou baixar o HackTricks em PDF**? Confira os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!
- Descubra [**A Família PEASS**](https://opensea.io/collection/the-peass-family), nossa coleção exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
- **Junte-se ao** [**💬**](https://emojipedia.org/speech-balloon/) [**grupo do Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo do telegram**](https://t.me/peass) ou **siga-me** no **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
- **Compartilhe suas técnicas de hacking enviando PRs para o [repositório hacktricks](https://github.com/carlospolop/hacktricks) e [hacktricks-cloud repo](https://github.com/carlospolop/hacktricks-cloud)**.
Os aplicativos Android podem conter bibliotecas nativas compiladas. As bibliotecas nativas são códigos que o desenvolvedor escreveu e depois compilou para uma arquitetura de computador específica. Na maioria das vezes, isso significa código escrito em C ou C++. As razões benignas, ou legítimas, pelas quais um desenvolvedor pode fazer isso é para operações matematicamente intensivas ou sensíveis ao tempo, como bibliotecas gráficas. Os desenvolvedores de malware começaram a migrar para o código nativo porque a engenharia reversa de binários compilados tende a ser um conjunto de habilidades menos comum do que a análise do bytecode DEX. Isso se deve em grande parte ao fato de que o bytecode DEX pode ser descompilado para Java, enquanto o código nativo compilado geralmente deve ser analisado como assembly.
O objetivo desta seção não é ensinar assembly (ASM) ou como engenharia reversa de código compilado de forma mais geral, mas sim como aplicar as habilidades de engenharia reversa binária mais gerais, especificamente para Android. Como o objetivo deste workshop não é ensinar as arquiteturas ASM, todos os exercícios incluirão uma versão ARM _e_ uma versão x86 da biblioteca a ser analisada para que cada pessoa possa escolher a arquitetura com a qual se sinta mais confortável.
Se você não tem experiência anterior em engenharia reversa binária / assembly, aqui estão alguns recursos sugeridos. A maioria dos dispositivos Android roda em ARM, mas todos os exercícios deste workshop também incluem uma versão x86 da biblioteca.
Para aprender e / ou revisar a assembleia ARM, eu sugiro fortemente o [ARM Assembly Basics](https://azeria-labs.com/writing-arm-assembly-part-1/) do [Azeria Labs](https://azeria-labs.com).
A Interface Nativa do Java (JNI) permite que os desenvolvedores declarem métodos Java que são implementados em código nativo (geralmente compilado em C/C++). A interface JNI não é específica do Android, mas está disponível mais geralmente para aplicativos Java que são executados em diferentes plataformas.
O Android Native Development Kit (NDK) é o conjunto de ferramentas específico do Android em cima do JNI. De acordo com a [documentação](https://developer.android.com/ndk/guides):
> No Android, o Kit de Desenvolvimento Nativo (NDK) é um conjunto de ferramentas que permite que os desenvolvedores escrevam código C e C++ para seus aplicativos Android.
Juntos, JNI e NDK permitem que os desenvolvedores Android implementem parte da funcionalidade de seus aplicativos em código nativo. O código Java (ou Kotlin) chamará um método nativo declarado em Java que é implementado na biblioteca nativa compilada.
* [Funções JNI](https://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/functions.html) <– Eu sempre tenho este aberto e me refiro a ele ao reverter bibliotecas nativas do Android
* [Dicas do JNI do Android](https://developer.android.com/training/articles/perf-jni) <– Altamente sugiro ler a seção "Bibliotecas nativas" para começar
* [Introdução ao NDK](https://developer.android.com/ndk/guides/) <– Este é um guia para como os desenvolvedores desenvolvem bibliotecas nativas e entender como as coisas são construídas, torna mais fácil reverter.
Para esta seção, estamos nos concentrando em como reverter a funcionalidade do aplicativo que foi implementada em bibliotecas nativas do Android. Quando dizemos bibliotecas nativas do Android, o que queremos dizer?
As bibliotecas nativas do Android são incluídas nos APKs como bibliotecas de objeto compartilhado `.so`, no formato de arquivo ELF. Se você já analisou binários Linux anteriormente, é o mesmo formato.
Essas bibliotecas por padrão são incluídas no APK no caminho do arquivo `/lib/<cpu>/lib<name>.so`. Este é o caminho padrão, mas os desenvolvedores também podem optar por incluir a biblioteca nativa em `/assets/<custom_name>` se assim o desejarem. Com mais frequência, estamos vendo desenvolvedores de malware escolherem incluir bibliotecas nativas em caminhos diferentes de `/lib` e usando diferentes extensões de arquivo para tentar "ocultar" a presença da biblioteca nativa.
Como o código nativo é compilado para CPUs específicas, se um desenvolvedor quiser que seu aplicativo seja executado em mais de um tipo de hardware, ele terá que incluir cada uma dessas versões da biblioteca nativa compilada no aplicativo. O caminho padrão mencionado acima inclui um diretório para cada tipo de CPU oficialmente suportado pelo Android.
Antes que um aplicativo Android possa chamar e executar qualquer código que seja implementado em uma biblioteca nativa, o aplicativo (código Java) deve carregar a biblioteca na memória. Existem duas chamadas de API diferentes que farão isso:
A diferença entre as duas chamadas de API é que `loadLibrary` só recebe o nome curto da biblioteca como argumento (ou seja, libcalc.so = "calc" e libinit.so = "init") e o sistema determinará corretamente a arquitetura em que está sendo executado e, portanto, o arquivo correto a ser usado. Por outro lado, `load` requer o caminho completo para a biblioteca. Isso significa que o desenvolvedor do aplicativo tem que determinar a arquitetura e, portanto, o arquivo de biblioteca correto a ser carregado.
Quando qualquer um desses dois APIs (`loadLibrary` ou `load`) é chamado pelo código Java, a biblioteca nativa que é passada como argumento executa seu `JNI_OnLoad` se ele foi implementado na biblioteca nativa.
Para reiterar, antes de executar quaisquer métodos nativos, a biblioteca nativa deve ser carregada chamando `System.loadLibrary` ou `System.load` no código Java. Quando qualquer um desses 2 APIs é executado, a função `JNI_OnLoad` na biblioteca nativa também é executada.
Para executar uma função da biblioteca nativa, deve haver um método nativo declarado em Java que o código Java possa chamar. Quando este método nativo declarado em Java é chamado, a função nativa "pareada" da biblioteca nativa (ELF/.so) é executada.
Um método nativo declarado em Java aparece no código Java como abaixo. Ele aparece como qualquer outro método Java, exceto que inclui a palavra-chave `native` e não tem código em sua implementação, porque seu código está realmente na biblioteca nativa compilada.
Para chamar este método nativo, o código Java o chamaria como qualquer outro método Java. No entanto, nos bastidores, o JNI e o NDK executariam a função correspondente na biblioteca nativa. Para isso, é necessário conhecer a associação entre um método nativo declarado em Java e uma função na biblioteca nativa.
Para vincular, ou associar, o método nativo declarado em Java e a função na biblioteca nativa dinamicamente, o desenvolvedor nomeia o método e a função de acordo com as especificações para que o sistema JNI possa fazer a vinculação dinamicamente.
De acordo com a especificação, o desenvolvedor nomearia a função da seguinte forma para que o sistema possa vincular dinamicamente o método nativo e a função. Um nome de método nativo é concatenado a partir dos seguintes componentes:
Se o desenvolvedor não quiser ou não puder nomear as funções nativas de acordo com a especificação (por exemplo, deseja remover símbolos de depuração), ele deve usar a vinculação estática com a API `RegisterNatives` ([doc](https://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/functions.html#wp5833)) para fazer a associação entre o método nativo declarado em Java e a função na biblioteca nativa. A função `RegisterNatives` é chamada a partir do código nativo, não do código Java, e é mais frequentemente chamada na função `JNI_OnLoad`, uma vez que `RegisterNatives` deve ser executado antes de chamar o método nativo declarado em Java.
Ao realizar engenharia reversa, se a aplicação estiver usando o método de vinculação estática, nós, como analistas, podemos encontrar a estrutura `JNINativeMethod` que está sendo passada para `RegisterNatives` para determinar qual sub-rotina na biblioteca nativa é executada quando o método nativo declarado em Java é chamado.
A estrutura `JNINativeMethod` requer uma string com o nome do método nativo declarado em Java e uma string com a assinatura do método, então devemos ser capazes de encontrar essas informações em nossa biblioteca nativa.
A estrutura `JNINativeMethod` requer a assinatura do método. Uma assinatura do método indica os tipos dos argumentos que o método recebe e o tipo do que ele retorna. Este link documenta [Assinaturas de Tipo JNI](https://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/types.html) na seção "Assinaturas de Tipo".
No Exercício #5, vamos aprender a carregar bibliotecas nativas em um desmontador e identificar a função nativa que é executada quando um método nativo é chamado. Para este exercício em particular, o objetivo não é engenharia reversa do método nativo, apenas encontrar o link entre a chamada ao método nativo em Java e a função que é executada na biblioteca nativa. Para este exercício, usaremos o aplicativo de amostra Mediacode.apk. Esta amostra está disponível em `~/samples/Mediacode.apk` na VM. Seu hash SHA256 é a496b36cda66aaf24340941da8034bd53940d1b08d83a97f17a65ae144ebf91a.
1. Abra o Mediacode.apk no jadx. Consulte o [Exercício #1](https://maddiestone.github.io/AndroidAppRE/reversing_intro.html#exercise-1---beginning-re-with-jadx) para obter mais informações.
2. Desta vez, se você expandir a guia Recursos, verá que este APK tem um diretório `lib/`. As bibliotecas nativas para este APK estão nos caminhos padrão da CPU.
3. Agora precisamos identificar quaisquer métodos nativos declarados. No jadx, pesquise e liste todos os métodos nativos declarados. Deve haver dois.
4. Em torno do método nativo declarado, veja se há algum lugar em que uma biblioteca nativa é carregada. Isso fornecerá orientação sobre em qual biblioteca nativa procurar a função a ser implementada.
5. Extraia a biblioteca nativa do APK criando um novo diretório e copiando o APK para essa pasta. Em seguida, execute o comando `unzip Mediacode.APK`. Você verá todos os arquivos extraídos do APK, que incluem o diretório `lib/`.
6. Selecione a arquitetura da biblioteca nativa que você deseja analisar.
7. Inicie o ghidra executando `ghidraRun`. Isso abrirá o Ghidra.
8. Para abrir a biblioteca nativa para análise, selecione "Novo Projeto", "Projeto Não Compartilhado", selecione um caminho para salvar o projeto e dê um nome a ele. Isso cria um projeto que você pode então carregar arquivos binários.
9. Depois de criar seu projeto, selecione o ícone do dragão para abrir o Navegador de Código. Vá em "Arquivo" > "Importar Arquivo" para carregar a biblioteca nativa na ferramenta. Você pode deixar todos os padrões.
10. Você verá a seguinte tela. Selecione "Analisar".
11. Usando as informações de vinculação acima, identifique a função na biblioteca nativa que é executada quando o método nativo declarado em Java é chamado.
Ao começar a engenharia reversa de bibliotecas nativas do Android, uma das coisas que eu não sabia que precisava saber era sobre `JNIEnv`. `JNIEnv` é uma estrutura de ponteiros de função para [Funções JNI](https://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/functions.html). Toda função JNI em bibliotecas nativas do Android, leva `JNIEnv*` como primeiro argumento.
> As declarações C de JNIEnv e JavaVM são diferentes das declarações C++. O arquivo de inclusão "jni.h" fornece diferentes typedefs dependendo se ele é incluído em C ou C++. Por esse motivo, é uma má ideia incluir argumentos JNIEnv em arquivos de cabeçalho incluídos por ambos os idiomas. (Dito de outra forma: se o seu arquivo de cabeçalho requer #ifdef \__cplusplus, você pode ter que fazer algum trabalho extra se algo nesse cabeçalho se referir a JNIEnv.)
