Pruebas de protecciones de aplicaciones móviles.

¿Necesitas saber si un atacante puede saltarse las protecciones RASP, anti-tampering o anti-bot de tu aplicación? Las ponemos a prueba con sus mismas técnicas y te decimos cuáles funcionan, cuáles no y por qué.

Para equipos que ya protegen su aplicación, con soluciones propias o de un proveedor.

Hasta qué punto funciona una protección en tu aplicación depende de tu configuración e integración: qué comprobaciones están activadas, cómo reacciona la aplicación y qué flujos están cubiertos. Si un atacante consigue saltársela, puede seguir automatizando fraude, manipulando la aplicación o clonándola.

Comprobamos si un atacante puede hacer lo que tus protecciones deben impedir, con técnicas como instrumentación dinámica (hooking), reempaquetado, emuladores o llamadas directas a tu API. Según tu aplicación, las pruebas pueden cubrir:

  • Protección de aplicaciones en tiempo de ejecución (RASP): detección de instrumentación, depuración y cambios en el entorno de ejecución.
  • Anti-tampering y comprobaciones de integridad: resistencia a la modificación y el reempaquetado de la aplicación.
  • Protecciones contra ingeniería inversa: si un atacante puede entender y modificar la lógica protegida.
  • Criptografía de caja blanca (white-box): si se pueden extraer las claves protegidas con criptografía de caja blanca o reutilizar las operaciones protegidas fuera de la aplicación.
  • Detección de root, jailbreak, emuladores y entornos virtuales: si un atacante puede saltarse las comprobaciones del entorno y qué queda accesible.
  • Detección de ubicación falsa (location spoofing): si se puede falsear la ubicación del dispositivo para saltarse restricciones geográficas o controles antifraude.
  • Atestación (como Play Integrity o App Attest) y verificación en el servidor: si tu backend rechaza las peticiones que no vienen de tu aplicación original en un dispositivo real, y si un atacante puede conseguir o reutilizar tokens válidos desde una aplicación o un dispositivo modificados.
  • Vinculación al dispositivo (device binding): si las claves, credenciales o sesiones vinculadas al dispositivo se pueden extraer o reutilizar en otro dispositivo.
  • Detección de bots y anti-automatización: si todavía se pueden automatizar los flujos que quieres proteger, como el registro o el inicio de sesión.
  • Protecciones de red: si un atacante puede saltarse el certificate pinning y otras protecciones del canal para interceptar o modificar el tráfico.
  • Protecciones de pantalla y superposiciones: si un atacante puede saltarse las protecciones contra capturas de pantalla, superposiciones (overlays) y abuso de los servicios de accesibilidad.
  • Respuesta ante detecciones: si un atacante puede anular la reacción de la aplicación cuando detecta algo, como cerrar la sesión o avisar a tu backend.
  1. Llamada: nos cuentas qué quieres impedir, como bots en el registro, aplicaciones clonadas, ubicaciones falsas o llamadas a tu API sin pasar por la aplicación.
  2. Propuesta: te enviamos el alcance acordado, lo que necesitamos de ti, el calendario y un precio cerrado.
  3. Pruebas: nos envías las builds y empezamos. Si encontramos algo crítico, te avisamos en el momento.
  4. Informe y revisión: te enviamos el informe y repasamos los bypasses con tu equipo.
  5. Retest: cuando hayáis corregido las vulnerabilidades, comprobamos en la nueva build si los bypasses siguen funcionando.

Bypasses confirmados

Cada bypass con su impacto, los pasos para reproducirlo y una prueba de concepto cuando proceda.

Objetivos del atacante

Cuáles de los objetivos acordados se pudieron conseguir y qué podría hacer un atacante como resultado.

Por qué funciona cada bypass

La debilidad que permite cada bypass y dónde la situamos: en la configuración o la integración de la protección, en la propia protección o en tu backend.

Cobertura de las pruebas

Qué protecciones probamos y cómo, también las que resistieron.

Lo recibes en un informe por plataforma con resumen ejecutivo y, si incluyes el retest, en una nueva versión con el estado de cada bypass en la nueva build.

Ayudamos a escribir las pruebas de resiliencia de OWASP

Nuestro equipo contribuye a MASVS-RESILIENCE, la parte de OWASP MAS que cubre la integridad de la plataforma y la resistencia a la depuración, la manipulación, la ingeniería inversa, los emuladores y la instrumentación dinámica. Esos mismos especialistas son los que ponen a prueba tus protecciones. OWASP reconoció este trabajo al nombrar a vulnit OWASP MAS Advocate.

Comprobado por un tercero independiente

