Las mejores herramientas para probar la evasión del blindaje de aplicaciones móviles
Compare Apktool, JADX, Ghidra, Frida, Objection y LLDB en pruebas manuales con la evaluación automatizada de blindaje móvil y RASP de Ostorlab para Android e iOS.
Resumen ejecutivo (TL;DR)
Probar si el blindaje de una aplicación móvil puede evadirse requiere herramientas distintas en cada etapa. Apktool decodifica, modifica y vuelve a compilar paquetes de Android para pruebas de reempaquetado; JADX y Ghidra ayudan a localizar la lógica de protección; Frida, Objection y LLDB ponen a prueba en tiempo de ejecución los controles de blindaje y de RASP; y Ostorlab automatiza la evaluación en Android e iOS.
El blindaje puede detectar un ataque y aun así no proteger la aplicación. En la evaluación de Ostorlab de cinco aplicaciones bancarias, una aplicación detectó que se ejecutaba en un dispositivo con root, pero siguió adelante hasta su pantalla de inicio de sesión. La protección existía. El problema era la respuesta.
Por lo tanto, las pruebas deben ir más allá de confirmar que existen la detección de root, la antidepuración o la fijación de certificados. Los equipos necesitan observar cómo responde la aplicación cuando se ponen a prueba estas protecciones y si esa respuesta puede eludirse.
Esta guía explica qué puede verificar cada herramienta, qué conocimientos requiere y dónde terminan sus capacidades. Está dirigida a los testers de seguridad móvil y a los equipos de AppSec que deben elegir entre un flujo de trabajo manual y una evaluación automatizada.
Sobre esta guía: Esta guía la publica Ostorlab, que está incluida en la comparación. Se basa en la documentación oficial, repositorios de código abierto, las directrices de OWASP e investigaciones técnicas publicadas.
¿Qué son el blindaje de aplicaciones móviles y las pruebas de RASP?
El blindaje de aplicaciones móviles es un conjunto de protecciones que se añaden a una aplicación Android o iOS para dificultar su análisis, su modificación y la interferencia en tiempo de ejecución. Puede incluir ofuscación de código, protección contra manipulaciones, comprobaciones de integridad, antidepuración, protección contra la instrumentación, detección de root o de jailbreak y fijación de certificados.
Runtime Application Self-Protection (RASP) se refiere más concretamente a las protecciones que supervisan la aplicación mientras se ejecuta. Cuando RASP detecta una condición sospechosa, puede mostrar una advertencia, restringir una acción o cerrar la aplicación. Por lo tanto, RASP es una parte de la capa más amplia de blindaje de aplicaciones móviles.
Las pruebas de evasión del blindaje y de RASP comprueban si estos controles detectan las condiciones de ataque previstas y si su respuesta puede neutralizarse o evitarse. Una protección no demuestra su eficacia por el simple hecho de estar presente o de generar una alerta. La prueba también debe establecer si la aplicación sigue permitiendo el comportamiento que la protección debía impedir.
Herramientas de prueba del blindaje de aplicaciones móviles de un vistazo
Las herramientas siguientes son gratuitas y de código abierto, pero ninguna cubre por sí sola toda la evaluación. Cada una se ocupa de una parte concreta del proceso, desde modificar la aplicación y localizar la lógica de protección hasta poner a prueba los controles en tiempo de ejecución y verificar el resultado.
| Herramienta | Cuándo usarla | Alcance móvil | Trabajo necesario | Limitación principal |
|---|---|---|---|---|
| Apktool | Preparar APK modificados para pruebas de reempaquetado, de firma y de protección contra manipulaciones. | APK de Android | Inspeccionar el manifiesto, los recursos o el código Smali; hacer un cambio controlado; volver a compilar y firmar el APK. | Solo Android; los fallos de recompilación o de firma deben distinguirse de la respuesta de blindaje de la aplicación. |
| JADX | Encontrar comprobaciones de protección y rastrear sus llamadores en el código DEX de Android. | Bytecode DEX de Android | Leer el código descompilado e identificar las decisiones que se probarán en tiempo de ejecución. | La descompilación puede ser incompleta; el código nativo requiere otra herramienta de análisis. |
| Ghidra | Rastrear la lógica de protección nativa e identificar ubicaciones para hooks o parches. | Bibliotecas nativas de Android; binarios de iOS | Interpretar el desensamblado y revisar las funciones descompiladas. | El código empaquetado o cifrado puede requerir una extracción en tiempo de ejecución antes del análisis. |
| Frida | Escribir hooks personalizados para observar o modificar en tiempo de ejecución las comprobaciones de blindaje y de RASP. | Android e iOS | Establecer el acceso al proceso, identificar funciones y adaptar scripts. | La protección contra la instrumentación puede bloquear Frida antes de que se ejecute un script. |
| Objection | Probar rutinas de evasión existentes para las comprobaciones habituales de root, jailbreak y fijación de certificados. | Android e iOS | Establecer el acceso de Frida, seleccionar rutinas y verificar la respuesta. | Depende de Frida; las protecciones personalizadas pueden requerir hooks a medida. |
| LLDB | Pausar la ejecución nativa para seguir una comprobación o inspeccionar un estado cambiante. | Código nativo de Android e iOS | Establecer el acceso del depurador e interpretar la ejecución, la memoria y los registros. | Los permisos del sistema operativo y las restricciones de firma pueden impedir la conexión con independencia del blindaje. |
Cómo encajan las herramientas de código abierto en una prueba de evasión del blindaje
Las pruebas de blindaje con herramientas de código abierto combinan varias herramientas en lugar de depender de un único escáner. Apktool facilita la inspección, la modificación y la recompilación de paquetes de Android. JADX y Ghidra ayudan a los testers a localizar y comprender la lógica de protección. Frida, Objection y LLDB se utilizan en tiempo de ejecución para poner a prueba esas protecciones y observar el resultado.
El proceso no siempre es lineal. Una prueba en tiempo de ejecución puede revelar algo que obligue al tester a volver al código para seguir analizándolo.
Apktool: recompilar aplicaciones Android para pruebas de manipulación
Apktool decodifica los paquetes de aplicaciones Android en una estructura similar a la de un proyecto, que contiene el manifiesto, los recursos y el código Smali. Después puede volver a compilar el paquete una vez realizados los cambios.
Función en la evaluación
Apktool resulta útil cuando una evaluación de blindaje necesita modificar y reempaquetar un APK. Un tester puede hacer un cambio controlado en el manifiesto, los recursos o el código Smali, volver a compilar el paquete y comprobar después si las protecciones de integridad, de firma o contra manipulaciones detectan la aplicación modificada.
Esta función es distinta de la de JADX. JADX presenta el código DEX como código legible similar a Java para su análisis, mientras que Apktool conserva una estructura de paquete que puede editarse y volver a compilarse. OWASP documenta Apktool como una forma de decodificar el manifiesto binario, extraer recursos, desensamblar archivos DEX a Smali y reempaquetar el resultado. (Consulte la guía de Apktool de OWASP)
Qué necesita el tester
El tester debe decidir qué cambiar, editar el archivo pertinente del manifiesto, de los recursos o de Smali, volver a compilar el APK y firmarlo antes de instalarlo. El resultado debe registrar dónde se produjo cualquier fallo: durante la decodificación, la recompilación, la firma, la instalación o después de iniciarse la aplicación.
Limitaciones
Apktool se limita a los paquetes de Android y no prueba por sí mismo las protecciones en tiempo de ejecución. Genera un APK sin firmar, por lo que la firma es un paso aparte. Una aplicación recompilada que no se instala o no se inicia no demuestra automáticamente que el blindaje detectó la modificación; la causa puede ser, en cambio, una compilación no válida, un problema de firma o una incompatibilidad del paquete. Apktool también documenta que algunos APK creados con herramientas de compilación de OEM modificadas no pueden decodificarse ni recompilarse. Preguntas frecuentes de Apktool
Cuando el objetivo es rastrear la lógica de protección de Android de más alto nivel antes de decidir qué cambiar, JADX ofrece una vista más legible.
JADX: investigar la lógica de protección de Android
JADX convierte el bytecode DEX de Android en código legible similar a Java. Los testers pueden buscar dentro de un APK, desplazarse entre métodos y seguir referencias sin ejecutar la aplicación.
Función en la evaluación
JADX ayuda a localizar comprobaciones de root, lógica de antidepuración, comprobaciones de integridad y el código que decide cómo responde la aplicación.
La respuesta puede gestionarse en un lugar distinto de la comprobación original. Un método puede detectar root, mientras que otro decide si mostrar una advertencia, cerrar la aplicación o restringir una funcionalidad. Seguir esas referencias ayuda al tester a identificar el punto de decisión que se investigará en tiempo de ejecución con Frida o con un depurador.
Qué necesita el tester
Usar JADX requiere familiaridad con el desarrollo de Android y la ingeniería inversa, especialmente cuando los nombres de las clases y el flujo de control están ofuscados.
El resultado descompilado es una interpretación del bytecode y no el código fuente original de la aplicación. JADX puede cambiar el nombre de clases y métodos o incorporarlos en línea, por lo que los identificadores que se muestran en la interfaz pueden no coincidir con los que se encuentran en tiempo de ejecución. Los resultados dudosos deben contrastarse con el código Smali subyacente o con el grafo de flujo de control. Orientación de JADX para la resolución de problemas
Limitaciones
JADX es una herramienta de análisis de Android, no una solución completa de evasión. Su depurador de Smali requiere una aplicación depurable o un dispositivo o emulador con root. La lógica de protección contenida en bibliotecas nativas, cifrada hasta el inicio o generada en tiempo de ejecución también requiere otras herramientas.
Cuando la lógica pertinente pasa del bytecode de Android a una biblioteca nativa, Ghidra puede continuar la investigación.
Ghidra: analizar el código de protección nativo
Ghidra analiza código nativo compilado, incluidas las bibliotecas .so de Android y los ejecutables y frameworks de iOS.
Función en la evaluación
El desensamblador, el descompilador, la búsqueda de cadenas y los grafos de funciones de Ghidra ayudan a los testers a reconstruir cómo funciona el código de protección nativo. En Android, puede continuar el análisis cuando JADX llega a una llamada a una biblioteca nativa pero no puede mostrar lo que ocurre en su interior.
Incluso cuando se han eliminado los nombres de las funciones, las cadenas, las constantes y las referencias entre funciones pueden revelar una probable comprobación de protección, su rama de decisión y la respuesta resultante de la aplicación. La guía de Ghidra de OWASP explica cómo funcionan conjuntamente estas vistas al revisar un binario.
Qué necesita el tester
Ghidra requiere mayores habilidades de ingeniería inversa nativa que JADX. Es posible que el tester deba corregir firmas de funciones, comparar el resultado descompilado con el ensamblador y comprender cómo se desplazan los valores entre registros y memoria.
El objetivo habitual es identificar una probable comprobación o punto de decisión para las pruebas en tiempo de ejecución. Encontrarlo en Ghidra no demuestra que pueda eludirse.
Limitaciones
El código empaquetado o cifrado puede permanecer oculto hasta que se ejecuta la aplicación. El depurador de Ghidra puede asociar un proceso en ejecución con el binario importado e inspeccionar la memoria en tiempo de ejecución, pero el tester debe obtener primero acceso de depuración y localizar el código pertinente.
Cualquier presunta evasión debe reproducirse igualmente mientras la aplicación se ejecuta. Frida se utiliza habitualmente para esa parte de la evaluación.
Frida: instrumentación personalizada en tiempo de ejecución
Frida inyecta JavaScript en procesos de Android e iOS. Permite a los testers interceptar llamadas a funciones, inspeccionar sus entradas y salidas y cambiar el comportamiento de la aplicación mientras se ejecuta.
Función en la evaluación
Frida se utiliza para poner a prueba las comprobaciones de protección y el código que responde a ellas. Permite comprobar si el comportamiento de una protección puede modificarse incluso cuando la detección inicial sigue funcionando.
En el ejemplo de OWASP con Android UnCrackable L1, la aplicación detecta root y muestra una advertencia antes de cerrarse. Un hook de Frida cambia la función responsable de cerrar la aplicación. La comprobación de root se sigue ejecutando, pero la aplicación ya no lleva a cabo la respuesta prevista.
Qué necesita el tester
El tester debe identificar las funciones pertinentes, escribir o adaptar hooks en JavaScript y verificar que el comportamiento objetivo haya cambiado realmente. Las protecciones personalizadas pueden requerir ingeniería inversa adicional para comprender cómo se conectan sus comprobaciones y sus respuestas.
El entorno de pruebas también importa. Las pruebas en Android suelen usar un dispositivo con root, aunque Frida Gadget puede incrustarse en una aplicación reempaquetada. En iOS, un dispositivo con jailbreak ofrece un acceso más amplio, mientras que las pruebas en un dispositivo sin jailbreak se limitan a aplicaciones depurables.
Limitaciones
El blindaje o RASP pueden detectar o bloquear Frida antes de que comience la prueba prevista. En la evaluación de Ostorlab de cinco aplicaciones bancarias, una aplicación terminó durante la inyección antes de que el script de Frida produjera su primer mensaje de registro. En esa situación, establecer una sesión de instrumentación operativa pasa a ser una parte independiente de la investigación.
Para las técnicas de evasión habituales, Objection ofrece un punto de partida más rápido al empaquetar rutinas de Frida existentes en comandos listos para usar.
Objection: funciones de evasión listas para usar
Objection se ejecuta sobre Frida y empaqueta técnicas habituales de pruebas móviles en una consola interactiva.
Función en la evaluación
Objection incluye comandos para intentar eludir comprobaciones conocidas de root y jailbreak, desactivar implementaciones habituales de fijación de certificados, inspeccionar las clases cargadas y observar las llamadas a métodos. Esto permite a los testers probar técnicas consolidadas antes de escribir un script de Frida personalizado.
Es posible que las comprobaciones que se ejecutan durante el arranque deban alcanzarse antes de que la aplicación termine de iniciarse. Objection admite la instrumentación temprana, que permite cargar comandos o scripts de Frida personalizados cuando la aplicación se reanuda.
Qué necesita el tester
El tester debe confirmar qué cambió cada comando y si realmente se llegó a la protección que se está evaluando. Que un comando se complete correctamente solo demuestra que la rutina se ejecutó. No establece que la protección se haya eludido.
Objection también puede parchear una aplicación Android con Frida Gadget. Como esto recompila y vuelve a firmar el APK, el tester debe determinar si cualquier fallo resultante procede del intento de evasión o de una comprobación de integridad o de firma.
Limitaciones
Objection funciona mejor cuando sus rutinas existentes coinciden con la protección que utiliza la aplicación. Resulta menos útil con lógica de protección personalizada o cuando la aplicación bloquea la sesión de Frida subyacente.
En esos casos, el tester suele necesitar análisis de código y un script de Frida a medida. Si la investigación requiere seguir la ejecución nativa instrucción por instrucción, LLDB ofrece una vista de más bajo nivel.
LLDB: examinar las comprobaciones de protección con un depurador
LLDB permite a los testers pausar el código nativo, recorrerlo instrucción por instrucción e inspeccionar registros, memoria y valores de retorno. Es el depurador predeterminado de Xcode y también se utiliza para la depuración nativa en Android.
Función en la evaluación
Un tester puede colocar un punto de interrupción en una presunta comprobación de protección, observar el valor que devuelve y seguir cómo responde la aplicación. LLDB también puede cambiar el estado del proceso durante una prueba controlada.
Sus watchpoints son útiles cuando el tester sabe dónde se almacena el resultado de una protección pero aún no sabe qué función lo actualiza.
Qué necesita el tester
Las compilaciones de producción suelen contener pocos símbolos útiles. Es posible que los testers tengan que trasladar direcciones y otros hallazgos desde Ghidra y luego tener en cuenta cómo se mapea el binario en memoria. Esto requiere comprender el ensamblador, las convenciones de llamada, los registros y el flujo de ejecución nativo. La guía de OWASP sobre depuración en iOS trata estas restricciones en las compilaciones de producción.
El acceso al dispositivo también afecta a lo que LLDB puede alcanzar. En un dispositivo Android sin root, Android Studio solo puede conectarse a procesos depurables. LLDB se ocupa de la capa nativa y no del código Java o Kotlin. En iOS, una aplicación de producción puede requerir un dispositivo adecuado y una compilación vuelta a firmar o depurable por otros medios.
Limitaciones
Que LLDB no consiga conectarse no significa automáticamente que el blindaje haya detenido al depurador. Los permisos del sistema operativo, los requisitos de firma o los entitlements de la aplicación pueden impedir la conexión antes de llegar a la protección.
El tester debe distinguir estos fallos de configuración de los casos en que la propia aplicación detecta o bloquea claramente la depuración. Como ocurre con las demás herramientas de tiempo de ejecución, conectar el depurador con éxito es solo el principio; la evidencia final debe mostrar cómo se comportó la protección objetivo durante la prueba.
Ostorlab: automatizar las pruebas del blindaje de aplicaciones móviles
El Mobile Shielding Scan de Ostorlab reúne el descubrimiento de protecciones, los intentos de evasión y la verificación en una única evaluación para Android e iOS. Gestiona el entorno de pruebas y utiliza agentes de IA para investigar cómo responde la aplicación cuando se ponen a prueba sus protecciones.
Qué automatiza Ostorlab
El flujo de trabajo de evaluación abarca cuatro etapas:
- Identificar las protecciones. El escaneo examina la aplicación en busca de detección de root y de jailbreak, comprobaciones de integridad, antidepuración, protección contra la instrumentación, fijación de certificados y ofuscación de código o de cadenas.
- Llegar a los flujos de trabajo protegidos. Ejecuta la aplicación en dispositivos reales y navega por sus pantallas para llegar a los puntos donde se activan las protecciones. Esto importa cuando una comprobación se ejecuta solo después del inicio de sesión o al abrirse una funcionalidad sensible.
- Intentar evasiones y seguir la respuesta. Según la protección, los intentos pueden implicar instrumentación en tiempo de ejecución, reempaquetado, nueva firma, ocultación de indicadores de root o modificación de la lógica de protección. Los agentes inspeccionan la interfaz y los registros, y luego utilizan advertencias, cierres inesperados, solicitudes bloqueadas y otras respuestas para orientar la investigación.
- Registrar lo ocurrido. Los hallazgos distinguen las protecciones que resistieron durante los ataques intentados de las que faltaban, estaban inactivas o fueron eludidas. Las evasiones logradas incluyen evidencias de respaldo y los pasos para reproducirlas.
Qué debe aportar usted: Un APK, AAB o IPA, o una aplicación seleccionada a través de Google Play, App Store o TestFlight. Tras elegir el perfil Mobile Shielding Scan, puede seleccionar los Cybermodels de Ostorlab o aportar su propia clave de un proveedor de IA compatible. Cybermodels ofrece distintos niveles de esfuerzo de investigación. También puede proporcionar credenciales de prueba e instrucciones de navegación para que el escaneo pueda llegar a pantallas autenticadas y a los flujos de trabajo pertinentes. Guía de configuración del escaneo
Cómo son los hallazgos
El panel de resultados ofrece una visión general del endurecimiento, calificaciones por categoría e información de cobertura, junto con cada comprobación verificada. Para un equipo de AppSec que investiga una evasión, el detalle útil es la evidencia que explica cómo se comportó una protección concreta.
Un ejemplo procede de la evaluación publicada por Ostorlab de cinco aplicaciones bancarias. Para investigar la fijación de certificados, el escaneo ejercitó dos veces el propio verificador de certificados de la aplicación. En ambas ejecuciones se usaron el mismo certificado, la misma instancia del verificador y las mismas fijaciones configuradas; los hooks de evasión estaban desactivados en una ejecución y activados en la otra.
| Observación | Hooks desactivados | Hooks activados |
|---|---|---|
| Ambas comparaciones de fijación | Devolvieron false |
Devolvieron true |
| Decisión del verificador de certificados | Rechazó el certificado y lanzó una excepción | Aceptó el certificado sin excepción |
El cambio controlado demuestra una evasión del verificador de certificados ejercitado en esa prueba. La evidencia procede de invocar directamente la lógica de verificación: la misma entrada que se rechazaba pasó a aceptarse cuando los hooks estaban activos.
Eso le da al equipo un fallo concreto que investigar y una condición específica que volver a comprobar tras una corrección: si el verificador sigue rechazando ese certificado cuando se intenta la misma evasión.
Limitaciones
Ostorlab es una plataforma comercial, por lo que requiere acceso de pago y está pensada principalmente para equipos de seguridad e ingeniería que realizan evaluaciones repetibles. A cambio, gestiona el entorno de pruebas, los intentos de evasión y la recopilación de evidencias que un flujo de trabajo manual obliga al equipo a montar y mantener.
Cómo elegir el enfoque adecuado para probar la evasión del blindaje de aplicaciones
El enfoque adecuado depende de si el equipo necesita encontrar una protección, ponerla a prueba mientras la aplicación se ejecuta o automatizar la evaluación más amplia.
- Para la modificación de paquetes y el análisis de código: utilice Apktool para decodificar, modificar y volver a compilar APK de Android, JADX para examinar el código DEX de Android y Ghidra para investigar binarios nativos de Android o iOS. Estas herramientas respaldan las pruebas de reempaquetado y ayudan a localizar las comprobaciones de protección, pero por sí solas no demuestran una evasión en tiempo de ejecución.
- Para las pruebas en tiempo de ejecución: Objection ofrece rutinas listas para usar para las protecciones habituales, mientras que Frida da a los testers más control mediante hooks personalizados. LLDB es útil cuando la investigación requiere pausar la ejecución nativa y seguir una decisión de protección instrucción por instrucción. Los hallazgos de JADX o Ghidra suelen orientar dónde deben centrarse estas pruebas en tiempo de ejecución.
- Para las pruebas automatizadas: Ostorlab reúne el descubrimiento de protecciones, los intentos de evasión y la recopilación de evidencias en un único flujo de trabajo automatizado. Las herramientas manuales pueden seguir utilizándose junto con él cuando un especialista necesita investigar en mayor profundidad un hallazgo concreto. Para evaluar una aplicación Android o iOS protegida, explore Mobile Shielding Scan.
Preguntas frecuentes
¿Qué herramientas pueden probar si la detección de root, la detección de jailbreak y la fijación de certificados resisten los intentos de evasión?
Objection incluye rutinas para las comprobaciones habituales de root, jailbreak y fijación de certificados. Frida puede utilizarse para crear hooks a medida cuando esas rutinas no coinciden con la implementación de la aplicación. Ostorlab Mobile Shielding Scan automatiza las pruebas en estas áreas de protección en Android e iOS. En todos los casos, el resultado debe identificar la compilación, el estado del dispositivo, el flujo de trabajo alcanzado y el comportamiento observado.
¿Pueden las herramientas de código abierto realizar una evaluación completa del blindaje móvil?
Pueden respaldar el flujo de trabajo manual completo cuando el equipo dispone del acceso y de los conocimientos de ingeniería inversa necesarios. Un tester puede usar Apktool para modificar y volver a compilar un paquete de Android, JADX o Ghidra para comprender una protección y luego Frida, Objection o LLDB para ponerla a prueba y verificar el resultado. Ninguna herramienta de código abierto de esta comparación realiza automáticamente todas las etapas, por lo que el equipo debe conectar las herramientas y documentar las evidencias.
¿Detectar una funcionalidad de blindaje demuestra que resiste los intentos de evasión?
No. Encontrar código de detección de root, de antidepuración o de fijación de certificados demuestra que existe una protección. Su eficacia se establece poniendo a prueba el control, observando la respuesta de la aplicación y comprobando si aún puede alcanzarse el comportamiento restringido.
¿Qué evidencia demuestra que una evasión del blindaje funcionó?
La evidencia más sólida vincula un cambio controlado con la decisión protegida. Por ejemplo, el mismo verificador y la misma entrada pueden ejercitarse con una evasión desactivada y activada, y comparar después los dos resultados. Un hook cargado o una sesión de instrumentación en ejecución no bastan por sí solos para demostrar que se eludió la protección prevista.