Marstek Venus D: Drei Controller, eine Registerkarte

Für die lokale Modbus-Anbindung der Venus D reicht es nicht, Register aus dem laufenden Gerät auszulesen. Das Repository Marstek-Venus-Firmware-Reverse-Engineering geht den umgekehrten Weg: Es zerlegt die Firmware-Images mit Ghidra. Das Ziel ist eine dokumentierte, cloud-freie Modbus-TCP-Schnittstelle für Home Assistant, mit Registerkarte, Skalierungsfaktoren und den Protokollen zwischen den Prozessoren.

Drei Prozessoren

In der Venus D arbeiten drei STM32-Controller (Cortex-M4F, FreeRTOS) zusammen:

• Control/EMS ist der Prozessor zur Außenwelt: Modbus TCP über WLAN (Quectel-Modul) und Ethernet (CH395), ein paralleler Modbus-RTU-Stack am externen RS485, BLE sowie der Weg zu Cloud und OTA.
• Micro-Inverter/VNS steuert den Wechselrichter.
• BMS überwacht die Zellen mit einem KA495XX-BMIC.

Verbunden sind sie über einen internen CAN-Bus und interne RS485-/UART-Strecken. „RS485“ meint dabei zwei verschiedene Dinge, was in der Dokumentation oft verwechselt wird: den externen Modbus-RTU-Stack (47400 Baud, FC03/FC06/FC10, dieselben Register wie bei Modbus TCP) und die internen Verbindungen zwischen den Controllern. Letztere – Control zu Micro-Inverter für Sollwerte und Modi, BMS-Master zu BMS-Slave-Packs für 96-Byte-Strukturen – sind ein proprietäres Strukturprotokoll und kein Modbus.

Die analysierten Images

Die Fingerabdrücke der Images im Überblick. Control wurde als 149.2, 150 und 147 untersucht, Micro/VNS als 116 und 115, das BMS als 118 und 117.7:

• Control 149.2: 385.024 Byte, 1618 von 1622 Funktionen benannt, Reset-Handler 0x08004A71.
• Micro/VNS 116: 115.712 Byte, 392 von 445 Funktionen benannt.
• BMS 118: 106.496 Byte, 550 von 550 Funktionen benannt.

Alle sechs Images laufen auf ARM Cortex-M4F (Thumb-2, little-endian) mit FreeRTOS (heap_4, ARM_CM4F-Port) und Flash-Basis 0x08000000. Aufgefallen ist, dass Micro/VNS 115 und 116 sowie BMS 117.7 und 118 jeweils exakt denselben Flash-Bereich belegen, obwohl sich die Funktionszahl unterscheidet – ein Hinweis auf eine feste OTA-Slot-Größe je Firmware-Typ.

Vorgehen

Eine bereits benannte Version dient als Vorlage: Beim Wechsel auf die nächste Firmware überträgt Ghidras Versionsvergleich Namen, Prototypen, Datentypen und Kommentare der gleichen Funktionen, danach werden die nur in der neuen Version vorhandenen Funktionen einzeln analysiert. So wurden BMS 118 und Control 147 aus der jeweils benachbarten Version abgeleitet und nicht neu von null aufgebaut. Methodik und Erfahrungen mit Ghidra stehen im Ordner Methodik_und_Meta/.

Registerkarte

Dieselbe Registerkarte ist über Modbus TCP (Port 502) und RS485-RTU erreichbar. Der Lese-Serializer wendet je Register Skalierungsfaktoren an; Lesezugriffe sind auf 32 Register pro Anfrage begrenzt. Die komplette Karte liegt als CSV mit Markdown-Notizen in Modbus_RS485_TCP/, zusammen mit Scan-Logs über Lade-, Entlade-, Backup- und DoD-Zustände. Für die Anbindung an Home Assistant sind sie der wichtigste Teil, ergänzt um die Strukturbeschreibungen in Control_FW/ und VNS_Micro_Inverter/.

Was nicht drinsteht

Gerätekennungen sind durch Platzhalter ersetzt. Firmware-Images und Dekompilat werden nicht verteilt. Beim Analysieren sind auch sicherheitsrelevante Dinge aufgefallen; die wurden per Responsible Disclosure gemeldet und stehen bewusst nicht im Repository, bis es eine Korrektur gibt. Verlinkt sind die Folgeprojekte: die Marstek Modbus Suite für Home Assistant und der Marstek Offline Endpoint, der auf einer Erkenntnis aus dieser Analyse beruht.