Presentamos Ostorlab Mobile Shielding Scan

El blindaje de aplicaciones móviles es fácil de eludir. Un atacante decidido lo superará de todos modos, así que probarlo no cambia nada.

Esa opinión exige al blindaje una promesa que nunca pretendió hacer.

El blindaje no debe hacer que una aplicación sea imposible de someter a ingeniería inversa. Debe hacer que la manipulación, la instrumentación, la interceptación del tráfico y el análisis del código sean significativamente más difíciles.

La verdadera pregunta es cuánta resistencia genera, especialmente en la era de la ingeniería inversa y la instrumentación impulsadas por IA.

Puede haber detección de root y, aun así, fallar frente a las técnicas modernas de ocultación. La fijación de certificados puede proteger una ruta de red y dejar otra expuesta. Una comprobación de integridad puede detectar una modificación y, aun así, permitir que la aplicación siga ejecutándose.

Saber que existe una protección es útil. Saber qué ocurre cuando alguien la ataca es lo que da confianza a los equipos. Y también saber si la solución de blindaje por la que se paga una suma considerable merece la pena.

Esto es lo que el nuevo Mobile Shielding Scan de Ostorlab está diseñado para mostrar.

El escaneo ataca lo que encuentra

Mobile Shielding Scan evalúa cómo se defienden las aplicaciones Android e iOS frente a la ingeniería inversa y la manipulación.

Comienza analizando la aplicación para identificar la detección de root y de jailbreak, los controles de protección contra manipulaciones y de integridad, la antidepuración, la protección contra la instrumentación, la fijación de certificados y la ofuscación de código o de cadenas.

A continuación, ejecuta la aplicación en dispositivos reales y recorre sus flujos de trabajo para llegar a los puntos en los que se activan esas protecciones. Algunos controles solo se ejecutan tras la autenticación, durante un pago o al abrir una funcionalidad sensible. No basta con encontrar el código subyacente si la protección nunca se activa durante el uso real.

Una vez alcanzado un control, el escaneo intenta derrotarlo.

Puede reempaquetar y volver a firmar la aplicación, adjuntar instrumentación en tiempo de ejecución con herramientas como Frida, ocultar las pruebas de que el dispositivo tiene root, interceptar el tráfico de red, parchear el código de la aplicación o de las bibliotecas y manipular las comprobaciones de integridad.

Los agentes de IA dirigen la investigación. Observan la interfaz, leen los registros e interpretan cómo responde la aplicación. Un bloqueo, un cuadro de diálogo de advertencia, una solicitud bloqueada, una salida silenciosa o un flujo de trabajo que deja de funcionar sin avisar pueden revelar si una defensa ha reaccionado.

Los agentes utilizan esa evidencia para elegir la siguiente técnica y volver a intentarlo. El proceso sigue el mismo ciclo básico que una evaluación manual de ingeniería inversa: observar, atacar, interpretar y adaptarse.

El escaneo puede ejecutarse sobre una compilación subida o directamente desde la ficha de una tienda.

Tres protecciones, parcheadas directamente en el dispositivo

El siguiente ejemplo se basa en un escaneo real, con los detalles identificativos eliminados.

Una aplicación bancaria implementaba tres protecciones del lado del cliente en su biblioteca nativa, libsecurity.so, y en su código DEX:

• Una comprobación en JNI_OnLoad analizaba /proc/self/maps en busca de artefactos de Frida y buscaba binarios su y claves de prueba. Si encontraba algo sospechoso, llamaba a _exit(1).
• Una comprobación de integridad nativa calculaba una suma de verificación CRC32 sobre los propios bytes de la biblioteca y la comparaba con un valor almacenado junto a una cadena marcadora.
• Un método de Java, HookDetector.isHooked(), buscaba en los mapas del proceso, en los nombres de los hilos y en los puertos predeterminados de Frida, 27042 y 27043.

Sobre el papel, la aplicación tenía protección contra la instrumentación, detección de root y protección de integridad. La debilidad era que todos los controles dependían de archivos y decisiones almacenados íntegramente en el dispositivo.

La aplicación utilizaba extractNativeLibs=false, lo que dejaba la biblioteca nativa sin comprimir dentro del APK instalado y la cargaba directamente desde allí. Su código DEX se ejecutaba desde el archivo VDEX del dispositivo. En un dispositivo con root, ambos podían modificarse in situ.

El escaneo parcheó la rama de terminación dentro de JNI_OnLoad para que siguiera la ruta de retorno limpia en lugar de llamar a _exit(1). Como modificar la biblioteca cambiaba su suma de verificación, el escaneo recalculó el valor CRC32 y escribió el nuevo resultado en el campo almacenado. La comprobación de integridad siguió ejecutándose, pero ahora consideraba válida la biblioteca parcheada.

A continuación, modificó HookDetector.isHooked() dentro del archivo VDEX para que siempre devolviera false. Tras el cambio, el escaneo reparó las sumas de verificación Adler-32 y SHA-1 del DEX necesarias para que el código se cargara correctamente.

Ninguno de estos cambios requirió recompilar, reempaquetar ni volver a firmar la aplicación.

La comprobación de firma de la aplicación no impidió el ataque, porque Android había almacenado en caché el certificado de firma original durante la instalación y no volvió a validar los archivos modificados en disco.

Con los tres parches aplicados, y con un artefacto de Frida todavía visible en /proc/self/maps, la aplicación mantuvo una sesión autenticada durante más de un minuto, pasó por varias pantallas y superó repetidas comprobaciones de integridad en segundo plano sin reaccionar.

Las tres protecciones estaban presentes y activas en la compilación original. Pero como cada una dependía de código del lado del cliente sin ninguna confirmación independiente en el servidor, las tres pudieron modificarse en el dispositivo que debían proteger.

Una lista de verificación habría indicado que la protección contra la instrumentación, la detección de root y la protección de integridad estaban presentes. Las pruebas activas mostraron exactamente cómo se podía eliminar cada una con un parche.

Un veredicto respaldado por evidencias

Cada protección se marca como Secure cuando reacciona y se mantiene, o como Hardening cuando falta, está inactiva o ha sido eludida. La detección por sí sola no basta si la aplicación sigue funcionando con normalidad.

Las defensas que fallan incluyen pasos de evasión reproducibles. Las que resisten se confirman bajo ataque. Los hallazgos se validan antes de notificarse y pueden cuestionarse o volver a ejecutarse con nuevas indicaciones.

Cada versión puede cambiar el resultado

Un cambio en la compilación o una actualización de un SDK pueden debilitar el blindaje sin romper la aplicación ni activar el pipeline de entrega.

Repetir el escaneo muestra qué se mantiene en la aplicación y en la compilación que se está entregando ahora.

Conozca lo que su blindaje puede soportar

Mobile Shielding Scan muestra qué defensas resistieron, cuáles fallaron y cómo se demostró el resultado.

El blindaje no tiene por qué hacer que una aplicación sea imposible de atacar. Necesita generar resistencia y demostrar que lo hace.

Pruebe lo que puede soportar su blindaje de aplicaciones móviles.