You can get away with ELM327 based readers (the cheap bluetooth/Wi-Fi OBDII readers you see on Amazon/eBay) if you want fairly standard data like speed, and some manufacturer specific data in the form of PIDs (https://en.wikipedia.org/wiki/OBD-II_PIDs)

If you want more involved data, or to send messages, it's mostly sniffing, doing an action, and seeing what changes.

`can-utils` has a nice UI for this, which lets you filter messages that don't change easily.

(Also, I've actually never seen a `.dbc` file before, but it looks like a map of PIDs, usually you [or the community for your car] have to reverse engineer those with the sniffing method, afaik)

-

The ELM327 can technically stream all the CAN messages on the bus and do that type of sniffing, but it has a very small buffer and gets completely hosed with chatty cars.

I personally use the MCP2515 with a Raspberry PI for more involved car hacking.

https://www.raspberrypi.org/forums/viewtopic.php?t=141052

The electrical modification mentioned is needed for the most common MCP2515 modules because the PI isn't 5v tolerant, but it's an easy enough fix

I have two of them hooked up to a Raspberry PI (one for each of my car's CAN busses, some cars have more), and that with `can-utils` has gotten me pretty far.

People should be aware that many of the cheapo "ELM327" readers on Amazon/eBay are counterfeit chips that merely identify themselves as ELM327. They do not perform as well as the real chip, but may be good enough for reading your check-engine code. For example, I had a fake one that choked if I tried querying engine RPM in a loop, while the real deal had no issues.

I've had success with clone ELM327 for reading stuff like RPM in real time, but it is hit or miss.

They're just generally slower and usually missing features of the newest ELM327 revisions.

The problem is if you just search for ELM327, most of them will be clones, so I just use the MCP2515 when I need lots of data, and use the ELM327 for basic stuff

If it's in the budget, I would highly recommend the Macchina M2[1], especially if you need to access more than one bus at a time. It's based on the Arduino Due, with dual CAN transceivers (and LIN). It has a lot of bells and whistles - but can be simplified down to just a can sniffer if needed. I'm currently using one with SavvyCan to reverse engineer a vehicle for a project, and it has no problem keeping up with the high-speed network.

[1]https://www.macchina.cc/m2-introduction

The car doesn't define its own interface, so you're stuck using the Internet.

Overall the easiest place to start is a forum for your specific vehicle. You may get lucky with predefined services or someone else having done the reverse engineering for you.

If you don't get lucky, it depends on the manufacturer. In the case of European manufacturers you are best off if you can acquire the ASAM ODX material for your vehicle (sadly there is not an easy "clear market" way to do this - reverse engineering the manufacturer's diagnostic tool is often easiest). This will define in a very complete manner the available services on your vehicle. Some aspects will still be proprietary, usually specified as DLL files referenced in the ODX (for example, the Seed/Key authentication algorithm for flashing VW vehicles). These you will have to find references to on forums or reverse engineer yourself.

I don't think you can pull a DBC file off of a vehicle. I think you have to build the DBC file yourself by reverse engineering everything--you'd monitor the CAN network, and then turn the light on and off, sit in the driver set, etc. The DBC file is the car's secret sauce.

There's also at least one repo [1] of DBC files that have already been reverse-engineered by the community

[1] https://github.com/commaai/opendbc