Reverse Engineering en desarrollo móvil: qué es, herramientas y métodos de análisis

¿Qué es Reverse Engineering?

Reverse Engineering (ingeniería inversa) es la disciplina de análisis de software destinada a recuperar las características, la lógica y la estructura de una aplicación a partir de su representación binaria. Para las aplicaciones móviles, los objetos de análisis son los archivos APK (Android) e IPA (iOS), que contienen código compilado, recursos, manifiestos y certificados. El resultado de la ingeniería inversa es la extracción de algoritmos, protocolos, claves de cifrado, esquemas de API y lógica de negocio.

Los objetivos de la ingeniería inversa se dividen en legítimos e ilegítimos. Legítimos: análisis de malware para crear herramientas de seguridad, auditoría de aplicaciones propias en busca de vulnerabilidades, garantía de compatibilidad con protocolos cerrados, análisis de patentes y educación. Ilegítimos: robo de propiedad intelectual, elusión de restricciones de licencia, creación de copias piratas y modificación de aplicaciones para robar datos de usuarios. Según Google Play Protect (2025), el 78% de las modificaciones maliciosas de aplicaciones bancarias se crean a partir del APK original procesado mediante ingeniería inversa.

La metodología de la ingeniería inversa incluye dos direcciones principales: el análisis estático (sin ejecutar la aplicación) y el análisis dinámico (durante la ejecución). Cada enfoque proporciona un nivel diferente de información. El análisis estático ofrece una imagen completa del código, pero sin datos de ejecución. El análisis dinámico revela el comportamiento real, el flujo de datos y las llamadas de red, pero solo dentro de un escenario de ejecución específico. La ingeniería inversa profesional siempre combina ambos enfoques.

Herramientas de análisis estático

El análisis estático es la primera etapa de la ingeniería inversa. El APK o IPA original se desempaqueta y cada componente se analiza por separado. Los objetivos principales: bytecode DEX, recursos, manifiesto, bibliotecas nativas (.so, .dylib) y metadatos.

jadx — descompilador de DEX a Java

jadx es la herramienta principal para el análisis estático de aplicaciones Android. Convierte el bytecode DEX en código Java legible con una pérdida mínima. jadx admite: descompilación multidex, reconocimiento de lambdas y clases Kotlin integradas, y exportación a proyecto Gradle. Para código ofuscado (ProGuard), jadx muestra código con nombres a, b, c, pero la estructura de clases y la secuencia de llamadas se conservan. Según pruebas independientes, jadx descompila correctamente entre el 85 y el 92% del código incluso con ofuscación.

apktool — desempaquetado de recursos

apktool decodifica APK en código smali (ensamblador DEX) y restaura los recursos en un formato legible: AndroidManifest.xml se convierte de AXML a XML legible, los diseños se convierten en marcado XML y strings.xml se convierte en texto plano. apktool permite modificar recursos y recompilar el APK. Después de desempaquetar con apktool y reemplazar recursos, la aplicación se puede instalar con contenido modificado.

Ghidra — análisis de bibliotecas nativas

Ghidra (NSA) es un framework de ingeniería inversa esencial para analizar bibliotecas .so en Android y .dylib en iOS. Ghidra desensambla código ARM64, reconstruye pseudocódigo C y construye grafos de llamadas. Para la ingeniería inversa móvil, Ghidra se utiliza para analizar implementaciones nativas de criptografía y mecanismos DRM. Ghidra admite scripting en Python y Java para automatizar el análisis.

# Desempaquetado y descompilación de APK
$ jadx -d output_dir app.apk

# Desempaquetado de recursos mediante apktool
$ apktool d app.apk -o app_unpacked

# Análisis de bibliotecas nativas mediante Ghidra
$ ghidra app.apk/lib/arm64-v8a/libnative.so

# Búsqueda de constantes de cadena en DEX
$ strings classes.dex | grep -i api_key

Herramientas de análisis dinámico

El análisis dinámico se realiza sobre una aplicación en ejecución. El analizador se conecta al proceso e intercepta las llamadas a funciones, los argumentos y los valores de retorno en tiempo real.

Frida — herramienta de instrumentación universal

