article:
elocation-id: de-svcustos-el-marco-de-intrusion-hasta-svperitus-n--16--n--25
author:
- Juan Antonio Lloret Egea
bibliography: /tmp/tmp-20h1OP6kmD7sWY.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
date:
day: 03
month: 03
year: 2026
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 = 16 ➔ n
= 25"
uri: "https://www.itvia.online/pub/de-svcustos-el-marco-de-intrusion-hasta-svperitus-n--16--n--25"
[video element]
De SVcustos, el marco (framework) de intrusión, hasta SVperitus: agentes especializados. (De n = 16 ➔ n = 25: segunda extensión del espacio paramétrico) {#de-svcustos-el-marco-framework-de-intrusin-hasta-svperitus-agentes-especializados-de-n-16-n-25-segunda-extensin-del-espacio-paramtrico}
(Documento 3 de 8)
Resumen
Este tercer documento de la serie «De SVcustos, el marco (framework) de
intrusión, hasta SVperitus: agentes especializados» extiende el nivel de
16 parámetros (n = 16 = 4²) a 25 parámetros (n = 25 = 5²), reorganizados
en 5 capas de 5: Red (P1--P5), Conectividad (P6--P10), Sensores
(P11--P15), Sistema (P16--P20) y Almacenamiento y Contexto (P21--P25).
Los 9 nuevos parámetros cubren vectores de amenaza ausentes en n = 16:
manipulación de la configuración de red, evasiones mediante modo avión,
suplantación de sensores de movimiento, modificación de archivos de
sistema, comunicación inter-procesos anómala, exfiltración por
almacenamiento externo, espionaje del portapapeles, sincronización con
servicios no autorizados y notificaciones push manipuladas.
El documento describe la reestructuración de los 16 parámetros
existentes en la nueva arquitectura 5 × 5, la transformación de cada
vector ternario en un polígono polar de 25 ejes a 14,4°, y la regla de
clasificación estricta con umbral n₁ ≥ 19 (razón ⌊7 × 25 / 9⌋). El
espacio combinacional asciende a 3²⁵ = 847.288.609.443 vectores
ternarios únicos, con una distribución de 13.256.611 vectores INTRUSIÓN
(0,00156 %), 847.262.096.221 INDETERMINADO (99,997 %) y 13.256.611
NORMAL (0,00156 %).
Abstract
This third document in the series extends the SVcustos intrusion
detection system from 16 parameters (n = 16 = 4²) to 25 parameters (n =
25 = 5²), reorganised into 5 layers of 5: Network (P1--P5), Connectivity
(P6--P10), Sensors (P11--P15), System (P16--P20), and Storage & Context
(P21--P25). The 9 new parameters cover threat vectors absent from n =
16: network configuration tampering, airplane-mode evasion,
motion-sensor spoofing, system-file modification, anomalous
inter-process communication, external-storage exfiltration, clipboard
surveillance, unauthorised external synchronisation, and manipulated
push notifications. The strict classification threshold is set at n₁ ≥
19 (⌊7 × 25 / 9⌋). The combinatorial space is 3²⁵ = 847,288,609,443
ternary vectors.
1. Posición en la serie
Este es el tercer 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.
Este documento (Documento 3): presenta la segunda extensión del sistema
a n = 25 = 5² parámetros, reorganizados en 5 capas de 5. Describe la
reestructuración de los 16 parámetros existentes, los 9 nuevos
parámetros (P5, P10, P15, P19, P20, P21, P22, P24, P25 en la nueva
numeración), la regla de clasificación actualizada y la distribución del
espacio 3²⁵.
Los documentos posteriores de la serie son: Documento 4 (n = 25 → n =
36), Documento 5 (Arquitectura de células SV en par), Documento 6 (n =
36 → n = 49), Documento 7 (SVperitus: agentes especializados) y
Documento 8 (Compilador de la serie completa).
2. Estado del sistema en n = 16
El sistema en n = 16 opera con 16 parámetros ternarios organizados en 4
capas de 4 (b = 4, n = b² = 16). Cada parámetro toma uno de tres
valores: 0 (normal), 1 (activo/intrusión) o U (indeterminado). La regla
de clasificación estricta establece que n₁ ≥ 12 → INTRUSIÓN, n₀ ≥ 12 →
NORMAL, resto → INDETERMINADO. El espacio total es 3¹⁶ = 43.046.721
vectores, con 34.113 INTRUSIÓN (0,079 %), 42.978.495 INDETERMINADO
(99,841 %) y 34.113 NORMAL (0,079 %).
+------+----------+----------+-------------+----------+------------------+
| Cód. | P | Capa | Herramienta | Peso | Procedencia |
| | arámetro | | | | |
+======+==========+==========+=============+==========+==================+
| P1 | URL no | Red | DnsResolver | ★ ALTO | Original n=9 |
| | au | | / | | |
| | torizada | | VpnService | | |
+------+----------+----------+-------------+----------+------------------+
| P2 | Comu | Red | T | ★ ALTO | Original n=9 |
| | nicación | | rafficStats | | |
| | no | | / | | |
| | cifrada | | VpnService | | |
+------+----------+----------+-------------+----------+------------------+
| P3 | Trans | Red | NetworkS | ★ ALTO | Original n=9 |
| | ferencia | | tatsManager | | |
| | datos al | | | | |
| | exterior | | | | |
+------+----------+----------+-------------+----------+------------------+
| P4 | Cer | Red | TrustMan | ★ ALTO | Nuevo n=16 |
| | tificado | | agerFactory | | |
| | TLS | | | | |
| | inválido | | | | |
+------+----------+----------+-------------+----------+------------------+
| P5 | BSSID no | Cone | WifiManager | ★ ALTO | Original n=9 |
| | au | ctividad | | | |
| | torizado | | | | |
+------+----------+----------+-------------+----------+------------------+
| P6 | B | Cone | Bluet | bajo | Original n=9 |
| | luetooth | ctividad | oothAdapter | | |
| | no | | | | |
| | au | | | | |
| | torizado | | | | |
+------+----------+----------+-------------+----------+------------------+
| P7 | GPS no | Cone | Loca | ★ ALTO | Original n=9 |
| | au | ctividad | tionManager | | |
| | torizado | | | | |
+------+----------+----------+-------------+----------+------------------+
| P8 | NFC no | Cone | NfcAdapter | ★ ALTO | Nuevo n=16 |
| | au | ctividad | | | |
| | torizado | | | | |
+------+----------+----------+-------------+----------+------------------+
| P9 | Cámara | Sensores | Ca | ★ ALTO | Original n=9 |
| | no | | meraManager | | |
| | au | | | | |
| | torizada | | | | |
+------+----------+----------+-------------+----------+------------------+
| P10 | M | Sensores | Ap | ★ ALTO | Original n=9 |
| | icrófono | | pOpsManager | | |
| | no | | | | |
| | au | | | | |
| | torizado | | | | |
+------+----------+----------+-------------+----------+------------------+
| P11 | Sensores | Sensores | Se | ★ ALTO | Nuevo n=16 |
| | de salud | | nsorManager | | |
| | no | | | | |
| | aut | | | | |
| | orizados | | | | |
+------+----------+----------+-------------+----------+------------------+
| P12 | Proceso | Sensores | Acti | ★ ALTO | Nuevo n=16 |
| | des | | vityManager | | |
| | conocido | | | | |
| | en | | | | |
| | e | | | | |
| | jecución | | | | |
+------+----------+----------+-------------+----------+------------------+
| P13 | Pa | Sistema | Se | bajo | Original n=9 |
| | rámetros | | nsorManager | | |
| | físicos | | | | |
| | anómalos | | | | |
+------+----------+----------+-------------+----------+------------------+
| P14 | Escalada | Sistema | Pac | ★ ALTO | Nuevo n=16 |
| | de | | kageManager | | |
| | permisos | | | | |
+------+----------+----------+-------------+----------+------------------+
| P15 | Acceso | Sistema | Ap | ★ ALTO | Nuevo n=16 |
| | no | | pOpsManager | | |
| | au | | | | |
| | torizado | | | | |
| | a datos | | | | |
| | pe | | | | |
| | rsonales | | | | |
+------+----------+----------+-------------+----------+------------------+
| P16 | Conexión | Sistema | Telep | ★ ALTO | Nuevo n=16 |
| | celular | | honyManager | | |
| | no | | | | |
| | au | | | | |
| | torizada | | | | |
+------+----------+----------+-------------+----------+------------------+
3. Justificación del salto a n = 25
La restricción algebraica del sistema SVcustos establece que n = b² con
b ≥ 3. El siguiente valor válido tras n = 16 (b = 4) es n = 25 (b = 5).
Este salto añade 9 parámetros y reorganiza los 25 resultantes en 5 capas
de 5.
3.1. Vectores de amenaza no cubiertos por n = 16
El nivel de 16 parámetros deja descubiertos cinco flancos críticos que
un atacante sofisticado puede explotar:
Evasión por configuración de red: P1--P4 detectan tráfico anómalo y
certificados inválidos, pero un atacante que modifica el proxy, DNS o
APN del dispositivo puede redirigir todo el tráfico legítimo a través de
un servidor intermedio sin que los parámetros de red actuales lo
detecten, porque la conexión resultante sigue siendo cifrada y hacia
URLs aparentemente legítimas.
Evasión por modo avión: El malware puede activar modo avión para
desconectar temporalmente los monitores de red (P1--P4) y de
conectividad (P5--P8), realizar operaciones locales de exfiltración al
almacenamiento externo o manipulación de archivos, y desactivar modo
avión para enviar los datos acumulados en una ráfaga breve.
Manipulación del sistema operativo: P12 detecta procesos desconocidos y
P14 detecta escalada de permisos, pero ningún parámetro supervisa la
modificación directa de archivos críticos del sistema (build.prop,
hosts, archivos de configuración de servicios). Un atacante con acceso
root puede alterar el comportamiento del SO sin generar nuevos procesos
ni escalar permisos visibles.
Canales laterales de exfiltración: P3 detecta transferencia de datos por
red y P16 detecta conexión celular no autorizada, pero el almacenamiento
externo (tarjeta SD, USB OTG), el portapapeles del sistema y los
servicios de sincronización en la nube constituyen canales de
exfiltración alternativos completamente invisibles para los parámetros
actuales.
Comunicación inter-procesos maliciosa: Dos aplicaciones aparentemente
legítimas pueden colaborar mediante IPC (Intents, ContentProviders,
Binder): una con permisos de red y otra con acceso a sensores.
Individualmente no generan alertas; conjuntamente realizan exfiltración
coordinada. Ningún parámetro de n = 16 supervisa este vector de
colusión.
3.2. Estructura: 5 capas × 5 parámetros
El salto a n = 25 = 5² organiza los parámetros en 5 capas temáticas de 5
parámetros cada una: Red (P1--P5), Conectividad (P6--P10), Sensores
(P11--P15), Sistema (P16--P20) y Almacenamiento y Contexto (P21--P25).
Esta reorganización implica renumerar los 16 parámetros originales y
situar los 9 nuevos en las posiciones que completan cada capa.
4. Reestructuración de los 16 parámetros originales en 5 capas
Los 16 parámetros originales no pierden ninguno de sus valores ni se
redefinen. Únicamente se renumeran para encajar en la arquitectura de 5
capas, dejando las posiciones P5, P10, P15, P19, P20, P21, P22, P24 y
P25 libres para los 9 nuevos parámetros. Los movimientos principales
son:
Capa Red (P1--P5): P1--P4 permanecen sin cambios. P5 es el nuevo
parámetro de configuración de red modificada, que cierra el flanco de
evasión por proxy/DNS.
Capa Conectividad (P6--P10): Los 4 parámetros de conectividad de n = 16
(BSSID, Bluetooth, GPS, NFC) se renumeran a P6--P9. P10 es el nuevo
parámetro de modo avión irregular.
Capa Sensores (P11--P15): Cámara (ex-P9) pasa a P11, micrófono (ex-P10)
a P12, salud (ex-P11) a P13, parámetros físicos (ex-P13) a P14. P15 es
el nuevo parámetro de sensores de movimiento.
Capa Sistema (P16--P20): Proceso desconocido (ex-P12) pasa a P16,
escalada de permisos (ex-P14) a P17, datos personales (ex-P15) a P18.
P19 y P20 son los nuevos parámetros de modificación de sistema e IPC
anómala.
Capa Almacenamiento y Contexto (P21--P25): P21 (almacenamiento externo),
P22 (portapapeles) y P24 (sincronización externa) son nuevos. Conexión
celular (ex-P16) migra a P23 porque es un canal de exfiltración
alternativo, semánticamente más próximo a los canales laterales que a
los procesos del SO. P25 (push notification anómala) es nuevo.
+-------------+-------------+-------------+-------------+-------------+
| Capa Red | Capa | Capa | Capa | Capa |
| (P1--P5) | C | Sensores | Sistema | Al |
| | onectividad | (P11--P15) | (P16--P20) | m./Contexto |
| | (P6--P10) | | | (P21--P25) |
+=============+=============+=============+=============+=============+
| P1 URL no | P6 BSSID | P11 Cámara | P16 Proceso | P21 Alm. |
| autorizada | (ex P5) P7 | (ex P9) P12 | (ex P12) | externo |
| P2 No | Bluetooth | Micrófono | P17 | ★NUEVO P22 |
| cifrada P3 | (ex P6) P8 | (ex P10) | Permisos | P |
| Transf. | GPS (ex P7) | P13 Salud | (ex P14) | ortapapeles |
| exterior P4 | P9 NFC (ex | (ex P11) | P18 Datos | ★NUEVO P23 |
| TLS | P8) P10 | P14 Físicos | pers. (ex | Celular (ex |
| inválido P5 | Modo avión | (ex P13) | P15) P19 | P16) P24 |
| Config. red | ★NUEVO | P15 | Mod. | Sin |
| ★NUEVO | | Movimiento | sistema | cronización |
| | | ★NUEVO | ★NUEVO P20 | ★NUEVO P25 |
| | | | IPC anómala | Push notif. |
| | | | ★NUEVO | ★NUEVO |
+-------------+-------------+-------------+-------------+-------------+
Distribución resultante: 21 parámetros de alto peso intrusivo (★ ALTO) y
4 de peso bajo (P7 Bluetooth, P14 Parámetros físicos, P15 Sensores de
movimiento, P25 Push notification). Total conservados del nivel
anterior: 16. Nuevos incorporados: 9.
5. Los 9 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. P5 --- Configuración de red modificada [Capa Red]
Peso intrusivo: ★ ALTO
Herramienta de captura: Android: ConnectivityManager.getDefaultProxy()
devuelve el ProxyInfo activo del sistema.
Settings.Global.getString(Settings.Global.HTTP_PROXY) para la
configuración de proxy persistente.
ConnectivityManager.registerDefaultNetworkCallback() con
NetworkCallback.onLinkPropertiesChanged() para detectar cambios en
servidores DNS, dominios de búsqueda y rutas en tiempo real. En entornos
con privilegios de sistema, NetworkPolicyManager permite auditar
políticas de red por UID. iOS: NEDNSSettingsManager y NEDNSProxyManager
(Network Extension framework) para supervisar configuraciones de DNS
personalizadas. URLSessionConfiguration.connectionProxyDictionary para
detectar proxies activos. NEConfigurationManager para auditar perfiles
VPN y proxy instalados.
Criterio de ternarización: Valor 1: se detecta un cambio en la
configuración de proxy, DNS o APN del dispositivo que no corresponde a
una acción explícita del usuario ni a un perfil MDM autorizado. Valor 0:
la configuración de red coincide con el baseline establecido durante el
aprovisionamiento o ha sido modificada exclusivamente mediante perfil
MDM. Valor U: primera ejecución sin baseline disponible, o el
dispositivo opera con configuración de red dinámica (DHCP con cambios
frecuentes de DNS) que impide distinguir modificaciones legítimas de
maliciosas.
Análisis adversarial:
+----------------------------------+----------------------------------+
| Argumento contrario | Réplica técnica |
+==================================+==================================+
| En redes corporativas con DHCP, | El parámetro no mide cambios de |
| los servidores DNS cambian con | DNS entregados por DHCP (estos |
| frecuencia por políticas de | se incorporan automáticamente al |
| balanceo de carga, lo que | baseline dinámico), sino |
| generaría falsos positivos | modificaciones en la |
| constantes. | configuración persistente del |
| | dispositivo: proxy manual, DNS |
| | privado (Android 9+) y perfiles |
| | de configuración APN. Estas |
| | modificaciones requieren acción |
| | explícita y son distinguibles |
| | del comportamiento DHCP |
| | estándar. |
+----------------------------------+----------------------------------+
5.2. P10 --- Modo avión irregular [Capa Conectividad]
Peso intrusivo: ★ ALTO
Herramienta de captura: Android:
Settings.Global.getInt(Settings.Global.AIRPLANE_MODE_ON) para estado
actual. BroadcastReceiver registrado para
Intent.ACTION_AIRPLANE_MODE_CHANGED con marca temporal de cada
transición. Análisis de frecuencia: se mantiene un buffer circular de
las últimas 24 horas de eventos y se calcula la tasa de conmutación.
Desde Android 11, Settings.Global es de solo lectura para aplicaciones
de terceros, por lo que la activación programática requiere privilegios
de sistema o ADB. iOS: no existe API pública directa para consultar el
estado de modo avión. Se infiere indirectamente mediante la combinación
de CTTelephonyNetworkInfo.serviceCurrentRadioAccessTechnology (pérdida
simultánea de todas las radios), NWPathMonitor (Network framework) para
caídas de conectividad totales, y CNCopyCurrentNetworkInfo para estado
WiFi.
Criterio de ternarización: Valor 1: modo avión se ha activado o
desactivado de forma programática (sin interacción física del usuario
con el toggle del sistema) o la frecuencia de conmutación supera el
umbral configurado (por defecto, más de 3 cambios por hora). Valor 0:
modo avión está desactivado de forma estable, o ha sido conmutado
manualmente por el usuario con frecuencia normal. Valor U: no se puede
determinar si la conmutación fue manual o programática (dispositivos
pre-Android 11 donde cualquier app con permiso WRITE_SETTINGS puede
modificar el estado).
Análisis adversarial:
+----------------------------------+----------------------------------+
| Argumento contrario | Réplica técnica |
+==================================+==================================+
| Los usuarios en vuelos reales | El parámetro no penaliza la |
| activan modo avión durante | activación prolongada de modo |
| horas, y en zonas de cobertura | avión (un solo evento no alcanza |
| deficiente alternan | el umbral de frecuencia). Lo que |
| repetidamente. El parámetro no | detecta es el patrón de |
| distingue estos usos legítimos. | conmutación rápida y repetitiva |
| | (on-off-on en intervalos cortos) |
| | que es característico de malware |
| | que necesita ventanas sin |
| | conectividad para operar |
| | localmente. Un vuelo real |
| | produce un único evento de |
| | activación, no una ráfaga. |
+----------------------------------+----------------------------------+
5.3. P15 --- Sensores de movimiento anómalos [Capa Sensores]
Peso intrusivo: bajo
Herramienta de captura: Android: SensorManager.registerListener() con
Sensor.TYPE_ACCELEROMETER y Sensor.TYPE_GYROSCOPE a frecuencia
SensorManager.SENSOR_DELAY_NORMAL. Se aplica ventana deslizante de 30
segundos y se comparan la magnitud media, la varianza y la frecuencia
dominante (mediante FFT) con los perfiles de referencia almacenados.
Detección de suplantación: se correlacionan datos de acelerómetro y
giróscopo; patrones físicamente inconsistentes (aceleración sin rotación
correspondiente) indican inyección de datos simulados. iOS:
CMMotionManager (CoreMotion) con
startAccelerometerUpdates(to:withHandler:) y
startGyroUpdates(to:withHandler:). CMSensorRecorder para análisis
histórico de datos acumulados.
Criterio de ternarización: Valor 1: los datos de movimiento son
físicamente inconsistentes (aceleración lineal constante sin componente
gravitatoria, giróscopo activo con acelerómetro estático), lo que indica
suplantación de sensores mediante Xposed/Magisk o entorno virtualizado.
Valor 0: los patrones de movimiento son coherentes con uso humano normal
del dispositivo. Valor U: el dispositivo no dispone de giróscopo
(smartwatches RTOS como Garmin), o los datos son insuficientes para
determinar coherencia (primeros 30 segundos tras el arranque).
Análisis adversarial:
+----------------------------------+----------------------------------+
| Argumento contrario | Réplica técnica |
+==================================+==================================+
| Un dispositivo apoyado en una | El peso bajo del parámetro |
| mesa durante una reunión larga | refleja precisamente esta |
| reporta aceleración y giro | ambigüedad. El parámetro no |
| prácticamente nulos, que podrían | clasifica reposo como intrusión: |
| confundirse con suplantación de | reposo real produce componente |
| sensores. | gravitatoria constante (~9,81 |
| | m/s² en un eje) y ruido térmico |
| | del sensor. La suplantación |
| | produce valores artificialmente |
| | limpios (cero exacto o constante |
| | arbitraria sin ruido), que son |
| | estadísticamente distinguibles |
| | del reposo real. |
+----------------------------------+----------------------------------+
5.4. P19 --- Modificación de archivos de sistema [Capa Sistema]
Peso intrusivo: ★ ALTO
Herramienta de captura: Android: FileObserver (clase android.os)
registrado sobre directorios críticos: /system, /vendor, /data/system.
Se monitorizan eventos MODIFY, DELETE, CREATE y MOVED_TO.
PackageManager.getPackageInfo() con GET_SIGNING_CERTIFICATES para
verificar integridad de firmas de paquetes de sistema. En entornos con
privilegios root: verificación dm-verity del estado de la partición de
sistema mediante getprop ro.boot.verifiedbootstate. iOS: no existe
acceso directo al sistema de archivos. La integridad se verifica
mediante MDM con DeviceInformation.QueryResponses (clave IsSupervised) y
la comprobación de jailbreak mediante canarios: intentos de acceso a
rutas características (/Applications/Cydia.app, /private/var/lib/apt) y
verificación de que fork() falla (sandbox intacta).
Criterio de ternarización: Valor 1: se detecta modificación de archivos
en particiones de sistema, alteración de firmas de paquetes de sistema,
o estado de verified boot distinto de «green» (Android) o detección
positiva de jailbreak (iOS). Valor 0: partición de sistema intacta
(dm-verity verificado), firmas de paquetes válidas, sin indicios de
jailbreak. Valor U: el dispositivo no soporta verified boot
(dispositivos pre-2018), o la aplicación de monitorización no tiene
privilegios suficientes para consultar el estado de la partición.
Análisis adversarial:
+----------------------------------+----------------------------------+
| Argumento contrario | Réplica técnica |
+==================================+==================================+
| Las actualizaciones OTA del | Las actualizaciones OTA |
| fabricante modifican | legitímas se aplican mediante el |
| legítimamente la partición de | servicio de sistema OTA del |
| sistema, lo que generaría falsos | fabricante, que actualiza |
| positivos tras cada | simultáneamente el baseline de |
| actualización. | verified boot. El parámetro |
| | compara contra el estado de |
| | dm-verity posterior al último |
| | arranque verificado, no contra |
| | un baseline estático. Tras una |
| | OTA exitosa, el nuevo estado |
| | «green» de verified boot se |
| | convierte automáticamente en la |
| | referencia. |
+----------------------------------+----------------------------------+
5.5. P20 --- Comunicación inter-procesos anómala [Capa Sistema]
Peso intrusivo: ★ ALTO
Herramienta de captura: Android: ActivityManager.getRunningServices()
combinado con análisis de Intents explícitos e implícitos mediante
PackageManager.queryIntentActivities() y queryIntentServices().
ContentResolver con ContentObserver para detectar accesos cruzados entre
aplicaciones a través de ContentProviders no públicos. En entornos con
privilegios de sistema: dumpsys activity service para inspección de
conexiones Binder activas. AppOpsManager para auditar operaciones de
clipboard cruzadas entre UIDs. iOS: la arquitectura sandbox de iOS
restringe la IPC a mecanismos controlados. Se supervisan URL schemes
(UIApplication.canOpenURL() con lista de esquemas monitorizados), App
Groups (FileManager acceso a contenedores compartidos), y
UIPasteboard.general con detección de cambios no iniciados por el
usuario.
Criterio de ternarización: Valor 1: se detecta comunicación entre dos o
más aplicaciones que individualmente no tendrían capacidad de
exfiltración pero que conjuntamente realizan operaciones de lectura de
datos sensibles y envío a destinos externos (colusión). Valor 0: toda la
IPC observada corresponde a patrones autorizados (servicios del sistema,
frameworks del fabricante, aplicaciones con relación declarada). Valor
U: la lista de servicios activos no es accesible con los privilegios
actuales (restricciones de Android 11+ sobre visibilidad de procesos), o
el volumen de IPC es demasiado alto para clasificar sin riesgo de falsos
positivos.
Análisis adversarial:
+----------------------------------+----------------------------------+
| Argumento contrario | Réplica técnica |
+==================================+==================================+
| Las aplicaciones de | El parámetro no contabiliza |
| productividad (Suite de Google, | volumen de IPC sino patrones de |
| Microsoft 365) intercambian | colusión: dos UIDs distintos que |
| datos constantemente mediante | acceden secuencialmente a datos |
| ContentProviders compartidos, lo | sensibles (contactos, ubicación) |
| que generaría un volumen de IPC | y luego a servicios de red. Las |
| legítima que ahoga las señales | suites de productividad |
| maliciosas. | comparten UID de firma y operan |
| | como proceso único para el |
| | sistema. La lista blanca se |
| | construye por UID de firma, no |
| | por paquete individual. |
+----------------------------------+----------------------------------+
5.6. P21 --- Almacenamiento externo no autorizado [Capa Almacenamiento y Contexto]
Peso intrusivo: ★ ALTO
Herramienta de captura: Android: StorageManager.getStorageVolumes() para
enumerar volúmenes montados (tarjeta SD, USB OTG).
StorageStatsManager.queryStatsForPackage() para auditar el uso de
almacenamiento por aplicación. Storage Access Framework (SAF) con
DocumentsProvider para interceptar operaciones de escritura a volúmenes
externos. BroadcastReceiver para Intent.ACTION_MEDIA_MOUNTED y
ACTION_UMS_CONNECTED para detectar conexiones de almacenamiento físico.
iOS: la arquitectura de sandbox impide el acceso directo a
almacenamiento externo. Se supervisan las extensiones de File Provider
(NSFileProviderManager) y la actividad de
UIDocumentInteractionController para detectar exportaciones a servicios
de almacenamiento de terceros.
Criterio de ternarización: Valor 1: una aplicación no autorizada ha
escrito datos en almacenamiento externo (SD, USB OTG) o se ha conectado
un dispositivo de almacenamiento físico no incluido en la lista blanca.
Valor 0: no hay actividad de almacenamiento externo, o toda la actividad
corresponde a aplicaciones y dispositivos autorizados. Valor U: el
dispositivo no dispone de ranura de tarjeta SD ni puerto OTG (la mayoría
de smartwatches), lo que hace el parámetro estructuralmente no
aplicable.
Análisis adversarial:
+----------------------------------+----------------------------------+
| Argumento contrario | Réplica técnica |
+==================================+==================================+
| En smartwatches sin ranura SD ni | Correcto. SVcustos asume |
| USB OTG, este parámetro vale | explícitamente que no todos los |
| siempre 0 o U, reduciendo | parámetros son observables en |
| efectivamente n a 24 parámetros | todas las familias de |
| funcionales para esa familia. | dispositivos. El parámetro P21 |
| | es relevante para smartphones y |
| | tabletas, que constituyen el |
| | grueso de los objetivos de |
| | exfiltración. En smartwatches, |
| | el valor U estructural se |
| | incorpora al vector sin |
| | distorsionar la clasificación: |
| | la regla estricta opera sobre n₁ |
| | confirmados, no sobre parámetros |
| | disponibles. |
+----------------------------------+----------------------------------+
5.7. P22 --- Portapapeles no autorizado [Capa Almacenamiento y Contexto]
Peso intrusivo: ★ ALTO
Herramienta de captura: Android:
ClipboardManager.addPrimaryClipChangedListener() para detectar cambios
en el portapapeles en tiempo real. Desde Android 12 (API 31), el sistema
muestra un toast automático cuando una aplicación lee el portapapeles,
lo que permite correlacionar accesos con UIDs.
AppOpsManager.startWatchingMode(OPSTR_READ_CLIPBOARD) para auditoría
continua de accesos por paquete. iOS: desde iOS 14, UIPasteboard.general
genera una notificación visible al usuario cuando una aplicación accede
al portapapeles. UIPasteboard.changeCount para detectar modificaciones.
En iOS 16+, UIPasteControl ofrece acceso explícito con consentimiento
visual.
Criterio de ternarización: Valor 1: una aplicación ha leído el
portapapeles sin interacción explícita del usuario (pegar) y el
contenido leído incluye datos sensibles (contraseñas, tokens,
coordenadas, números de tarjeta). Valor 0: no hay accesos al
portapapeles, o todos los accesos corresponden a operaciones de pegar
iniciadas por el usuario. Valor U: versión de Android anterior a 12
donde no es posible determinar con certeza si el acceso fue programático
o iniciado por el usuario.
Análisis adversarial:
+----------------------------------+----------------------------------+
| Argumento contrario | Réplica técnica |
+==================================+==================================+
| Los gestores de contraseñas leen | Los gestores de contraseñas |
| el portapapeles legítimamente | autorizados se identifican por |
| para detectar campos de | su UID y se incluyen en la lista |
| autocompletado, y las | blanca del dispositivo. El |
| aplicaciones de traduccción lo | parámetro detecta accesos de |
| hacen para ofrecer traducción | UIDs no autorizados a contenido |
| instantánea. | sensible. Los gestores modernos |
| | utilizan el Autofill Framework |
| | (Android) o AutoFill/Passwords |
| | (iOS), que no requieren acceso |
| | al portapapeles. Las |
| | aplicaciones que aún usan |
| | portapapeles para este fin son |
| | identificables y listables. |
+----------------------------------+----------------------------------+
5.8. P24 --- Sincronización externa no autorizada [Capa Almacenamiento y Contexto]
Peso intrusivo: ★ ALTO
Herramienta de captura: Android:
ContentResolver.addStatusChangeListener(ContentResolver.SYNC_OBSERVER_TYPE_ACTIVE)
para detectar sincronizaciones activas. AccountManager.getAccounts()
para enumerar cuentas configuradas.
SyncManager.getSyncAutomatically(account, authority) para verificar qué
autoridades tienen sincronización automática habilitada. Se compara la
lista de cuentas y autoridades contra la política de seguridad para
detectar servicios en la nube no autorizados. iOS: NSFileCoordinator y
NSMetadataQuery para detectar sincronización activa con iCloud Drive.
MDM puede consultar las cuentas configuradas mediante DeviceInformation.
CKContainer para monitorizar operaciones CloudKit no esperadas.
Criterio de ternarización: Valor 1: se detecta sincronización activa con
un servicio en la nube o cuenta no incluida en la política de seguridad
(por ejemplo, cuenta de Google/iCloud personal en dispositivo
corporativo, o servicio de almacenamiento en nube no autorizado como
servicios de transferencia de archivos anónimos). Valor 0: toda la
sincronización activa corresponde a cuentas y servicios autorizados por
la política. Valor U: la auditoría de cuentas no es posible con los
privilegios actuales, o el dispositivo tiene sincronización automática
desactivada globalmente (no se puede determinar si hay sincronizaciones
manuales puntuales).
Análisis adversarial:
+----------------------------------+----------------------------------+
| Argumento contrario | Réplica técnica |
+==================================+==================================+
| La sincronización con servicios | El parámetro no prohíbe la |
| en la nube es una funcionalidad | sincronización: la clasifica |
| esencial del dispositivo. | como autorizada o no autorizada |
| Prohibirla genera fricción | según la política. Un |
| operativa y reduce la adopción | dispositivo corporativo con |
| del sistema de seguridad. | Google Workspace autorizado |
| | sincroniza con valor 0. El valor |
| | 1 solo se genera cuando aparece |
| | un servicio no declarado en la |
| | política. La granularidad por |
| | cuenta y autoridad evita |
| | prohibiciones genéricas. |
+----------------------------------+----------------------------------+
5.9. P25 --- Push notification anómala [Capa Almacenamiento y Contexto]
Peso intrusivo: bajo
Herramienta de captura: Android: NotificationListenerService (requiere
permiso explícito del usuario o provisión MDM) para interceptar todas
las notificaciones entrantes. Se inspeccionan: paquete origen,
categoría, prioridad, presencia de PendingIntent con acción de red, y
contenido del payload (URLs embebidas).
FirebaseMessaging.getInstance().getToken() para verificar que el token
FCM corresponde al servidor autorizado. iOS:
UNUserNotificationCenter.current().getDeliveredNotifications() para
lista de notificaciones entregadas. Inspección del campo userInfo del
payload para detectar URLs o comandos embebidos. App Transport Security
(ATS) ya bloquea conexiones HTTP desde notificaciones, pero no impide
payloads con instrucciones codificadas.
Criterio de ternarización: Valor 1: se recibe una notificación push
desde un servidor no autorizado (token FCM/APNS no reconocido) o cuyo
payload contiene URLs, comandos o datos codificados que no corresponden
a la funcionalidad declarada de la aplicación. Valor 0: todas las
notificaciones proceden de servidores autorizados y sus payloads son
coherentes con la función de la aplicación. Valor U:
NotificationListenerService no tiene permiso activo, o el contenido del
payload está cifrado end-to-end y no es inspeccionable.
Análisis adversarial:
+----------------------------------+----------------------------------+
| Argumento contrario | Réplica técnica |
+==================================+==================================+
| La inspección del contenido de | El parámetro inspecciona |
| notificaciones push compromete | metadatos y estructura del |
| la privacidad del usuario y | payload (origen, formato, |
| puede infringir regulaciones | presencia de URLs), no el |
| GDPR si se almacena el | contenido textual destinado al |
| contenido. | usuario. El análisis se realiza |
| | en memoria volátil y no se |
| | almacena el cuerpo del mensaje. |
| | El peso bajo refleja la |
| | dificultad práctica de |
| | implementar esta inspección sin |
| | fricción, especialmente en |
| | dispositivos de consumo. |
+----------------------------------+----------------------------------+
6. Tabla completa de los 25 parámetros
+----+----------+------------+------------+----------+--------------+
| Có | P | Capa | H | Peso | Procedencia |
| d. | arámetro | | erramienta | | |
+====+==========+============+============+==========+==============+
| P1 | URL no | Red | D | ★ ALTO | Original n=9 |
| | au | | nsResolver | | |
| | torizada | | | | |
+----+----------+------------+------------+----------+--------------+
| P2 | Comu | Red | Tr | ★ ALTO | Original n=9 |
| | nicación | | afficStats | | |
| | no | | | | |
| | cifrada | | | | |
+----+----------+------------+------------+----------+--------------+
| P3 | Trans | Red | NetworkSt | ★ ALTO | Original n=9 |
| | ferencia | | atsManager | | |
| | datos al | | | | |
| | exterior | | | | |
+----+----------+------------+------------+----------+--------------+
| P4 | Cer | Red | TrustMana | ★ ALTO | Nuevo n=16 |
| | tificado | | gerFactory | | |
| | TLS | | | | |
| | inválido | | | | |
+----+----------+------------+------------+----------+--------------+
| P5 | Config. | Red | Connectiv | ★ ALTO | Nuevo n=25 |
| | red | | ityManager | | |
| | mo | | | | |
| | dificada | | | | |
+----+----------+------------+------------+----------+--------------+
| P6 | BSSID no | Co | W | ★ ALTO | Original n=9 |
| | au | nectividad | ifiManager | | |
| | torizado | | | | |
+----+----------+------------+------------+----------+--------------+
| P7 | B | Co | Blueto | bajo | Original n=9 |
| | luetooth | nectividad | othAdapter | | |
| | no | | | | |
| | au | | | | |
| | torizado | | | | |
+----+----------+------------+------------+----------+--------------+
| P8 | GPS no | Co | Locat | ★ ALTO | Original n=9 |
| | au | nectividad | ionManager | | |
| | torizado | | | | |
+----+----------+------------+------------+----------+--------------+
| P9 | NFC no | Co | NfcAdapter | ★ ALTO | Nuevo n=16 |
| | au | nectividad | | | |
| | torizado | | | | |
+----+----------+------------+------------+----------+--------------+
| P | Modo | Co | Setti | ★ ALTO | Nuevo n=25 |
| 10 | avión | nectividad | ngs.Global | | |
| | i | | | | |
| | rregular | | | | |
+----+----------+------------+------------+----------+--------------+
| P | Cámara | Sensores | Cam | ★ ALTO | Original n=9 |
| 11 | no | | eraManager | | |
| | au | | | | |
| | torizada | | | | |
+----+----------+------------+------------+----------+--------------+
| P | M | Sensores | App | ★ ALTO | Original n=9 |
| 12 | icrófono | | OpsManager | | |
| | no | | | | |
| | au | | | | |
| | torizado | | | | |
+----+----------+------------+------------+----------+--------------+
| P | Sensores | Sensores | Sen | ★ ALTO | Nuevo n=16 |
| 13 | de salud | | sorManager | | |
| | no | | | | |
| | aut | | | | |
| | orizados | | | | |
+----+----------+------------+------------+----------+--------------+
| P | Pa | Sensores | Sen | bajo | Original n=9 |
| 14 | rámetros | | sorManager | | |
| | físicos | | | | |
| | anómalos | | | | |
+----+----------+------------+------------+----------+--------------+
| P | Sensores | Sensores | SensorMan | bajo | Nuevo n=25 |
| 15 | de | | ager/CMMot | | |
| | mo | | ionManager | | |
| | vimiento | | | | |
| | anómalos | | | | |
+----+----------+------------+------------+----------+--------------+
| P | Proceso | Sistema | Activ | ★ ALTO | Nuevo n=16 |
| 16 | des | | ityManager | | |
| | conocido | | | | |
| | en | | | | |
| | e | | | | |
| | jecución | | | | |
+----+----------+------------+------------+----------+--------------+
| P | Escalada | Sistema | Pack | ★ ALTO | Nuevo n=16 |
| 17 | de | | ageManager | | |
| | permisos | | | | |
+----+----------+------------+------------+----------+--------------+
| P | Acceso | Sistema | App | ★ ALTO | Nuevo n=16 |
| 18 | no | | OpsManager | | |
| | au | | | | |
| | torizado | | | | |
| | a datos | | | | |
| | pe | | | | |
| | rsonales | | | | |
+----+----------+------------+------------+----------+--------------+
| P | Modi | Sistema | Fi | ★ ALTO | Nuevo n=25 |
| 19 | ficación | | leObserver | | |
| | de | | / | | |
| | archivos | | dm-verity | | |
| | de | | | | |
| | sistema | | | | |
+----+----------+------------+------------+----------+--------------+
| P | IPC | Sistema | Activ | ★ ALTO | Nuevo n=25 |
| 20 | anómala | | ityManager | | |
| | | | / Binder | | |
+----+----------+------------+------------+----------+--------------+
| P | Almace | Alm | Stor | ★ ALTO | Nuevo n=25 |
| 21 | namiento | ./Contexto | ageManager | | |
| | externo | | / SAF | | |
| | no | | | | |
| | au | | | | |
| | torizado | | | | |
+----+----------+------------+------------+----------+--------------+
| P | Port | Alm | Clipbo | ★ ALTO | Nuevo n=25 |
| 22 | apapeles | ./Contexto | ardManager | | |
| | no | | | | |
| | au | | | | |
| | torizado | | | | |
+----+----------+------------+------------+----------+--------------+
| P | Conexión | Alm | Teleph | ★ ALTO | Nuevo n=16 |
| 23 | celular | ./Contexto | onyManager | | |
| | no | | | | |
| | au | | | | |
| | torizada | | | | |
+----+----------+------------+------------+----------+--------------+
| P | Sincro | Alm | Conte | ★ ALTO | Nuevo n=25 |
| 24 | nización | ./Contexto | ntResolver | | |
| | externa | | / | | |
| | no | | S | | |
| | au | | yncManager | | |
| | torizada | | | | |
+----+----------+------------+------------+----------+--------------+
| P | Push | Alm | Notific | bajo | Nuevo n=25 |
| 25 | noti | ./Contexto | ationListe | | |
| | fication | | nerService | | |
| | anómala | | | | |
+----+----------+------------+------------+----------+--------------+
7. Del vector de 25 parámetros al polígono polar
El vector ternario de 25 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 25 equiespaciados a 14,4°
entre sí (360° / 25 = 14,4°). 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 tiene 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 5 capas (cinco
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 la capa de Red (0°--72°), Conectividad (72°--144°),
Sensores (144°--216°), Sistema (216°--288°) o Almacenamiento/Contexto
(288°--360°).
La resolución angular de 14,4° es menor que los 22,5° del nivel
anterior, lo que incrementa la densidad visual del polígono. No
obstante, los 5 sectores de 72° 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 = 25
8.1. Principio de clasificación estricta
El sistema SVcustos mantiene en n = 25 el mismo principio de
clasificación estricta establecido en los niveles anteriores: 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 = 25
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₁ ≥ 19. Al menos 19 de los 25 parámetros están confirmados
en valor 1. El umbral se obtiene de la razón del nivel base: ⌊7 × 25 /
9⌋ = ⌊19,44⌋ = 19.
NORMAL: n₀ ≥ 19. Al menos 19 de los 25 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,997 % 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. 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²⁵ = 847.288.609.443 vectores ternarios únicos.
Esto representa una expansión de factor ×19.683 respecto al nivel
anterior (847.288.609.443 / 43.046.721 = 19.683 = 3⁹), correspondiente a
los 9 nuevos parámetros ternarios añadidos.
9. Distribución del espacio ternario
La distribución algebraica del espacio de 3²⁵ = 847.288.609.443 vectores
bajo la regla estricta (n₁ ≥ 19 para INTRUSIÓN, n₀ ≥ 19 para NORMAL) es:
Clasificación Vectores Porcentaje
INTRUSIÓN 13.256.611 0,00156 %
INDETERMINADO 847.262.096.221 99,99687 %
NORMAL 13.256.611 0,00156 %
La concentración del 99,997 % del espacio en INDETERMINADO es
consecuencia directa de la exigencia del umbral estricto: con 25
parámetros, se necesitan al menos 19 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
19 C(25,19) × 2⁶ 11.334.400 85,50 %
20 C(25,20) × 2⁵ 1.700.160 12,82 %
21 C(25,21) × 2⁴ 202.400 1,53 %
22 C(25,22) × 2³ 18.400 0,10 %
23 C(25,23) × 2² 1.200 < 0,01 %
24 C(25,24) × 2¹ 50 < 0,01 %
25 C(25,25) × 2⁰ 1 < 0,01 %
10. Tres ejemplos de vectores ilustrativos
10.1. Ejemplo INTRUSIÓN
Vector: (1, 1, 1, 1, 1, 1, 0, 1, 1, 1, 1, 1, 1, 0, 1, 1, 1, 1, 1, 1, 1,
1, 0, 1, 0)
Conteo: n₁ = 21, n₀ = 4, nᵤ = 0. Clasificación: INTRUSIÓN (n₁ = 21 ≥
19).
Interpretación: 21 de los 25 parámetros están confirmados activos. Las
únicas excepciones son P7 (Bluetooth, peso bajo), P14 (parámetros
físicos, peso bajo), P23 (conexión celular en valor 0 porque el
dispositivo no tiene SIM) y P25 (push notification, peso bajo). El
polígono polar ocupa casi todo el anillo externo en 21 de los 25 ejes.
Las 5 capas muestran activación masiva. Gradiente de riesgo: 21,0.
10.2. Ejemplo NORMAL
Vector: (0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, U, 0, U, 0, 0, 0, 0, U, 0,
U, 0, 0, U)
Conteo: n₁ = 0, n₀ = 20, nᵤ = 5. Clasificación: NORMAL (n₀ = 20 ≥ 19).
Interpretación: 20 de los 25 parámetros confirman estado normal. Los
cinco indeterminados (P13 salud, P15 movimiento, P20 IPC, P22
portapapeles, P25 push) corresponden a parámetros cuyas APIs no pudieron
completar la verificación en el ciclo de muestreo, posiblemente por
restricciones de privilegios. El polígono es compacto, pegado al centro.
Gradiente de riesgo: 2,5.
10.3. Ejemplo INDETERMINADO
Vector: (1, 1, 0, 1, 1, U, 0, 1, 0, 1, 1, U, 1, 0, U, 1, 1, 0, 1, U, 1,
0, 1, U, 0)
Conteo: n₁ = 13, n₀ = 7, nᵤ = 5. Clasificación: INDETERMINADO (n₁ = 13
< 19 y n₀ = 7 < 19).
Interpretación: 13 parámetros confirmados activos y 5 indeterminados. Si
los 5 valores U se resolvieran como 1, n₁ llegaría a 18, aún por debajo
del umbral 19. Este vector es de alta prioridad dentro de INDETERMINADO:
el gradiente de riesgo es 13 + 0,5 × 5 = 15,5, lo que indica un nivel de
activación crítico que requiere resolución urgente de los 5 parámetros
indeterminados. La activación se concentra en Red (3 de 5) y Sistema (3
de 5).
11. Valoración de implementación
El salto de n = 16 a n = 25 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 9 nuevos
parámetros, 6 utilizan APIs públicas documentadas accesibles sin
privilegios especiales (P5 configuración de red, P10 modo avión, P15
sensores de movimiento, P22 portapapeles, P24 sincronización, P25 push
notification). Los 3 restantes (P19 modificación de sistema, P20 IPC
anómala, P21 almacenamiento externo) requieren, según el grado de
profundidad deseado, privilegios de sistema, acceso MDM o
funcionalidades específicas del fabricante.
El espacio combinacional de 847.288.609.443 vectores ternarios excede
con mucho la capacidad de enumeración explícita: su generación completa
requeriría del orden de días en hardware estándar y produciría un
fichero de cientos de terabytes. 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 4 capas a 5 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
La completitud del vector de 25 parámetros depende de la topología de
despliegue elegida (autónoma, acoplada o externa) y de la familia de
dispositivos. En particular:
Smartwatches RTOS (Garmin, Fitbit básico): P5 (config. red), P19
(archivos de sistema), P20 (IPC) y P21 (almacenamiento externo) son
estructuralmente no observables en estas plataformas. El vector efectivo
se reduce a ~21 parámetros funcionales, con 4 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). P21
(almacenamiento externo) produce U estructural por ausencia de hardware.
Smartphones y tabletas: Los 25 parámetros son potencialmente
observables. P19 y P20 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,997 % para n = 25).
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 = 25, se extenderá la configuración del dataset con un nuevo
fichero config/n25.yaml que definirá n = 25, b = 5, umbral n₁ ≥ 19,
ángulo entre ejes de 14,4° y la paleta de 5 sectores correspondiente a
las 5 capas. Esta extensión sigue el mismo patrón establecido en los
niveles anteriores (config/n9.yaml, config/n16.yaml).
11.3. Condiciones generales
Las condiciones generales de aplicabilidad descritas en los Documentos 1
y 2 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ñ TM.
[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] He, K., Zhang, X., Ren, S., & Sun, J. (2016). Deep Residual
Learning for Image Recognition. Proceedings of the IEEE CVPR, 770--778.
[5] Android Developers. (2025). Android API Reference:
ConnectivityManager, Settings.Global, FileObserver, ClipboardManager,
NotificationListenerService, StorageManager.
https://developer.android.com/reference
[6] Apple Developer. (2025). iOS SDK Documentation: Network Extension,
CoreMotion, CoreTelephony, UIPasteboard, UNUserNotificationCenter.
https://developer.apple.com/documentation
[7] OWASP Mobile Application Security Verification Standard (MASVS)
v2.0 (2023). https://mas.owasp.org/MASVS/
[8] NIST SP 800-124 Rev. 2 (2023). Guidelines for Managing the
Security of Mobile Devices in the Enterprise.
[9] 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 4 de 8: «De n = 25 a n = 36: tercera extensión del espacio
paramétrico». El cuarto documento de la serie presenta la tercera
extensión del sistema, que amplía el vector a 6 capas de 6 parámetros (n
= 36 = 6²) e incorpora 11 nuevos parámetros (P26--P36) que cubren
autenticación e identidad (credenciales, biometría, keystore, tokens de
sesión, SMS y llamadas sin interacción) y comunicaciones activas y
evasión forense (API de pago, DNS, borrado de logs, horario anómalo,
tráfico cifrado a IPs anónimas). El espacio combinacional se expande a
3³⁶ ≈ 1,5 × 10¹⁷ vectores ternarios. El umbral estricto de intrusión se
recalibrará a n₁ ≥ 28 (razón ⌊7 × 36 / 9⌋).
