article:
elocation-id: de-svcustos-el-marco-de-intrusion-hasta-svperitus-n--25--n--36
author:

Juan Antonio Lloret Egea
bibliography: /tmp/tmp-2036mS9lnKPABW.json
copyright:
link: "https://creativecommons.org/licenses/by-nc-nd/4.0/"
text: Creative Commons Attribution-NonCommercial-NoDerivatives 4.0
International License
type: CC-BY-NC-ND
csl: /app/dist/server/server/utils/citations/citeStyles/apa-6th-edition.csl
journal:
publisher-name: IA eñ ™ - (La Biblia de la IA - The Bible of AI ™ ISSN
2695-641)
title: IA eñ ™
link-citations: true
title: "De SVcustos, el marco de intrusión, hasta SVperitus: n = 25 ➔ n
= 36"
uri: "https://www.itvia.online/pub/de-svcustos-el-marco-de-intrusion-hasta-svperitus-n--25--n--36"

{#n4peaa3orrs}

[video element]

De SVcustos, el marco (framework) de intrusión, hasta SVperitus: agentes especializados. (De n = 25 ➔ n = 36: tercera extensión del espacio paramétrico) {#de-svcustos-el-marco-framework-de-intrusin-hasta-svperitus-agentes-especializados-de-n-25-n-36-tercera-extensin-del-espacio-paramtrico}

(Documento 4 de 8)

Resumen

Este cuarto documento de la serie «De SVcustos, el marco (framework) de
intrusión, hasta SVperitus: agentes especializados» extiende el nivel de
25 parámetros (n = 25 = 5²) a 36 parámetros (n = 36 = 6²), reorganizados
en 6 capas de 6: Red (P1--P6), Conectividad (P7--P12), Sensores
(P13--P18), Sistema (P19--P24), Autenticación e Identidad (P25--P30) y
Comunicaciones y Evasión (P31--P36). Los 11 nuevos parámetros cubren
vectores de amenaza ausentes en n = 25: tráfico cifrado a IPs anónimas,
manipulación de credenciales, fuerza bruta biométrica, acceso al
keystore criptográfico, interceptación de tokens de sesión, exfiltración
por SMS y llamadas sin interacción del usuario, transacciones de pago no
autorizadas, consultas DNS a infraestructura C2, actividad fuera de
ventana horaria habitual y detección de secuencias temporales anómalas.

El documento describe la reestructuración de los 25 parámetros
existentes en la nueva arquitectura 6 × 6, la transformación de cada
vector ternario en un polígono polar de 36 ejes a 10°, y la regla de
clasificación estricta con umbral n₁ ≥ 28 (razón ⌊7 × 36 / 9⌋). El
espacio combinacional asciende a 3³⁶ = 150.094.635.296.999.121 vectores
ternarios únicos (≈ 1,5 × 10¹⁷), con una distribución de 8.952.874.705
vectores INTRUSIÓN (0,000006 %), 150.094.617.391.249.711 INDETERMINADO
(99,999988 %) y 8.952.874.705 NORMAL (0,000006 %).

Abstract

This fourth document in the series extends the SVcustos intrusion
detection system from 25 parameters (n = 25 = 5²) to 36 parameters (n =
36 = 6²), reorganised into 6 layers of 6: Network (P1--P6), Connectivity
(P7--P12), Sensors (P13--P18), System (P19--P24), Authentication &
Identity (P25--P30), and Communications & Evasion (P31--P36). The 11 new
parameters cover threat vectors absent from n = 25: encrypted traffic to
anonymous IPs, credential manipulation, biometric brute force,
cryptographic keystore access, session token interception, SMS/call
exfiltration without user interaction, unauthorised payment
transactions, DNS queries to C2 infrastructure, activity outside
habitual time windows, and anomalous temporal event sequences. The
strict classification threshold is set at n₁ ≥ 28 (⌊7 × 36 / 9⌋). The
combinatorial space is 3³⁶ ≈ 1.5 × 10¹⁷ ternary vectors.

1. Posición en la serie

Este es el cuarto documento de una serie de 8 que describe la evolución
completa del sistema SVcustos, desde su nivel base (n = 9) hasta su
transposición al dominio de conocimiento experto (SVperitus). La serie
sigue la progresión algebraica n = b² con b ≥ 3.

Documento 1: «El nivel base: 9 parámetros y el origen del sistema».
Estableció los fundamentos del sistema: la restricción algebraica n =
b², la lógica ternaria {0, 1, U}, la transformación polar y los 9
parámetros organizados en 3 capas de 3. Para n = 9 se definió una
primera implementación de la clasificación con umbral estricto
(INTRUSIÓN si n₁ ≥ 7, INDETERMINADO si n₁ ∈ {5, 6} con nᵤ ≥ 1, NORMAL el
resto).

Documento 2: «De n = 9 a n = 16: primera extensión». Presentó la
reestructuración a 4 capas de 4, añadiendo 7 nuevos parámetros (TLS,
NFC, sensores de salud, procesos, permisos, datos personales, red
celular). Por primera vez en la serie, formalizó la regla general de
clasificación estricta simétrica sobre el espacio 3ⁿ: INTRUSIÓN si n₁ ≥
⌊7n/9⌋, NORMAL si n₀ ≥ ⌊7n/9⌋, INDETERMINADO el resto. Espacio: 3¹⁶ =
43.046.721. Umbral: n₁ ≥ 12.

Documento 3: «De n = 16 a n = 25: segunda extensión». Reestructuró los
parámetros a 5 capas de 5, añadiendo 9 nuevos parámetros (configuración
de red, modo avión, sensores de movimiento, modificación de sistema, IPC
anómala, almacenamiento externo, portapapeles, sincronización externa,
push notification). Aplicó la regla general ya establecida en el
Documento 2. Espacio: 3²⁵ = 847.288.609.443. Umbral: n₁ ≥ 19.

Este documento (Documento 4): presenta la tercera extensión del sistema
a n = 36 = 6² parámetros, reorganizados en 6 capas de 6. Incorpora 11
nuevos parámetros que cubren autenticación e identidad y comunicaciones
activas con evasión forense. Aplica la misma regla general de
clasificación con umbral n₁ ≥ 28. El espacio combinacional se expande a
3³⁶ ≈ 1,5 × 10¹⁷ vectores ternarios.

2. Estado del sistema en n = 25

El sistema en n = 25 opera con 25 parámetros ternarios organizados en 5
capas de 5 (b = 5, n = b² = 25). Cada parámetro toma uno de tres
valores: 0 (normal), 1 (activo/intrusión) o U (indeterminado). La regla
de clasificación estricta, formalizada en el Documento 2 y aplicada sin
modificación desde entonces, determina: n₁ ≥ 19 → INTRUSIÓN, n₀ ≥ 19 →
NORMAL, resto → INDETERMINADO. El espacio total es 3²⁵ = 847.288.609.443
vectores, con 13.256.611 INTRUSIÓN (0,00156 %), 847.262.096.221
INDETERMINADO (99,997 %) y 13.256.611 NORMAL (0,00156 %).

3. Justificación del salto a n = 36

3.1. Vectores de amenaza no cubiertos por n = 25

El análisis adversarial de los 25 parámetros existentes revela dos
dominios de amenaza sin cobertura.

El primero es el de autenticación e identidad: ningún parámetro de n =
25 detecta ataques sobre el mecanismo de autenticación del dispositivo,
ya sea por fuerza bruta biométrica, manipulación de credenciales o
acceso al almacén de claves del sistema. P17 (escalada de permisos)
opera a nivel de sistema operativo, pero no detecta la modificación
directa de credenciales de cuenta ni la intercepción de tokens de sesión
a nivel de aplicación.

El segundo dominio es el de Comunicaciones y Evasión (comunicaciones
activas y evasión forense): el sistema actual detecta tráfico pasivo
(P1--P5: escuchas, transferencias, certificados, configuración) pero no
comunicaciones iniciadas activamente por el malware (SMS, llamadas
silenciosas) ni intentos de borrar el rastro de su actividad. P3 detecta
exfiltración por red IP, pero no por canal SMS. P19 detecta modificación
de archivos de sistema, pero no contempla específicamente la
manipulación de registros de auditoría ni el análisis temporal de la
actividad del dispositivo. Un sistema que detecta exfiltración pero no
puede caracterizar los patrones temporales de esa actividad ni verificar
la integridad de los registros forenses tiene una cobertura incompleta
del ciclo de amenaza.

Estos dos dominios son cualitativamente distintos de los cubiertos en n
= 25 y corresponden a fases del ciclo de ataque no representadas: la
fase de establecimiento de persistencia mediante control de identidad y
la fase de post-explotación mediante evasión y ocultación.

Adicionalmente, la capa de Red carece de un parámetro que detecte
tráfico cifrado dirigido a IPs fuera de lista blanca (el complemento de
P2, que detecta tráfico no cifrado). Los parámetros P29 y P30 (SMS y
llamadas) cubren canales de exfiltración alternativos que usan la red
celular de voz/datos, completamente separada de la red IP que supervisan
P1--P5.

3.2. Estructura: 6 capas × 6 parámetros

La restricción algebraica del sistema SVcustos establece que n = b² con
b ≥ 3. El siguiente valor válido tras n = 25 (b = 5) es n = 36 (b = 6).
Este salto añade 11 parámetros y reorganiza los 36 resultantes en 6
capas temáticas de 6: Red (P1--P6), Conectividad (P7--P12), Sensores
(P13--P18), Sistema (P19--P24), Autenticación e Identidad (P25--P30) y
Comunicaciones y Evasión (P31--P36).

La quinta capa (Autenticación e Identidad) es completamente nueva y
cubre el vector de identidad y control de acceso. Las demás capas
integran parámetros nuevos con los existentes renumerados. La
renumeración implica reasignaciones semánticas: por ejemplo, la conexión
celular (P23 en n = 25) se traslada a Conectividad (P12 en n = 36),
donde es más coherente con los demás parámetros de interfaz.

El ángulo entre ejes del polígono polar se reduce a 360° / 36 = 10°, lo
que incrementa la densidad visual pero mantiene los 6 sectores de 60°
suficientemente amplios para la discriminación por capa. El espacio
combinacional se expande de 3²⁵ ≈ 8,5 × 10¹¹ a 3³⁶ ≈ 1,5 × 10¹⁷, un
factor de 3¹¹ = 177.147 correspondiente a los 11 nuevos parámetros
ternarios.

4. Reestructuración de los 25 parámetros originales en 6 capas

Los 25 parámetros originales no pierden ninguno de sus valores ni se
redefinen. Únicamente se renumeran para encajar en la arquitectura de 6
capas de 6. La siguiente tabla muestra la correspondencia entre la
numeración de n = 25 (5 × 5) y la nueva de n = 36 (6 × 6), junto con los
11 parámetros nuevos insertados en sus posiciones correspondientes.

Los cambios de asignación de capa más significativos son: P23 (conexión
celular) se traslada de Almacenamiento y Contexto a Conectividad, donde
es semánticamente más coherente con los demás parámetros de interfaz de
conexión; P16 (proceso desconocido) se traslada de Sistema a Sensores,
agrupándose con los demás parámetros de monitorización de actividad; P21
en n = 25 (almacenamiento externo) y P22 (portapapeles) se integran en
Sistema, consolidando todos los parámetros de acceso al sistema
operativo en una única capa. La cobertura de P21 en n = 36 (modificación
de archivos de sistema) se amplía explícitamente para incluir la
integridad de los registros de log, absorbiendo el vector de evasión
forense por manipulación de registros de auditoría.

+-------------+-------------+-------------+-------------+-------------+
| n=25 | n=36 | Parámetro | Capa n=25 | Capa n=36 |
+=============+=============+=============+=============+=============+
| P1 | P1 | URL no | Red | Red |
| | | autorizada | | |
+-------------+-------------+-------------+-------------+-------------+
| P2 | P2 | C | Red | Red |
| | | omunicación | | |
| | | no cifrada | | |
+-------------+-------------+-------------+-------------+-------------+
| P3 | P3 | Tr | Red | Red |
| | | ansferencia | | |
| | | datos al | | |
| | | exterior | | |
+-------------+-------------+-------------+-------------+-------------+
| P4 | P4 | Certificado | Red | Red |
| | | TLS | | |
| | | inválido | | |
+-------------+-------------+-------------+-------------+-------------+
| P5 | P5 | Co | Red | Red |
| | | nfiguración | | |
| | | de red | | |
| | | modificada | | |
+-------------+-------------+-------------+-------------+-------------+
| --- | P6 | Tráfico | --- | Red (nuevo) |
| | | cifrado a | | |
| | | IPs no | | |
| | | ca | | |
| | | tegorizadas | | |
+-------------+-------------+-------------+-------------+-------------+
| P6 | P7 | BSSID no | C | C |
| | | autorizado | onectividad | onectividad |
+-------------+-------------+-------------+-------------+-------------+
| P7 | P8 | Bluetooth | C | C |
| | | no | onectividad | onectividad |
| | | autorizado | | |
+-------------+-------------+-------------+-------------+-------------+
| P8 | P9 | GPS no | C | C |
| | | autorizado | onectividad | onectividad |
+-------------+-------------+-------------+-------------+-------------+
| P9 | P10 | NFC no | C | C |
| | | autorizado | onectividad | onectividad |
+-------------+-------------+-------------+-------------+-------------+
| P10 | P11 | Modo avión | C | C |
| | | irregular | onectividad | onectividad |
+-------------+-------------+-------------+-------------+-------------+
| P23 | P12 | Conexión | Alm. y | C |
| | | celular no | Contexto | onectividad |
| | | autorizada | | |
+-------------+-------------+-------------+-------------+-------------+
| P11 | P13 | Cámara no | Sensores | Sensores |
| | | autorizada | | |
+-------------+-------------+-------------+-------------+-------------+
| P12 | P14 | Micrófono | Sensores | Sensores |
| | | no | | |
| | | autorizado | | |
+-------------+-------------+-------------+-------------+-------------+
| P13 | P15 | Sensores de | Sensores | Sensores |
| | | salud no | | |
| | | autorizados | | |
+-------------+-------------+-------------+-------------+-------------+
| P16 | P16 | Proceso | Sistema | Sensores |
| | | desconocido | | |
| | | en | | |
| | | ejecución | | |
+-------------+-------------+-------------+-------------+-------------+
| P15 | P17 | Sensores de | Sensores | Sensores |
| | | movimiento | | |
| | | anómalos | | |
+-------------+-------------+-------------+-------------+-------------+
| P14 | P18 | Parámetros | Sensores | Sensores |
| | | físicos | | |
| | | anómalos | | |
+-------------+-------------+-------------+-------------+-------------+
| P17 | P19 | Escalada de | Sistema | Sistema |
| | | permisos | | |
+-------------+-------------+-------------+-------------+-------------+
| P18 | P20 | Acceso | Sistema | Sistema |
| | | datos | | |
| | | personales | | |
+-------------+-------------+-------------+-------------+-------------+
| P19 | P21 | M | Sistema | Sistema |
| | | odificación | | |
| | | archivos de | | |
| | | sistema | | |
+-------------+-------------+-------------+-------------+-------------+
| P20 | P22 | IPC anómala | Sistema | Sistema |
+-------------+-------------+-------------+-------------+-------------+
| P21 | P23 | Alm | Alm. y | Sistema |
| | | acenamiento | Contexto | |
| | | externo | | |
+-------------+-------------+-------------+-------------+-------------+
| P22 | P24 | P | Alm. y | Sistema |
| | | ortapapeles | Contexto | |
| | | no | | |
| | | autorizado | | |
+-------------+-------------+-------------+-------------+-------------+
| --- | P25 | Cambio | --- | Au |
| | | c | | tenticación |
| | | redenciales | | (nuevo) |
| | | no | | |
| | | autorizado | | |
+-------------+-------------+-------------+-------------+-------------+
| --- | P26 | Biometría | --- | Au |
| | | fallida | | tenticación |
| | | reiterada | | (nuevo) |
+-------------+-------------+-------------+-------------+-------------+
| --- | P27 | Acceso al | --- | Au |
| | | keystore | | tenticación |
| | | del sistema | | (nuevo) |
+-------------+-------------+-------------+-------------+-------------+
| --- | P28 | Token de | --- | Au |
| | | sesión | | tenticación |
| | | manipulado | | (nuevo) |
+-------------+-------------+-------------+-------------+-------------+
| --- | P29 | SMS sin | --- | Au |
| | | interacción | | tenticación |
| | | del usuario | | (nuevo) |
+-------------+-------------+-------------+-------------+-------------+
| --- | P30 | Llamada sin | --- | Au |
| | | interacción | | tenticación |
| | | del usuario | | (nuevo) |
+-------------+-------------+-------------+-------------+-------------+
| P24 | P31 | Sin | Alm. y | Com. y |
| | | cronización | Contexto | Evasión |
| | | servicios | | |
| | | no | | |
| | | autorizados | | |
+-------------+-------------+-------------+-------------+-------------+
| P25 | P32 | Push | Alm. y | Com. y |
| | | n | Contexto | Evasión |
| | | otification | | |
| | | anómala | | |
+-------------+-------------+-------------+-------------+-------------+
| --- | P33 | API de pago | --- | Com. y |
| | | no | | Evasión |
| | | autorizada | | (nuevo) |
+-------------+-------------+-------------+-------------+-------------+
| --- | P34 | Consultas | --- | Com. y |
| | | DNS no | | Evasión |
| | | ca | | (nuevo) |
| | | tegorizadas | | |
+-------------+-------------+-------------+-------------+-------------+
| --- | P35 | Actividad | --- | Com. y |
| | | fuera de | | Evasión |
| | | ventana | | (nuevo) |
| | | horaria | | |
+-------------+-------------+-------------+-------------+-------------+
| --- | P36 | Secuencias | --- | Com. y |
| | | temporales | | Evasión |
| | | anómalas | | (nuevo) |
+-------------+-------------+-------------+-------------+-------------+

Las filas sombreadas en verde indican los 11 nuevos parámetros. Los 25
parámetros existentes conservan su definición, criterio de
ternarización, herramienta de captura y peso intrusivo íntegros.

5. Los 11 nuevos parámetros: descripción completa

Para cada nuevo parámetro se describe: el vector de amenaza que cubre,
la herramienta real de captura con nombre de API o clase para Android e
iOS, el criterio exacto de ternarización (qué produce valor 0, qué
produce valor 1 y qué produce valor U), su peso intrusivo, y un análisis
adversarial con el argumento técnico contrario más sólido y la réplica
correspondiente.

5.1. P6 --- Tráfico cifrado a IPs no categorizadas [Capa Red]

Peso intrusivo: ★ ALTO

Herramienta de captura: Android: VpnService.Builder para interceptar
tráfico de red. NetworkStatsManager para volumen por UID.
ConnectivityManager.registerNetworkCallback() para detectar conexiones
activas. En entornos con privilegios de sistema, eBPF (extended Berkeley
Packet Filter) mediante tc (traffic control) para inspección a nivel de
socket sin overhead de VPN. iOS: NEFilterDataProvider (Network Extension
framework) para inspección de flujos de red a nivel de contenido.
NWPathMonitor para supervisar rutas activas. NEDNSProxyManager para
correlacionar resoluciones DNS con conexiones posteriores.

Criterio de ternarización: Valor 1: Se detecta tráfico cifrado (TLS/SSL)
dirigido a direcciones IP que no pertenecen a ninguna lista blanca
conocida (CDN principales, servicios corporativos autorizados, dominios
verificados). El volumen o la frecuencia de conexión superan el umbral
configurado. Valor 0: Todo el tráfico cifrado del dispositivo se dirige
a IPs pertenecientes a listas blancas actualizadas o a servicios
previamente categorizados como legítimos. Valor U: La lista blanca de
IPs no está disponible o actualizada, o el dispositivo opera en una red
que modifica las IPs de destino (proxy corporativo, VPN de salida)
impidiendo la verificación directa.

Análisis adversarial:

5.2. P25 --- Cambio de credenciales no autorizado [Capa Autenticación e Identidad]

Peso intrusivo: ★ ALTO

Herramienta de captura: Android:
AccountManager.addOnAccountsUpdatedListener() para detectar cambios en
cuentas registradas. KeyguardManager.isDeviceSecure() para verificar
estado del bloqueo de pantalla. DevicePolicyManager.resetPassword()
(solo dispositivos gestionados) para detectar cambios de PIN/patrón
programáticos. ContentObserver sobre Settings.Secure para monitorizar
cambios en lock_pattern_autolock y lockscreen.password_type. iOS:
LAContext (LocalAuthentication) para verificar si la política de
autenticación ha cambiado. MDM con DeviceInformation.QueryResponses
(clave IsPasscodeLockGracePeriod) para supervisar cambios de código de
acceso. UIApplication.isProtectedDataAvailable para inferir estado de
protección.

Criterio de ternarización: Valor 1: Se detecta una modificación de
credenciales de acceso al dispositivo (PIN, patrón, contraseña) o de
cuentas registradas (Google, Apple ID, cuentas corporativas) sin
interacción directa del usuario con la interfaz de cambio de
credenciales. Valor 0: Las credenciales del dispositivo y las cuentas
registradas se mantienen estables, o los cambios se han realizado a
través de la interfaz estándar del sistema con interacción verificable
del usuario. Valor U: El dispositivo no dispone de mecanismo para
distinguir cambios programáticos de cambios manuales (dispositivos
pre-Android 10 sin BiometricPrompt), o la aplicación de monitorización
carece de privilegios para consultar el estado de las credenciales.

Análisis adversarial:

5.3. P26 --- Autenticación biométrica fallida de forma reiterada [Capa Autenticación e Identidad]

Peso intrusivo: ★ ALTO

Herramienta de captura: Android: BiometricManager.canAuthenticate() para
verificar disponibilidad. BiometricPrompt.AuthenticationCallback con
conteo de onAuthenticationFailed() en ventana temporal configurable (por
defecto, 5 intentos en 60 segundos). FingerprintManager (deprecated pero
presente en API < 28) para compatibilidad con dispositivos antiguos.
iOS: LAContext.evaluatePolicy(.deviceOwnerAuthenticationWithBiometrics)
con manejo de errores LAError.authenticationFailed.
LAContext.biometryLockoutState para detectar bloqueo por intentos
excesivos.

Criterio de ternarización: Valor 1: El número de intentos de
autenticación biométrica fallidos en la ventana temporal configurada
supera el umbral (por defecto, N ≥ 5 en 60 segundos), o el subsistema
biométrico ha entrado en estado de lockout. Valor 0: La autenticación
biométrica se realiza con éxito en los primeros intentos, o no se han
producido intentos de autenticación biométrica en el ciclo de muestreo.
Valor U: El dispositivo no dispone de sensor biométrico, o el usuario ha
desactivado la autenticación biométrica, o la API no reporta el número
de intentos fallidos (dispositivos pre-Android 9).

Análisis adversarial:

5.4. P27 --- Acceso al keystore del sistema [Capa Autenticación e Identidad]

Peso intrusivo: ★ ALTO

Herramienta de captura: Android: Android Keystore System
(java.security.KeyStore con tipo «AndroidKeyStore»).
KeyGenParameterSpec.Builder para auditar las propiedades de claves
generadas. KeyInfo.isInsideSecureHardware() para verificar respaldo en
hardware seguro (TEE/StrongBox). KeyChain API para certificados de
sistema. iOS: Security framework: SecItemCopyMatching para enumerar
elementos del Keychain. kSecAttrAccessControl para verificar políticas
de acceso. DCAppAttestService (DeviceCheck) para verificar integridad de
la app que solicita acceso.

Criterio de ternarización: Valor 1: Se detecta acceso al almacén de
claves criptográficas del sistema (lectura, exportación o modificación
de claves privadas, certificados o tokens) por parte de una aplicación
no autorizada, o se detecta una clave generada sin respaldo en hardware
seguro cuando el dispositivo lo soporta. Valor 0: Los accesos al
keystore provienen exclusivamente de aplicaciones autorizadas (firmadas
por el sistema o incluidas en la whitelist MDM), y todas las claves
sensibles tienen respaldo en hardware seguro. Valor U: El dispositivo no
soporta hardware seguro (TEE/StrongBox), o la aplicación de
monitorización no tiene privilegios suficientes para auditar los accesos
al keystore, o el keystore está cifrado con una clave derivada de
credenciales de usuario no disponibles.

Análisis adversarial:

5.5. P28 --- Token de sesión manipulado o interceptado [Capa Autenticación e Identidad]

Peso intrusivo: ★ ALTO

Herramienta de captura: Android: CookieManager (android.webkit) para
inspeccionar cookies de sesión en WebView. AccountManager.getAuthToken()
con monitorización de tokens OAuth. Interceptor de OkHttp/Retrofit para
inspeccionar cabeceras Authorization en tráfico de aplicaciones.
SharedPreferences monitor para detectar modificación de tokens
almacenados localmente. iOS: WKHTTPCookieStore para cookies de WebView.
URLSession.configuration.httpCookieStorage para cookies de sesión.
ASWebAuthenticationSession para flujos OAuth monitorizados. Keychain
Services (SecItemCopyMatching con kSecClassGenericPassword) para tokens
almacenados.

Criterio de ternarización: Valor 1: Se detecta un token de sesión
(OAuth, JWT, cookie de sesión) cuya firma es inválida, cuyo tiempo de
expiración ha sido modificado, o que está siendo utilizado desde un
contexto de ejecución distinto al que lo generó (cambio simultáneo de
IP, user-agent y device fingerprint). Valor 0: Todos los tokens de
sesión activos tienen firmas válidas, no han sido modificados y se
utilizan desde el mismo contexto que los generó. Valor U: La aplicación
no utiliza tokens de sesión estándar (protocolos propietarios), o los
tokens están cifrados de extremo a extremo impidiendo la inspección, o
el dispositivo opera en una red con IP dinámica que cambia legítimamente
el contexto.

Análisis adversarial:

5.6. P29 --- SMS o MMS enviado sin interacción del usuario [Capa Autenticación e Identidad]

Peso intrusivo: ★ ALTO

Herramienta de captura: Android: SmsManager.sendTextMessage() /
sendMultimediaMessage() con BroadcastReceiver para SENT_SMS_ACTION.
ContentObserver sobre content://sms/sent para detectar mensajes
enviados. Verificación de que la actividad de envío corresponde a una
interacción de usuario (requireActivity()) o fue iniciada
programáticamente. iOS: No existe API pública para enviar SMS sin
interacción del usuario en iOS. MFMessageComposeViewController requiere
confirmación explícita. La detección se realiza mediante MDM
supervisado: perfil de restricciones que audita el log de mensajes
enviados y compara con sesiones de uso activo del dispositivo.

Criterio de ternarización: Valor 1: Se detecta el envío de un SMS o MMS
sin que el usuario haya interactuado con la interfaz de mensajería del
sistema. La detección se basa en la ausencia de evento de toque
(MotionEvent) en la ventana temporal inmediatamente anterior al envío.
Valor 0: Todos los SMS/MMS enviados corresponden a interacciones
verificables del usuario con la aplicación de mensajería, o no se han
enviado mensajes en el ciclo de muestreo. Valor U: El dispositivo no
tiene tarjeta SIM (opera solo por WiFi/Bluetooth), o la aplicación de
monitorización no tiene permiso READ_SMS / RECEIVE_SMS, o el dispositivo
utiliza una aplicación de mensajería de terceros que no pasa por
SmsManager.

Análisis adversarial:

5.7. P30 --- Llamada telefónica iniciada sin interacción del usuario [Capa Autenticación e Identidad]

Peso intrusivo: ★ ALTO

Herramienta de captura: Android: TelecomManager.placeCall() / Intent
ACTION_CALL con monitorización de CALL_PHONE permission.
PhoneStateListener / TelephonyCallback (API 31+) para detectar
transiciones a estado OFFHOOK sin evento de toque previo. CallLog.Calls
con ContentObserver para correlacionar llamadas salientes con sesiones
de uso activo. iOS: CallKit (CXCallObserver) para detectar llamadas
salientes. CTCallCenter (deprecated pero funcional) para compatibilidad.
La detección de llamadas sin interacción se realiza correlacionando
CXCallObserver.callChanged con UIApplication.State: una llamada iniciada
en estado .background sin transición previa a .active indica activación
programática.

Criterio de ternarización: Valor 1: Se detecta una llamada telefónica
saliente sin interacción verificable del usuario con la interfaz de
llamada del sistema. El dispositivo pasa a estado OFFHOOK (Android) o
conectado (iOS) sin evento de toque en la ventana temporal precedente.
Valor 0: Todas las llamadas salientes corresponden a interacciones
verificables del usuario, o no se han realizado llamadas en el ciclo de
muestreo. Valor U: El dispositivo no tiene capacidad de llamada (solo
WiFi/datos), o la aplicación no tiene permiso READ_PHONE_STATE /
CALL_PHONE, o el dispositivo utiliza VoIP que no pasa por el stack
telefónico nativo.

Análisis adversarial:

5.8. P33 --- Acceso a API de pago no autorizada [Capa Comunicaciones y Evasión]

Peso intrusivo: ★ ALTO

Herramienta de captura: Android: NFC Host Card Emulation
(HostApduService) para detectar transacciones NFC en modo HCE. Google
Pay API (PaymentsClient.isReadyToPay()) para verificar estado del stack
de pagos. PackageManager.queryIntentActivities(ACTION_PROCESS_PAYMENT)
para enumerar aplicaciones con capacidad de pago registrada. iOS:
PassKit framework (PKPaymentAuthorizationController) para detectar
inicialización de transacciones Apple Pay. NFC Core
(NFCTagReaderSession) para sesiones de lectura de tags de pago. StoreKit
para compras in-app no autorizadas.

Criterio de ternarización: Valor 1: Se detecta una transacción de pago
(NFC-HCE, compra in-app, o invocación de API de pago) no iniciada por
interacción directa del usuario con la interfaz de pago del sistema.
Valor 0: No se han detectado transacciones de pago, o todas las
transacciones corresponden a interacciones verificables del usuario con
la interfaz de pago. Valor U: El dispositivo no soporta NFC o no tiene
aplicaciones de pago instaladas, o el stack de pagos está desactivado
por política MDM.

Análisis adversarial:

5.9. P34 --- Consultas DNS a dominios no categorizados [Capa Comunicaciones y Evasión]

Peso intrusivo: ★ ALTO

Herramienta de captura: Android: VpnService con DnsResolver (API 29+)
para interceptar y registrar todas las consultas DNS del dispositivo.
DnsResolver.query() para resolución programática con callback.
ConnectivityManager.getLinkProperties().getDnsServers() para identificar
los servidores DNS configurados. En entornos con privilegios: eBPF hook
sobre dns_resolve para captura sin VPN. iOS: NEDNSProxyManager (Network
Extension) para interceptar consultas DNS. NWConnection con parámetros
.tls y .tcp para monitorizar resoluciones. NEFilterDataProvider para
correlacionar resoluciones DNS con conexiones de red posteriores.

Criterio de ternarización: Valor 1: Se detectan consultas DNS a dominios
que no aparecen en ninguna categoría de las listas de clasificación
utilizadas (Tranco, Alexa, Majestic, o lista corporativa), especialmente
si las consultas siguen un patrón de beaconing (intervalos regulares) o
utilizan técnicas de DNS tunneling (subdominios codificados
excesivamente largos). Valor 0: Todas las consultas DNS del dispositivo
se dirigen a dominios categorizados en las listas de referencia o a
dominios corporativos conocidos. Valor U: Las listas de categorización
no están actualizadas (última actualización > 7 días), o el dispositivo
utiliza DNS over HTTPS (DoH) / DNS over TLS (DoT) a un resolver externo
que impide la inspección de las consultas.

Análisis adversarial:

5.10. P35 --- Actividad fuera de ventana horaria habitual [Capa Comunicaciones y Evasión]

Peso intrusivo: bajo

Herramienta de captura: Android: UsageStatsManager.queryUsageStats()
para obtener el perfil de uso temporal del dispositivo (horas de
actividad, aplicaciones más usadas por franja horaria).
PowerManager.isInteractive() para detectar actividad cuando la pantalla
está apagada. AlarmManager con análisis de alarmas programadas fuera del
perfil habitual. iOS: NSProcessInfo.processInfo.thermalState como proxy
de actividad del dispositivo. UIApplication.State para detectar
actividad en background durante horas inusuales. Screen Time API
(DeviceActivityMonitor) para perfil de uso autorizado (solo dispositivos
supervisados).

Criterio de ternarización: Valor 1: Se detecta actividad significativa
del dispositivo (transferencia de red, acceso a sensores, ejecución de
procesos) fuera de la ventana horaria habitual del usuario, definida por
el percentil 95 del perfil de uso acumulado de los últimos 30 días.
Ejemplo: un dispositivo corporativo muestra tráfico de red sostenido a
las 03:00 cuando el historial de uso del titular se concentra entre las
08:00 y las 20:00. Valor 0: Toda la actividad del dispositivo se produce
dentro de la ventana horaria habitual del usuario, o la actividad fuera
de ventana corresponde exclusivamente a procesos de sistema conocidos
(actualizaciones, sincronización programada). Valor U: El sistema no
dispone de baseline suficiente (menos de 7 días de perfil de uso
acumulado), o el usuario tiene un patrón de uso altamente irregular
(trabajadores por turnos, viajeros entre zonas horarias) que impide
establecer una ventana horaria significativa.

Análisis adversarial:

5.11. P36 --- Secuencias temporales anómalas [Capa Comunicaciones y Evasión]

Peso intrusivo: bajo

Herramienta de captura: Android: UsageStatsManager.queryEvents() para
secuencias de eventos de aplicación (apertura, cierre, transiciones).
ContentObserver sobre CallLog, SMS y AccountManager para registrar la
cadena temporal de acciones. JobScheduler / WorkManager para detectar
ráfagas de tareas programadas fuera del patrón habitual. iOS: MetricKit
(MXSignpostMetric) para capturar secuencias de señalización de
aplicaciones. NSUserActivity para transiciones entre actividades.
DeviceActivityMonitor (Screen Time API, dispositivos supervisados) para
registrar orden y duración de sesiones de uso.

Criterio de ternarización: Valor 1: Se detecta una secuencia de eventos
cuyo orden o ritmo se desvía significativamente del patrón aprendido:
ráfagas de intentos de autenticación seguidas de acceso al keystore y
transferencia de datos en intervalos de milisegundos (consistente con
script automatizado), o cadenas de login → token → acción que se
completan más rápido de lo que un usuario humano puede ejecutar. Valor
0: Las secuencias de eventos siguen patrones temporales consistentes con
interacción humana: intervalos variables entre acciones, pausas
naturales, y orden coherente con la navegación de la interfaz de
usuario. Valor U: El sistema no dispone de suficiente historial de
secuencias para establecer un modelo base (menos de 14 días de actividad
registrada), o la aplicación de monitorización no tiene acceso a los
eventos de uso (dispositivos sin permiso PACKAGE_USAGE_STATS).

Análisis adversarial:

6. Tabla completa de los 36 parámetros

La siguiente tabla recoge los 36 parámetros del nivel n = 36,
organizados en sus 6 capas de 6. De los 36 parámetros, 30 tienen peso
intrusivo ★ ALTO y 6 tienen peso bajo (P8 Bluetooth, P17 movimiento, P18
parámetros físicos, P32 push notification, P35 ventana horaria y P36
secuencias temporales).

Los parámetros marcados como peso «bajo» no disminuyen el umbral
estricto de clasificación; solo reducen su contribución al gradiente de
riesgo dentro del espacio INDETERMINADO. En otras palabras, un parámetro
de peso bajo con valor 1 cuenta igualmente para el conteo n₁ a efectos
de la regla estricta (n₁ ≥ 28), pero su aportación a la puntuación
ponderada del gradiente de riesgo es menor que la de un parámetro de
peso alto. Esta distinción es relevante únicamente para la priorización
de vectores dentro de la zona INDETERMINADO, no para la clasificación
binaria INTRUSIÓN/NORMAL.

7. Del vector de 36 parámetros al polígono polar

El vector ternario de 36 componentes se transforma en un polígono en
coordenadas polares siguiendo el mismo principio que los niveles
anteriores. Cada parámetro ocupa un eje de los 36 equiespaciados a 10°
entre sí (360° / 36 = 10°). Los valores lógicos se mapean a radios:
valor 0 → radio 1 (mínimo, cerca del centro), valor 1 → radio 2
(intermedio, capa de actividad/intrusión), valor U → radio 3 (máximo,
corona externa de incertidumbre).

Esta representación conserva dos propiedades relevantes. Primera: los
vectores con muchos parámetros en valor 1 producen polígonos expandidos
hacia la periferia, visualmente distinguibles de los vectores normales
(compactos cerca del centro). Segunda: la organización en 6 capas (seis
ejes consecutivos por capa) hace que los patrones de activación por capa
sean inmediatamente visibles como deformaciones sectoriales del
polígono. Un analista puede identificar a simple vista si la activación
se concentra en Red (0°--60°), Conectividad (60°--120°), Sensores
(120°--180°), Sistema (180°--240°), Autenticación e Identidad
(240°--300°) o Comunicaciones y Evasión (300°--360°).

La resolución angular de 10° es menor que los 14,4° del nivel anterior,
lo que incrementa la densidad visual del polígono. No obstante, los 6
sectores de 60° siguen siendo suficientemente amplios para que la CNN
ResNet34 discrimine las capas sin ambigüedad. La imagen polar resultante
se genera a resolución 224 × 224 píxeles para mantener compatibilidad
con la arquitectura ImageNet estándar de la red.

8. Regla de clasificación para n = 36

8.1. Principio de clasificación estricta

El sistema SVcustos mantiene en n = 36 el mismo principio de
clasificación estricta formalizado en el Documento 2 y aplicado sin
modificación en los Documentos 3 y 4: solo los parámetros confirmados en
valor 1 determinan la entrada en estado de INTRUSIÓN. Los parámetros en
valor U (indeterminados) no cuentan para el umbral de intrusión, porque
la incertidumbre no confirma amenaza.

8.2. Umbral estricto para n = 36

La regla de clasificación opera sobre tres conteos:

n₁ = número de parámetros con valor 1 (confirmados activos).

n₀ = número de parámetros con valor 0 (confirmados normales).

nᵤ = número de parámetros con valor U (indeterminados).

La clasificación se determina como sigue:

INTRUSIÓN: n₁ ≥ 28. Al menos 28 de los 36 parámetros están confirmados
en valor 1. El umbral se obtiene de la razón del nivel base: ⌊7 × 36 /
9⌋ = ⌊28,0⌋ = 28.

NORMAL: n₀ ≥ 28. Al menos 28 de los 36 parámetros están confirmados en
valor 0. Simétrica a la regla de intrusión.

INDETERMINADO: todo vector que no cumpla ninguna de las dos condiciones
anteriores. Esta es la zona mayoritaria del espacio, donde opera el
gradiente de riesgo.

8.3. Gradiente de riesgo dentro de INDETERMINADO

La zona de INDETERMINADO contiene el 99,999988 % del espacio ternario.
Dentro de ella, la puntuación ponderada n₁ + 0,5 × nᵤ no determina la
clasificación, sino que ordena los vectores por su nivel de riesgo para
que los analistas puedan priorizar su inspección. Los parámetros de peso
★ ALTO contribuyen con su valor completo al gradiente, mientras que los
de peso bajo (sin reducir el umbral estricto; sólo modulan el gradiente
de riesgo dentro de INDETERMINADO) contribuyen con un factor reducido
(configurable por despliegue, por defecto 0,5). Esta distinción es
fundamental: la duda acumulada eleva la prioridad de inspección, pero no
sustituye la confirmación.

8.4. Espacio combinacional

Espacio total: 3³⁶ = 150.094.635.296.999.121 vectores ternarios únicos
(≈ 1,5 × 10¹⁷).

Esto representa una expansión de factor ×177.147 respecto al nivel
anterior (150.094.635.296.999.121 / 847.288.609.443 = 177.147 = 3¹¹),
correspondiente a los 11 nuevos parámetros ternarios añadidos. A esta
escala, la justificación del uso de IA no es solo de eficiencia sino de
viabilidad: no existe alternativa computacional práctica al clasificador
neuronal para inspeccionar un espacio de esta magnitud.

9. Distribución del espacio ternario

La distribución algebraica del espacio de 3³⁶ = 150.094.635.296.999.121
vectores bajo la regla estricta (n₁ ≥ 28 para INTRUSIÓN, n₀ ≥ 28 para
NORMAL) es:

Clasificación Vectores Porcentaje

INTRUSIÓN 8.952.874.705 0,000006 %
INDETERMINADO 150.094.617.391.249.711 99,999988 %
NORMAL 8.952.874.705 0,000006 %

La concentración del 99,999988 % del espacio en INDETERMINADO es
consecuencia directa de la exigencia del umbral estricto: con 36
parámetros, se necesitan al menos 28 confirmados en valor 1 para
clasificar como INTRUSIÓN. Esto confirma que la clasificación algebraica
actúa como primer filtro del sistema. La red neuronal ResNet34 se
entrena para aproximar dicha función de decisión a partir de la imagen
polar, con el doble objetivo de validar la representación geométrica y
preparar la infraestructura para futuras fases con distribuciones
empíricas.

9.1. Desglose de INTRUSIÓN por nivel de activación

n₁ Combinaciones Vectores Subtotal

28 C(36,28) × 2⁸ 7.746.647.040 86,53 %
29 C(36,29) × 2⁷ 1.068.503.040 11,93 %
30 C(36,30) × 2⁶ 124.658.688 1,39 %
31 C(36,31) × 2⁵ 12.063.744 0,13 %
32 C(36,32) × 2⁴ 942.480 0,01 %
33 C(36,33) × 2³ 57.120 < 0,01 %
34 C(36,34) × 2² 2.520 < 0,01 %
35 C(36,35) × 2¹ 72 < 0,01 %
36 C(36,36) × 2⁰ 1 < 0,01 %

10. Tres ejemplos de vectores ilustrativos

10.1. Ejemplo INTRUSIÓN

Vector: (1, 1, 1, 1, 1, 1, 1, 0, 1, 1, 1, 1, 1, 1, 1, 1, 0, 0, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 0, 1, 1, 1, 1)

Conteo: n₁ = 32, n₀ = 4, nᵤ = 0. Clasificación: INTRUSIÓN (n₁ = 32 ≥
28).

Interpretación: 32 de los 36 parámetros están confirmados activos. Las
únicas excepciones son P8 (Bluetooth, peso bajo), P17 (movimiento, peso
bajo), P18 (parámetros físicos, peso bajo) y P32 (push notification,
peso bajo). El polígono polar ocupa el anillo intermedio en 32 de los 36
ejes. Las 6 capas muestran activación masiva, incluyendo la totalidad de
la capa de Autenticación e Identidad. Gradiente de riesgo: 32,0.

10.2. Ejemplo NORMAL

Vector: (0, 0, 0, 0, 0, U, 0, 0, 0, 0, 0, 0, 0, 0, U, 0, U, 0, 0, 0, 0,
0, U, 0, 0, 0, U, 0, 0, 0, 0, U, 0, 0, 0, U)

Conteo: n₁ = 0, n₀ = 29, nᵤ = 7. Clasificación: NORMAL (n₀ = 29 ≥ 28).

Interpretación: 29 de los 36 parámetros confirman estado normal. Los
siete indeterminados (P6 tráfico cifrado, P15 salud, P17 movimiento, P23
almacenamiento externo, P27 keystore, P32 push y P36 secuencias
temporales) corresponden a parámetros cuyas APIs no pudieron completar
la verificación en el ciclo de muestreo, posiblemente por restricciones
de privilegios o por falta de baseline temporal. El polígono es
compacto, pegado al centro. Gradiente de riesgo: 3,5.

10.3. Ejemplo INDETERMINADO

Vector: (1, 1, 0, 1, 1, 1, U, 0, 1, 0, 1, 1, 1, U, 1, 0, U, 1, 1, 0, 1,
U, 1, 0, 1, 1, 0, 1, U, 1, 1, 0, 1, U, 0, 1)

Conteo: n₁ = 20, n₀ = 10, nᵤ = 6. Clasificación: INDETERMINADO (n₁ = 20
< 28 y n₀ = 10 < 28).

Interpretación: 20 parámetros confirmados activos y 6 indeterminados. Si
los 6 valores U se resolvieran como 1, n₁ llegaría a 26, aún por debajo
del umbral 28. Este vector es de alta prioridad dentro de INDETERMINADO:
el gradiente de riesgo es 20 + 0,5 × 6 = 23,0, lo que indica un nivel de
activación elevado que requiere resolución urgente de los 6 parámetros
indeterminados. La activación se concentra en Red (5 de 6),
Autenticación e Identidad (4 de 6) y Comunicaciones y Evasión (4 de 6).

11. Valoración de implementación

El salto de n = 25 a n = 36 es técnicamente viable con las APIs actuales
de Android (API 29+) e iOS (14+), aunque introduce condicionantes de
privilegios más exigentes que el nivel anterior. De los 11 nuevos
parámetros, 7 utilizan APIs públicas documentadas accesibles sin
privilegios especiales (P6 tráfico cifrado, P25 credenciales, P26
biometría, P28 token de sesión, P29 SMS, P30 llamadas, P35 ventana
horaria). Los 4 restantes (P27 keystore, P33 API de pago, P34 DNS, P36
secuencias temporales) requieren, según el grado de profundidad deseado,
privilegios de sistema, acceso MDM o funcionalidades específicas del
fabricante.

El espacio combinacional de 150.094.635.296.999.121 vectores ternarios
(≈ 1,5 × 10¹⁷) excede por varios órdenes de magnitud la capacidad de
enumeración explícita. Sin embargo, la clasificación algebraica de
cualquier vector individual sigue siendo una operación trivial de conteo
sobre n₁, n₀ y nᵤ. El entrenamiento de la ResNet34 se realiza sobre
muestras representativas generadas sintéticamente (1.000 imágenes por
clase), no sobre la totalidad del espacio.

La reorganización de 5 capas a 6 capas es transparente para el sistema
de clasificación: la regla estricta opera sobre conteos globales, no
sobre la estructura de capas. Las capas constituyen una organización
semántica para el analista humano y un soporte para la interpretabilidad
visual del polígono polar.

11.1. Condiciones de aplicabilidad por familia de dispositivos

Smartwatches RTOS (Garmin, Fitbit básico): P6 (tráfico cifrado), P21
(archivos de sistema), P22 (IPC), P23 (almacenamiento externo), P25--P28
(autenticación completa), P33 (API pago) y P34 (DNS) son
estructuralmente no observables en estas plataformas. El vector efectivo
se reduce a ~25 parámetros funcionales, con 11 valores U permanentes.

Smartwatches SO completo (Wear OS, watchOS): La mayoría de parámetros
son observables directamente o mediante delegación al smartphone
companion (WearableListenerService en Android, WCSession en iOS). P23
(almacenamiento externo) produce U estructural por ausencia de hardware.
P29 y P30 (SMS y llamadas) solo son funcionales en smartwatches con SIM
propia.

Smartphones y tabletas: Los 36 parámetros son potencialmente
observables. P21, P22, P27 y P34 alcanzan máxima granularidad en
dispositivos gestionados por MDM o con la aplicación de monitorización
firmada como agente de sistema.

11.2. Dataset de entrenamiento: SVcustos-dataset

El repositorio GitHub SVcustos-dataset
(https://github.com/juantoniolloretegea/SVcustos-dataset) contiene el
dataset de imágenes polares utilizado para entrenar la red ResNet34 en
cada nivel de la serie. Las imágenes se generan sintéticamente aplicando
el mismo criterio algebraico de clasificación descrito en este
documento: cada vector ternario se clasifica como INTRUSIÓN, NORMAL o
INDETERMINADO según la regla estricta, y se transforma en su polígono
polar correspondiente.

Es importante señalar que el dataset se equilibra deliberadamente a
partes iguales entre las tres clases (1.000 imágenes por clase en la
configuración base), a pesar de que la distribución real del espacio 3ⁿ
está fuertemente concentrada en INDETERMINADO (99,999988 % para n = 36).
Este equilibrio artificial es una decisión de diseño para evitar el
sesgo de clase mayoritaria durante el entrenamiento: la red debe
aprender a discriminar las tres geometrías polares, no a predecir
siempre INDETERMINADO. La distribución real del espacio se aplica a
posteriori como prior bayesiano o como ponderación en la función de
pérdida, según la estrategia de despliegue.

Para n = 36, se extenderá la configuración del dataset con un nuevo
fichero config/n36.yaml que definirá n = 36, b = 6, umbral n₁ ≥ 28,
ángulo entre ejes de 10° y la paleta de 6 sectores correspondiente a las
6 capas. Esta extensión sigue el mismo patrón establecido en los niveles
anteriores (config/n9.yaml, config/n16.yaml, config/n25.yaml).

11.3. Condiciones generales

Las condiciones generales de aplicabilidad descritas en los Documentos
1, 2 y 3 se mantienen: SVcustos es un marco arquitectónico cuya
implementación depende de las capacidades concretas de cada familia de
dispositivos y de las restricciones normativas del entorno de
despliegue.

12. Referencias

[1] Lloret Egea, J. A. et al. (2021). «Framework» basado en imágenes
parametrizadas sobre ResNet para identificar intrusiones en
«smartwatches» u otros dispositivos afines. IA Eñ ™.

[2] Lloret Egea, J. A. (2026). De SVcustos, el marco (framework) de
intrusión, hasta SVperitus: agentes especializados. Documento 1 de 8: El
nivel base: 9 parámetros y el origen del sistema.

[3] Lloret Egea, J. A. (2026). De SVcustos, el marco (framework) de
intrusión, hasta SVperitus: agentes especializados. Documento 2 de 8: De
n = 9 a n = 16: primera extensión.

[4] Lloret Egea, J. A. (2026). De SVcustos, el marco (framework) de
intrusión, hasta SVperitus: agentes especializados. Documento 3 de 8: De
n = 16 a n = 25: segunda extensión.

[5] He, K., Zhang, X., Ren, S., & Sun, J. (2016). Deep Residual
Learning for Image Recognition. Proceedings of the IEEE CVPR, 770--778.

[6] Android Developers. (2025). Android API Reference:
ConnectivityManager, BiometricManager, AccountManager, SmsManager,
TelecomManager, VpnService, DnsResolver, UsageStatsManager,
FileObserver, NFC HostApduService.
https://developer.android.com/reference

[7] Apple Developer. (2025). iOS SDK Documentation: Network Extension,
LocalAuthentication, Security (Keychain Services), PassKit, CallKit,
CoreTelephony, MetricKit. https://developer.apple.com/documentation

[8] OWASP Mobile Application Security Verification Standard (MASVS)
v2.0 (2023). https://mas.owasp.org/MASVS/

[9] NIST SP 800-124 Rev. 2 (2023). Guidelines for Managing the
Security of Mobile Devices in the Enterprise.

[10] Lloret Egea, J. A. (2026). SVcustos-dataset: Dataset de
entrenamiento para la red ResNet34 del sistema SVcustos. GitHub.
https://github.com/juantoniolloretegea/SVcustos-dataset

13. Próximo documento

Documento 5 de 8: «Células SV en par: la arquitectura de dos células n =
b² independientes». El quinto documento de la serie presenta la
arquitectura de células SV en par, que resuelve el problema de los
parámetros de integridad del sistema operativo (AccessibilityService,
grabación de pantalla, root/bootloader, instalación de fuentes no
autorizadas, red promiscua, USB/OTG, overlay de UI) que son
semánticamente distintos de los parámetros de comportamiento observable:
no detectan qué está ocurriendo, sino si el propio sistema de detección
es fiable. La solución consiste en dos células n = b² completas e
independientes operando juntas: la célula principal n = 36 (b = 6) para
comportamiento observable y una célula de integridad n = 9 (b = 3) para
integridad del SO, con una regla formal de composición ternaria entre
ambas clasificaciones.

n = 25 ➔ n = 36.md

De SVcustos, el marco (framework) de intrusión, hasta SVperitus: agentes especializados. (De n = 25 ➔ n = 36: tercera extensión del espacio paramétrico) {#de-svcustos-el-marco-framework-de-intrusin-hasta-svperitus-agentes-especializados-de-n-25-n-36-tercera-extensin-del-espacio-paramtrico}

Resumen

Abstract

1. Posición en la serie

2. Estado del sistema en n = 25

3. Justificación del salto a n = 36

3.1. Vectores de amenaza no cubiertos por n = 25

3.2. Estructura: 6 capas × 6 parámetros

4. Reestructuración de los 25 parámetros originales en 6 capas

5. Los 11 nuevos parámetros: descripción completa

5.1. P6 --- Tráfico cifrado a IPs no categorizadas [Capa Red]

5.2. P25 --- Cambio de credenciales no autorizado [Capa Autenticación e Identidad]

5.3. P26 --- Autenticación biométrica fallida de forma reiterada [Capa Autenticación e Identidad]

5.4. P27 --- Acceso al keystore del sistema [Capa Autenticación e Identidad]

5.5. P28 --- Token de sesión manipulado o interceptado [Capa Autenticación e Identidad]

5.6. P29 --- SMS o MMS enviado sin interacción del usuario [Capa Autenticación e Identidad]

5.7. P30 --- Llamada telefónica iniciada sin interacción del usuario [Capa Autenticación e Identidad]

5.8. P33 --- Acceso a API de pago no autorizada [Capa Comunicaciones y Evasión]

5.9. P34 --- Consultas DNS a dominios no categorizados [Capa Comunicaciones y Evasión]

5.10. P35 --- Actividad fuera de ventana horaria habitual [Capa Comunicaciones y Evasión]

5.11. P36 --- Secuencias temporales anómalas [Capa Comunicaciones y Evasión]

6. Tabla completa de los 36 parámetros

7. Del vector de 36 parámetros al polígono polar

8. Regla de clasificación para n = 36

8.1. Principio de clasificación estricta

8.2. Umbral estricto para n = 36

8.3. Gradiente de riesgo dentro de INDETERMINADO

8.4. Espacio combinacional

9. Distribución del espacio ternario

9.1. Desglose de INTRUSIÓN por nivel de activación

10. Tres ejemplos de vectores ilustrativos

10.1. Ejemplo INTRUSIÓN

10.2. Ejemplo NORMAL

10.3. Ejemplo INDETERMINADO

11. Valoración de implementación

11.1. Condiciones de aplicabilidad por familia de dispositivos

11.2. Dataset de entrenamiento: SVcustos-dataset

11.3. Condiciones generales

12. Referencias

13. Próximo documento