CCS communication sniffer

[mlotfi]

Hello everyone,

I am working on a project to make a module that can listen to all the packets between the EVSE and EV. I have seen the great work done in this project: https://github.com/uhi22/pyPLC and I am trying to overcome the limitations.

I am using a QCA7000 chip, and so far I have been successful in capturing the SLAC messages (however, I am still facing the 'side issue': a PEV can see the SLAC messages of a EVSE but not of another PEV, and vice versa). I activated the sniffer mode in QCA7000, but I am not getting any useful information from the beacon messages. So my questions are:

1. Anyone has any idea how to go from here so that we can work together on that project?
2. If anyone has one of the commerical CCS sniffers, can they take a picture of their electronics, or at least tell me which chip they are using?

I am open to your ideas. Thanks.

[uhi22]

Hi and welcome,

great to see you working in this direction.
Regarding the commercial sniffers, there is one answer here: viewtopic.php?p=66083#p66083, it would be interesting how these look like in detail, and whether there are other options.

If somebody likes signal processing, there is also an interesting approach using software defined radio, which was tested two years ago: https://www.goingelectric.de/forum/view ... 1#p1777211

Regarding the "sniffer mode" I was also hoping that it helps to get all packets, but I was not able to make it running, and I understood it maybe does not just route all data, but only some management information. Could you detail what you found out, how to enable it and what data it provides?

I'm still hoping that it should be possible to use the QCA7000 (or AR7420) for sniffing, because the packets are most likely received by the RF frontend and decoded, but then in the software just not forwarded to the ethernet/SPI port. So the "only" thing would be to convince the software to just forward everything. This *may* be possible if we find a configuration bit in the PIB. Maybe not. One other approach would be to patch the QCAs software, just removing the condition "if notInterested then discard". But this is a longer way to go, because even they say it is an ARM controller, the public software files and the content of the external firmware flash are not ARM code, seems to be compressed. Is there an idea how to extract the ARM code from the flash image? Another way could be the JTAG of the QCA, first baby steps are done, but finding out which scan chains are to be activated in which way is the hurdle. The (chaotic) investigation results are available here: https://github.com/uhi22/Ioniq28Investi ... A_Analysis

[mlotfi]

Hi and welcome,

great to see you working in this direction.
Regarding the commercial sniffers, there is one answer here: viewtopic.php?p=66083#p66083, it would be interesting how these look like in detail, and whether there are other options.

If somebody likes signal processing, there is also an interesting approach using software defined radio, which was tested two years ago: https://www.goingelectric.de/forum/view ... 1#p1777211

Regarding the "sniffer mode" I was also hoping that it helps to get all packets, but I was not able to make it running, and I understood it maybe does not just route all data, but only some management information. Could you detail what you found out, how to enable it and what data it provides?

I'm still hoping that it should be possible to use the QCA7000 (or AR7420) for sniffing, because the packets are most likely received by the RF frontend and decoded, but then in the software just not forwarded to the ethernet/SPI port. So the "only" thing would be to convince the software to just forward everything. This *may* be possible if we find a configuration bit in the PIB. Maybe not. One other approach would be to patch the QCAs software, just removing the condition "if notInterested then discard". But this is a longer way to go, because even they say it is an ARM controller, the public software files and the content of the external firmware flash are not ARM code, seems to be compressed. Is there an idea how to extract the ARM code from the flash image? Another way could be the JTAG of the QCA, first baby steps are done, but finding out which scan chains are to be activated in which way is the hurdle. The (chaotic) investigation results are available here: https://github.com/uhi22/Ioniq28Investi ... A_Analysis

Hey!

I am taking a look at the signal processing approach.

Regarding the sniffer mode, I use https://github.com/sogeti-esec-lab/HomePlugPWN to enable the sniffer mode (I made some minor changes to the code to be compatibly with python 3, will be happy to give you my version if needed). I attached an example of the packets I am getting (change the file extension from txt to pcapng to view it on wireshark). There is another sniffer mode, which is the one mentioned in the piboffset file (you talked about it in your project), but I could not go anywhere with that. I will take a look at the firmware manipulation approach and see how it goes.