FR-RATEL: Der Handleser, den wir geknackt haben
Der FR-RATEL ist einer dieser kompakten USB-Handleser, die man oft unter dem Namen „iCopy V300CD-Klon” findet: klein, batteriebetrieben über USB, mit einem Tastenfeld und einem kleinen Display. Gedacht für Mifare-Classic- und 125-kHz-Karten unterwegs. Das Problem: Ohne die Hersteller-Software war das Gerät am PC bisher eine Blackbox. Wir haben das Protokoll vollständig reverse-engineered — und bauen darauf jetzt einen eigenständigen Windows-Client.
Was ist der FR-RATEL überhaupt?
Auf dem Markt kursiert das Gerät unter mehreren Namen — FR-RATEL, iCopy V300CD, teils auch nur „Handleser”. Hardwareseitig ist es ein USB-HID-Gerät mit einer HF-Antenne (13,56 MHz, Mifare Classic) und einer LF-Antenne (125 kHz, EM4100 / HID Prox), dazu Tasten und Display für den Offline-Betrieb ohne PC. Beliebt bei Schließanlagen-Technikern und Pentestern, weil er klein, günstig und schnell griffbereit ist — ein Werkzeug für den schnellen Check vor Ort, nicht für die Tiefenanalyse am Labortisch.
Die Blackbox
Ohne die Hersteller-App sprach mit dem FR-RATEL bisher niemand. Das Gerät meldet sich am PC nicht als serieller Port, sondern als reines USB-HID-Gerät, und jedes einzelne Datenpaket ist verschlüsselt — ohne den passenden Schlüssel liest man nur Rauschen. Eigene Software, eigene Automatisierung, eigene Integration in eine bestehende Pentest-Toolchain: alles unmöglich, solange man an die mitgelieferte Windows-App gebunden ist.
Was wir gemacht haben
Wir haben den USB-Traffic zwischen der Hersteller-App und dem Gerät mitgeschnitten und das Protokoll Schicht für Schicht zerlegt: wie die 64-Byte-HID-Pakete aufgebaut sind, wie Länge und Prüfsumme in jedem Paket stecken, und wie die Verschlüsselung funktioniert, die jedes Paket in beide Richtungen unlesbar macht. Jeden Schritt haben wir gegen echte Hardware verifiziert — nicht nur am Papier, sondern am laufenden Lesevorgang mit echten Karten. Ergebnis: eine eigene, von der Hersteller-App unabhängige Implementierung, die genau weiß, wie man mit dem Gerät spricht.
Was jetzt möglich ist
Aus der reversed Implementierung ist ein eigenständiger Windows-Client geworden, der den FR-RATEL komplett ohne Hersteller-App ansteuert — eine einzelne .exe, kein Installer.
| Bereich | Funktion | Status |
|---|---|---|
| HF (13,56 MHz) | UID scannen | verifiziert |
| HF | Vollständiger Sektor-Dump | verifiziert |
| HF | Auto-Crack-Dump (Schlüssel-Wörterbuch) | verifiziert |
| HF | Sektor schreiben | experimentell |
| HF | Hardware-Wörterbuch-Crack | verifiziert |
| HF | Nested-Angriff (bekannter/unbekannter Schlüssel) | verifiziert |
| LF (125 kHz) | EM4100 / HID Prox lesen | verifiziert |
| LF | EM4100 auf T5577 klonen | hardware-verifiziert |
| LF | HID Prox schreiben | unverifiziert |
Für wen ist das
Der Client richtet sich an autorisierte Pentester und an Techniker, die eigene bzw. ausdrücklich freigegebene Hardware prüfen oder reparieren — etwa wenn eine Zugangskarte verloren geht und ein neues Token für dieselbe Anlage angelernt werden muss, oder wenn im Rahmen eines Pentests Mifare-Classic-Systeme auf schwache Schlüssel geprüft werden. Lesen und Analysieren von Karten ist dabei grundlegend Dual-Use-Technik — dieselben Werkzeuge nutzen auch Transit-Betreiber und Zugangskontroll-Hersteller selbst zur Qualitätssicherung. Kein Freifahrtschein für fremde Systeme: der Rahmen bleibt derselbe wie bei jedem anderen SSR-Labs-Werkzeug.
Hier der Download
Wie der FR-RATEL angesteuert wird
USB-HID-Reader (iCopy V300CD-Klon), VID 0x1629 / PID 0x1831. Protokoll aus der
Vendor-DeviceAgreement-Lib reversed, gegen echte Hardware verifiziert. Referenz:
FrRatelClient/Hardware/FrRatelReader.cs.
1 · Transport
Der Reader meldet sich als HID-Gerät (kein serieller COM-Port). Jede Nachricht — in beide
Richtungen — ist ein 64-Byte HID-Report, dem beim Schreiben ein Report-ID-Byte 0x00
vorangestellt wird (macht 65 Bytes auf dem Wire). Ein logischer Befehl kann über mehrere
solcher 64-Byte-Reports verteilt sein, wenn die Antwort länger als 64 Byte ist.
Zugriff läuft über SetupDiGetClassDevs /
CreateFile / ReadFile / WriteFile auf den HID-GUID-Pfad —
gefiltert auf vid_1629 + mi_00. Genau wie beim PN532 gilt: ein generischer
serieller Zugriff funktioniert hier nicht, es muss der native HID-Layer sein.
2 · Frame-Aufbau
Vor der Verschlüsselung sieht ein Befehls-Frame so aus — Länge + Payload + CRC16, auf 64 Byte aufgefüllt:
Das ganze 64-Byte-Paket wird anschließend mit RC4 verschlüsselt — inklusive der
Padding-Nullen. Antworten laufen spiegelbildlich: erst RC4-entschlüsseln, dann stehen die
ersten 2 Byte für die tatsächliche Länge, Byte 3 ist der Status (0x01 = OK).
3 · RC4-Schlüssel
Der RC4-Schlüssel ist 16 Byte lang und setzt sich aus einem 4-Byte Geräteschlüssel plus einem festen 8-Byte-Suffix zusammen (die restlichen 4 Byte des 16-Byte-Puffers bleiben 0):
Mit diesem einen festen Schlüssel wird jedes Frame in beide Richtungen ver- bzw. entschlüsselt — es gibt keine Session-Rotation. Standard-RC4-KSA/PRGA, byteweise XOR.
4 · Verbindungsaufbau (Handshake)
Vor jedem Befehl steht ein zweistufiger Handshake: Geräteerkennung, dann ein Nonce-Austausch, bei dem der PC der Zufallszahl des Geräts antworten muss.
sequenceDiagram
participant PC as PC-Software
participant DEV as FR-RATEL (USB-HID)
PC->>DEV: 0x06 FindDevice
DEV-->>PC: ack
PC->>DEV: 0x01 ver=01, packSize=5120, devType=0F04, pcRandom=5264
DEV-->>PC: status=1, devRandom (4 Byte, Offset 12..15)
PC->>DEV: 0x01 Echo von devRandom
DEV-->>PC: status=1 — Handshake fertig
Note over PC,DEV: Erst jetzt nehmen 0x21 / 0x17 / 0x13 ... Befehle an
5 · Befehlssatz
| Code | Funktion | Wire | Status |
|---|---|---|---|
| 0x06 | FindDevice | [06] | verifiziert |
| 0x01 | Handshake-Nonce | [01][ver][pack 2B][devType 2B][pcRand 4B] | verifiziert |
| 0x10 | Init / Select (HF) | [10] | verifiziert |
| 0x21 | HF-UID lesen | [21] → UID 4B, ATQA 2B | verifiziert |
| 0x17 | Auth + Sektor lesen | [17][Sector][Flag][KeyA 6B][KeyB 6B] | verifiziert |
| 0x18 | Auth + Sektor schreiben | [18][Sector][Flag][KeyA][KeyB][Data] | experimentell |
| 0x13 | HW-Dictionary-Check | [13][Block][KeyType][Count][Keys…] | verifiziert |
| 0x14 | Nested (bekannter Key) | [14][CheckBlock][Type][Key 6B][AttBlock][Type][Rand 4B] | verifiziert |
| 0x15 | Nested-Nonce (unbekannt) | [15][02][AttBlock][AttType] | verifiziert |
| 0x28 | LF lesen (EM4100) | [28][Auto=1][Freq=0] → ID 5B LE | verifiziert |
| 0x29 | LF lesen (HID Prox) | [29] | verifiziert |
| 0x2D | EM4100 → T5577/EM4305 klonen | [2D][Freq][CardID 4B][PlantID 1B] | hardware-verifiziert |
| 0x2E | HID Prox schreiben | [2E][CardID 12B] | unverifiziert |
6 · Beispiel: HF-Scan Ende-zu-Ende
Payload bauen: [0x21] → mit Länge+CRC auf [len][0x21][crc_lo][crc_hi], Rest mit Nullen auf 64 Byte auffüllen.
Die vollen 64 Byte (inkl. Padding) mit RC4 verschlüsseln.
Als HID-Report senden: Byte 0 = Report-ID 0x00, Byte 1–64 = verschlüsseltes Frame.
Antwort-Report lesen (64 Datenbytes), mit demselben RC4-Key entschlüsseln.
Entschlüsselte Bytes 0–1 = Länge → ggf. weitere 64-Byte-Reports nachlesen und an den RC4-Stream anhängen, bis die volle Länge erreicht ist.
Byte 2 = Status (1 = OK), Bytes 3–6 = UID, Bytes 7–8 = ATQA (little-endian).
7 · Kurzfassung in Code
Dieses Dokument beschreibt ausschließlich die USB-Transportschicht des eigenen
Lesers zum autorisierten Pentesting/Reparatur-Zweck. Vollständige Referenzimplementierung:
FrRatelClient/Hardware/FrRatelReader.cs (SSR-Labs.de).
