* ¿Trabajas en una **empresa de ciberseguridad**? ¿Quieres ver tu **empresa anunciada en HackTricks**? o ¿quieres acceder a la **última versión de PEASS o descargar HackTricks en PDF**? Consulta los [**PLANES DE SUSCRIPCIÓN**](https://github.com/sponsors/carlospolop)!
* Descubre [**La Familia PEASS**](https://opensea.io/collection/the-peass-family), nuestra colección de [**NFTs**](https://opensea.io/collection/the-peass-family) exclusivos
* Consigue el [**merchandising oficial de PEASS & HackTricks**](https://peass.creator-spring.com)
* **Únete al** [**💬**](https://emojipedia.org/speech-balloon/) [**grupo de Discord**](https://discord.gg/hRep4RUj7f) o al [**grupo de Telegram**](https://t.me/peass) o **sígueme** en **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Comparte tus trucos de hacking enviando PRs al** [**repositorio de hacktricks**](https://github.com/carlospolop/hacktricks) **y al** [**repositorio de hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).
Las aplicaciones Android pueden contener bibliotecas nativas compiladas. Las bibliotecas nativas son código que el desarrollador escribió y luego compiló para una arquitectura de computadora específica. La mayoría de las veces, esto significa código que está escrito en C o C++. Las razones benignas, o legítimas, por las que un desarrollador puede hacer esto es para operaciones matemáticamente intensivas o sensibles al tiempo, como bibliotecas gráficas. Los desarrolladores de malware han comenzado a moverse hacia el código nativo porque la ingeniería inversa de binarios compilados tiende a ser un conjunto de habilidades menos común que el análisis de bytecode DEX. Esto se debe en gran medida a que el bytecode DEX puede descompilarse a Java mientras que el código nativo compilado, a menudo debe analizarse como ensamblador.
El objetivo de esta sección no es enseñarte ensamblador (ASM) o cómo hacer ingeniería inversa de código compilado más en general, sino cómo aplicar las habilidades más generales de ingeniería inversa de binarios, específicamente a Android. Dado que el objetivo de este taller no es enseñarte las arquitecturas ASM, todos los ejercicios incluirán una versión ARM _y_ una versión x86 de la biblioteca a analizar para que cada persona pueda elegir la arquitectura con la que se sienta más cómodo.
Si no tienes experiencia previa en ingeniería inversa de binarios/ensamblador, aquí hay algunos recursos sugeridos. La mayoría de los dispositivos Android funcionan con ARM, pero todos los ejercicios de este taller también incluyen una versión x86 de la biblioteca.
Para aprender y/o repasar ensamblador ARM, sugiero encarecidamente los [Fundamentos de Ensamblador ARM](https://azeria-labs.com/writing-arm-assembly-part-1/) de [Azeria Labs](https://azeria-labs.com).
### Introducción a la Interfaz Nativa de Java (JNI) <a href="#introduction-to-the-java-native-interface-jni" id="introduction-to-the-java-native-interface-jni"></a>
La Interfaz Nativa de Java (JNI) permite a los desarrolladores declarar métodos Java que están implementados en código nativo (usualmente C/C++ compilado). La interfaz JNI no es específica de Android, sino que está disponible de manera más general para aplicaciones Java que se ejecutan en diferentes plataformas.
El Android Native Development Kit (NDK) es el conjunto de herramientas específico de Android sobre JNI. Según la [documentación](https://developer.android.com/ndk/guides):
> En Android, el Native Development Kit (NDK) es un conjunto de herramientas que permite a los desarrolladores escribir código en C y C++ para sus aplicaciones Android.
Juntos, JNI y NDK permiten a los desarrolladores de Android implementar parte de la funcionalidad de su aplicación en código nativo. El código Java (o Kotlin) llamará a un método nativo declarado en Java que está implementado en la biblioteca nativa compilada.
* [Especificación de JNI](https://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/jniTOC.html)
* [Funciones de JNI](https://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/functions.html) <– Siempre tengo esta abierta y la consulto mientras hago ingeniería inversa de bibliotecas nativas de Android
* [Consejos de JNI de Android](https://developer.android.com/training/articles/perf-jni) <– Sugiero leer encarecidamente la sección "Bibliotecas Nativas" para empezar
* [Introducción al NDK](https://developer.android.com/ndk/guides/) <– Esta es una guía de cómo los desarrolladores desarrollan bibliotecas nativas y entender cómo se construyen las cosas, facilita la ingeniería inversa.
En esta sección, nos centramos en cómo hacer ingeniería inversa de la funcionalidad de la aplicación que ha sido implementada en bibliotecas nativas de Android. ¿Qué queremos decir cuando hablamos de bibliotecas nativas de Android?
Las bibliotecas nativas de Android se incluyen en los APKs como bibliotecas de objeto compartido `.so`, en el formato de archivo ELF. Si has analizado binarios de Linux anteriormente, es el mismo formato.
Estas bibliotecas por defecto se incluyen en el APK en la ruta de archivo `/lib/<cpu>/lib<name>.so`. Esta es la ruta predeterminada, pero los desarrolladores también podrían optar por incluir la biblioteca nativa en `/assets/<custom_name>` si así lo desean. Más a menudo, estamos viendo que los desarrolladores de malware eligen incluir bibliotecas nativas en rutas distintas a `/lib` y utilizando diferentes extensiones de archivo para intentar "ocultar" la presencia de la biblioteca nativa.
Debido a que el código nativo está compilado para CPUs específicas, si un desarrollador quiere que su aplicación funcione en más de un tipo de hardware, tiene que incluir cada una de esas versiones de la biblioteca nativa compilada en la aplicación. La ruta predeterminada mencionada anteriormente, incluye un directorio para cada tipo de CPU oficialmente soportado por Android.
Antes de que una app de Android pueda llamar y ejecutar cualquier código que esté implementado en una biblioteca nativa, la aplicación (código Java) debe cargar la biblioteca en la memoria. Hay dos llamadas a la API diferentes que harán esto:
La diferencia entre las dos llamadas a la API es que `loadLibrary` solo toma el nombre corto de la biblioteca como argumento (es decir, libcalc.so = "calc" y libinit.so = "init") y el sistema determinará correctamente la arquitectura en la que se está ejecutando y, por lo tanto, el archivo correcto a utilizar. Por otro lado, `load` requiere la ruta completa a la biblioteca. Esto significa que el desarrollador de la aplicación tiene que determinar la arquitectura y, por lo tanto, el archivo de biblioteca correcto para cargar por sí mismos.
Cuando cualquiera de estas dos APIs (`loadLibrary` o `load`) es llamada por el código Java, la biblioteca nativa que se pasa como argumento ejecuta su `JNI_OnLoad` si fue implementado en la biblioteca nativa.
Para reiterar, antes de ejecutar cualquier método nativo, la biblioteca nativa tiene que ser cargada llamando a `System.loadLibrary` o `System.load` en el código Java. Cuando cualquiera de estas 2 APIs se ejecuta, la función `JNI_OnLoad` en la biblioteca nativa también se ejecuta.
Para ejecutar una función de la biblioteca nativa, debe haber un método nativo declarado en Java que el código Java pueda llamar. Cuando se llama a este método nativo declarado en Java, se ejecuta la función nativa "emparejada" de la biblioteca nativa (ELF/.so).
Un método nativo declarado en Java aparece en el código Java como se muestra a continuación. Parece cualquier otro método de Java, excepto que incluye la palabra clave `native` y no tiene código en su implementación, porque su código está en realidad en la biblioteca nativa compilada.
Para llamar a este método nativo, el código Java lo llamaría como cualquier otro método Java. Sin embargo, en el backend, el JNI y NDK ejecutarían en su lugar la función correspondiente en la biblioteca nativa. Para hacer esto, debe conocer el emparejamiento entre un método nativo declarado en Java con una función en la biblioteca nativa.
Para enlazar o emparejar el método nativo declarado en Java y la función en la biblioteca nativa de manera dinámica, el desarrollador nombra el método y la función de acuerdo con las especificaciones de tal manera que el sistema JNI pueda realizar el enlace dinámicamente.
De acuerdo con la especificación, el desarrollador nombraría la función de la siguiente manera para que el sistema pueda enlazar dinámicamente el método nativo y la función. Un nombre de método nativo se concatena a partir de los siguientes componentes:
Si el desarrollador no quiere o no puede nombrar las funciones nativas de acuerdo con la especificación (por ejemplo, desea eliminar los símbolos de depuración), entonces debe usar el enlazado estático con la API `RegisterNatives` ([doc](https://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/functions.html#wp5833)) para realizar el emparejamiento entre el método nativo declarado en Java y la función en la biblioteca nativa. La función `RegisterNatives` se llama desde el código nativo, no desde el código Java y se llama con más frecuencia en la función `JNI_OnLoad`, ya que `RegisterNatives` debe ejecutarse antes de llamar al método nativo declarado en Java.
Al realizar ingeniería inversa, si la aplicación utiliza el método de enlace estático, nosotros como analistas podemos encontrar la estructura `JNINativeMethod` que se pasa a `RegisterNatives` para determinar qué subrutina en la biblioteca nativa se ejecuta cuando se llama al método nativo declarado en Java.
La estructura `JNINativeMethod` requiere una cadena con el nombre del método nativo declarado en Java y una cadena con la firma del método, por lo que deberíamos poder encontrar estas en nuestra biblioteca nativa.
La estructura `JNINativeMethod` requiere la firma del método. Una firma de método indica los tipos de argumentos que el método acepta y el tipo de lo que devuelve. Este enlace documenta las [Firmas de Tipo JNI](https://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/types.html) en la sección "Type Signatures".
#### Ejercicio #5 - Encontrar la Dirección de la Función Nativa <a href="#exercise-5---find-the-address-of-the-native-function" id="exercise-5---find-the-address-of-the-native-function"></a>
En el Ejercicio #5 vamos a aprender a cargar bibliotecas nativas en un desensamblador e identificar la función nativa que se ejecuta cuando se llama a un método nativo. En este ejercicio en particular, el objetivo no es ingeniería inversa del método nativo, solo encontrar el vínculo entre la llamada al método nativo en Java y la función que se ejecuta en la biblioteca nativa. Para este ejercicio, usaremos el ejemplo Mediacode.apk. Este ejemplo está disponible en `~/samples/Mediacode.apk` en la VM. Su hash SHA256 es a496b36cda66aaf24340941da8034bd53940d1b08d83a97f17a65ae144ebf91a.
1. Abrir Mediacode.apk en jadx. Volver a [Ejercicio #1](https://maddiestone.github.io/AndroidAppRE/reversing_intro.html#exercise-1---beginning-re-with-jadx)
2. Esta vez, si expandes la pestaña Recursos, verás que este APK tiene un directorio `lib/`. Las bibliotecas nativas para este APK están en las rutas de CPU predeterminadas.
3. Ahora necesitamos identificar cualquier método nativo declarado. En jadx, buscar y listar todos los métodos nativos declarados. Debería haber dos.
4. Alrededor del método nativo declarado, ver si hay algún lugar donde se cargue una biblioteca nativa. Esto proporcionará orientación sobre qué biblioteca nativa buscar para la función a implementar.
5. Extraer la biblioteca nativa del APK creando un nuevo directorio y copiando el APK en esa carpeta. Luego ejecutar el comando `unzip Mediacode.APK`. Verás todos los archivos extraídos del APK, que incluye el directorio `lib/`.
6. Seleccionar la arquitectura de la biblioteca nativa que deseas analizar.
7. Iniciar ghidra ejecutando `ghidraRun`. Esto abrirá Ghidra.
8. Para abrir la biblioteca nativa para análisis, seleccionar "Nuevo Proyecto", "Proyecto No Compartido", seleccionar una ruta para guardar el proyecto y darle un nombre. Esto crea un proyecto en el que luego puedes cargar archivos binarios.
9. Una vez que hayas creado tu proyecto, seleccionar el icono del dragón para abrir el Navegador de Código. Luego ir a "Archivo" > "Importar Archivo" para cargar la biblioteca nativa en la herramienta. Puedes dejar todos los valores predeterminados.
10. Verás la siguiente pantalla. Seleccionar "Analizar".
11. Usando la información de enlace anterior, identificar la función en la biblioteca nativa que se ejecuta cuando se llama al método nativo declarado en Java.
**Solución**
### Ingeniería Inversa del Código de Bibliotecas Nativas de Android - JNIEnv <a href="#reversing-android-native-libraries-code---jnienv" id="reversing-android-native-libraries-code---jnienv"></a>
Al comenzar a realizar ingeniería inversa en bibliotecas nativas de Android, una de las cosas que no sabía que necesitaba saber era sobre `JNIEnv`. `JNIEnv` es una estructura de punteros a funciones a [Funciones JNI](https://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/functions.html). Cada función JNI en bibliotecas nativas de Android, toma `JNIEnv*` como el primer argumento.
Desde la documentación de [Consejos JNI](https://developer.android.com/training/articles/perf-jni) de Android:
> Las declaraciones de JNIEnv y JavaVM en C son diferentes de las declaraciones en C++. El archivo de inclusión "jni.h" proporciona diferentes typedefs dependiendo de si se incluye en C o C++. Por esta razón, es una mala idea incluir argumentos JNIEnv en archivos de cabecera incluidos por ambos lenguajes. (Dicho de otra manera: si tu archivo de cabecera requiere #ifdef \_\_cplusplus, es posible que tengas que hacer un trabajo extra si algo en ese archivo se refiere a JNIEnv.)
Aquí hay algunas funciones comúnmente utilizadas (y sus desplazamientos en JNIEnv):
Al analizar bibliotecas nativas de Android, la presencia de JNIEnv significa que:
1. Para funciones nativas JNI, los argumentos se desplazarán por 2. El primer argumento es siempre JNIEnv\*. El segundo argumento será el objeto sobre el cual se debe ejecutar la función. Para métodos nativos estáticos (tienen la palabra clave static en la declaración de Java) esto será NULL.
2. A menudo verás ramificaciones indirectas en el desensamblado porque el código está agregando el desplazamiento al puntero JNIEnv\*, desreferenciándolo para obtener el puntero de función en esa ubicación, y luego ramificando a la función.
Aquí hay una [hoja de cálculo](https://docs.google.com/spreadsheets/d/1yqjFaY7mqyVIDs5jNjGLT-G8pUaRATzHWGFUgpdJRq8/edit?usp=sharing) de la implementación en C de la estructura JNIEnv para saber qué punteros de función están en los diferentes desplazamientos.
En la práctica, en el desensamblado esto se muestra como muchas ramificaciones diferentes a direcciones indirectas en lugar de la llamada directa a la función. La imagen a continuación muestra una de estas llamadas a función indirecta. La línea resaltada en el desensamblado muestra un `blx r3`. Como ingenieros inversos, necesitamos averiguar qué es r3. No se muestra en la captura de pantalla, pero al principio de esta función, `r0` se movió a `r5`. Por lo tanto, `r5` es `JNIEnv*`. En la línea 0x12498 vemos `r3 = [r5]`. Ahora `r3` es `JNIEnv` (sin \*).
En la línea 0x1249e, agregamos 0x18 a `r3` y lo desreferenciamos. Esto significa que `r3` ahora es igual a cualquier puntero de función que esté en el desplazamiento 0x18 en JNIEnv. Podemos averiguarlo mirando la hoja de cálculo. `[JNIEnv + 0x18] = Puntero al método FindClass`
Por lo tanto, `blx r3` en la línea 0x124a4 está llamando a `FindClass`. Podemos buscar información sobre `FindClass` (y todas las demás funciones en JNIEnv) en la documentación de JNIFunctions [aquí](https://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/functions.html).
```markdown
Afortunadamente, ¡hay una manera de obtener la función JNI sin hacer todo esto manualmente! En los descompiladores Ghidra y IDA Pro, puedes cambiar el tipo del primer argumento en las funciones JNI a `JNIEnv *` y automáticamente identificará las funciones JNI que se están llamando. En IDA Pro, esto funciona directamente. En Ghidra, primero tienes que cargar los tipos JNI (ya sea el archivo jni.h o un archivo de tipos de datos de Ghidra del archivo jni.h). Para facilitar, cargaremos los tipos JNI desde el archivo de tipos de datos de Ghidra (gdt) producido por Ayrx y disponible [aquí](https://github.com/Ayrx/JNIAnalyzer/blob/master/JNIAnalyzer/data/jni\_all.gdt). Para facilitar, este archivo está disponible en la VM en `~/jni_all.gdt`.
Para cargarlo para su uso en Ghidra, en la ventana del Administrador de Tipos de Datos, haz clic en la flecha hacia abajo en la esquina derecha y selecciona "Abrir Archivo de Tipos de Datos".
Luego selecciona el archivo `jni_all.gdt` para cargar. Una vez cargado, deberías ver jni\_all en la lista del Administrador de Tipos de Datos como se muestra a continuación.
Una vez que esto esté cargado en Ghidra, puedes seleccionar cualquier tipo de argumento en el descompilador y seleccionar "Cambiar Tipo de Variable". Establece el nuevo tipo a JNIEnv \*. Esto hará que el descompilador ahora muestre los nombres de las funciones JNIFunctions llamadas en lugar de los desplazamientos desde el puntero.
#### Ejercicio #6 - Encontrar y Revertir la Función Nativa <a href="#exercise-6---find-and-reverse-the-native-function" id="exercise-6---find-and-reverse-the-native-function"></a>
Vamos a unir todas nuestras habilidades previas: identificar puntos de partida para RE, revertir DEX y revertir código nativo para analizar una aplicación que puede haber trasladado sus comportamientos dañinos al código nativo. La muestra es `~/samples/HDWallpaper.apk`.
**Objetivo**
El objetivo de este ejercicio es juntar todas nuestras habilidades de reversión de Android para analizar una aplicación en su totalidad: su código DEX y nativo.
**Contexto del Ejercicio**
Eres un analista de malware para aplicaciones Android. Te preocupa que esta muestra pueda estar realizando fraude de SMS premium, lo que significa que envía un SMS a un número de teléfono premium sin divulgación y consentimiento del usuario. Para marcar como malware, necesitas determinar si la aplicación Android está:
1. Enviando un mensaje SMS, y
2. Ese mensaje SMS se está enviando a un número premium, y
3. Si hay una divulgación obvia, y
4. Si el mensaje SMS solo se envía al número premium después del consentimiento del usuario.
**Consulta este blog:** [**https://medium.com/@shubhamsonani/how-to-debug-android-native-libraries-using-jeb-decompiler-eec681a22cf3**](https://medium.com/@shubhamsonani/how-to-debug-android-native-libraries-using-jeb-decompiler-eec681a22cf3)
* ¿Trabajas en una **empresa de ciberseguridad**? ¿Quieres ver tu **empresa anunciada en HackTricks**? o ¿quieres tener acceso a la **última versión de PEASS o descargar HackTricks en PDF**? Consulta los [**PLANES DE SUSCRIPCIÓN**](https://github.com/sponsors/carlospolop)!
* Descubre [**La Familia PEASS**](https://opensea.io/collection/the-peass-family), nuestra colección de [**NFTs**](https://opensea.io/collection/the-peass-family) exclusivos
* Consigue el [**merchandising oficial de PEASS & HackTricks**](https://peass.creator-spring.com)
* **Únete al** [**💬**](https://emojipedia.org/speech-balloon/) [**grupo de Discord**](https://discord.gg/hRep4RUj7f) o al [**grupo de telegram**](https://t.me/peass) o **sígueme** en **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Comparte tus trucos de hacking enviando PRs al** [**repositorio de hacktricks**](https://github.com/carlospolop/hacktricks) **y al** [**repositorio de hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).
