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 mantenerla viva. Una documentación de treinta y cuatro documentos con fechas, versiones y URLs empieza a pudrirse el día siguiente de escribirse. La «sección 8 · Cómo mantener esta documentación al día» 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 · Literatura académica» 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 · Lo que se quedó fuera, y por qué» dice qué se quedó fuera por no poder confirmarlo, que es información tan útil como la lista misma.
3. Alcance. Aquí se documentan 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.3 · Packers» 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 · Literatura académica» 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 una documentación que se verifica con guiones (ver «§8.4 · Informe de enlaces al 13 de agosto de 2026»).

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 muestrario 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, reflexión de Java y packing, cada uno medido por separado en el ecosistema real.

Qué aporta hoy: el vocabulario. Cuando aquí se habla de «cuatro familias de transformación» se 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 de estos documentos.

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: el 12 de agosto de 2026 respondía por HTTP (200) y servía todavía la página real de DeGuard, pero por HTTPS devolvía 502 con un certificado de otro dominio (debin.ai, que a su vez no resuelve). El 24 de septiembre ya no contesta: el dominio resuelve, pero la conexión no llega a establecerse ni por HTTP ni por HTTPS. 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 se toma de este trabajo 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 muestrario: 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 esta documentación, 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 41.172 aplicaciones —3.018 de F-Droid, 13.601 de un rastreo de Google Play y 24.553 muestras de malware—, comparando cuatro decompiladores: jadx, CFR, Fernflower y Procyon. 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 · La comparación honesta: qué dicen las mediciones», 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.

Kargén, Ulf; Mauthe, Noah; Shahmehri, Nahid — «Android decompiler performance on benign and malicious apps: an empirical study». Empirical Software Engineering 28(2):48, 2023. DOI 10.1007/s10664-022-10281-9. https://liu.diva-portal.org/smash/get/diva2:1743022/FULLTEXT01

Es la versión en revista del anterior: repite la metodología y añade 54.945 muestras de malware de AndroZoo, sin fijar tampoco las versiones de los decompiladores. Es la medición pública más reciente que se ha localizado («30-herramientas/01 §6»).

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 «muestrario» —86 aplicaciones— 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 esta documentación —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 muestrario 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 de aquí que lo explica; quien busque saltárselo, esta documentación 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 esta documentación. 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 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, 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 esta documentación: 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 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 esta documentación 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 documentación 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 esta documentación:

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 llegó así: está en la etiqueta android-17.0.0_r1 y no en main, que se congeló en marzo de 2025. Estos ficheros se vigilan en las etiquetas y en la rama que nombra android-latest-release.
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 · Los issue trackers, que son la mejor fuente de modos de fallo»).

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 de esta documentación y comprobarla. Sin User-Agent, o developer.android.com devolverá 302 falsos («§8.4 · Informe de enlaces al 13 de agosto de 2026»):

cd <raíz de la documentación>
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 — Muestrario de APK (horas). El muestrario 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 muestrario, hay que re-medir y volver a fechar, no ajustar a mano.

8.4 Informe de enlaces al 13 de agosto de 2026

Barrido sobre los 34 documentos: 307 URL distintas comprobadas. Se excluyen del recuento los marcadores de posición de la documentación (https://url.exacta/aqui, https://api.ejemplo.com), los URI de espacio de nombres XML de schemas.android.com, que no son documentos y no deben resolver, y los prefijos: una plantilla como https://api.github.com/repos/<org>/<repo> o una asignación de shell B=https://… no son direcciones y devuelven 404 por construcción. verificar.py los descarta desde el 13 de agosto de 2026; hasta entonces producía dos falsas alarmas fijas en cada barrido.

Enlace realmente roto: uno.

El segundo enlace roto que figuraba aquí el 12 de agosto, …/frameworks/base/+/refs/tags, no era un enlace: es la variable B de la receta del paso 5, que se completa con $T y $F antes de usarse. Lo correcto no era arreglar la URL sino el verificador, y eso es lo que se hizo. Merece quedar anotado porque el error de método —tratar un prefijo como una dirección— es el mismo que produce las docenas de falsos positivos de googlesource que describe el párrafo de más abajo.

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 muestrario, 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 muestrario, un enlace que sí está muerto y conviene no añadir: www.softxjournal.com, hoy un dominio aparcado.

apk-deguard.com es otro caso («§3.2 · Deofuscación»). El 12 de agosto estaba medio rota: resolvía (138.201.196.241) y por HTTP devolvía 200 con la página real de DeGuard, mientras HTTPS daba 502 con un certificado de otro dominio. El 24 de septiembre ya no contesta por ninguno de los dos.

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 · Deofuscación», 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 · Prevalencia y técnicas de ofuscación». 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 · Prevalencia y técnicas de ofuscación».
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 · Decompilación». Las cifras concretas que se toman 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 · Packers». 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 · Packers».
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 · Firma».
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 · Infraestructura y datasets».
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 · Infraestructura y datasets». 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 · Infraestructura y datasets».
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 · Infraestructura y datasets». 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 · Charlas y presentaciones».
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 · CTF y material de aprendizaje». 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 · CTF y material de aprendizaje». 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 · Blogs y autores técnicos». 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 · Los issue trackers, que son la mejor fuente de modos de fallo».
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 · Qué mirar en cada release de Android».
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 · Deofuscación», 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. Repetido el 24 de septiembre de 2026 con curl: el dominio sigue resolviendo a 138.201.196.241, pero la conexión caduca sin respuesta por HTTP y por HTTPS. De ahí la redacción de la «sección 3.2 · Deofuscación».
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 · Charlas y presentaciones».
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 · Blogs y autores técnicos»; los cita «40-ofuscacion/03».
23. Comprobación de enlaces de esta documentación — 307 URL distintas extraídas de los 34 documentos con un guion en python3 (verificar.py) —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: primer barrido el 12 de agosto de 2026 e informe al 13, cuando el guion dejó de tratar los prefijos como direcciones. De aquí sale íntegra la «sección 8.4 · Informe de enlaces al 13 de agosto de 2026»: el enlace realmente roto (el 12 de agosto figuraban dos, y el segundo era un prefijo), 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 · Informe de enlaces al 13 de agosto de 2026», que coinciden con lo que declara «30-herramientas/02».
25. Kargén, Mauthe, Shahmehri — Empirical Software Engineering 28(2):48, 2023 — https://doi.org/10.1007/s10664-022-10281-9 y https://liu.diva-portal.org/smash/get/diva2:1743022/FULLTEXT01 Consultado el 25 de septiembre de 2026. «Sección 3.4 · Decompilación».