Reverse Engineering

Protokoll-RE: Alte Maschinen sprechen wieder

Februar 2026·12 min Lesezeit

Das häufigste Problem in Manufacturing & Automation: Die alte Maschine läuft — aber die neue Software kann nicht mit ihr sprechen. Der Hersteller der Steuerung existiert nicht mehr. Protokoll-Dokumentation: keine. Unsere Lösung: Wir lesen das Protokoll selbst.

Warum proprietäre Protokolle existieren

In den 1990ern und 2000ern entwickelte jeder Hersteller sein eigenes Kommunikationsprotokoll — oft als Schutzmaßnahme, um Lock-in zu erzeugen. RS-232, RS-485, CAN-Bus oder proprietäre Ethernet-Erweiterungen waren die Träger. Das Format: bekannt nur dem Hersteller.

Heute, 20–30 Jahre später, ist dieser Hersteller oft verschwunden, übernommen oder hat das Produkt eingestellt. Die Maschine läuft, aber sie ist stumm — sie spricht eine Sprache, die niemand mehr versteht.

Phase 1: Passive Traffic-Analyse

Bevor wir ein einziges Byte senden, hören wir zu. Passives Monitoring bedeutet: Wir klinken uns in die Kommunikationsleitung ein, ohne das Verhalten der Maschine zu beeinflussen.

# Typisches Setup für RS-232 Monitoring
Maschine ──RS-232── [Y-Kabel] ── USB-Serial Adapter ── Capture PC

# Gleichzeitig: Original-Terminal bleibt angeschlossen
Maschine ──RS-232── [Original Terminal] (normaler Betrieb)

Wir erfassen typisch 48–72 Stunden im realen Produktionsbetrieb. Warum so lang? Weil viele Muster nur bei bestimmten Ereignissen auftreten — Schichtwechsel, Werkzeugwechsel, Fehlerzustände, Produktionsstarts.

Phase 2: Musteranalyse & Protokoll-Rekonstruktion

Nach dem Capture beginnt die eigentliche Arbeit. Wir suchen nach:

Start/End-Sequenzen
Längenfeldern
Prüfsummen (CRC8/CRC16/XOR)
Befehlscodes (Opcodes)

Ein reales Beispiel: CNC-Protokoll dekodieren

Im Fallbeispiel MFG-001 fanden wir nach 3 Tagen Analyse folgendes Frame-Format:

# Dekodiertes Frame-Format (22 Bytes)
0x00 SOH (0x01)         — Start Of Header, immer konstant
0x01 CMD                — Befehlstyp (0x10=Status, 0x20=Move, 0x30=Stop …)
0x02 SEQ                — Sequenznummer (1 Byte, rollt über)
0x03 LEN                — Payload-Länge in Bytes
0x04 PAYLOAD[LEN]       — Nutzdaten (variabel)
N-2  CRC16_HI           — CRC16/MODBUS High Byte
N-1  CRC16_LO           — CRC16/MODBUS Low Byte
N    EOT (0x04)         — End Of Transmission

Das Timing war kritisch: Die Steuerung erwartete eine Antwort innerhalb von 50 ms. Überschreitung führte zu einem Timeout-Fehler und Reset der Verbindung. Dieses Timing-Requirement war nur durch dynamische Messung — nicht aus statischer Analyse — zu ermitteln.

Phase 3: Die Custom Protocol Bridge

Mit dem vollständig dokumentierten Protokoll implementieren wir einen Parser in Node.js. Wichtige Design-Entscheidungen:

Fehlertoleranz first: Frames verwerfen, weiter scannen, nie abstürzen.
Vollständiges Logging: dekodiert + Raw-Hex.
Automatischer Reconnect: State sauber resetten.

Was schief gehen kann — und wie wir es vermeiden

Protokoll-Varianten: mehrere Firmware-Versionen capturen.
Undokumentierte Sonderzustände: Fehler-/Wartungsfälle systematisch auslösen.
Timing-Abhängigkeiten: mit Oszilloskop messen, nicht nur Software-Capture.
Polling vs. Event: Kommunikationsmodell früh klären.

Fazit

In unserer Erfahrung lassen sich über 90 % der proprietären industriellen Protokolle innerhalb von 1–2 Wochen vollständig dokumentieren. Das Ergebnis: Eine Maschine, die seit 20 Jahren stumm war, spricht plötzlich wieder — mit Ihrer modernen Software, in Echtzeit, zu einem Bruchteil der Kosten einer neuen Anlage.