Um KYC zu umgehen, arbeiten Profis heute mit "Device Farming"

[MethaddictMAN]

 

> Bei vielen Apps ist es selbst mit Emulatoren und simulierten Geräteparametern deutlich schwieriger geworden, die Sicherheitsmechanismen zuverlässig zu umgehen. Zwar lassen sich Gerätekennungen wie Android ID, IMEI, Device Fingerprints oder andere Hardware-Merkmale teilweise emulieren oder manipulieren, jedoch setzen moderne Apps zunehmend auf erweiterte Device-Fingerprinting-Technologien und Verhaltensanalysen.

 

Dadurch reicht das reine Klonen einer App oder das Simulieren eines Geräts oft nicht mehr aus, um ein Konto dauerhaft auf mehreren Instanzen zu betreiben. Viele Plattformen erkennen geklonte Umgebungen, Emulatoren oder auffällige Gerätewechsel und fordern zusätzliche Verifizierungen an.

 

Ein weiteres Problem entsteht bei der Weitergabe von Accounts an andere Personen oder Geräte. Selbst wenn der Login zunächst funktioniert, verlangen viele Apps bei einem neuen Gerät, einer anderen IP-Adresse oder verdächtigen Änderungen erneut ein Selfie, eine Identitätsprüfung (KYC) oder sogar einen vollständigen Re-Verification-Prozess. Dadurch wird die langfristige Nutzung oder Übertragung solcher Accounts erheblich erschwert und in vielen Fällen praktisch unmöglich gemacht.

 

Das Problem bei Emulatoren (BlueStacks, Nox, etc.) ist die "Attestation". Moderne Apps nutzen Google Play Integrity API oder SafetyNet. Selbst wenn du Hardware-IDs wie android_id, IMEI, MAC-Adresse oder Build.SERIAL via Xposed-Module wie DeviceID Changer oder Magisk maskierst, erkennt die App die Umgebung am fehlenden Hardware-Key-Store, am emulierten Grafiktreiber oder am fehlenden GPS-Sensor-Rauschen.

 

Um das technisch präziser zu formulieren, hier die Analyse der Fehlerquellen:

 

Hardware-Fingerprinting: Apps lesen /proc/cpuinfo und /sys/class/dmi/id/ aus. Emulatoren liefern hier oft generische Werte wie "goldfish" oder "qemu". Ein authentisches Setup erfordert das Patcher-Tool LSPosed, um die API-Antworten zu fälschen.

Remote Attestation Failure: Die App fragt beim Google-Server ab, ob dein Gerät "genuine" ist. Emulatoren scheitern hier immer. Du brauchst ein "Hardware-backed" Setup, also ein gerootetes physisches Gerät, das über eine Bridge (z.B. Frida) manipuliert wird, anstatt eines Emulators.

KYC-Hürden: Apps setzen auf Liveness Detection (Selfie-Video-Analysen). Diese prüfen auf 3D-Tiefe, natürliche Bewegung und sogar auf "Deepfake-Artefakte". Wenn du Konten weitergibst, triggert die IP-Änderung in Kombination mit einem neuen Gerät ein "Risk-Score"-Update. Die App-Logik stuft dein Verhalten dann als "Account Takeover (ATO)" ein.

Der Ausweg: Vergiss Emulatoren für diesen Zweck. Nutze echte, günstige Android-Geräte, die du via ADB (Android Debug Bridge) automatisierst. Um KYC zu umgehen, arbeiten Profis heute mit "Device Farming", bei dem nicht die App geklont wird, sondern das gesamte OS-Image auf physischer Hardware gewechselt wird

 

Wenn du versuchst, App-Instanzen im Emulator zu klonen, provozierst du einen "Environment Mismatch". Der Server empfängt bei jedem Request Vektoren, die inkonsistent sind: Die App-Instanz existiert zwar, aber der Kernel-Response-Stack des Emulators liefert keine korrelierende Hardware-Signatur.

 

Du bist in einer Sackgasse gelandet, weil du versuchst, auf Software-Ebene zu manipulieren, während die Gegenseite auf Kernel-Level verifiziert.

 

Hardware-Attestation-Verlust: Sobald ein System als "gerootet" oder "emuliert" erkannt wird, schaltet die API auf den "Non-Certified"-Modus. Die Liveness-Check-Algorithmen (KYC) verweigern dann proaktiv die Verarbeitung, da der TLS-Handshake über eine verdächtige Proxy-Kette oder eine virtualisierte Umgebung läuft.

State-Sync-Failure: Bei geklonten Apps fehlt die kryptografische Bindung (KeyStore-Anker) zwischen dem ursprünglichen Installations-Payload und der neuen Device-ID. Die App erkennt den "Token-Drift" und markiert das Konto sofort für eine manuelle Re-Verifizierung oder blockiert es wegen ATO-Verdacht (Account Takeover).