Tu proveedor te entrega la protección lista para usar. Nosotros atacamos tu aplicación para comprobar si de verdad te protege, qué aguanta, qué no y por qué.

La ingeniería inversa es nuestro día a día

Analizamos aplicaciones protegidas en nuestras auditorías y proyectos de investigación, también cuando la lógica está en código nativo ofuscado o la aplicación detecta herramientas como Frida. Desarrollamos nuestra propia tecnología, como Chameleon, para los casos en que las herramientas públicas se quedan cortas.

Conoce al equipo
¿Qué es RASP?

La protección de aplicaciones en tiempo de ejecución (RASP) detecta actividad sospechosa, o reacciona ante ella, mientras la aplicación se ejecuta. Es una de las protecciones que probamos: comprobamos si funciona frente a los escenarios de ataque acordados y si, al saltarla, quedan al descubierto el comportamiento o los datos que debería proteger.

¿En qué se diferencia de un pentest de aplicaciones móviles?

Un pentest de aplicaciones móviles busca vulnerabilidades en todo el alcance acordado de la aplicación. Este servicio se centra en la eficacia de las protecciones frente a la ingeniería inversa, la manipulación y la modificación en tiempo de ejecución. Los dos servicios se complementan.

¿Y si la protección es de un proveedor?

La probamos igual. Tu proveedor puede ayudarte a confirmar si cada debilidad se corrige con la configuración o es una limitación de su producto. Si desarrollas soluciones de protección, consulta nuestra auditoría de soluciones RASP.

¿Cuánto se tarda y cuánto cuesta?

Depende de cuántas aplicaciones y plataformas haya que probar (Android, iOS o ambas), de las protecciones y los objetivos del atacante incluidos en el alcance y de si se incluyen comprobaciones del backend. Te enviamos una propuesta con un precio cerrado y el calendario. Las pruebas suelen llevar entre una y dos semanas por plataforma, con el informe incluido, según la complejidad de tu aplicación. Normalmente podemos empezar la misma semana en que aceptas la propuesta; la fecha de inicio depende de la carga del equipo y la indicamos en la propuesta.

¿Qué necesitáis de nosotros?

Las builds de la aplicación con las protecciones activadas (APK o AAB para Android, IPA para iOS), usuarios de prueba y acceso al entorno que prefieras, ya sea producción o un entorno de pruebas. Si probamos en producción, acordamos contigo cuándo, con qué volumen y desde qué IP. Lo concretamos en la propuesta.

¿Es necesario dar el código fuente?

No. Por defecto, las pruebas son de caja negra (black-box): partimos del mismo conocimiento que tendría un atacante. Si lo prefieres, también podemos revisar el código fuente.

¿Probáis en dispositivos físicos?

Cuando hace falta. En Android trabajamos sobre todo con Chameleon, nuestro entorno de análisis, que reproduce un dispositivo físico con sus capacidades de hardware. Si encontramos alguna limitación relevante para tu aplicación, usamos dispositivos físicos. En iOS usamos dispositivos físicos.

¿Usáis IA con mi aplicación?

Sí, para cubrir más partes de tu aplicación y profundizar más en el mismo tiempo. Usamos proveedores de IA que no entrenan sus modelos con tus datos. Trabajamos solo con las cuentas que nos das o que creamos nosotros, nunca con cuentas de otros usuarios reales. Nuestros especialistas dirigen el trabajo y validan cada resultado. Si tu política no permite usar IA externa, dínoslo al acordar el alcance y trabajamos sin ella.

¿Puedo enseñar los resultados a mis clientes o socios?

Sí. El informe incluye un resumen ejecutivo para lectores no técnicos. Si lo necesitas, también te damos una carta firmada, sin coste adicional, con lo que probamos, la versión, la fecha y el resultado.

¿El retest está incluido?

El retest se presupuesta aparte, a tarifa reducida. En la propuesta te damos dos opciones: solo las pruebas o las pruebas con una ronda de retest, para que sepas el coste total desde el principio.

¿En qué idioma está el informe?

En inglés por defecto. Si lo necesitas en español, dínoslo.

¿Cómo se gestiona la confidencialidad?

Acordamos las condiciones de confidencialidad antes de que compartas builds o documentación. Tenemos un NDA tipo, pero si prefieres usar el tuyo, lo revisamos sin problema.

Háblanos de tu aplicación y de lo que quieres impedir. Te respondemos en un plazo de un día laborable para acordar una llamada y definir el alcance.

Háblanos de tus protecciones

Una cookie necesaria recuerda tus preferencias durante un máximo de 180 días. Política de privacidad.