Bibliografía y comunidad

1. Qué es y por qué existe

Los dos documentos anteriores cubren lo normativo: la especificación cuando la hay y el código cuando no. Este cubre el resto: quién ha medido este ecosistema, quién lo explica bien y dónde se aprende a trabajar en él.

Y cierra con la sección más práctica del bloque, la 8: cómo mantener este corpus vivo. Un corpus documental de treinta y cinco documentos con fechas, versiones y URLs empieza a pudrirse el día siguiente de escribirse. La sección 8 dice qué se pudre primero, qué mirar y con qué órdenes comprobarlo dentro de un año.

1.1 Criterio de admisión

Tres reglas, y la tercera es de alcance:

1. Autor identificable. Nada de agregadores anónimos, ni de sitios que reescriben la documentación de Android con publicidad encima. Si no se sabe quién lo firma, no entra.
2. Verificado. Cada cita académica de la sección 3 tiene autores, año y venue comprobados contra el PDF o la página institucional, no contra una lista de terceros. La sección 3.7 dice qué se quedó fuera por no poder confirmarlo, que es información tan útil como la lista misma.
3. Alcance. Este corpus documenta protecciones para detectar e informar, no para neutralizar. Aquí eso se traduce en: literatura que analiza packers, PairIP o Play Integrity, sí; recetas de bypass o de desempaquetado paso a paso, no. La sección 3.6 detalla los dos casos frontera que sí entran y por qué, y la 3.7 los que se dejaron fuera.

2. Cómo leer la sección académica

Los papers de esta área envejecen de una forma peculiar: la metodología sigue siendo válida mucho después de que las cifras dejen de serlo. Un estudio de 2018 que mide qué porcentaje de aplicaciones de Google Play están ofuscadas ya no describe el Play de hoy, pero su forma de detectar la ofuscación sigue sirviendo, y su cifra sigue siendo el punto de comparación.

Por eso cada entrada dice qué aporta que siga siendo cierto, no solo de qué va.

Todos los enlaces de la sección 3 se comprobaron el 12 de agosto de 2026 y devuelven HTTP 200. Se han elegido deliberadamente las copias de autor o institucionales en lugar de los DOI: dl.acm.org y sciencedirect.com devuelven 403 a cualquier cliente que no sea un navegador, lo que los hace inútiles para un corpus que se verifica con guiones (ver §8.4).

3. Literatura académica

3.1 Prevalencia y técnicas de ofuscación

Wermke, Dominik; Huaman, Nicolas; Acar, Yasemin; Reaves, Bradley; Traynor, Patrick; Fahl, Sascha — «A Large Scale Investigation of Obfuscation Use in Google Play». ACSAC 2018, pp. 222–235. DOI 10.1145/3274694.3274726. https://dwermke.com/pdf/conf-acsac-wermke18.pdf · preprint: https://arxiv.org/abs/1801.02742

Mide la ofuscación en 1,7 millones de aplicaciones gratuitas de Google Play. El resultado que se cita en todas partes: solo alrededor del 24,92 % están ofuscadas por decisión del desarrollador, pese a que la herramienta viene integrada en la cadena de compilación.

Qué aporta hoy: el punto de comparación. Cuando uno mide su propio corpus y le sale una proporción, esta es la cifra contra la que se contrasta. Lo usa 40-ofuscacion/02 §9.

Dong, Shuaike; Li, Menghao; Diao, Wenrui; Liu, Xiangyu; Liu, Jian; Li, Zhou; Xu, Fenghao; Chen, Kai; Wang, XiaoFeng; Zhang, Kehuan — «Understanding Android Obfuscation Techniques: A Large-Scale Investigation in the Wild». SecureComm 2018, LNICST 254, pp. 172–192. DOI 10.1007/978-3-030-01701-9_10. https://diaowenrui.github.io/paper/securecomm18-dong.pdf · preprint: https://arxiv.org/abs/1801.01633

La taxonomía de referencia: renombrado de identificadores, cifrado de cadenas, ofuscación de flujo de control y packing, cada uno medido por separado en el ecosistema real.

Qué aporta hoy: el vocabulario. Cuando el corpus habla de «cuatro familias de transformación» está usando esta clasificación. También la observación sobre los alfabetos de renombrado, que es una huella práctica de identificación.

Niroshan, Akila; Seneviratne, Suranga; Seneviratne, Aruna — «State of Obfuscation: A Longitudinal Study of Code Obfuscation Practices in Google Play Store». SAC 2025. DOI 10.1145/3672608.3707860.

⚠️ Citado sin enlace verificable. Los metadatos se confirmaron en el catálogo de ACM, pero no se ha encontrado ninguna URL que responda: tanto dl.acm.org como la resolución del DOI devuelven 403. Se incluye porque es el estudio longitudinal más reciente localizado sobre el tema y quien tenga acceso institucional lo querrá; no se ha podido leer, y por tanto no se apoya en él ninguna afirmación del corpus.

3.2 Deofuscación

Bichsel, Benjamin; Raychev, Veselin; Tsankov, Petar; Vechev, Martin — «Statistical Deobfuscation of Android Applications». ACM CCS 2016, Viena. DOI 10.1145/2976749.2978422. https://files.sri.inf.ethz.ch/website/papers/deguard.pdf · ficha: https://www.sri.inf.ethz.ch/publications/bichsel2016statistical

DeGuard, del grupo SRI de la ETH de Zúrich. Revierte la ofuscación de layout de ProGuard mediante un modelo probabilístico entrenado sobre Big Code: dado un nombre a.b.c, predice el nombre original a partir del contexto estructural. Recupera el 79,1 % de los nombres.

Qué aporta hoy: es la referencia obligada de la frontera entre deofuscación determinista y heurística, que es la distinción que ordena 40-ofuscacion/05. Aplicar un mapping.txt es determinista y exacto; esto es estadístico y falla el 20 % de las veces. Confundir ambas cosas es el error conceptual más frecuente en este dominio.

El precursor metodológico, por si hace falta la base teórica: Raychev, Veselin; Vechev, Martin; Krause, Andreas — «Predicting Program Properties from Big Code». ACM POPL 2015 (https://www.sri.inf.ethz.ch/publications/raychev2015predicting). Es JSNICE, sobre JavaScript; DeGuard aplica la misma máquina de predicción estructurada a Android. El motor está publicado: https://github.com/eth-sri/Nice2Predict

⚠️ Estado de la demo pública apk-deguard.com, comprobado el 12 de agosto de 2026: responde por HTTP (200) y sirve todavía la página real de DeGuard, pero por HTTPS devuelve 502 y el certificado que presenta es de otro dominio (debin.ai, que a su vez no resuelve). Es decir: no está muerta, está medio rota. Se cita el paper, no la demo.

3.3 Packers

Duan, Yue; Zhang, Mu; Bhaskar, Abhishek Vasisht; Yin, Heng; Pan, Xiaorui; Li, Tongxin; Wang, Xueqiang; Wang, XiaoFeng — «Things You May Not Know About Android (Un)Packers: A Systematic Study based on Whole-System Emulation». NDSS 2018, San Diego. https://www.ndss-symposium.org/wp-content/uploads/2018/02/ndss2018_04A-4_Duan_paper.pdf

DroidUnpack. El primer estudio sistemático de los packers de Android mainstream: qué hacen, cómo se comportan en tiempo de ejecución y qué implicaciones de seguridad tienen.

Caso frontera, y se incluye. El trabajo presenta un framework genérico de desempaquetado, lo que lo acerca al límite del alcance. Se incluye porque su objeto declarado es el estudio sistemático del fenómeno, no instrucciones contra un producto comercial concreto, y porque la caracterización del modelo stub más payload cifrado que sostiene 40-ofuscacion/03 viene de aquí. Lo que el corpus toma es la descripción del modelo y las huellas, no el método de extracción.

Dong, Zikan; Liu, Hongxuan; Wang, Liu; Luo, Xiapu; Guo, Yao; Xu, Guoai; Xiao, Xusheng; Wang, Haoyu — «What Did You Pack in My App? A Systematic Analysis of Commercial Android Packers». ESEC/FSE 2022, Industry Track, Singapur. DOI 10.1145/3540250.3558969. https://yaoguopku.github.io/papers/Dong-FSE-22.pdf

PackDiff. Mide qué comportamientos sensibles —permisos, APIs, recogida de datos— añaden siete packers comerciales sin que el desarrollador lo sepa.

Caso frontera, y se incluye. Analiza qué hacen los packers, no cómo evadirlos. Es además el argumento más sólido para la posición del corpus: un packer no es solo un obstáculo para el análisis, es código de un tercero con capacidades propias dentro de la aplicación, y por eso detectarlo e informarlo tiene valor por sí mismo.

El grupo de Xiapu Luo (PolyU) y la línea de unpacking académico. Existe un conjunto coherente de trabajos —DexHunter, PackerGrind, Happer, Parema— accesibles en https://www4.comp.polyu.edu.hk/~csxluo/ (comprobados los cuatro). Los cita 40-ofuscacion/03, que es el documento donde corresponden.

Aquí se listan pero no se desarrollan. Son la misma categoría frontera que DroidUnpack: su aportación reutilizable es la caracterización de qué hace cada familia de packer, que es lo que alimenta la detección. Su método de extracción queda fuera del alcance de este corpus, y esta bibliografía no lo resume.

3.4 Decompilación

Mauthe, Noah; Kargén, Ulf; Shahmehri, Nahid — «A Large-Scale Empirical Study of Android App Decompilation». SANER 2021, Honolulu, pp. 400–410. DOI 10.1109/SANER50967.2021.00044. Best Paper Award. https://www.ida.liu.se/~ulfka17/papers/SANER2021.pdf

Cuantifica los fallos de decompilación sobre 9.452 aplicaciones, comparando herramientas. Dos conclusiones que van contra la intuición del sector: la ofuscación es rara incluso en malware, y la mayoría de los fallos de decompilación son errores de implementación de las herramientas, no defensas deliberadas de la aplicación.

Qué aporta hoy: es la fuente de toda la sección 6 de 30-herramientas/01, incluido el 96 % de complementariedad entre decompiladores, y de las cifras de detección de packers por APKiD de 30-herramientas/05 §6.3. Es probablemente el paper más útil de esta lista para quien elige herramienta.

3.5 Firma

Wang, Haoyu; Liu, Hongxuan; Xiao, Xusheng; Meng, Guozhu; Guo, Yao — «Characterizing Android App Signing Issues». ASE 2019. DOI 10.1109/ASE.2019.00035. https://impillar.github.io/files/ase2019sig.pdf

El primer estudio a gran escala de firmas de APK: más de 3 millones de aplicaciones distintas, de Google Play y de 24 mercados alternativos. Produce una taxonomía de 21 anti-patrones, incluidos Master Key y Janus.

Qué aporta hoy: contexto empírico para 20-firma/. Las vulnerabilidades que 10-formatos/01 §12 describe una a una, aquí están medidas: cuántas aplicaciones reales las presentaban y en qué mercados.

3.6 Infraestructura y datasets

Allix, Kevin; Bissyandé, Tegawendé F.; Klein, Jacques; Le Traon, Yves — «AndroZoo: Collecting Millions of Android Apps for the Research Community». MSR 2016, pp. 468–471. DOI 10.1145/2901739.2903508. https://jacquesklein2302.github.io/papers/2016-androzoo-msr.pdf

El dataset de referencia del área: millones de APK con etiquetado antivirus. Casi todo estudio empírico posterior de esta lista lo usa como base.

Qué aporta hoy: si alguna vez hay que ampliar el corpus de verificación —86 contenedores— a una escala estadística, esta es la vía establecida.

Arzt, Steven; Rasthofer, Siegfried; Fritz, Christian; Bodden, Eric; Bartel, Alexandre; Klein, Jacques; Le Traon, Yves; Octeau, Damien; McDaniel, Patrick — «FlowDroid: Precise Context, Flow, Field, Object-sensitive and Lifecycle-aware Taint Analysis for Android Apps». PLDI 2014, Edimburgo. DOI 10.1145/2594291.2594299. https://www.bodden.de/pubs/far+14flowdroid.pdf

Análisis de taint estático sensible al ciclo de vida de Android. 93 % de recall y 86 % de precisión sobre DroidBench.

Qué aporta hoy: está fuera del alcance directo de este corpus —es análisis de flujo de datos, no de formato—, pero es la referencia que explica por qué el análisis estático de Android es difícil más allá del parseo: el ciclo de vida de los componentes no tiene un main, y eso rompe las técnicas clásicas.

Backes, Michael; Bugiel, Sven; Derr, Erik — «Reliable Third-Party Library Detection in Android and its Security Applications». ACM CCS 2016, Viena. DOI 10.1145/2976749.2978333. https://group.cispa.io/bugiel/publication/derr-16-ccs/derr-16-ccs.pdf (la dirección antigua trust.cispa.saarland/… redirige aquí: el CISPA cambió de dominio)

LibScout: detección de bibliotecas de terceros resistente a la ofuscación, con un estudio longitudinal sobre 96.995 paquetes de 3.590 aplicaciones.

Qué aporta hoy: la técnica —comparar perfiles estructurales en vez de nombres— es directamente aplicable a la deofuscación heurística, porque resuelve el mismo problema: identificar código cuando los nombres ya no sirven.

Aonzo, Simone; Georgiu, Gabriel Claudiu; Verderame, Luca; Merlo, Alessio — «Obfuscapk: An open-source black-box obfuscation tool for Android apps». SoftwareX, vol. 11 (2020), art. 100403. DOI 10.1016/j.softx.2020.100403. Repositorio: https://github.com/ClaudiuGeorgiu/Obfuscapk

La herramienta de ofuscación black-box modular que se usa como generador de ground truth al evaluar detectores. Sus 21 transformaciones son el catálogo de 40-ofuscacion/02 §6.

⚠️ El artículo en sciencedirect.com devuelve 403 a clientes automatizados. Los datos bibliográficos se confirmaron por otras vías; el enlace útil es el del repositorio.

3.7 Lo que se quedó fuera, y por qué

Parte del valor de una bibliografía es lo que descarta. Estos son los casos:

Nota explícita sobre PairIP. Al consolidar las fuentes del corpus aparecieron dos recursos sobre PairIP cuyo objeto es revertir la protección: una entrada de blog que reconstruye su máquina virtual y un repositorio de código con el mismo fin. Los cita 40-ofuscacion/04, que es donde se explica qué es PairIP y cómo se detecta.

Esta bibliografía no los recoge, y la omisión es deliberada, no un descuido: el bypass de PairIP queda fuera del alcance sin matices, y un índice bibliográfico que los listara los estaría recomendando como lectura. Aquí la frontera se aplica a la recomendación, no solo a la redacción. Quien necesite saber qué es PairIP tiene el documento del corpus que lo explica; quien busque saltárselo, este corpus no es su sitio. | Literatura y utilidades de bypass de Play Integrity y PairIP | Fuera de alcance, sin excepción. Ver la nota de abajo |

4. Charlas y presentaciones

Con vídeo o transparencias públicas y comprobadas.

Strazzere, Tim; Sawyer, Jon — «Android Hacker Protection Level 0». DEF CON 22 (2014). Transparencias: https://media.defcon.org/DEF%20CON%2022/DEF%20CON%2022%20presentations/DEF%20CON%2022%20-%20Strazzere-and-Sawyer-Android-Hacker-Protection-Level-UPDATED.pdf Vídeo: https://media.defcon.org/DEF%20CON%2022/DEF%20CON%2022%20video%20and%20slides/DEF%20CON%2022%20-%20Tim%20Strazzere%20%26%20Jon%20Sawyer%20-%20Android%20Hacker%20Protection%20Level%200.mp4

El repaso clásico al panorama de protectores de Android: qué familias había, qué hacía cada una y qué las delataba. Tiene más de diez años y las familias concretas han cambiado, pero el marco de análisis no.

Por qué está aquí: Tim Strazzere es el autor de APKiD, la herramienta cuyas reglas YARA sostienen buena parte de 40-ofuscacion/02 §7. Esta charla es el razonamiento que hay detrás de esas reglas.

---

Stone, Maddie — «Securing the System: A Deep Dive into Reversing Android Pre-Installed Apps». Black Hat USA 2019. Transparencias: https://i.blackhat.com/USA-19/Thursday/us-19-Stone-Securing-The-System-A-Deep-Dive-Into-Reversing-Android-Preinstalled-Apps.pdf Vídeo: https://www.youtube.com/watch?v=U6qTcpCfuFc

Qué cambia al analizar aplicaciones preinstaladas frente a las de usuario, con casos reales de puertas traseras y de modificaciones del framework.

⚠️ Corrección de una atribución frecuente: esta charla se cita a menudo como de DEF CON 27. Fue Black Hat USA 2019. Se verificó contra el PDF alojado en i.blackhat.com.

---

Stone, Maddie — «Unpacking the Packed Unpacker: Reversing an Android Anti-Analysis Native Library». Black Hat USA 2018. https://i.blackhat.com/us-18/Thu-August-9/us-18-Stone-Unpacking-The-Packed-Unpacker.pdf

Análisis de una biblioteca nativa anti-análisis real, encontrada por el equipo de Google Play Protect: qué comprobaciones hacía y cómo estaban implementadas.

Por qué es la charla más útil de esta sección para este corpus. Es la contrapartida práctica de 40-ofuscacion/04: muestra anti-debug, anti-emulador y comprobaciones de integridad tal como aparecen en un binario real, no en abstracto. El título y la autoría se verificaron en la diapositiva de portada del PDF.

---

⚠️ www.blackhat.com devuelve 403 a clientes automatizados; el subdominio de contenidos i.blackhat.com, donde viven los PDF, responde con normalidad. Las páginas de ponente no se pueden comprobar con guion.

5. Blogs y autores técnicos

Con nombre y trayectoria identificable. La regla del corpus es que nunca se cita un blog para un dato que está en la especificación; estos sirven para lo que no está en ninguna parte: el contexto, la historia y los modos de fallo.

Cómo usarlos: para el porqué y para la historia. Para el qué, la spec o el código.

6. Foros y comunidad

6.1 Los issue trackers, que son la mejor fuente de modos de fallo

Esta es la recomendación menos obvia y la más rentable del documento.

El conocimiento sobre cómo fallan estas herramientas no está documentado en ningún sitio salvo en sus issues. Ninguna documentación de apktool dice qué APK concretos no consigue reempaquetar; los issues sí, con el fichero adjunto y la traza.

Cómo se usa bien: buscar por mensaje de error exacto, no por descripción del problema. Ver 50-procesos/04, que es el documento que convierte esto en catálogo.

6.2 Foros

Reverse Engineering Stack Exchange — https://reverseengineering.stackexchange.com/ Preguntas con respuesta razonada y votada. La etiqueta android es la relevante. ⚠️ El listado por etiqueta devuelve 403 a clientes automatizados (Cloudflare); la raíz del sitio responde con normalidad. Se navega bien desde un navegador.

XDA Developers — https://xdaforums.com/ El foro histórico de la modificación de Android. Sigue siendo el mejor sitio para lo específico de dispositivo y de ROM. ⚠️ No se ha podido comprobar automáticamente: devuelve 403 tanto a curl como a WebFetch (protección anti-bot). No se afirma aquí nada sobre su estado más allá de que el dominio responde rechazando clientes no navegador.

Advertencia de calidad, que vale para los dos: el material de foro es la última opción del orden de preferencia de fuentes de este corpus, y con motivo. Mucho de lo que circula sobre formatos de APK en foros son cadenas de copiar y pegar de hace ocho años, con datos que ya eran inexactos entonces. Un dato de foro se contrasta contra el código antes de escribirlo.

7. CTF y material de aprendizaje

Para quien llega al dominio y quiere práctica, no lectura.

Stone, Maddie — «Android App Reverse Engineering 101» https://github.com/maddiestone/AndroidAppRE · web: https://www.ragingrock.com/AndroidAppRE/ (la ruta https://maddiestone.github.io/AndroidAppRE/ redirige allí)

Taller completo con ejercicios: fundamentos de la aplicación, introducción al reversing, análisis de DEX, código nativo y ofuscación. Es el mejor punto de partida práctico que existe, y es gratuito.

---

OWASP MASTG — Mobile Application Security Testing Guide https://mas.owasp.org/MASTG/ · repositorio: https://github.com/OWASP/mastg (el nombre anterior OWASP/owasp-mastg redirige)

La guía de referencia del sector para prueba de seguridad de aplicaciones móviles. Su valor aquí no es la parte de pentesting sino la sistematización: qué se comprueba, en qué orden y con qué herramienta.

OWASP MASTG Crackmes — https://mas.owasp.org/crackmes/ Aplicaciones Android deliberadamente protegidas, con soluciones publicadas. Son el material de entrenamiento que mejor se ajusta a este corpus: obligan a leer AXML, a seguir la lógica hasta .so y a entender comprobaciones de integridad, que es justo lo que documentan 10-formatos/ y 40-ofuscacion/.

---

Nota de alcance sobre los crackmes. Resolver un crackme es neutralizar una protección. Se incluye igualmente porque son binarios escritos para ser resueltos, sin usuario ni producto detrás, y porque el objetivo es formativo. La frontera de alcance del corpus es sobre protecciones de aplicaciones reales de terceros, no sobre ejercicios didácticos. Lo que no entra aquí son writeups cuyo objeto sea saltarse la protección de una aplicación comercial concreta.

8. Cómo mantener este corpus al día

La sección que hay que leer dentro de un año.

8.1 Qué caduca, y con qué ritmo

La asimetría es la enseñanza: el 80 % del esfuerzo de mantenimiento se va en el 20 % del corpus que habla de herramientas y de requisitos comerciales. Los documentos de formato apenas necesitan tocarse.

8.2 Qué mirar en cada release de Android

Dónde se anuncian los cambios:

Qué ficheros de AOSP vigilar, en orden de impacto sobre este corpus:

1. frameworks/base/libs/androidfw/include/androidfw/ResourceTypes.h — si cambia una estructura aquí, cambia 10-formatos/04 y 10-formatos/05.
2. frameworks/base/tools/aapt2/format/binary/TableFlattener.cpp — cambios en qué escribe aapt2. Un flag nuevo aquí aparece en los APK reales un año después.
3. art/libdexfile/dex/dex_file.h y standard_dex_file.cc — una versión nueva de DEX.
4. tools/apksig/.../v3/V3SchemeConstants.java — un esquema de firma nuevo (v3.2 ya está en el .jar de las build-tools pero no en la rama pública).
5. system/libziparchive/zip_archive.cc — un endurecimiento del lector de ZIP convierte en no instalables APK que antes lo eran.

Las señales de que un formato ha cambiado, por orden de aparición:

• Una constante nueva RES_* o un flag nuevo en ResourceTypes.h.
• Un kDexVersion nuevo, o kNumDexVersions incrementado.
• Un identificador de bloque nuevo en *SchemeConstants.java.
• La señal práctica, y la que llega primero: una avalancha de issues en apktool o jadx con el mismo mensaje de error nuevo. La comunidad detecta los cambios de formato antes de que se documenten (§6.1).

8.3 Procedimiento de revisión

En este orden, porque cada paso es más caro que el anterior.

Paso 1 — Enlaces (minutos, automatizable). Regenerar la lista de URL del corpus y comprobarla. Sin User-Agent, o developer.android.com devolverá 302 falsos (§8.4):

cd <raíz del corpus>
grep -rhoE 'https?://[^ )>"'"'"'`,]+' --include='*.md' . \
  | sed 's/[.,;:]$//' | grep -v '^http://schemas.android.com' | sort -u > /tmp/urls.txt
while read -r u; do
  printf '%s\t%s\t%s\n' \
    "$(curl -sSL --max-time 30 -o /dev/null -w '%{http_code}\t%{url_effective}' "$u")" "$u"
done < /tmp/urls.txt | awk -F'\t' '$1!="200" || $2!=$3'

Salidas a revisar: los 404 (enlace muerto) y los casos en que la URL final difiere de la original (redirección: hay que actualizar la cita antes de que la redirección se retire).

Paso 2 — Herramientas (minutos). Versión y actividad de cada repositorio de 00-panorama/02:

for r in skylot/jadx iBotPeaches/Apktool google/smali REAndroid/ARSCLib \
         REAndroid/APKEditor rednaga/APKiD google/bundletool avast/apkverifier; do
  curl -s "https://api.github.com/repos/$r" | python3 -c "
import sys,json; d=json.load(sys.stdin)
print(f\"{d['full_name']:28} {d['default_branch']:8} push={d['pushed_at'][:10]} archived={d['archived']}\")"
done

Señales de alarma: archived=True, o un pushed_at de más de un año.

Paso 3 — Requisitos de Play (minutos, pero hay que leer). Abrir https://developer.android.com/google/play/requirements/target-sdk y comparar con la tabla de 60-referencias/01 §9. Da por hecho que ha cambiado: cambia todos los agostos.

Paso 4 — Rutas de AOSP (minutos). Comprobar que las rutas de 60-referencias/02 siguen existiendo, y de paso cuál es la etiqueta más alta:

curl -s 'https://android.googlesource.com/platform/frameworks/base/+refs' \
  | grep -oE 'android-[0-9]+\.0\.0_r[0-9]+' | sort -uV | tail -5

Paso 5 — Formatos (horas; solo si el paso 4 delata movimiento). Comparar el fichero de la etiqueta nueva contra el de la vieja. Esto es lo que detecta un cambio de formato de verdad:

F=libs/androidfw/include/androidfw/ResourceTypes.h
B=https://android.googlesource.com/platform/frameworks/base/+/refs/tags
for T in android-16.0.0_r4 android-17.0.0_r1; do
  curl -s "$B/$T/$F?format=TEXT" | base64 -d > "/tmp/RT-$T.h"
done
diff -u /tmp/RT-android-16.0.0_r4.h /tmp/RT-android-17.0.0_r1.h | head -80

Si el diff sale vacío, los documentos de formato no necesitan revisión, y ese es el resultado más frecuente.

Paso 6 — Corpus de APK (horas). El corpus de verificación es una foto de agosto de 2026. Las cifras que salen de él —porcentajes de ofuscación, de source stamp, de alineación— describen esa foto. Si se amplía el corpus, hay que re-medir y volver a fechar, no ajustar a mano.

8.4 Informe de enlaces al 12 de agosto de 2026

Barrido final sobre los 31 documentos del corpus: 286 URL distintas comprobadas, 276 con HTTP 200. Se excluyeron del recuento los marcadores de posición de la documentación (https://url.exacta/aqui, https://api.ejemplo.com) y los URI de espacio de nombres XML de schemas.android.com, que no son documentos y no deben resolver.

Enlaces realmente rotos: dos.

Bloqueos de cliente, no enlaces muertos (funcionan en navegador; devuelven 403 a curl):

Falso positivo por límite de tasa. Trece URL de android.googlesource.com devolvieron 429 en el barrido. No es un problema de los enlaces, es del método: se consultaron demasiadas seguidas. Reconsultadas con tres segundos de separación, doce devolvieron 200 y la decimotercera resultó ser el 404 real de la tabla de arriba. Quien repita esta comprobación debe espaciar las peticiones a googlesource o se llevará una docena de falsas alarmas.

Enlace muerto encontrado fuera del corpus, mencionado para que no se añada: dexlayout.cc en la rama main de ART devuelve 404 porque el directorio fue eliminado (doc 02 §3.2).

Diecinueve redirecciones, que conviene corregir en su origen: hoy funcionan, pero el día que se retire la redirección la cita queda muerta. Las que importan:

Trampa metodológica, y la más importante de este informe: comprobar developer.android.com con curl y un User-Agent de navegador devuelve 302 hacia accounts.google.com por el mecanismo de auto-inicio de sesión. Sin User-Agent devuelve 200. Una primera pasada de esta verificación marcó cuatro páginas como caídas por este motivo, y ninguna lo estaba. Quien automatice la comprobación debe hacerlo sin User-Agent.

Fuera del corpus, dos enlaces relevantes que sí están muertos y conviene no añadir: apk-deguard.com (la demo de DeGuard, §3.2) no resuelve, y www.softxjournal.com es hoy un dominio aparcado.

Fuentes

1. Bichsel, Benjamin; Raychev, Veselin; Tsankov, Petar; Vechev, Martin — «Statistical Deobfuscation of Android Applications», ACM CCS 2016 — https://files.sri.inf.ethz.ch/website/papers/deguard.pdf Consultado el 12 de agosto de 2026. Autores, año y venue verificados contra la portada del PDF y la ficha institucional del grupo SRI de la ETH de Zúrich (https://www.sri.inf.ethz.ch/publications/bichsel2016statistical). De aquí sale la sección 3.2, incluido el 79,1 % de nombres recuperados. Se confirmó que el nombre es Petar Tsankov, no «Peter», como aparece en algunas fuentes secundarias.
2. Wermke, Huaman, Acar, Reaves, Traynor, Fahl — ACSAC 2018 — https://dwermke.com/pdf/conf-acsac-wermke18.pdf y https://arxiv.org/abs/1801.02742 Consultados el 12 de agosto de 2026. Sección 3.1. En las actas figura «Bradley Reaves»; en arXiv, «Brad Reaves».
3. Dong, Li, Diao, Liu, Liu, Li, Xu, Chen, Wang, Zhang — SecureComm 2018 — https://diaowenrui.github.io/paper/securecomm18-dong.pdf Consultado el 12 de agosto de 2026. Sección 3.1.
4. Mauthe, Kargén, Shahmehri — SANER 2021 — https://www.ida.liu.se/~ulfka17/papers/SANER2021.pdf Consultado el 12 de agosto de 2026. Sección 3.4. Las cifras concretas que el corpus toma de este trabajo están en 30-herramientas/01 §6.
5. Duan, Zhang, Bhaskar, Yin, Pan, Li, Wang, Wang — NDSS 2018 — https://www.ndss-symposium.org/wp-content/uploads/2018/02/ndss2018_04A-4_Duan_paper.pdf Consultado el 12 de agosto de 2026. Sección 3.3. Se confirmó que NDSS 2018 es la 25.ª edición, no la 24.ª como indican varias fuentes secundarias.
6. Dong, Liu, Wang, Luo, Guo, Xu, Xiao, Wang — ESEC/FSE 2022 — https://yaoguopku.github.io/papers/Dong-FSE-22.pdf Consultado el 12 de agosto de 2026. Sección 3.3.
7. Wang, Liu, Xiao, Meng, Guo — ASE 2019 — https://impillar.github.io/files/ase2019sig.pdf Consultado el 12 de agosto de 2026. Sección 3.5.
8. Allix, Bissyandé, Klein, Le Traon — MSR 2016 — https://jacquesklein2302.github.io/papers/2016-androzoo-msr.pdf Consultado el 12 de agosto de 2026. Sección 3.6.
9. Arzt, Rasthofer, Fritz, Bodden, Bartel, Klein, Le Traon, Octeau, McDaniel — PLDI 2014 — https://www.bodden.de/pubs/far+14flowdroid.pdf Consultado el 12 de agosto de 2026. Sección 3.6. Tiene dos DOI; el canónico es el de las actas de PLDI '14 (10.1145/2594291.2594299), no el de la reimpresión en SIGPLAN Notices.
10. Backes, Bugiel, Derr — ACM CCS 2016 — https://trust.cispa.saarland/publication/derr-16-ccs/derr-16-ccs.pdf Consultado el 12 de agosto de 2026. Sección 3.6.
11. Aonzo, Georgiu, Verderame, Merlo — SoftwareX 11 (2020), art. 100403 — https://github.com/ClaudiuGeorgiu/Obfuscapk Consultado el 12 de agosto de 2026. Sección 3.6. El artículo en sciencedirect.com devuelve 403; los datos bibliográficos se confirmaron por otras vías y el enlace útil es el del repositorio.
12. Strazzere, Tim; Sawyer, Jon — «Android Hacker Protection Level 0», DEF CON 22 (2014) — transparencias y vídeo en https://media.defcon.org/DEF%20CON%2022/ Consultados el 12 de agosto de 2026. La existencia de ambos ficheros se verificó listando los índices DEF CON 22 presentations/ y DEF CON 22 video and slides/ del archivo de medios de DEF CON, y comprobando después que ambas URL devuelven HTTP 200. Sección 4.
13. Stone, Maddie — «Securing the System: A Deep Dive into Reversing Android Pre-Installed Apps», Black Hat USA 2019 — https://i.blackhat.com/USA-19/Thursday/us-19-Stone-Securing-The-System-A-Deep-Dive-Into-Reversing-Android-Preinstalled-Apps.pdf y https://www.youtube.com/watch?v=U6qTcpCfuFc Consultados el 12 de agosto de 2026. El venue se corrigió: se cita con frecuencia como DEF CON 27 y el PDF alojado en i.blackhat.com/USA-19/ acredita que fue Black Hat USA 2019.
14. Stone, Maddie — «Android App Reverse Engineering 101» — https://github.com/maddiestone/AndroidAppRE Consultado el 12 de agosto de 2026. Sección 7. Se comprobó que maddiestone.github.io/AndroidAppRE/ redirige a www.ragingrock.com/AndroidAppRE/.
15. OWASP MASTG y MASTG Crackmes — https://mas.owasp.org/MASTG/ , https://mas.owasp.org/crackmes/ y https://github.com/OWASP/mastg Consultados el 12 de agosto de 2026. Sección 7. Se comprobó que el repositorio anterior OWASP/owasp-mastg redirige a OWASP/mastg.
16. Blogs de autor — https://connortumbleson.com/ , https://rednaga.io/ , https://calebfenton.github.io/ , https://www.saurik.com/ y https://www.guardsquare.com/blog Consultados el 12 de agosto de 2026, los cinco con HTTP 200. Sección 5. La atribución de apktool a Connor Tumbleson y de APKiD a Tim Strazzere y Caleb Fenton procede de 00-panorama/02 y 30-herramientas/05.
17. Issue trackers de jadx, apktool, smali y ARSCLib — https://github.com/skylot/jadx/issues y las tres homólogas. Consultados el 12 de agosto de 2026, los cuatro con HTTP 200. Sección 6.1.
18. Fuentes de seguimiento de releases de Android — https://developer.android.com/about/versions , https://developer.android.com/about/versions/16/behavior-changes-all , https://source.android.com/docs/security/bulletin , https://developer.android.com/studio/releases y https://android.googlesource.com/platform/frameworks/base/+refs Consultadas el 12 de agosto de 2026, las cinco con HTTP 200. De aquí sale íntegra la tabla de la sección 8.2.
19. Raychev, Vechev, Krause — «Predicting Program Properties from Big Code», ACM POPL 2015 — https://www.sri.inf.ethz.ch/publications/raychev2015predicting y el motor https://github.com/eth-sri/Nice2Predict Consultados el 12 de agosto de 2026. Autores, año y venue verificados contra la ficha institucional. Sección 3.2, como precursor metodológico de DeGuard.
20. Estado de apk-deguard.com — comprobado el 12 de agosto de 2026 con curl y openssl s_client. Lo que se observó, y es lo único que se afirma: por HTTP devuelve 200 y sirve una página titulada «DeGuard | Statistical Deobfuscation for Android»; por HTTPS devuelve 502; el certificado presentado tiene CN=debin.ai y ese dominio no resuelve. De ahí la redacción de la sección 3.2.
21. Stone, Maddie — «Unpacking the Packed Unpacker: Reversing an Android Anti-Analysis Native Library», 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. El título completo, la autoría y el congreso se leyeron de la diapositiva de portada del PDF descargado, no de fuentes secundarias. Sección 4.
22. Quarkslab — blog técnico — https://blog.quarkslab.com/a-glimpse-into-tencents-legu-packer.html y https://blog.quarkslab.com/practical-android-software-protection-in-the-wild-an-appetizer.html Consultados el 12 de agosto de 2026, ambos con HTTP 200. Sección 5; los cita 40-ofuscacion/03.
23. Comprobación de enlaces del corpus — 286 URL distintas extraídas de los 31 documentos con un guion en python3 —descartando marcadores de posición, plantillas con variables y los URI de espacio de nombres de schemas.android.com— y comprobadas con curl -sSL -o /dev/null -w '%{http_code}\t%{url_effective}' sin User-Agent, el 12 de agosto de 2026. De aquí sale íntegra la sección 8.4: los 276 HTTP 200, los dos enlaces realmente rotos, los cinco bloqueos de cliente, las diecinueve redirecciones y los dos falsos positivos metodológicos —el User-Agent en developer.android.com, aislado comparando la misma URL con y sin cabecera, y el límite de tasa de googlesource, aislado reconsultando con tres segundos de separación—.
24. API de crates.io — https://crates.io/api/v1/crates/smali Consultada el 12 de agosto de 2026 con User-Agent propio, que es lo que exige el servicio. De aquí sale la confirmación de la versión 0.6.2, la licencia GPL-3.0-only y las 4.745 descargas de la tabla de la sección 8.4, que coinciden con lo que declara 30-herramientas/02.