You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I already bought a Vgate iCar Pro ELM327 device which I first planned to use. Chose this one because I do not want to connect the ELM by hand every trip, but just keep it plugged in.
This one is going to sleep automatically when the car is off for 30 minutes and is not draining off my battery - bit for sure, in the meantime it is accessible. Also when starting up, first device connected has access. The iCar does not have a pair button (and also this would be bypassable with some BT magic afaik) and the pin code is always default, so if someone really wants to have access and is focusing my car, it would be definitely possible.
Additionally, I had a longer talk about my project plans with one of the security specialists in our company.
He brought up some real good points concerning that the connection allows much more then just reading out basic parameters like car speed and gauge. In fact the ELM327 can be also accessed from outside the car for some real bad stuff.
Starting with triggering car functions (one of his examples: spamming/flooding CAN messages on some cars makes the car triggering the emergency break assistance).
Then, sending messages which flash and maybe break some stuff could be possible.
And also opening doors or deactivating closing mechanism by thieves or such stuff is not impossible.
A lot of what is possible depends on how it is implemented by the car manufacturer, and which security issues showed up later and are not fixed until now. It seems to be almost impossible to get an overview of the risks for the own car.
After this discussion I decided to better go the hard wired way, using an MCP2515 connected to an ESP32 directly. Here I can limit what can be sent to the CAN in which intervals. I can decide which devices are allowed to communicate with my ESP. And it also is off directly after the car is off.
I found some very low level libraries for using the MCP, but for sure this one is much more convenient to use :)
Is it possible to communicate by SPI to CAN instead of BL to ELM327? Or could you think of a place in the code where this could be added "easily", and give me a good place to start?
For those who are interested, here is what I found so far:
"MCP2515" (CAN to SPI) is cheap on Aliexpress (< 2€ each).
"30CM OBDII Dual Connector Y Splitter" cable cost me also ~2€. So I have one connector left for accessing if diagnostic access is needed, and the other I just cut to have direct access to the CAN pins. (For sure the ESP must not be powered when accessing the other connector :D )
I think what you’re wanting to do here is somewhat beyond the scope of what ELMduino is designed to do. While the lib and an ELM327 can be used to enable CAN communication, you’ll be writing a lot of custom code to make that happen. IMO, the main strength of ELMduino is providing an easy to use interface to the well known OBD2 PIDs and values.
The main communication with the adapter is done using the Arduino Serial API (BTSerial implements the same API). So to enable communication via SPI, perhaps look into creating a lib that also implements Serial and converts that to communication over SPI.
The ELM327 isn't a transparent interface for the car's CAN port or anything. The inputs to the ELM327 are scrubbed and also prevent you from spamming queries, so I'm not sure what all these concerns are about. That doesn't mean there are no vulnerabilities 100% confirmed, but I think by-and-large these security concerns are mostly paranoia
Hiho,
I already bought a Vgate iCar Pro ELM327 device which I first planned to use. Chose this one because I do not want to connect the ELM by hand every trip, but just keep it plugged in.
This one is going to sleep automatically when the car is off for 30 minutes and is not draining off my battery - bit for sure, in the meantime it is accessible. Also when starting up, first device connected has access. The iCar does not have a pair button (and also this would be bypassable with some BT magic afaik) and the pin code is always default, so if someone really wants to have access and is focusing my car, it would be definitely possible.
Additionally, I had a longer talk about my project plans with one of the security specialists in our company.
He brought up some real good points concerning that the connection allows much more then just reading out basic parameters like car speed and gauge. In fact the ELM327 can be also accessed from outside the car for some real bad stuff.
Starting with triggering car functions (one of his examples: spamming/flooding CAN messages on some cars makes the car triggering the emergency break assistance).
Then, sending messages which flash and maybe break some stuff could be possible.
And also opening doors or deactivating closing mechanism by thieves or such stuff is not impossible.
A lot of what is possible depends on how it is implemented by the car manufacturer, and which security issues showed up later and are not fixed until now. It seems to be almost impossible to get an overview of the risks for the own car.
After this discussion I decided to better go the hard wired way, using an MCP2515 connected to an ESP32 directly. Here I can limit what can be sent to the CAN in which intervals. I can decide which devices are allowed to communicate with my ESP. And it also is off directly after the car is off.
I found some very low level libraries for using the MCP, but for sure this one is much more convenient to use :)
Is it possible to communicate by SPI to CAN instead of BL to ELM327? Or could you think of a place in the code where this could be added "easily", and give me a good place to start?
For those who are interested, here is what I found so far:
The linked libs seem to be very powerful, but one has to puzzle his own CAN messages here and write an own interface to have readable code in the end.
The text was updated successfully, but these errors were encountered: