das Thema Revers-Engineering klappt hier im Forum gar nicht so schlecht (z.B. hier: Beitrag "AL4 TCU Reverse Engineering"), daher versuch ich mal, mit einem Projekt weiterzukommen, was schon einige Zeit vor sich hin dümpelt.
Hintergrund: Die Kommunikation zwischen Fahrzeug und Ladesäule beim CCS-Laden geht über Powerline-Kommunikation (PLC). Zur Analyse, was da kommuniziert wird, wäre ein Sniffer ganz hilfreich. Aktuell scheint es keine Open-Source-Methode dazu zu geben.
Ein Ansatz ist, einen Modem-Chip (QCA7005) so zu modifizieren, dass er alle Datenpakete einfach weitergibt, anstatt sie zu verwerfen. Mit der "normalen" Software ist er zu intelligent, er gibt nur Broadcasts weiter, aber nicht die Pakete, die zwischen anderen Teilnehmern ausgetauscht werden. Also leider zum Sniffen nicht geeignet.
Verschiedene Ansätze sind denkbar, das zu verbessern. Kommerzielle Geräte gibt es, aber teuer. Firmware des QCA debuggen über JTAG mag möglich sein, aber wie genau der Zugriff funktioniert, ist noch nicht klar. Das Firmware-Image, was im externen Flash liegt, ist komprimiert, also leider nicht spontan zu disassemblieren.
Das Firmware-Image, was im externen Flash liegt, ist komprimiert
Bist du dir sicher?
Wenn dem so ist, dann müsste es irgendwo noch was geben, was das Entpacken übernimmt und genügend RAM um den entpackten Code zu speichern, damit er ausgeführt werden kann?
AM29F200BB = 128 K x 16-Bit, wie hast du es eigentlich geschafft daraus ein 307.544 Bytes großes Binary auszulesen? Die müsste doch eigentlich genau 256k groß sein?
Der 300K-Programmblock ist dort zweimal drin, vermutlich aus Redundanzgründen, und noch andere kleinere Blöcke.
Ja, der QCA enthält einen Bootloader, der die Applikation entweder vom Host oder vom SPI-Flash abholt. Wenn er keine bekommt, also SPI-Flash nicht vorhanden, meldet er Softwareversion "Bootloader". Ja, der QCA hat offenbar eine Menge RAM, damit das alles funktioniert. Das Datenblatt ist hier verlinkt https://openinverter.org/forum/viewtopic.php?t=3727 , allerdings ist das nicht sehr ausführlich. Mit NDA gäbe es mehr Details, aber NDA und opensource passt nicht zusammen.
Es gibt spannende Neuigkeiten, daher fasse ich für Mitleser und potentielle zukünftige Mit-Forscher kurz den aktuellen Stand zusammen.
Die Nutzung der JTAG-Schnittstelle zum Auslesen vom internen Speicher ist einem Forenmitglied gelungen. Es ist verstanden, mit welcher Kompressionsmethode das Firmware-Image komprimiert ist. Ein paar Leute von der Uni Oxford haben auf der Defcon berichtet, wie sie die Konfiguration des Modems über die Powerline-Kommunikation verändern können, haben den Startup-Vorgang mit den verschiedenen Stufen verstanden und als Demo, was man so anstellen kann, DOOM als Applikation auf dem QCA laufen lassen. Link zum Video und Diskussion der Konsequenzen hier: https://openinverter.org/forum/viewtopic.php?p=86171#p86171
Respekt und Danke an alle Mitwirkenden :-)
PS: Wenn das alles etwas oberflächlich und "geheimnisvoll" klingt, liegt das daran, dass nicht klar ist, wieviel Details man veröffentlichen darf/kann/will. Das Thema ist etwas heikel, da sowohl Qualcomm als auch Hersteller und Betreiber von Ladeinfrastruktur und Fahrzeugen leichte Schweißausbrüche bekommen könnten.
Ein paar Leute
von der Uni Oxford haben auf der Defcon berichtet, wie sie die
Konfiguration des Modems über die Powerline-Kommunikation verändern
können, haben den Startup-Vorgang mit den verschiedenen Stufen
verstanden
Damit seid ihr wahrscheinlich an den Grenzen des Machbaren angekommen. Wenn ihr zerstörerisch veranlagt seid könnt ihr die QCA Module von außen so umkonfigurieren dass sie nicht mehr verwendet werden können. Aber ich glaube nicht dass eine reelle Chance besteht an brisante Daten heran zu kommen.
Es ist schon ein paar Jahre her dass ich tief im Thema war, ist die Kommunikation nach dem Startupvorgang nicht TLS verschlüsselt?
Das war doch so in etwa:
SLAC um seinen Kommunikationspartner zu finden
SDP (im wesentlichen ein UDP/IPv6 Paket), um die Verbindung auszuhandeln
Die eigentliche, TLS verschlüsselte, Kommunikation über TCP/IPv6
Also selbst wenn du die Pakete absniffst kannst du mit den Daten nichts anfangen. Der vielversprechendste Ansatz wäre ein Man-in-the-Middle Sniffer. Aber auch da musst du irgendwie an die Zertifikate der Teilnehmer kommen um die TLS Verbindungen zu beiden Seiten hin auf zu bauen.
Ja, die Kommunikation kann TLS-verschlüsselt sein, aber das ist optional. Im Feld gibt es eine Menge Autos, die unverschlüsselt kommunizieren, meins inklusive (Modelljahr 2016). Ich persönlich seh im mitschneiden der Kommunikation nicht wirklich eine Gefahr. Dass das Autocharge gefährdet ist durch geklonte MAC-Adressen, ist schon eine Weile bekannt und offenbar trotzdem wenig lukrativ für Betrüger.
Der spannende Anwendungsfall für nicht-Kriminelle ist die Anzeige der Ladekommunikation, um zu verstehen, woher eine Leistungsbeschränkung kommt (Säule oder Auto), und warum es Abbrüche oder Fehlstarts gibt.
Es ist vollbracht. Danke an alle die vor und hinter den Kulissen mitgewirkt haben.
Wie ging das jetzt, und warum nicht vor fünf Jahren? Mit Ghidra zu decompilieren geht, ist aber recht mühsam bei ein paar hundert Kilobyte Multitask-Betriebssystem. Es wurde einige Zeit darin vergraben, viel verstanden, die entscheidenden Stellen nicht gefunden, und Patches auf Assemblerebene machen händisch nicht viel Spaß. Dann kam Claude, genauer Claude Code in VSCode, und wenn man dem Zugriff auf alles nötige (openOCD am JTAG, Flashen des SPI-Flashs mit flashrom, Spannungsversorgung, Status-LEDs, PLC-Knoten für Ladestations- und Autoseite) gibt, und ein paar Fragen stellt, beißt er sich rein, erklärt den Code, macht Vorschläge für Patches, baut die ein, flasht sie, testet sie, und das ganze wird im Dialog verfeinert. Die Hauptarbeit war dann in einer Woche erledigt, wobei Claude teils 15-Stunden-Schichten arbeitete, während Mensch nur ab und zu mal ein paar Hinweise, Fragen, Korrekturen beisteuerte. Absoluter Wahnsinn was da geht, und für 20 Euro im Monat ein Schnäppchen. Schöne neue Welt.
Interessanter Beitrag, auch wenn ich keinen blassen Schimmer von der Thematik habe. Weiß zwar, dass zwischen Fahrzeug und Ladesäule PLC stattfindet. Aber nicht, dass da so ein Geheimnis draus gemacht wird.
Gibt es im Protokoll keine offenen Standards?
Ist es quasi unmöglich mit "Boardmitteln" einen CSS zum Laufen zu bekommen?
Gut, da kann einiges bei schief gehen.
Aber die Kommunikation für einen Typ-2 ist doch vergleichsweise simpel, oder?
Gibt es im Protokoll keine offenen Standards?
Ist es quasi unmöglich mit "Boardmitteln" einen CSS zum Laufen zu
bekommen?
Das kommt auf die Boardmittel an. Es hat fast 5 Jahre gedauert von meinen ersten Gehversuchen (https://www.goingelectric.de/forum/viewtopic.php?t=74226), über mehrere spannende Open-Source-Projekt mit etlichen Mitstreitern (z.B. https://openinverter.org/forum/viewtopic.php?t=2262), bis neulich das letzte fehlende Puzzleteilchen passte. Es ist deutlich komplexer als eine handvoll Seiten Spezifikation wie beim Typ2-Laden. Die DIN70121 und ggf. ISO15118 (mehrere Bände) kann man zwar kaufen, aber dort ist nicht beschrieben, was das Powerline-Modem intern so macht und wie man das ändert. Dazu müsste man mit dem Hersteller eine Geheimhaltungsvereinbarung (NDA) ausmachen, passt aber schlecht zu dem Gedanken einer offenen Lösung. Die "Boardmittel", wenn man das proprietäre Modem umgehen will, wären ein breitbandiges (2 bis 30 MHz) software-defined-radio, viel Wissen um Signalverarbeitung in Echtzeit, den Homeplug-GP-Standard umsetzen, dann noch IPv6, EXI-Decoder, und noch Kleinigkeiten dazwischen.
Was ist die Frage? Wie teuer die Vereinbarung war? Null Euro, wir haben keine abgeschlossen. Die ISO-Norm? Schwer zu sagen, ich weiß nicht wer von den Mitstreitern wieviele gekauft hat, aber schätzungsweise leicht vierstellig dürfte der Verlag verdient haben.
Die einen möchten gern im Alltag wissen, warum "das heute so langsam läd, liegt's an der Säule oder am Auto?". Die Info hat zwar sowohl die Säule als auch das Auto, aber die Hersteller wollen oft den Nutzer nicht mit Details überfordern. Daher ist eine Anzeige für die "Nerds" die eine Motivation.
Und dann gibt's ja die, die Autos selber auf- und umbauen auf elektrisch, die wollen auch CCS laden, und dafür ist eine Lösung bei der man volle Kontrolle hat nützlich. Genau so für die, die das Auto zuhause an den Hybridwechselrichter anschließen und damit als Heimspeicher verwenden.
Und über Jahre durchgehalten. Neben dem akademischen Interesse, was
treibt einem an da rein zu gehen?
Ist ja potentiell hoch riskant, in die CSS-Ladung einzugreifen.
Es könnte die Möglichkeit geben, für Besitzer eines Hochvolt-Hausakkus einerseits das Auto DC aus dem Akku zu laden oder andererseits den Hausakku DC aus dem Autoakku aufzuladen, geregelt nach Belastbarkeit und PV Ertrag.
Aber traut sich schon zu, selbst die CSS-Ladung in die Hand zu nehmen?
Da braucht man nochmal Jahre, Kompetenzen sammeln in
Leistungs-Elektronik?!
Auf Auto Seite nicht, denn das Ladegerät mit aller Leistungselektronik ist bei CCS die Ladesäule. Die Batterie des Autos hängt dann quasi direkt an den beiden großen Pins im Stecker.
Es gibt ja auch diese CCS Discharger. Die gaukeln dem Auto eine Ladesession vor, das HV Schütz schaltet den Akku auf die CCS Kontakte und man kann die 400V nutzen.
Sowas hätte ich gerne für den Fall eines Stromausfalls.
Ich weiß aber nicht ob der Astra Electric da mit spielt, das klappt wohl nicht bei allen Autos.
