Anti-análisis y hardening

1. Alcance de este documento, antes de nada

Aquí se documenta qué comprueba cada técnica y cómo se identifica su presencia en el binario, para que el analista entienda por qué su entorno le está dando resultados raros. No se documenta cómo desactivarlas, ni cómo parchearlas, ni cómo evadirlas.

La razón por la que este documento existe no es la curiosidad: es que estas protecciones se manifiestan como fallos de herramienta. Una aplicación que cierra sola al arrancar en un emulador, un jadx que decompila cien clases vacías, un Frida que se desconecta a los tres segundos. Quien no sabe que existe una capa de anti-análisis interpreta esos síntomas como un bug en su instrumental y pierde horas. La «sección 10 · Los síntomas, que es lo que uno ve primero» es la tabla de síntoma → causa que resuelve eso, y enlaza con «Diagnóstico de fallos».

La fuente principal es la OWASP Mobile Application Security Testing Guide (MASTG), que es un catálogo público, con identificadores estables y orientado a verificar que una aplicación implementa estas defensas. Se cita por identificador. Cuando una técnica muy conocida no aparece en la página de MASTG que le correspondería, se dice explícitamente y se busca otra fuente con autor identificable, en vez de atribuírsela a OWASP.

Versiones de referencia: OWASP MASTG v2.0.0 y su rama master, APKiD 3.1.0 y su rama master, y Android hasta el nivel de API 36, consultadas en agosto y septiembre de 2026.

2. Qué es y por qué existe

La ofuscación («Ofuscadores comerciales») y el empaquetado («Packers y protectores») atacan el análisis estático: hacen caro leer el binario. No sirven de nada contra el análisis dinámico, donde el analista deja que la aplicación se descifre a sí misma y observa lo que hace.

El anti-análisis es la respuesta a eso: código que, en ejecución, comprueba si el entorno es el de un usuario normal o el de alguien que está mirando, y reacciona. La industria lo vende bajo la sigla RASP (Runtime Application Self-Protection), y las fichas de producto de los ofuscadores comerciales lo listan como un bloque aparte. DexGuard, por ejemplo, declara seis: certificate checks, debugger and emulator checks, root detection, hook detection, tamper detection y malware protection. No todo el RASP viene de un ofuscador: APKiD 3.1.0 identifica también Appdome, con las reglas appdome_dex —la clase Lruntime/loading/InjectedActivity;, que según el comentario de la regla se inyecta en todo— y appdome_elf —las parejas de símbolos __start_adinit/__stop_adinit, __start_hook/__stop_hook o __start_ipcent/__stop_ipcent—; en master se suma appdome_elf_b, que busca libloader.so.

Dos observaciones que conviene tener presentes al leer todo lo que sigue.

Estas comprobaciones son detecciones basadas en artefactos, no pruebas. MASTG lo dice de su categoría de detección de herramientas: «este tipo de detección se basa en artefactos. No prueba que el código o la memoria de la aplicación hayan sido modificados, pero puede proporcionar señales útiles de que el entorno de ejecución es sospechoso». Y advierte de la otra cara: «algunas comprobaciones pueden producir falsos positivos cuando un dispositivo contiene herramientas de seguridad, herramientas de desarrollo, herramientas de accesibilidad o software de monitorización empresarial».

La plataforma les ha ido quitando terreno. Varias de las técnicas clásicas ya no funcionan o funcionan a medias por cambios de Android, y el detalle importa porque explica falsos negativos:

Ese último es el más útil para el analista: una aplicación que comprueba paquetes de root y declara QUERY_ALL_PACKAGES o una lista <queries> larga en el manifiesto está anunciando su propia detección, y eso se ve sin ejecutar nada.

3. Anti-debug

MASTG lo cubre en MASTG-KNOW-0028 («Anti-Debugging») y su test asociado MASTG-TEST-0046, hoy marcado deprecated y sustituido en master por MASTG-TEST-0352 y MASTG-TEST-0353; en la versión publicada, MASTG v2.0.0 (30 de junio de 2026), los sustitutos son MASTG-TEST-0046-1 y MASTG-TEST-0046-2. El encuadre, literal: «hay que lidiar con dos protocolos de depuración en Android: se puede depurar a nivel Java con JDWP o en la capa nativa con un depurador basado en ptrace». Y distingue entre defensas preventivas —impedir que el depurador se conecte— y reactivas —detectar que ya está conectado y reaccionar.

