a9d0df0034
- assets/mercado.svg: diagrama de las tres patas de una operación (hardware / software / identidad) y el modelo de picos y palas - README: nueva sección "El mercado" con ASCII de los tres negocios bajo el mismo nombre, el diagrama, y la tabla de players con enlaces a cada uno. Antes solo estaba en el doc de investigación - mercado_y_players.md: la tabla de players pasa a llevar enlaces - capa_identidad.md: ASCII de la cadena de atestación (dispositivo real vs contenedor) para verlo de un vistazo
324 lines
17 KiB
Markdown
324 lines
17 KiB
Markdown
# La capa de identidad: verificación, reputación de IP y atestación
|
|
|
|
Por qué la identidad, y no el cómputo, es el cuello de botella de una granja, y cómo se integran
|
|
las capas que la componen.
|
|
|
|
Alcance: esto describe cómo funcionan los mecanismos y por qué las granjas pierden contra ellos.
|
|
No es un manual operativo de alta masiva de cuentas — no hay proveedores de SIM, ni técnicas de
|
|
evasión de fingerprint, ni calendarios de maduración. Esa parte es fraude de identidad a escala y
|
|
está bajo persecución activa en la UE; ver [legal_ue.md](legal_ue.md).
|
|
|
|
Una plataforma no pregunta quién eres. Comprueba tres cosas —si controlas un número, desde dónde
|
|
llegas y qué dispositivo eres— y luego una cuarta: en qué te pareces a las otras cuentas. Las tres
|
|
primeras se atacan con dinero. La cuarta no, y es la que hunde el negocio.
|
|
|
|
---
|
|
|
|
## 1 · Verificación telefónica
|
|
|
|
### Qué se comprueba
|
|
|
|
El OTP por SMS no verifica tu identidad. Verifica que **controlas un número en el momento del
|
|
alta**. Es una prueba de posesión, no de identidad. Pero detrás del número hay una cadena que sí
|
|
lleva a una persona:
|
|
|
|
```
|
|
número → operador → contrato o prepago registrado → KYC → persona
|
|
```
|
|
|
|
En la UE, esa cadena existe casi siempre. En España el registro de prepago es obligatorio desde
|
|
2007. Es el motivo por el que el eslabón telefónico es el que rompe las investigaciones: la
|
|
plataforma no sabe quién eres, pero el operador sí, y a la policía se lo cuenta.
|
|
|
|
### Por qué el mercado usa SIM físicas
|
|
|
|
Las granjas no compran números uno a uno: compran **acceso a números por API**. Detrás hay
|
|
SIM-boxes — bastidores con cientos de ranuras de SIM físicas y un módem por ranura — con una capa
|
|
de software que expone "dame un número de país X" y "dame el SMS que acaba de llegar al número Y".
|
|
|
|
El suministro es prepago comprado a granel en jurisdicciones donde el registro es débil o
|
|
evitable. Eso es lo que se revende como *número como servicio*.
|
|
|
|
### La eSIM: por qué NO es la respuesta
|
|
|
|
La eSIM es peor para una granja que la SIM física. Para ver por qué hay que mirar el
|
|
aprovisionamiento.
|
|
|
|
Una eSIM no es un fichero que se copia. Es un **perfil** que se descarga a un chip concreto:
|
|
|
|
```
|
|
eUICC (chip físico soldado, con su EID único de fábrica)
|
|
↑
|
|
│ descarga de perfil autenticada contra el EID
|
|
│
|
|
SM-DP+ del operador ← contrato / alta ← KYC
|
|
```
|
|
|
|
Tres consecuencias que lo descartan:
|
|
|
|
1. **El EID es una identidad de hardware.** Cada descarga de perfil queda asociada a un chip
|
|
físico concreto, registrado por el operador y por el SM-DP+. Donde la SIM prepago de plástico
|
|
es anónima hasta el registro, la eSIM nace **atada a un identificador de hardware trazable**.
|
|
2. **El aprovisionamiento deja rastro contractual.** Necesitas un código de activación emitido por
|
|
un operador, y para eso, una relación con él. Justo lo que una granja quiere evitar.
|
|
3. **No escala como el plástico.** Un SIM-box acepta cientos de tarjetas de plástico intercambiables
|
|
en segundos. Los perfiles eSIM se aprovisionan uno a uno contra EIDs distintos, y moverlos entre
|
|
dispositivos depende de que el operador lo permita.
|
|
|
|
Resumen: la eSIM cambia un consumible anónimo y barato por un identificador de hardware trazable
|
|
con contrato detrás. **Por eso el mercado sigue con plástico** — no por inercia, por diseño.
|
|
|
|
### El problema para un rack
|
|
|
|
Un contenedor redroid **no tiene banda base**. No hay módem, no hay IMEI legítimo, no puede
|
|
recibir un SMS. Nunca. Así que el número y el dispositivo están **necesariamente desacoplados**:
|
|
el SMS llega a un SIM-box en otro sitio y alguien lo teclea en el Android.
|
|
|
|
Ese desacople es en sí mismo una señal. La plataforma puede comprobar la coherencia entre el
|
|
prefijo del número, el operador que lo emite, la geolocalización de la IP, el idioma del sistema,
|
|
la zona horaria y el teclado. En un móvil real de una persona real, todo eso concuerda solo. En una
|
|
granja, concuerda solo si alguien lo hace concordar, en cada cuenta, cada vez.
|
|
|
|
### Por qué es el eslabón que cae
|
|
|
|
**Operación SIMCARTEL**, Europol, octubre de 2025: 1.200 SIM-boxes, 40.000 SIMs activas,
|
|
49 millones de cuentas falsas, 7 detenidos, gogetsms.com y apisim.com incautados.
|
|
|
|
No cayeron por la parte técnica. Cayeron por **la capa SIM**: las tarjetas tienen KYC en origen y
|
|
el dinero de comprarlas deja rastro. Detalle en [legal_ue.md](legal_ue.md).
|
|
|
|
---
|
|
|
|
## 2 · Reputación de IP
|
|
|
|
La segunda pregunta: desde dónde llegas.
|
|
|
|
### Las tres clases de dirección
|
|
|
|
Toda IP pública cae en una de tres categorías, y las plataformas las tratan de forma radicalmente
|
|
distinta:
|
|
|
|
| Clase | Qué es | Cómo la trata la plataforma |
|
|
|---|---|---|
|
|
| **Datacenter** | AWS, Hetzner, OVH, cualquier hosting | Bandera roja inmediata en un alta de consumidor. Nadie se abre Instagram desde un rack |
|
|
| **Residencial** | ISP doméstico — Movistar fibra, Vodafone | Normal. Es de donde viene la gente |
|
|
| **Móvil** | Red celular — datos de Movistar, Orange | **La más limpia de todas.** Y por una razón estructural |
|
|
|
|
### Por qué la IP móvil es el producto premium
|
|
|
|
No es que sea "más confiable". Es que **la plataforma no puede castigarla**.
|
|
|
|
Los operadores móviles usan **CGNAT**: miles de abonados comparten una misma IP pública. Bloquear
|
|
esa IP significa bloquear a miles de clientes legítimos a la vez. Ninguna plataforma puede
|
|
permitírselo.
|
|
|
|
Ese es todo el secreto del mercado de proxies móviles: no vende anonimato, vende **inmunidad al
|
|
bloqueo por daño colateral**.
|
|
|
|
### De dónde salen los proxies residenciales
|
|
|
|
La mayoría del inventario residencial no viene de servidores: viene de SDKs embebidos en apps y
|
|
VPNs gratuitas, que convierten el móvil del usuario en nodo de salida a cambio de que la app sea
|
|
gratis. El consentimiento suele estar enterrado en unos términos que nadie lee.
|
|
|
|
Cuando alguien compra tráfico residencial, muy probablemente está saliendo por la conexión de una
|
|
persona que no lo sabe. Eso ha generado litigios.
|
|
|
|
### Qué mira la plataforma, más allá de la clase
|
|
|
|
La clasificación es solo el principio. Hay un mercado entero de datos de reputación —
|
|
MaxMind, IPQualityScore, Spur, IPinfo — que vende exactamente esto:
|
|
|
|
- **Clasificación de ASN**: si el rango pertenece a un hosting, se sabe
|
|
- **Detección de proxy/VPN conocido**: los rangos de los proveedores comerciales están catalogados
|
|
- **Velocidad**: cuántas cuentas se han dado de alta desde esa IP y en cuánto tiempo
|
|
- **Distribución**: una IP residencial con 40 cuentas es más rara que 40 IPs con una cada una
|
|
- **Coherencia geográfica**: IP en Letonia, número español, dispositivo en inglés, zona horaria de
|
|
Vietnam. Cada desajuste es una señal
|
|
- **Huella de transporte**: JA3/JA4 (el fingerprint del handshake TLS), orden de cabeceras HTTP,
|
|
versión de la librería de red. Identifica al cliente por debajo de la aplicación
|
|
|
|
Con eso último no hace falta mirar la app para saber que no es la app.
|
|
|
|
---
|
|
|
|
## 3 · Atestación de dispositivo
|
|
|
|
La tercera pregunta: qué dispositivo eres. Es donde se decidió la partida.
|
|
|
|
### De SafetyNet a Play Integrity
|
|
|
|
SafetyNet Attestation, la generación anterior, era básicamente software comprobando software: se
|
|
podía derrotar con suficiente trabajo, y por eso existió un mercado de bypasses. Google la retiró
|
|
y la sustituyó por la **Play Integrity API**, que devuelve tres veredictos escalonados:
|
|
|
|
| Veredicto | Qué afirma |
|
|
|---|---|
|
|
| `MEETS_BASIC_INTEGRITY` | Algo parecido a un Android, sin garantías fuertes |
|
|
| `MEETS_DEVICE_INTEGRITY` | Dispositivo Android real, con Play Services y arranque verificado |
|
|
| `MEETS_STRONG_INTEGRITY` | Lo anterior **más prueba respaldada por hardware** |
|
|
|
|
### Qué significa "respaldada por hardware"
|
|
|
|
Es la clave técnica del proyecto entero.
|
|
|
|
Un Android certificado sale de fábrica con una **clave privada de atestación grabada en su elemento
|
|
seguro** — el TEE, o StrongBox si hay chip dedicado. Esa clave nunca sale del hardware. Cuando la
|
|
plataforma pide una prueba, el dispositivo genera una clave dentro del TEE y devuelve una **cadena
|
|
de certificados** que se remonta, eslabón a eslabón, hasta **una raíz firmada por Google**.
|
|
|
|
En la cadena viaja además el estado de **Verified Boot**: si el arranque está verificado
|
|
(`GREEN`), si el bootloader está desbloqueado (`ORANGE`), si hay algo modificado.
|
|
|
|
```
|
|
Dispositivo certificado Contenedor redroid
|
|
┌────────────────────────────┐ ┌────────────────────────────┐
|
|
│ clave privada en el TEE │ │ (no hay TEE) │
|
|
│ │ firma │ │ │
|
|
│ ▼ │ │ │
|
|
│ cert del dispositivo │ │ nada que firmar │
|
|
│ ▼ │ │ nada que encadenar │
|
|
│ cert intermedio (OEM) │ │ │
|
|
│ ▼ │ │ │
|
|
│ RAÍZ de Google ✓ ok │ │ la verificación falla ✗ │
|
|
└────────────────────────────┘ └────────────────────────────┘
|
|
```
|
|
|
|
Entonces, ¿qué le falta a un contenedor redroid, o a cualquier emulador?
|
|
|
|
**La clave privada.** No es que sea difícil de imitar: es que **no la tiene y no puede tenerla**.
|
|
Está grabada en silicio en la fábrica de un dispositivo certificado. No hay software que la
|
|
produzca, porque su valor consiste precisamente en que no se puede producir por software.
|
|
|
|
Junto a eso, todo lo demás cae por su propio peso: sin TEE, sin arranque verificado, sin banda
|
|
base, sin IMEI legítimo, con cadenas de GPU que dicen SwiftShader, sin acelerómetro que dé ruido
|
|
real, sin sensor de luz que varíe.
|
|
|
|
### Por qué esto ya no es una carrera armamentística
|
|
|
|
Esto cambia la naturaleza del problema:
|
|
|
|
> La detección de emulador dejó de ser **estadística** y pasó a ser **criptográfica**.
|
|
|
|
Antes, detectar un emulador era acumular indicios y decidir con un umbral — y todo umbral se puede
|
|
esquivar. Ahora es verificar una firma contra una raíz de confianza. Para el nivel respaldado por
|
|
hardware, **o tienes la clave o no la tienes**: no hay imitación que valga (ver la subsección
|
|
siguiente para el matiz por niveles).
|
|
|
|
Explica también por qué GenFarmer vende cajas con teléfonos físicos de 400 $ en vez de software
|
|
para tu servidor: lo que venden no es cómputo, es el único sitio donde vive la clave.
|
|
|
|
### ¿Se puede imitar la clave en vez de robarla?
|
|
|
|
Es la pregunta natural, y la respuesta no es "imposible" a secas: es **por niveles**. Lo que decide
|
|
cada nivel es una distinción simple.
|
|
|
|
> La imitación derrota comprobaciones que inspeccionan **propiedades**. Es inútil contra una
|
|
> comprobación que verifica una **firma**.
|
|
|
|
Falsear una propiedad es cambiar lo que el sistema *dice de sí mismo*: el build fingerprint, si hay
|
|
root, el estado del bootloader. Falsear una firma no existe: o valida contra la raíz de Google o no,
|
|
y no hay apariencia que retocar. Play Integrity mezcla las dos cosas:
|
|
|
|
| Veredicto | Qué comprueba | ¿Imitable? |
|
|
|---|---|---|
|
|
| `BASIC_INTEGRITY` | Propiedades reportadas por software | Sí, con trabajo |
|
|
| `DEVICE_INTEGRITY` | Antes propiedades; **desde 2024, firma por hardware** | Ya casi no |
|
|
| `STRONG_INTEGRITY` | Firma respaldada por hardware | No |
|
|
|
|
**Qué existe en el mundo real.** Hay un ecosistema entero dedicado a esto sobre móviles rooteados:
|
|
Magisk/Zygisk para ocultar el root, módulos tipo *Play Integrity Fix* y **fingerprints de
|
|
dispositivos reales prestados** para que un teléfono modificado se presente como uno de fábrica. Es
|
|
la misma partida de gato y ratón de siempre, ahora sobre firmas en vez de sobre umbrales.
|
|
|
|
**Por qué no se sostiene.** Google movió `DEVICE_INTEGRITY` a respaldo por hardware en 2024, lo que
|
|
rompió el spoofing que solo cambiaba fingerprints. Lo que quedó fue tirar de **keyboxes filtrados**
|
|
—conjuntos de claves de atestación reales sacados de dispositivos— y Google los **revoca** en cuanto
|
|
se usan en masa. Es un recurso que caduca: usarlo mucho es exactamente lo que lo quema.
|
|
|
|
**Y para esta granja en concreto es el caso más difícil.** Todo lo anterior asume un móvil real
|
|
rooteado, con su TEE y su cadena de arranque. Un contenedor redroid **no tiene bootloader, ni
|
|
verified boot, ni TEE**: parte de una posición peor que un teléfono modificado, así que ni siquiera
|
|
`BASIC_INTEGRITY` es cómodo.
|
|
|
|
El fondo honesto, entonces: **se puede en los niveles que no dependen de hardware**, invirtiendo
|
|
mucho trabajo y con recursos que expiran; el nivel hardware no; y aunque cueles la atestación, a
|
|
escala te sigue hundiendo la correlación del punto 4. No es un muro infinito, es un muro caro, alto
|
|
y que hay que reconstruir cada vez.
|
|
|
|
### Para saber más
|
|
|
|
Documentación oficial y una fuente académica para entender el mecanismo por dentro. Este documento
|
|
se queda en el análisis; no incluye receta de bypass (ver el alcance en el [README](../README.md)).
|
|
|
|
- [Play Integrity API](https://developer.android.com/google/play/integrity) — los tres veredictos y qué garantiza cada uno
|
|
- [Android Key Attestation](https://developer.android.com/privacy-and-security/security-key-attestation) — la cadena de certificados hasta la raíz de Google
|
|
- [Verified Boot](https://source.android.com/docs/security/features/verifiedboot) — los estados de arranque (`GREEN`/`ORANGE`)
|
|
- ["Trust Dies in Darkness: Shedding Light on Samsung's TrustZone Keymaster" (2022)](https://eprint.iacr.org/2022/208) — extracción de claves en un TEE vulnerable, y por qué es per-dispositivo y revocable
|
|
|
|
---
|
|
|
|
## 4 · Cómo se integra todo: la correlación
|
|
|
|
Las tres capas anteriores se pueden atacar por separado con dinero: SIM-box, proxies móviles,
|
|
teléfonos físicos. Caras, pero atacables. Lo que hunde el negocio es la cuarta pregunta, y es de
|
|
otra naturaleza.
|
|
|
|
### La plataforma no evalúa cuentas, evalúa grupos
|
|
|
|
Una cuenta se mira sola solo en el alta. A partir de ahí, los sistemas antiabuso hacen
|
|
**clustering**: buscan grupos de cuentas que se parecen más entre sí de lo que se parecerían por
|
|
azar.
|
|
|
|
Las aristas que unen el grafo:
|
|
|
|
- **Dispositivo**: identificadores, huellas de hardware, versiones exactas de SO y app
|
|
- **Red**: rangos de IP, ASN, huellas TLS, patrones de tránsito
|
|
- **Comportamiento**: horas de actividad, velocidad de escritura, ritmo de desplazamiento, tiempo
|
|
entre acciones, sesiones
|
|
- **Grafo social**: a quién siguen, en qué orden, qué contenido tocan
|
|
- **Temporal**: cohortes de registro. 45 cuentas dadas de alta el mismo martes por la tarde ya son
|
|
un grupo, aunque todo lo demás esté impecable
|
|
|
|
### El problema de escala
|
|
|
|
Fabricar **una** cuenta indistinguible de la de una persona real es caro pero factible.
|
|
|
|
Fabricar **cuarenta y cinco cuentas mutuamente independientes** es un problema distinto: no basta
|
|
con que cada una parezca real, hace falta que **no se parezcan entre sí más de lo normal**. Cada
|
|
recurso compartido — un rango de IP, un patrón horario, una plantilla de comportamiento, el momento
|
|
del alta — es una arista que las une.
|
|
|
|
De ahí sale la conclusión económica que explica todo el mercado:
|
|
|
|
> El coste por cuenta **crece** con el tamaño de la flota, en vez de bajar.
|
|
|
|
Es lo contrario de una economía de escala. Y por eso el sector es un flujo constante de operadores
|
|
pequeños quemando cuentas, en lugar de unos pocos grandes con márgenes estables. La única forma de
|
|
que salgan las cuentas es externalizar el riesgo: comprar las SIMs a nombre de otros, sacar los
|
|
proxies de los móviles de terceros. Que es exactamente **lo que persiguen y por lo que caen**.
|
|
|
|
---
|
|
|
|
## 5 · Qué significa para este proyecto
|
|
|
|
El rack no sirve para las plataformas sociales, y no por falta de potencia: no tiene la clave.
|
|
Ninguna cantidad de blades, RAM o ancho de banda produce una clave de atestación grabada en
|
|
fábrica. La detección no es un umbral que se pueda esquivar, es una firma que no se puede
|
|
falsificar.
|
|
|
|
Sí sirve como laboratorio de QA propio. Probar `oasis_mobile` en una matriz de versiones de
|
|
Android, y el escenario multi-dispositivo de los dos APKs que se tienen que ver entre sí, es
|
|
exactamente para lo que 45 Android en red interna son buenos. Ahí no hay atestación que superar:
|
|
es tu app en tus dispositivos.
|
|
|
|
---
|
|
|
|
## Fuentes y lecturas
|
|
|
|
- [Play Integrity API](https://developer.android.com/google/play/integrity) — los tres veredictos
|
|
- [Android Key Attestation](https://developer.android.com/privacy-and-security/security-key-attestation) — la cadena de certificados hasta la raíz de Google
|
|
- [Verified Boot](https://source.android.com/docs/security/features/verifiedboot) — estados de arranque
|
|
- [GSMA eSIM / arquitectura de aprovisionamiento remoto](https://www.gsma.com/esim/) — EID, SM-DP+, perfiles
|
|
- Europol, Operación SIMCARTEL — ver [fuentes.md](fuentes.md)
|
|
- Informes de transparencia DSA de TikTok y Meta — cifras de cuentas falsas bloqueadas
|