Frida es la herramienta líder para el análisis dinámico de aplicaciones móviles. Frida inyecta un motor JavaScript en el proceso de la aplicación (Android ART o iOS) y permite interceptar llamadas tanto a funciones Java/Objective-C como a funciones C/C++. Con Frida, los ingenieros inversos pueden: registrar todas las llamadas al método AES.decrypt() con parámetros, sustituir valores de retorno de forma arbitraria, desactivar SSL-pinning mediante Universal Android SSL Unpin y rastrear llamadas nativas a través de Stalker. Frida funciona sin modificar el APK/IPA, lo que la hace indispensable para las pruebas de penetración.

Objection — envoltura de Frida

Objection proporciona comandos listos para tareas comunes de ingeniería inversa sin necesidad de escribir scripts JavaScript: disable-pinning (desactivación de SSL pinning), dump-keychain (iOS), explore (navegación por la jerarquía de clases), memory search (búsqueda de cadenas en memoria). Objection permite realizar un análisis dinámico completo sin una sola línea de código. Para aplicaciones iOS, Objection encuentra y registra automáticamente las llamadas a NSURLSession, CFNetwork y NSKeyedArchiver.

Xposed Framework

Xposed es un framework para Android que funciona reemplazando el archivo app_process en Zygote. A diferencia de Frida, Xposed no requiere acceso root después de la instalación. Los módulos de Xposed pueden interceptar llamadas a métodos en cualquier aplicación. Para la ingeniería inversa, Xposed es conveniente para análisis a largo plazo: el módulo se instala y funciona continuamente, registrando el comportamiento de la aplicación en diferentes escenarios. Xposed es compatible con Android hasta la versión 8.1; para Android 9+ se utiliza EdXposed basado en SandHook.

// Frida: interceptación del método decrypt() en una aplicación
let aesClass = Java.use("javax.crypto.Cipher");

aesClass.doFinal.overload(
    "[B", "int", "int"
).implementation = function(
    input, offset, len
) {
    console("[AES] decrypt called, len=" + len);
    return this.doFinal(input, offset, len);
};

Proceso de ingeniería inversa de una aplicación Android

El flujo de trabajo estándar de la ingeniería inversa consta de pasos secuenciales, cada uno de los cuales proporciona un determinado nivel de información.

Paso 1: Recopilación de información

El analista examina el APK a nivel de metadatos: targetSdk, uses-permission (qué permisos se solicitan), intent-filter y componentes exportados. Los permisos pueden revelar qué API se utilizan (android.permission.CAMERA → cámara, android.permission.RECORD_AUDIO → audio). Las actividades exportadas identifican puntos de entrada sin autorización. Esta etapa se realiza mediante aapt o ApkAnalyzer y toma de 1 a 2 minutos.

Paso 2: Descompilación DEX

El APK se desempaqueta y classes.dex (o multidex) se introduce en jadx. La salida es código Java/Kotlin organizado en paquetes. El analista busca clases clave: CryptoUtils, ApiClient, AuthManager, DatabaseHelper, y verifica qué algoritmos se utilizan. Si el código contiene cadenas como AES/CBC/PKCS5Padding, la aplicación utiliza cifrado y es necesario encontrar la clave. En esta etapa se identifican: claves hardcodeadas, URL de API, tokens OAuth y secretos. Sin ofuscación, todo el código de la aplicación se lee como un proyecto Java normal.

Paso 3: Análisis de tráfico

Después de configurar Frida u Objection para desactivar el SSL-pinning, el analista inicia la aplicación e intercepta el tráfico de red a través de Burp Suite o mitmproxy. Los datos de tráfico revelan el esquema de la API: qué endpoints, qué parámetros y en qué formato. Si es posible, el analista modifica las solicitudes y verifica la respuesta del servidor a datos incorrectos o maliciosos. La falta de validación del lado del servidor es una vulnerabilidad directa descubierta en este paso.

Paso 4: Registro en data.json

Los resultados del análisis se registran en un formato estructurado. Para cada punto vulnerable encontrado se indica: clase y método, descripción de la vulnerabilidad, vector de explotación y recomendación de corrección. Este conjunto de datos se entrega al equipo de desarrollo o se utiliza para elaborar un informe de prueba de penetración. En entornos automatizados (MobSF), el informe se genera automáticamente basándose en los resultados del análisis estático y dinámico.

Características de la ingeniería inversa en iOS

