Reverse-Engineering Powerline-Modem QCA7005

[Uwe (uhi)]

Hallo Reverse-Engineers :-)

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.

Fragen:

1. Wie könnte man rausbekommen, wie man aus dem komprimierten Image den 
ARM-Maschinencode entpacken kann? Interessanter Teil des Binaries liegt 
hier: 
https://github.com/uhi22/Ioniq28Investigations/blob/main/CCM_ChargeControlModule_PLC_CCS/QCA_Analysis/CCM_FlashDump_SpiFlash_Ioniq_compressed_part.bin 
und ein paar Ideen hier: 
https://github.com/uhi22/Ioniq28Investigations/blob/main/CCM_ChargeControlModule_PLC_CCS/QCA_Analysis/readme.md

2. JTAG mit unbekannter innerer Struktur, gibt's da "offensichtliche" 
Vorgehensweisen, oder hilft nur mit Glück und Geduld alles mögliche 
probieren?

[Irgend W. (Firma: egal) (irgendwer)]

Uwe schrieb:
> 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?

[Uwe (uhi)]

Der SPI-Flash hat 2 MByte. 
https://github.com/uhi22/Ioniq28Investigations/tree/main/CCM_ChargeControlModule_PLC_CCS#flash-memory-u4

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.

[Uwe (uhi)]

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.

[Peter W. (peterguy)]

Moin,

interessantes Vorhaben.

Uwe schrieb:
> 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:
1) SLAC um seinen Kommunikationspartner zu finden
2) SDP (im wesentlichen ein UDP/IPv6 Paket), um die Verbindung 
auszuhandeln
3) 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.

[Uwe (uhi)]

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.