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.