El matiz de TracerPid que casi nadie menciona, y que MASTG sí: «recuerda que esto solo aplica al código nativo. Si estás depurando una aplicación solo de Java/Kotlin, el valor del campo TracerPid debería ser 0». Un depurador JDWP no deja rastro ahí.

⚠️ ptrace(PTRACE_TRACEME) sobre sí mismo —la técnica más citada de todas: el proceso se traza a sí mismo para que nadie más pueda— no aparece en MASTG-KNOW-0028, que solo menciona PTRACE_ATTACH y PTRACE_CONT. La fuente con autor identificable donde sí está documentada es la charla de Tim Strazzere y Jon Sawyer, «Android Hacker Protection Level 0», DEF CON 22 (2014), que publica el pseudocódigo del JNI_OnLoad de APKProtect con ptrace(PTRACE_TRACEME, ...) y una función find_qemud_process(). No se atribuya a OWASP.

⚠️ Debug.waitingForDebugger() tampoco aparece en esa página de MASTG.

Cómo se identifica en el binario, sin ejecutar nada: la cadena TracerPid o /proc/self/status en el string_ids del DEX o en las cadenas de un .so; la referencia a Landroid/os/Debug;.isDebuggerConnected en method_ids; el símbolo ptrace importado por una biblioteca nativa; y android:debuggable en el manifiesto —que además es de por sí un dato que hay que reportar—.

4. Anti-emulador

MASTG-KNOW-0031 («Emulator Detection») y MASTG-TEST-0049, hoy marcado deprecated y sustituido por MASTG-TEST-0351. El detalle metodológico que sorprende: MASTG documenta estas comprobaciones a través de los campos Java de android.os.Build, no como lectura cruda de propiedades del sistema ro.*.

MASTG recomienda «normalizar a minúsculas al comprobar estos valores», detalle que importa si uno busca las cadenas en el binario.

Ficheros y sockets característicos, comprobados con java.io.File.exists():

Telefonía: getLine1Number() devolviendo un número de la serie 15555215554…15555215584 —los sufijos pares—, getNetworkOperatorName() devolviendo android en minúscula, y getVoiceMailNumber() devolviendo 15552175049. getLine1Number() está deprecado desde Android 13 (API 33) en favor de SubscriptionManager.getPhoneNumber(int).

Paquetes de emuladores, con los prefijos com.vphone., com.bignox., com.nox.mopen.app, me.haima., com.bluestacks, cn.itools., com.kop., com.kaopu., com.microvirt., y el paquete exacto com.google.android.launcher.layouts.genymotion.

OpenGL: GLES20.glGetString(GL_RENDERER) conteniendo Bluestacks o Translator.

⚠️ Tres artefactos clásicos que no aparecen en MASTG-KNOW-0031, comprobado por búsqueda sobre el fuente de la página: ro.kernel.qemu, /system/lib/libc_malloc_debug_qemu.so e IMEI 000000000000000. La propiedad ro.kernel.qemu es real y muy citada, pero no procede de OWASP. Donde sí están documentadas propiedades del sistema con nombre propio es en el trabajo de Maddie Stone, «Unpacking the Packed Unpacker» (Virus Bulletin 2018 / Black Hat USA 2018), que analiza un packer que «realiza más de 45 comprobaciones distintas en tiempo de ejecución» y nombra init.svc.qemud, qemu.sf.fake_camera e init.svc.goldfish-setup, más detección de Xposed vía la clase de/robv/android/xposed/XposedBridge.

Cómo se identifica en el binario: cualquiera de las cadenas de las tablas anteriores en el string_ids del DEX o en un .so. Es la categoría más fácil de detectar estáticamente, porque las comprobaciones son literalmente comparaciones contra constantes de texto — salvo que estén cifradas («Ofuscadores comerciales → §2.2 · Cifrado de cadenas»), que es exactamente el motivo de que se cifren.

5. Detección de root y de Frida

5.1 Root — MASTG-KNOW-0027, MASTG-TEST-0045

MASTG-TEST-0045 está marcado deprecated; lo sustituyen MASTG-TEST-0324 y MASTG-TEST-0325.

5.2 Frida y herramientas de instrumentación — MASTG-KNOW-0030, MASTG-TEST-0048

