Phase 4: Protokoll-Rekonstruktion

Lernziel

Nach dieser Seite weißt du, wie du JADX-Code und PCAP-Mitschnitte miteinander korrelierst, eine vollständige GATT-Hierarchie dokumentierst, Befehlsformate reverse engineerst und das Kommunikationsprotokoll eines BLE-Geräts als Zustandsmaschine (DFA) modellierst — mit drei echten Geräteprotokollen als Praxisbeispiele.

Was ist Protokoll-Rekonstruktion?

Stell dir vor, du hörst ein Gespräch in einer fremden Sprache. In Phase 2 hast du jeden Satz aufgeschrieben. In Phase 3 hast du das Wörterbuch gefunden. Jetzt, in Phase 4, baust du die vollständige Grammatik dieser Sprache nach — die Regeln, in welcher Reihenfolge Sätze gesagt werden dürfen, was eine Antwort auslöst und was passiert, wenn ein Schritt übersprungen wird.

Das Ergebnis dieser Phase ist eine Protokollspezifikation: ein strukturiertes Dokument, das beschreibt, welche Charakteristik welche Befehle erwartet, welches Byte-Format gilt und in welcher Reihenfolge Nachrichten ausgetauscht werden müssen.

Zeitaufwand: 3–5 Stunden für ein unbekanntes Gerät.

Schritt 1: JADX und PCAP korrelieren

Der wichtigste Schritt in Phase 4 ist die Korrelation: Du schaust gleichzeitig auf den dekompilierten Java-Code (JADX) und auf den Netzwerkmitschnitt (Wireshark) und fragst: "Welche Codezeile erzeugt welches Paket?"

Vorgehen

1. Öffne JADX-GUI mit der APK und Wireshark mit der .pcapng-Datei nebeneinander.
2. Suche in JADX nach dem BLE-Schreibaufruf (writeCharacteristic) und schau, welche Daten übergeben werden.
3. Suche in Wireshark nach demselben Byte-Muster (Filter: btatt.value).
4. Dokumentiere: Code-Funktion → Byte-Sequenz → Zeitpunkt im Capture.

# Pseudocode: Korrelationsdokument aufbauen
{
  "funktion": "sendColorCommand",
  "charakteristik": "0000fff3-0000-1000-8000-00805f9b34fb",
  "beispiel_bytes": "7e 07 05 03 80 ff 00 10 ef",
  "wireshark_frame": 42,
  "zeitstempel_pcap": "17.380s"
}

Schritt 2: GATT-Hierarchie dokumentieren

Bevor du einzelne Befehle analysierst, dokumentierst du die vollständige GATT-Struktur des Geräts. Diese Hierarchie ist das "Inhaltsverzeichnis" des Protokolls.

GATT (Generic Attribute Profile) organisiert BLE-Dienste in einer Baumstruktur: Ein Gerät hat Services (Dienste), jeder Service hat Characteristics (Charakteristiken), jede Charakteristik hat Permissions (Rechte: Lesen, Schreiben, Notify).

Praxisbeispiel: LED-Brille

Die Brille hat einen herstellerspezifischen Service auf 0xFFF0 mit drei Charakteristiken:

GLASSES-12B008
 |
 +-- LED Control Service (0xFFF0)
 |    +-- Control (Handle: 0x0012)
 |    |    UUID: d44bc439-abfd-45a2-b575-925416129600
 |    |    Permissions: WRITE, WRITE_WITHOUT_RESPONSE
 |    |
 |    +-- Data (Handle: 0x0015)
 |    |    UUID: d44bc439-abfd-45a2-b575-92541612960a
 |    |    Permissions: WRITE, WRITE_WITHOUT_RESPONSE
 |    |
 |    +-- Notification (Handle: 0x001B)
 |         UUID: d44bc439-abfd-45a2-b575-925416129601
 |         Permissions: NOTIFY
 |
 +-- OTA/Firmware Service (0xFD00)

Die Aufgabenteilung ist direkt aus den Charakteristik-Namen und Permissions ablesbar: Control-Schreiben löst Steuerkommandos aus, Data-Schreiben überträgt Nutzdaten, und Notification empfängt Bestätigungen vom Gerät.

Praxisbeispiel: LED-Strip

Der Strip verwendet Standard-UUIDs aus dem 0xFFF0-Bereich — ein Indiz für eine generische Firmware-Plattform:

LED-STRIP
 |
 +-- Control Service (0xFFF0)
      +-- Command (Handle: 0x000D)
           UUID: 0000fff3-0000-1000-8000-00805f9b34fb
           Permissions: WRITE, WRITE_WITHOUT_RESPONSE

Auffälligkeit: Nur eine einzige Charakteristik für alle Befehle. Das deutet auf ein einfaches Befehlsformat hin, bei dem der Befehlstyp über einen Opcode im Payload kodiert wird — nicht über verschiedene Charakteristiken.

Praxisbeispiel: Körperwaage

Die Waage hat eine besondere Architektur: Sie nutzt keine GATT-Kommunikation für Messwerte, sondern sendet alles über BLE-Advertisements:

Körperwaage "Yoda1"
 |
 +-- Manufacturer Specific Data (Advertisements)
      Hersteller-ID: 0x05C0 (Chipsea Technologies)
      Nutzdaten: Gewicht + Impedanz (unverschlüsselt)

Das bedeutet: Du musst dich gar nicht verbinden, um die Messdaten zu empfangen. Ein passiver Sniffer in BLE-Reichweite genügt.

Schritt 3: Befehlsformate reverse engineern

Jetzt analysierst du die tatsächlichen Byte-Sequenzen und brichst sie in ihre Felder auf.

LED-Strip: Einfaches Frame-Format

Nach der Korrelation von JADX und PCAP ergibt sich für den LED-Strip ein klares, konsistentes Frame-Format:

7E [len] [opcode] [param1] [param2] [param3] [param4] 10 EF

Opcodes aus dem PCAP-Mitschnitt (69 analysierte Commands):

LED-Brille: Zustandsabhängiges Protokoll mit Verschlüsselung

Die Brille ist komplexer. Alle Pakete sind AES-128-ECB-verschlüsselt (mit dem in Phase 3 extrahierten Schlüssel). Erst nach der Entschlüsselung sind die Befehle lesbar:

DATS-Befehl (Datenübertragung ankündigen):

Klartext:  07 44 41 54 53 01 00 26 00 00 00 00 00 00 00 00
           [7]['D']['A']['T']['S'][1][SIZE_HI][SIZE_LO][...Padding...]
Chiffretext: e7 03 dd 68 d7 c0 bb 9c a7 5f 01 40 df 55 e2 19

Das Byte 07 ist der interne Befehlstyp. DATS ist eine ASCII-Kennung. SIZE_HI und SIZE_LO kodieren die Gesamtgröße der folgenden Daten als Big-Endian-16-Bit-Zahl.

Zeichenkodierung: Die Brille hat ein 14×12-LED-Matrix-Display. Jedes Zeichen wird als Spaltenbitmap kodiert: 2 Bytes pro Spalte, 12 Spalten pro Zeichen, also ca. 24 Bytes pro Zeichen. Das Wort "HELLO" benötigt damit 52 Bytes und wird in 16-Byte-AES-Blöcken übertragen (1 Byte Längenheader + bis zu 15 Bytes Nutzdaten pro Block).

Körperwaage: Advertisement-Payload dekodieren

Der Manufacturer-Data-Payload (Hersteller-ID 0x05C0) hat folgendes Format:

Offset  Bytes   Bedeutung
------  ------  ---------
0-1     c0 0e   Status/Flags
2-3     0c 99   Gewicht (Big Endian, Einheit: 0,01 kg)
4-5     13 88   Impedanz (Big Endian, Einheit: 0,1 Ohm)

Dekodierung Gewicht: 0x0C99 = 3225 → 3225 × 0,01 kg = 32,25 kg

Dekodierung Impedanz: 0x1388 = 5000 → 5000 × 0,1 Ω = 500,0 Ω

Schritt 4: DFA-Modellierung

Ein DFA (Deterministischer Finiter Automat — englisch: Deterministic Finite Automaton) ist ein formales Modell für zustandsabhängige Systeme. Im BLE-Kontext beschreibt er, in welchem Zustand sich das Gerät gerade befindet und welche Nachrichten es in diesem Zustand erwartet.

Das ist keine akademische Übung — ohne DFA-Modell wirst du in Phase 5 fehlerhaften Exploit-Code schreiben, weil du eine Nachricht in der falschen Reihenfolge sendest.

Wann brauchst du einen DFA?

