- mercado_y_players.md: nueva sección sobre cómo operan GenFarmer y PhoneFarmBox (hardware de densidad + automatización por OCR + capa de identidad aparte, modelo de picos y palas), mapa de players por capa (bastidores, cloud phones, antidetect, proxies, OTP, automatización) y alternativas separadas por caso: device lab legal vs plataformas sociales - README: sustituida la sección "Por qué esto no sirve" por una sobre la atestación por niveles, con disclaimer de alcance
120 lines
4.8 KiB
Markdown
120 lines
4.8 KiB
Markdown
# Rebelión en la granja
|
||
|
||
Laboratorio de dispositivos Android sobre un chasis de blades Dell PowerEdge M1000e, más la
|
||
investigación sobre granjas de dispositivos que llevó a montarlo así.
|
||
|
||
Sin móviles físicos: cada dispositivo es un contenedor
|
||
[redroid](https://github.com/remote-android/redroid-doc) — Android real sobre el kernel del blade.
|
||
|
||
## Arquitectura
|
||
|
||

|
||
|
||
```
|
||
Dell PowerEdge M1000e — 16 blades (8 arriba + 8 abajo)
|
||
│
|
||
├── blade-01 ................ coordinador: adb + fleet
|
||
│
|
||
└── blade-02 .. blade-16 .... nodos de carga
|
||
└── Debian 12
|
||
└── Docker
|
||
└── N × redroid
|
||
|
||
8 GB/blade → 3 instancias → 45 Android
|
||
32 GB/blade → 14 instancias → 210 Android
|
||
```
|
||
|
||
Debian va directo sobre el hierro. Sin Proxmox, sin VMs, sin LXC anidado: con 8 GB por blade cada
|
||
capa de hipervisor se come una instancia entera.
|
||
|
||
## Hardware
|
||
|
||

|
||
|
||
Datos del manual del propietario del M1000e (Dell, modelo BMX01, rev. A06, oct. 2019). Dos
|
||
exigencias del manual condicionan el proyecto entero: las seis fuentes y los nueve ventiladores son
|
||
obligatorios, se usen 3 blades o 16. No se puede arrancar el chasis a medias.
|
||
|
||
Detalle en [02_device_lab/hardware_m1000e.md](02_device_lab/hardware_m1000e.md).
|
||
|
||
## Software
|
||
|
||

|
||
|
||
| Capa | Tecnología |
|
||
|---|---|
|
||
| SO | Debian 12 bookworm |
|
||
| Kernel | `binder_linux` con devices `binder,hwbinder,vndbinder` (Debian no trae binderfs) |
|
||
| Contenedores | Docker CE + Compose v2 |
|
||
| Android | redroid 13 |
|
||
| Orquestación | Ansible, solo `ansible.builtin` |
|
||
| Control | adb sobre TCP + `fleet` |
|
||
| Red | `portmap` (NAT) o `macvlan` (IP real de LAN por Fabric A) |
|
||
|
||
## Red
|
||
|
||

|
||
|
||
## Números
|
||
|
||
| | |
|
||
|---|---|
|
||
| Capacidad | 45 Android; 210 con la RAM ampliada |
|
||
| Chasis | 10U · 44,0 × 44,7 × 75,5 cm · 200,5 kg cargado |
|
||
| Consumo | 2,6–3,6 kW · 70–85 dB · 6 fuentes C20 · 9 ventiladores |
|
||
| Térmico | 10–35 °C en continuo |
|
||
| Coste 24/7 | ~360 €/mes |
|
||
| Coste por ventanas de 4 h/día | ~59 €/mes |
|
||
| Coste por dispositivo | 8,0 €/mes; 1,8 €/mes con la RAM ampliada |
|
||
|
||
## Arranque
|
||
|
||
```bash
|
||
git clone https://gitea.laenre.net/hacklab/REBELION_EN_LA_GRANJA.git
|
||
cd REBELION_EN_LA_GRANJA/02_device_lab/ansible
|
||
|
||
sudo apt install ansible
|
||
cp inventory/hosts.yml.example inventory/hosts.yml # poner las IPs reales
|
||
|
||
ansible-playbook playbooks/preflight.yml # solo lectura, no toca nada
|
||
ansible-playbook site.yml
|
||
ansible-playbook playbooks/status.yml
|
||
```
|
||
|
||
El preflight va primero. Identifica el modelo de blade leyéndolo del DMI, comprueba si esas CPUs
|
||
sirven para Android x86_64 y calcula cuántas instancias caben.
|
||
|
||
Para probar sin encender el chasis, el inventario incluye un bloque de piloto de un nodo que
|
||
levanta todo el pipeline en un sobremesa.
|
||
|
||
## Contenido
|
||
|
||
| | |
|
||
|---|---|
|
||
| [GUIA.md](GUIA.md) | Estado, qué está verificado y qué no, siguientes pasos |
|
||
| [docs/requisitos.md](docs/requisitos.md) | Eléctrico, físico, red, tiempo. Checklist de bloqueantes |
|
||
| [docs/costes.md](docs/costes.md) | Consumo y coste por escenario |
|
||
| [docs/seguridad.md](docs/seguridad.md) | 11 hallazgos, uno crítico |
|
||
| [docs/usabilidad.md](docs/usabilidad.md) | Cómo se opera la flota |
|
||
| [02_device_lab/ansible/](02_device_lab/ansible/) | La automatización |
|
||
| [02_device_lab/hardware_m1000e.md](02_device_lab/hardware_m1000e.md) | El chasis según el manual |
|
||
| [01_investigacion/](01_investigacion/) | Mercado, stack, capa de identidad, marco legal |
|
||
|
||
## La atestación de dispositivo
|
||
|
||
La detección de emulador pasó de estadística a criptográfica. Un Android certificado lleva una
|
||
clave privada grabada en el TEE de fábrica, con cadena de certificados hasta una raíz de Google. El
|
||
nivel de integridad respaldado por hardware verifica una firma, no una apariencia, así que un
|
||
contenedor no lo pasa por imitación.
|
||
|
||
Pero no es un "no" absoluto: los veredictos que solo inspeccionan propiedades **sí se falsean por
|
||
software** —con mucho trabajo, recursos que caducan y nunca a escala—, y solo el nivel hardware
|
||
resiste. El desglose por niveles, más cómo operan los vendedores de este mercado (GenFarmer,
|
||
PhoneFarmBox y los demás) y qué alternativas existen, está en
|
||
[01_investigacion/capa_identidad.md](01_investigacion/capa_identidad.md) y
|
||
[01_investigacion/mercado_y_players.md](01_investigacion/mercado_y_players.md).
|
||
|
||
> **Alcance.** Este repositorio documenta cómo funciona el mercado y monta un laboratorio de QA
|
||
> para apps propias. No contiene operativa de alta masiva de cuentas —sourcing de SIMs, evasión de
|
||
> fingerprint, maduración—, que es fraude de identidad a escala y en la UE está bajo persecución
|
||
> activa. Contexto legal en [01_investigacion/legal_ue.md](01_investigacion/legal_ue.md).
|