MASTG-TEST-0048 está marcado deprecated; lo sustituye MASTG-TEST-0341.

⚠️ La cadena frida:rpc, que se cita mucho, no aparece en MASTG-KNOW-0030; la documentada es LIBFRIDA. Y el prefijo de socket que documenta MASTG hoy es frida-zymbiote-; re.frida.server aparece solo como componente de la ruta del agente.

La limitación que MASTG declara es la que más afecta al analista: «desde Android 7.0, nivel de API 24, la visibilidad de procesos y servicios está restringida, y las APIs a nivel de aplicación no exponen de forma fiable demonios no relacionados como frida-server». Por eso las comprobaciones útiles hoy son las que miran dentro del propio proceso —/proc/self/*, nombres de hilo, cadenas en memoria— y no las que enumeran el sistema.

La fuente primaria que la propia MASTG cita es «The Jiu-Jitsu of Detecting Frida», de Bernhard Mueller.

Cómo se identifica en el binario: las rutas /proc/self/maps, /system/xbin/su, /data/local/tmp, los nombres de paquete com.topjohnwu.magisk y eu.chainfire.supersu, y las cadenas frida, LIBFRIDA, gum-js-loop en el DEX o en los .so. Y, de nuevo, la declaración de QUERY_ALL_PACKAGES o de una lista <queries> con gestores de root en el manifiesto.

6. Comprobación de integridad en ejecución

Dos familias distintas: comprobar quién firmó y comprobar qué se está ejecutando.

6.1 Verificación de la firma desde el propio código

Es la defensa contra el reempaquetado: la aplicación comprueba que sigue estando firmada con el certificado de su autor y no con uno cualquiera.

Las APIs, con sus niveles confirmados en la referencia oficial:

La forma canónica es: obtener el SigningInfo, calcular el SHA-256 del certificado y compararlo con un valor incrustado en el código —normalmente cifrado, y con frecuencia la comparación misma movida a nativo—. getSchemeVersion() permite además exigir un esquema mínimo: rechazar una instalación que solo tenga v1 elimina de golpe una clase de manipulaciones («Esquemas de firma»). Pero solo desde Android 15, y las constantes con las que comparar su resultado, desde el 16: una aplicación con minSdk menor necesita una vía alternativa.

Guardsquare lo vende exactamente así: «DexGuard da a tu aplicación la capacidad de asegurar que ha sido firmada con el certificado original».

El checksum del classes.dex leído de la propia entrada ZIP del APK sí está documentado como control anti-tamper: MASTG-KNOW-0029, «File Integrity Checks», con implementación de referencia sobre ZipEntry.getCrc() —new ZipFile(getPackageCodePath()), getEntry("classes.dex"), comparación contra un valor guardado en recursos— y su test asociado MASTG-TEST-0047, hoy marcado deprecated y sustituido por MASTG-TEST-0338. La misma página enumera AndroidManifest.xml, los *.dex y los *.so como los ficheros que habitualmente se protegen así.

⚠️ Lo que no está documentado en MASTG es la comprobación de getInstallerPackageName como control anti-tamper: una búsqueda de código sobre el repositorio de OWASP devuelve cero apariciones del identificador. Es una técnica real y frecuente, pero aquí se menciona como observación, no como cita.

6.2 Integridad del código en ejecución

MASTG-KNOW-0032 («Runtime Integrity Verification») organiza esto en cuatro preguntas, que es la mejor taxonomía disponible:

Los artefactos concretos que nombra: permisos sospechosos en /proc/self/maps —rwxp donde se espera r-xp—; la sección .data.rel.ro para las vtables; los campos de ArtMethod entry_point_from_quick_compiled_code_, entry_point_from_interpreter_ y access_flags_, más el flag kAccNative (0x0100); el trampolín ARM64 LDR X16, .+8 ; BR X16 con los bytes 50 00 00 58 00 02 1F D6 y su variante ARM32/Thumb LDR PC, [PC, #-4]; la inyección desde rutas escribibles como /data/local/tmp; y la detección de Xposed por la clase de/robv/android/xposed/XposedBridge en el classloader, o de LSPosed por META-INF/xposed/java_init.list y META-INF/xposed/native_init.list.

Ese último par es una huella estática: se ve mirando el ZIP.

7. Lógica movida a nativo

La forma más simple y más efectiva de dificultar el análisis: sacar el código de Java/Kotlin y ponerlo en C/C++ dentro de un .so («Código nativo y ELF»).

Por qué funciona tan bien, y no es porque el nativo sea intrínsecamente más difícil:

1. El DEX es un formato de alto nivel. Conserva tipos, firmas, jerarquía de clases y nombres de método. Un .so con los símbolos eliminados no conserva nada de eso: el decompilador de Ghidra tiene que inferir hasta el número de argumentos.
2. No hay decompilador de referencia gratuito y bueno. jadx produce Java legible en segundos; reconstruir C desde ARM64 es un trabajo manual de horas por función.
3. El anti-debug nativo es más potente, porque tiene acceso a ptrace, a /proc y al propio mapa de memoria del proceso (secciones «3» y «6.2»).
4. Se puede empaquetar y ofuscar aparte con las mismas técnicas que un binario de escritorio.

Los packers de nivel 3 lo llevan al extremo con lo que Happer llama JNI Transformation: «los packers pueden usar código nativo para reimplementar métodos seleccionados de la aplicación».

Cómo se identifica: un lib/ grande frente a un classes.dex pequeño; muchos métodos native declarados en el DEX —el flag ACC_NATIVE = 0x100 en el access_flags del encoded_method, con code_off a cero («Formato DEX», secciones «10» y «13»)—; y en el .so, o bien símbolos exportados con el patrón Java_<paquete>_<clase>_<método> —registro por descubrimiento—, o bien solo JNI_OnLoad —registro dinámico con RegisterNatives(), que oculta la correspondencia—.

Consecuencia práctica: hay que bajar a Ghidra. Ver «Análisis binario y estático».

8. PairIP

Es la protección de integridad que Google Play aplica del lado de la tienda, sin que el desarrollador toque su código.

Lo que Google publica. La documentación oficial no usa nunca el nombre «PairIP»: lo llama automatic protection o Automatic Integrity Protection. Sus dos funciones, verbatim:

«La protección automática de Google Play es un servicio que ayuda a proteger tus aplicaciones y juegos contra la redistribución no autorizada y la piratería.»

«La protección automática puede añadir una comprobación de instalador de Google Play al código de tu aplicación, que ocurre en tiempo de ejecución cuando se abre la aplicación.»

«La protección automática puede añadir comprobaciones en tiempo de ejecución al código de tu aplicación para detectar modificaciones, y usar técnicas avanzadas de ofuscación para impedir que las comprobaciones se eliminen o se sometan a ingeniería inversa.»

La segunda función tiene requisitos de elegibilidad publicados: 25.000 $/mes de gasto de consumidores, o al menos 20.000 $ en cada uno de los seis meses anteriores, o al menos un millón de usuarios activos mensuales en una categoría sensible, o pertenencia a un programa de Google Play.

Cómo se identifica. El nombre real del paquete es com.pairip, no com.google.android.pairip. Las huellas que se han podido verificar en fuentes de identificación mantenidas:

El export ExecuteProgram y la clase VMRunner cuentan la historia: PairIP es una protección basada en máquina virtual, del tipo descrito en la «sección 3.3 de Packers y protectores · Tres niveles de sofisticación». El bytecode que interpreta viaja en assets/.

⚠️ Varios puntos no confirmados que conviene no propagar: la clase com.google.android.pairip.application.SuperpoweredApplication no existe en ninguna fuente consultada; y los nombres concretos de los ficheros de assets/ no se han podido verificar en ninguna fuente con autoría identificable.

Un matiz de detección que el issue #495 de APKiD señaló y que hay que respetar: la regla de la versión 3.1.0, googleIntegrityProtection, detecta libpairipcore.so pero lo describe como «Google Play Integrity», es decir, confunde la protección automática (com.pairip) con el uso normal de la Play Integrity API (com.google.android.play.core.integrity). Son cosas distintas: la primera la inyecta Play, la segunda la integra el desarrollador. El PR #496, fusionado en master el 21 de mayo de 2026 y aún sin versión publicada, las separa: google_aip_installer_check y google_aip_elf para la protección automática y una regla nueva, google_playintegrity_api, para la API. Esta última también lleva la etiqueta protector, así que con master esa etiqueta salta con cualquier uso de la Play Integrity API.

El «muestrario» no contiene ninguna muestra con PairIP. Buscado en los 717 APK —58 standalone más 659 dentro de contenedores—, incluidos los cuatro juegos, que es donde más se aplica: la subcadena pairip no aparece en ninguno de los 323 ficheros classes*.dex, y no hay libpairipcore.so en ningún lib/. Cero coincidencias. El hueco sigue abierto y es honesto decirlo: todo lo de esta sección procede de fuentes externas, no de observación propia.

9. Play Integrity

Es la otra mitad, y no debe confundirse con la anterior: PairIP la aplica Play al binario; la Play Integrity API la llama el desarrollador desde su código.

Su función, verbatim: «ayuda a comprobar que las acciones de usuario y las peticiones al servidor vienen de tu aplicación genuina, instalada por Google Play, ejecutándose en un dispositivo Android genuino y certificado».

Los veredictos que emite:

Son opcionales, y hay que activarlos: MEETS_BASIC_INTEGRITY, MEETS_STRONG_INTEGRITY, deviceAttributes, appAccessRiskVerdict, playProtectVerdict, recentDeviceActivity y deviceRecall (en beta). Los dos del entorno llegan juntos dentro de environmentDetails.

Relación con SafetyNet Attestation. Es su sucesora directa. La página oficial de retirada lo dice así: «la SafetyNet Attestation API quedó obsoleta en 2022 y se retiró por completo en enero de 2025. Los desarrolladores deben migrar a la Play Integrity API, que consolida varias ofertas de integridad —incluido el veredicto de integridad de SafetyNet Attestation— bajo una única API». Y sobre el estado actual: «si intentas llamar a la SafetyNet Attestation API recibirás un error. La API attest devuelve una tarea que siempre invoca el listener de fallo con una ApiException y un código de estado 7 (NETWORK_ERROR)». ⚠️ La página, en su estado actual, ya no publica la tabla de hitos intermedios: solo da «2022» y «enero de 2025», sin día.

Qué significa para quien analiza una aplicación legítimamente. Tres cosas, y ninguna es técnica de evasión:

1. Los veredictos son señales, no verdad. MEETS_DEVICE_INTEGRITY ausente en un análisis sobre emulador es el resultado esperado y correcto: el dispositivo, efectivamente, no es uno certificado.
2. La comprobación es del lado del servidor. El veredicto viaja firmado por Google al backend de la aplicación. Lo que se observa en el dispositivo es la petición, no la decisión. Un análisis que solo mire el cliente no va a entender por qué la aplicación rechaza operar.
3. La presencia de la API es una huella estática legítima y reportable: las clases com.google.android.play.core.integrity.* en el DEX dicen que la aplicación depende de ella, lo cual es información de arquitectura útil y perfectamente publicable.

10. Los síntomas, que es lo que uno ve primero

El analista no encuentra estas protecciones: las padece. Esta tabla va en la dirección real de descubrimiento —del síntoma a la causa— y complementa «Diagnóstico de fallos».

Y la comprobación previa, que cuesta un minuto y ahorra varias horas: antes de ejecutar nada, mirar el manifiesto y las cadenas. QUERY_ALL_PACKAGES, una lista <queries> con com.topjohnwu.magisk, un com.pairip.licensecheck.LicenseActivity, un libpairipcore.so, la cadena TracerPid, la cadena /system/xbin/su: todo eso es estático, gratis, y dice de antemano qué va a pasar.

Fuentes

1. OWASP MASTG — MASTG-KNOW-0028, «Anti-Debugging» — https://mas.owasp.org/MASTG/knowledge/android/MASVS-RESILIENCE/MASTG-KNOW-0028/ Consultado el 12 de agosto de 2026, con el fuente en raw.githubusercontent.com/OWASP/owasp-mastg/master/knowledge/android/MASVS-RESILIENCE/MASTG-KNOW-0028.md. De aquí sale íntegra la tabla de la «sección 3 · Anti-debug», incluido el matiz de TracerPid y las estructuras de JDWP. Test asociado: MASTG-TEST-0046.
2. OWASP MASTG — MASTG-KNOW-0031, «Emulator Detection» — https://mas.owasp.org/MASTG/knowledge/android/MASVS-RESILIENCE/MASTG-KNOW-0031/ Consultado el 12 de agosto de 2026. De aquí salen las cuatro tablas de la «sección 4 · Anti-emulador» y los cambios de plataforma de la «sección 2 · Qué es y por qué existe». Test asociado: MASTG-TEST-0049.
3. OWASP MASTG — MASTG-KNOW-0027, «Root Detection» — https://mas.owasp.org/MASTG/knowledge/android/MASVS-RESILIENCE/MASTG-KNOW-0027/ Consultado el 12 de agosto de 2026. De aquí sale la tabla de la «sección 5.1 · Root — MASTG-KNOW-0027, MASTG-TEST-0045». Test asociado: MASTG-TEST-0045.
4. OWASP MASTG — MASTG-KNOW-0030, «Reverse Engineering Tool Detection» — https://mas.owasp.org/MASTG/knowledge/android/MASVS-RESILIENCE/MASTG-KNOW-0030/ Consultado el 12 de agosto de 2026. De aquí sale la tabla de la «sección 5.2 · Frida y herramientas de instrumentación — MASTG-KNOW-0030, MASTG-TEST-0048», las dos citas sobre artefactos y falsos positivos, y la referencia a «The Jiu-Jitsu of Detecting Frida» de Bernhard Mueller. Test asociado: MASTG-TEST-0048.
5. OWASP MASTG — MASTG-KNOW-0032, «Runtime Integrity Verification» — https://mas.owasp.org/MASTG/knowledge/android/MASVS-RESILIENCE/MASTG-KNOW-0032/ Consultado el 12 de agosto de 2026. De aquí salen la taxonomía de cuatro preguntas de la «sección 6.2 · Integridad del código en ejecución» y todos sus artefactos concretos.
6. PackageManager — https://developer.android.com/reference/android/content/pm/PackageManager y SigningInfo — https://developer.android.com/reference/android/content/pm/SigningInfo Consultados el 12 de agosto de 2026. De aquí sale íntegra la tabla de la «sección 6.1 · Verificación de la firma desde el propio código», con los niveles de API y los valores constantes.
7. Strazzere, T. y Sawyer, J. — «Android Hacker Protection Level 0», DEF CON 22 (2014) — https://www.defcon.org/images/defcon-22/dc-22-presentations/Strazzere-Sawyer/DEFCON-22-Strazzere-and-Sawyer-Android-Hacker-Protection-Level-UPDATED.pdf Consultado el 12 de agosto de 2026. De aquí sale ptrace(PTRACE_TRACEME) y find_qemud_process() de la «sección 3 · Anti-debug», que MASTG no documenta.
8. Stone, M. — «Unpacking the Packed Unpacker», Virus Bulletin 2018 / Black Hat USA 2018 — https://i.blackhat.com/us-18/Thu-August-9/us-18-Stone-Unpacking-The-Packed-Unpacker.pdf Consultado el 12 de agosto de 2026. De aquí salen las «más de 45 comprobaciones distintas» y las propiedades init.svc.qemud, qemu.sf.fake_camera e init.svc.goldfish-setup de la «sección 4 · Anti-emulador».
9. Prevent unauthorized redistribution with automatic protection (Google Play Console) — https://support.google.com/googleplay/android-developer/answer/10183279 Consultado el 12 de agosto de 2026. De aquí salen las tres citas de la «sección 8 · PairIP» y los requisitos de elegibilidad.
10. APKiD — apkid/rules/dex/protectors.yara y elf/protectors.yara — raw.githubusercontent.com/rednaga/APKiD/master/apkid/rules/ Consultados el 12 de agosto de 2026. De aquí salen las reglas google_aip_installer_check (autor Ivan Baheux) y google_aip_elf (autor Eduardo Novella) con Lcom/pairip/licensecheck/LicenseContentProvider;, libpairipcore.so y el export ExecuteProgram de la «sección 8 · PairIP».
11. APKiD issue #495 — https://github.com/rednaga/APKiD/issues/495 y repositorio Solaree/pairipcore — https://github.com/Solaree/pairipcore Consultados el 12 de agosto de 2026. De aquí salen las entradas de manifiesto com.pairip.licensecheck.LicenseActivity y LicenseContentProvider, las clases com.pairip.VMRunner y com.pairip.SignatureCheck, y la advertencia sobre la confusión entre com.pairip y com.google.android.play.core.integrity.
12. Gültekin, A. — «Reversing Google's New VM-Based Integrity Protection: PairIP», 3 de marzo de 2025 — https://blog.byterialab.com/reversing-googles-new-vm-based-integrity-protection-pairip/ Consultado el 12 de agosto de 2026. De aquí salen VMRunner, la firma de executeVM y el registro por RegisterNatives en JNI_OnLoad de la «sección 8 · PairIP». Se han tomado únicamente los marcadores de identificación.
13. Play Integrity API — Overview y Verdicts — https://developer.android.com/google/play/integrity/overview y https://developer.android.com/google/play/integrity/verdicts Consultados el 12 de agosto de 2026. De aquí salen la definición y la tabla completa de veredictos de la «sección 9 · Play Integrity».
14. SafetyNet Attestation deprecation timeline — https://developer.android.com/privacy-and-security/safetynet/deprecation-timeline Consultado el 12 de agosto de 2026. De aquí salen las dos citas sobre la retirada de la «sección 9 · Play Integrity».
15. DexGuard factsheet 2024 (Guardsquare) — «https://www.guardsquare.com/hubfs/Website/Resources/Fact sheets/factsheet-DexGuard-2024.pdf» Consultado el 12 de agosto de 2026. De aquí sale la lista de seis mecanismos RASP de la «sección 2 · Qué es y por qué existe» y la cita sobre comprobación de certificado de la «sección 6.1 · Verificación de la firma desde el propio código».
16. Xue, Luo et al. — «Happer» — https://www4.comp.polyu.edu.hk/~csxluo/Happer.pdf Consultado el 12 de agosto de 2026. De aquí sale la JNI Transformation de la «sección 7 · Lógica movida a nativo».
17. OWASP MASTG — MASTG-TEST-0045 a MASTG-TEST-0049 — https://mas.owasp.org/MASTG/tests/android/MASVS-RESILIENCE/MASTG-TEST-0045/ y siguientes, con el fuente en github.com/OWASP/mastg, tests/android/MASVS-RESILIENCE/ Consultado el 25 de septiembre de 2026. De aquí sale que los cinco tests están marcados status: deprecated, con sus sustitutos en covered_by: 0324 y 0325, 0352 y 0353, 0338, 0341 y 0351 (secciones «3», «4», «5.1», «5.2» y «6.1»).
18. Play Integrity API — Integrity verdicts — https://developer.android.com/google/play/integrity/verdicts Consultado el 25 de septiembre de 2026. De aquí salen environmentDetails como contenedor de appAccessRiskVerdict y playProtectVerdict, MEETS_BASIC_INTEGRITY como etiqueta opcional y deviceAttributes.sdkVersion («sección 9 · Play Integrity»).
19. APKiD — etiqueta v3.1.0, PR #496 y reglas appdome_* — https://github.com/rednaga/APKiD/pull/496 y https://github.com/rednaga/APKiD/blob/v3.1.0/apkid/rules/dex/protectors.yara Consultados el 25 de septiembre de 2026. De aquí salen la regla googleIntegrityProtection de la 3.1.0, su sustitución en master por el commit 5ae8f40 del 21 de mayo de 2026 («sección 8 · PairIP») y las reglas appdome_dex y appdome_elf («sección 2 · Qué es y por qué existe»).
20. OWASP MASTG, etiqueta v2.0.0 frente a master — https://github.com/OWASP/mastg/releases/tag/v2.0.0, con el fuente en raw.githubusercontent.com/OWASP/mastg/v2.0.0/ y .../master/, tests/android/MASVS-RESILIENCE/ y knowledge/android/MASVS-RESILIENCE/ Consultado el 25 de septiembre de 2026. De aquí sale que v2.0.0, del 30 de junio de 2026, es la última versión publicada; que en ella MASTG-TEST-0046 remite a MASTG-TEST-0046-1 y MASTG-TEST-0046-2 y no a 0352 y 0353, mientras que 0045, 0047, 0048 y 0049 tienen los mismos sustitutos que en master; y que MASTG-KNOW-0027 a 0032 no difieren en contenido entre las dos («secciones 3 · Anti-debug» a 6).
21. rednaga/APKiD, apkid/rules/elf/protectors.yara en master — https://github.com/rednaga/APKiD/blob/master/apkid/rules/elf/protectors.yara Consultado el 25 de septiembre de 2026. De aquí sale la regla appdome_elf_b, ausente en v3.1.0 («sección 2 · Qué es y por qué existe»).