• Wenn das Gerät auf Nachrichten mit Bestätigungen antwortet (Notification-Charakteristik).
• Wenn die Reihenfolge der Nachrichten einen Unterschied macht (fehlgeschlagene Übertragung ohne vorherige Ankündigung).
• Wenn bestimmte Nachrichten nur in bestimmten Zuständen akzeptiert werden.

Der LED-Strip hat keinen DFA — jeder Befehl funktioniert sofort, unabhängig von vorherigen Befehlen. Die LED-Brille hat einen DFA mit 5 Zuständen.

Praxisbeispiel: Fünfstufiger Handshake der LED-Brille

Der PCAP-Mitschnitt (420+ erfasste Pakete) zeigt ein klares Muster: Bevor das Gerät Daten annimmt, muss ein Handshake abgeschlossen werden.

Smartphone                    LED-Brille
    |                              |
    |  1. DATS (Ankündigung)       |
    |----------------------------->|  Handle 0x0012 (Control)
    |                              |
    |  2. DATSOK (Bereit)          |
    |<-----------------------------|  Handle 0x001B (Notification)
    |                              |
    |  3. DATA (Zeichendaten)      |
    |----------------------------->|  Handle 0x0015 (Data), mehrere Pakete
    |                              |
    |  4. DATCP (Ende)             |
    |----------------------------->|  Handle 0x0012 (Control)
    |                              |
    |  5. DATCPOK (Fertig)         |
    |<-----------------------------|  Handle 0x001B (Notification)
    |                              |

Wichtig: Ohne die Bestätigung DATSOK in Schritt 2 darf kein DATA-Paket gesendet werden. Das Gerät ignoriert DATA ohne vorherigen Handshake. Außerdem gilt ein Pflicht-Pause von 50 ms zwischen DATA-Paketen — sonst verwirft das Gerät Pakete.

Schritt 5: Protokollspezifikation schreiben

Am Ende von Phase 4 erstellst du ein schriftliches Dokument — die Protokollspezifikation. Dieses Dokument ist die Grundlage für Phase 5 (PoC-Entwicklung).

Eine minimale Protokollspezifikation enthält:

1. GATT-Tabelle: Alle UUIDs, Handles, Permissions
2. Befehlstabelle: Alle Opcodes, Parameter, Beispiel-Bytes
3. DFA-Diagramm: Zustände und Transitionen (falls zustandsbehaftet)
4. Timing-Anforderungen: Pflicht-Pausen zwischen Paketen
5. Kodierungsregeln: Endianness (Big/Little Endian), Einheiten, Padding

Praxisbeispiel: Protokollspezifikation LED-Strip (Kurzform)

Gerät: Smart-LED-Strip (wl.smartled)
Protokoll: Klartext GATT-Write, zustandslos

GATT:
  Service:        0000fff0-0000-1000-8000-00805f9b34fb
  Characteristic: 0000fff3-0000-1000-8000-00805f9b34fb
  Permission:     WRITE, WRITE_WITHOUT_RESPONSE

Frame-Format: 7E [len] [opcode] [p1] [p2] [p3] [p4] 10 EF

Befehle:
  RGB-Farbe:   7e 07 05 03 [R] [G] [B] 10 ef
  Effektmodus: 7e 05 03 [effect_id] [speed] 10 ef
  Power:       7e 04 04 [01=an / 00=aus] 00 10 ef
  Helligkeit:  7e 04 01 [0-255] 00 10 ef

DFA: keiner (zustandslos — jeder Befehl sofort gültig)
Authentifizierung: keine
Verschlüsselung: keine

Vergleich der drei Geräte

Zusammenfassung

• Protokoll-Rekonstruktion korreliert JADX-Code und PCAP-Mitschnitt, um Byte-Sequenzen Funktionen zuzuordnen
• Die GATT-Hierarchie (Services, Charakteristiken, Permissions) ist das strukturelle Gerüst des Protokolls
• Einfache Geräte wie der LED-Strip haben ein zustandsloses Opcode-Frame-Format; komplexere Geräte wie die LED-Brille haben einen DFA mit Handshake
• Geräte wie die Körperwaage nutzen ausschließlich Advertisements und erfordern keine aktive Verbindung
• Die Protokollspezifikation am Ende von Phase 4 ist die direkte Eingabe für Phase 5 (PoC-Entwicklung)