Protokoll-Reverse-Engineering

Was macht Protokoll-Reverse-Engineering?

AKTION ERFORDERLICH (nach dem Lesen sofort ausführen)

1. JETZT: Lese ../field-journal/precedent-reverse.md — Bestätige Autorisierung und allgemeine Betriebsgrenzen
2. JETZT: Bestätige, ob die Aufgabe Protokoll/Datenverkehr/Serialisierungsformat Reverse Engineering betrifft (keine reinen Web-Parameter-Signaturen → wechsle zu js-reverse/)
3. JETZT: Bei Zielnetzwerkinteraktion → ../scripts/case-init.ps1 ausführen, um Scope festzulegen; falls auth nicht erteilt, keine Aktionen gegen das Ziel
4. NÄCHSTES: Lese ../tool-index.md; falls Tools fehlen, Bootstrap (tshark/wireshark etc. müssen ggf. manuell installiert werden)
5. AKTION: Starte Arbeitsablauf Phase 1, erstelle Entwurf eines Frame-Layouts oder Nachrichtenwörterbuchs

Anwendungsbereiche

• Benutzerdefinierte TCP/UDP Binärprotokolle
• Protobuf / gRPC / FlatBuffers / MessagePack
• WebSocket / MQTT / Private RPC
• PCAP / PCAPNG Wiederherstellung von Feldern und Zustandsautomaten
• Client-Server Prüfsummen, Sequenznummern, verschlüsselte Frame-Header

Nicht für diesen Skill

Situation	Ziel-Skill
Nur HTTP-Parameter-Signaturen / JS-Verschlüsselung	js-reverse/
Nur TLS-Zertifikatsprobleme	pentest-tools/ oder Browser-Proxy
Firmware-Protokollstapel mit Simulation	firmware-pentest/ dann zurück zu diesem Skill

Arbeitsablauf

Phase 1 — Erfassung und Triage

□ Probe erhalten: PCAP / Proxy-Export / Client-Log / Binärdatei
□ Richtung markieren: C→S / S→C; Gibt es Handshake, Heartbeat, Wiederaufbau?
□ Fester Header? Magische Bytes? Längenfeld? TLV? Feste Länge?
□ Komprimiert (zlib/gzip/lz4) oder verschlüsselt (AES/ChaCha innerhalb des Frames)?
□ tshark -r cap.pcap -T fields -e frame.number -e ip.src -e tcp.payload

Phase 2 — Frame-Layout Rekonstruktion

□ Mehrere ähnliche Nachrichten abgleichen, invariante Bytes / aufsteigende Sequenznummern finden
□ Längenfeld: Big-Endian/Little-Endian, mit/ohne Header
□ Prüfsumme: CRC16/32, Checksumme, HMAC-Position
□ Zustandsautomaten zeichnen: Connect → Auth → Ready → Request/Response → Close
□ Tools: Wireshark benutzerdefinierter Dissector-Entwurf / ImHex / 010 Editor-Vorlage / Kaitai Struct

Phase 3 — Serialisierung und Verschlüsselung

□ Protobuf: .proto Wiederherstellung (blackboxprotobuf / pbtk / protoc --decode_raw)
□ gRPC: HTTP/2 Header + Protobuf Body
□ Verschlüsselung: Schlüsselableitung suchen (Client so/dll/JS) → gemeinsam mit ida-reverse / js-reverse / apk-reverse
□ Replay: Nur innerhalb autorisierten Scopes; zuerst unkritische Felder, dann sensible Operationen

Phase 4 — Ergebnisse

MÜSSEN erstellt werden:
- Nachrichtentypentabelle (name / opcode / felder)
- Mindestens 1 reproduzierbarer Dekodierungsbefehl oder Skript
- Evidenz: Original-Hex-Auszüge + dekodierte Ergebnisse (anonymisiert)

Werkzeugkette

Werkzeug	Erforderlich	Zweck	Bootstrap
tshark / Wireshark	Dringend empfohlen	PCAP-Analyse	Manuell / winget
Python3	Ja	Dekodierungsskripte	System
blackboxprotobuf	Optional	Unbekannte Protobufs	pip
ImHex / 010	Optional	Strukturvorlagen	Manuell
IDA / r2 / Ghidra	Nach Bedarf	Client-Serialisierungsfunktionen	Siehe entsprechenden Skill

Referenzen

• references/protocol-workflow.md — Frame-Layout und Protobuf-Spickzettel
• Verwandt: ../ida-reverse/ ../js-reverse/ ../firmware-pentest/ ../pentest-tools/

Routing-Kontext

Upstream: MASTER-ROUTING R21 · routing.md
Downstream: Bei Bedarf an Client-Algorithmen → ida-reverse/js-reverse; Bei Bedarf an Replay → pentest-tools/api-security
Gleichrangig: malware-analysis (C2-Protokolle), digital-forensics (Verkehrsforensik)

Aufgabenabschluss-Checkliste

• Wurde das Nachrichtenlayout oder der Zustandsautomat rekonstruiert (nicht nur Hex-Auszüge)?
• Gibt es reproduzierbare Dekodierungsbefehle?
• Wurde der Scope eingehalten / anonymisiert?
• Wurde das field-journal / der Bericht aktualisiert?