Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Security concerns: using wired MCP2515 instead of BT ELM327 possible? #267

Open
Inso42 opened this issue Dec 20, 2024 · 2 comments
Open
Assignees
Labels
question Further information is requested

Comments

@Inso42
Copy link

Inso42 commented Dec 20, 2024

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.

@Inso42 Inso42 added the question Further information is requested label Dec 20, 2024
@jimwhitelaw
Copy link
Collaborator

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.

That said, I think an easier route to accomplish your goal is to use this:
https://store.mrdiy.ca/p/esp32-can-bus-shield/

@PowerBroker2
Copy link
Owner

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

3 participants