La ingeniería inversa de aplicaciones iOS es más difícil que la de Android debido a la arquitectura de seguridad más estricta de Apple y la falta de acceso directo al sistema de archivos en dispositivos stock. Se requiere jailbreak para el análisis de iOS.

Análisis estático de Mach-O

Un archivo IPA contiene un binario Mach-O, el formato universal de archivos ejecutables de Apple. Para la descompilación se utiliza Hopper Disassembler o IDA Pro. A diferencia de Android DEX, que se descompila en Java con pérdidas mínimas, Mach-O contiene código ARM64 nativo que se reconstruye en pseudocódigo C con menor precisión. Hopper logra entre el 60 y el 70% de reconstrucción; el resto debe analizarse a nivel de ensamblador.

Análisis dinámico con Frida para iOS

Frida en iOS requiere jailbreak e instalación de frida-server. Después de la conexión, Frida intercepta métodos Objective-C a través del enrutamiento de mensajes de la API. Para aplicaciones iOS, un escenario típico incluye: interceptar NSURLSession.dataTaskWithRequest para registrar solicitudes HTTP, interceptar NSKeyedUnarchiver para analizar datos serializados y rastrear consultas CoreData a través de frida-trace. Frida estuvo disponible para iOS 15-17 con el lanzamiento del jailbreak Dopamine.

Modificación de IPA

La ingeniería inversa puede implicar la modificación del IPA seguida de reempaquetado e instalación en el dispositivo. Las herramientas incluyen: ipatool para desempaquetar, MachOView para ver secciones y optool para inyección de código. Después de la modificación, el IPA se firma mediante ldid o fastlane sigh para su instalación en un dispositivo con jailbreak. Para iOS 16+, la firma de código se verifica a nivel de Secure Enclave y un IPA modificado no se ejecutará en un dispositivo sin jailbreak.

// Frida: interceptación de solicitudes HTTP en una aplicación iOS
if (ObjC.available) {
    let NSURLSession = ObjC.classes.NSURLSession;
    let dataTaskWithRequest = ObjC.protocol("NSURLSessionDelegate")
        .method("- URLSession:dataTask:didReceiveData:");
    Interceptor.attach(dataTaskWithRequest.implementation, {
        onEnter(args) {
            let data = ObjC.Object(args[3]);
            console("[HTTP Response]", data.toString());
        }
    });
}

Métodos de protección contra la ingeniería inversa

La protección contra la ingeniería inversa sigue el principio de seguridad en capas: ningún método proporciona una protección del 100%, pero una combinación hace que la ingeniería inversa sea económicamente inviable.

Ofuscación de código

El nivel básico es ProGuard para Android, que reemplaza los nombres de clases y métodos con nombres de un solo carácter. Para una protección mejorada, DexGuard añade inducción de sobrecarga (múltiples métodos con diferentes firmas y el mismo nombre) y cifrado de cadenas AES-256. La ofuscación aumenta el tiempo de análisis del código de 5 minutos a 5-20 horas dependiendo del nivel. DexGuard además ofusca el flujo de control, haciendo que el código sea ilegible para jadx.

Cifrado de constantes

Todas las constantes de cadena (URL, claves, tokens, consultas SQL) se cifran en tiempo de compilación y se descifran en tiempo de ejecución. Esto protege contra el análisis estático de cadenas en archivos DEX. Un atacante que ejecute strings en app.apk no verá ningún endpoint de API. Incluso después de la descompilación, todas las cadenas aparecen como datos binarios. Cada cadena puede usar una clave separada, lo que complica la desofuscación.

RASP y controles de integridad

Un agente RAP dentro de la aplicación detecta Frida y la depuración en tiempo de ejecución. Los controles de integridad mediante hash SHA-256 del APK evitan la ejecución de una versión modificada de la aplicación. Si el hash del APK no coincide con el hash de referencia (almacenado en la capa nativa), la aplicación se cierra. Esto bloquea los ataques basados en la modificación del APK, incluido el reempaquetado.

Protección del lado del servidor

La lógica de negocio crítica debe ejecutarse en el servidor, no en el cliente. Incluso si un atacante descompila completamente la aplicación, el código del servidor permanece inaccesible. La validación del lado del servidor de todas las solicitudes y parámetros evita la explotación de vulnerabilidades encontradas durante la ingeniería inversa. La atestación del servidor mediante Play Integrity API o App Attest confirma que la solicitud proviene de una aplicación genuina y no modificada.