In order to start, you need to determine the type of communication running on the CAN BUS. You’ll often want to identify a certain signal or the way a certain component talks—for example, now the car unlocks or how the drivetrain works. In order to do so, locate the bus those target components use, and then reverse engineer, analysis the packets traveling on that CAN BUS to identify their purpose and get information from them.
To monitor the activity on your CAN, you need a device that can monitor and generate CAN packets, such as the ones that you already learned in previous blogs.
There are a ton of these devices and application on the market. The cheap OBD-II devices that sell for under $20 technically work, but their sniffers are slow and will miss a lot of packets and information about our car. It’s always best to have a device that’s as open as possible because it’ll work with the majority of software tools—open source hardware and software is ideal. However, a proprietary device specifically designed to sniff CAN should still work. We’ll look at using “candump”, from the can-utils suite, and Wireshark to capture and filter the packets these two tools will work together like butter 🙂 .
Generic and over standardized packet analysis won’t work for CAN because CAN packets are unique to each vehicle’s make and model. Also, because there’s so much noise on the CAN, it’s too cumbersome to sort through every packet as it flows by in sequence.
Wireshark is a common network monitoring analysis tool. If your background is in networking, your first instinct may be to use Wireshark to look at CAN packets because Wireshark is open source and User friendly interface can help you on this. What you’ve learned in this blog technically works, but we will soon see why Wireshark is not the best tool for the job.
If you want to use Wireshark to capture CAN packets, you can do so together with SocketCAN. Wireshark can listen on both canX and vcanX devices, but not on slcanX because serial-link devices are not true netlink devices and they need a translation daemon in order for them to work. If you need to use a slcanX device with Wireshark, try changing the name from slcanX to canX.
If renaming the interface doesn’t work or you simply need to move
CAN packets from an interface that Wireshark can’t read to one it can, you
can bridge the two interfaces. You’ll need to use candump from the can-utils
package in bridge mode to send packets from slcan0 to vcan0.