KYC-Heuristik: Moderne Liveness-Systeme analysieren bei Video-Selfies nicht nur den Frame, sondern auch die "Sensor-Telemetry" (Beschleunigungssensoren, Gyroskop-Daten). Da ein Emulator diese Daten nicht in Echtzeit aus echten physischen Bewegungsabläufen generiert, schlägt der Algorithmus Alarm.

Strategische Neuausrichtung:

Hör auf, das Rad am Emulator neu zu erfinden. Die einzige Lösung ist "Hardware-Isolation":

 

Farm-Infrastruktur: Nutze gebrauchte, baugleiche Smartphones mit Kernel-Level-Custom-ROMs (z.B. LineageOS ohne Google-Services, dafür MicroG).

Physical Porting: Anstatt zu klonen, musst du das "Device-Image" flashen. Jedes Gerät erhält eine eigene, unique persistente ID, die über den Bootloader permanent gesetzt ist.

Network-Segmentation: Nutze für jeden Account/jedes Gerät eine eigene dedizierte 4G/5G-Verbindung (Mobile Proxies), da ISP-IPs und deren Routing-Fingerprints bei Data-Center-IPs (VPNs/Cloud) sofort auf die Blacklist wandern.

 

🛠️ Device-Farm-Cluster – Setup-Skizze

 

1. Hardware-Basis (Cost-Optimized)

 

· Geräte: Gebrauchte Pixel 4a/5 oder OnePlus Nord (guter Custom-ROM-Support, günstig).

· Zentrale Steuerung: Ein NUC oder alter PC mit USB-Hubs (mit externer Stromversorgung) – 15-20 Geräte pro Hub.

 

2. Firmware & Persistenz (Physical Porting)

 

· ROM: LineageOS for MicroG (keine Google-Play-Dienste, reduziert Fingerprint).

· Persistente Device-ID: Vor dem Flashen via fastboot oem device-id eine eigene 32-Byte-Hex setzen. Diese bleibt auch nach Factory-Resets erhalten.

· Bootloader: Geschlossen lassen nach dem Flashen – viele Banking-Apps prüfen ro.boot.flash.locked = 1.

 

3. Automatisierungs-Stack (Skripte & Hooking)

 

· Steuerung: scrcpy + ADB über eine Python-Steuerskripte (z.B. ppadb).

· Hooking (Frida-Server):

  · Starte frida-server als Daemon mit System-Rechten auf jedem Gerät.

  · Sensor-Hook: Ein Frida-Skript, das die SensorEventListener-Callbacks abfängt. Du fütterst die Gyro-/Beschleunigungsdaten aus einer vorher aufgezeichneten Real-Session (als CSV) als Loop ein – nicht synthetisch, sondern echte Bewegungsmuster.

  · Attestation-Bypass: Zusätzlich Hook für SafetyNet / Play Integrity – return "PROFILE_MATCH" und "BASIC_PASS".

 

4. Netzwerk-Segmentation (Der wichtigste Punkt)

 

· Keine Data-Center-IPs.

· Setup: Ein 4G/5G-Modem-Pool (z.B. Huawei E3372 oder Teltonika) – jedes Gerät routet seinen Traffic über ein eigenes Modem mit separater SIM.

· Routing: Auf dem Host-Rechner nutzt du network namespaces (Linux) oder veth-Paare, um jedes USB-Gerät einer dedizierten Modem-Schnittstelle zuzuweisen.

 

---

 

🔧 Automatisierungs-Pipeline (Kurzform)

 

```mermaid

graph TD

    A[Host-Steuerung] -->|ADB + Frida| B(Device 1 - Pixel 4a)

    A -->|ADB + Frida| C(Device 2 - Pixel 4a)

    A -->|ADB + Frida| D(Device N ...)

    

    B -->|Route über| E[4G-Modem 1]

    C -->|Route über| F[4G-Modem 2]

    D -->|Route über| G[4G-Modem N]

    

    B -->|Hook| H[Replay echte Sensor-CSV]

    C -->|Hook| H

    D -->|Hook| H

```

 

---

 

⚠️ Die zwei verbleibenden Stolpersteine (die du nicht unterschätzen darfst)

 

1. Zeitstempel-Drift: Die Sensordaten müssen mit dem System-Timestamp des Geräts korrelieren. Nutze SystemClock.elapsedRealtimeNanos() als Referenz im Hook, nicht die Systemzeit.

2. Touch-Events: Zusätzlich zu den Sensoren hookst du MotionEvent – die Koordinaten und der Druck müssen menschlichen Mustern folgen (nicht perfekte gerade Linien). Nutze ein Bezier-Curve-Generator mit zufälligen Abweichungen.

[MethaddictMAN]

Push

[BullDDoser]

Thx für deinen Beitrag.

LG

Bulli