My biggest problem while diving into CAN-Bus communication was, that it is nearly impossible to send IDs with own data, which are also sent by the regulary device in the car. The CAN-IDs will “mix” in time and it is up to the receiver if which, or if any, data he processes. I had more succeess in senden an ID twice or more often than the forgein device would do. E.g. if the BCM is sending ID 433 every 250ms, i send this ID also with my own data every 100 oder 50ms. This way it’s more likely for the receiver to use my data, than the original one. But this only works for some hardened IDs because receivers go into error-state when too many too different data arrives.
The only solution i see here for now, is to bring a gateway-device into the CAN-wire right in front of the module to attack. This way my software can decide which IDs pass the gateway will unmangeled data and which i want to manipulate.
But this means much work and also harm the wireing of the car.
Yes, exactly. You have two choices (both of which you mentioned):
-
You can trigger your own data when you see that the original device sent a message you wish to override. Sometimes this will cause the receiving device to use your data instead of the original data.
-
You can cut the CAN lines and put a device in the middle. Then you filter out and do not send the original message you want to replace. Every time you receive that message you transmit your own in its place.
Thems the options. Unfortunately there really isn’t much else you can do.
Thank you Collin!
I think option 1. is very unlikely to work and i also tried this. What’s happening here is, that if the rouge CAN-device is really fast, the bits overlap while transmission and so the message is jammed and discarded, because of bitstuffing or CRC error.
The only attacking vector here i see, is to do this every time a speciall ID is seen on the bus and fortunately bring the senders errorcounter up to a state where it shuts down the communication. But this is a bus-task, not per ID, so the device will not send ANY messages. In this case the bus is free to send own messages, but also it’s unlikely to have the desired result.
I’m currently working on option 2. but the problem here is the physical impact on the car wiring harness and, non the less to achieve physical access to the device connector.
I guess the best way to let a device do a “custom action” is to reverse-engineer the diagnostic actuator code for the action required. There would be many, if not any actions a CAN device can do, or sensor values it can provide as testprocedures for car repairs and manufacture testing. Also its very hard to get these codes. Some of them are public because they are often used or even standards (like particle filter regeneration and such)
If you have access to a factory manual for the car they generally show all connections for the devices, Or you can try tracing the wires back to a splice if you don’t have direct access to the module. In later model GM vehicles I have seen where they actually have a specific location for easy diagnostics of each module which allows you to easily tap into any module you want to.
If you want to split out a module you can remove the pin(s) for the related module in the splice and build your own bridge for this. The pins are easy to get although you normally end up having to order a few of them at a time. It does require finding out what pin the factory uses but if you have a shop manual this is easy to find then you just have to find a source for the pins. Most dealers WILL have a source for the pins if you find what ones you need but they can also be sourced online. I have factory manuals for GM vehicles 1996-2009 and have added features to vehicles such as fog lights by adding pins and such that my vehicle didn’t have in a connector.
I plan to use this method myself when I want to isolate a module to test it.
I’ve build a filtering/gateway device myself for this task. It’s very handy to know which CAN-ID is produced by which device. Also you can find out which IDs the device consumes by removing them one by one until the devices fails or lacks some functions.
But gaining physical access in front of the modules is a big task and requires to disassemble great parts of your vehicle. This is not everybodys thing to do…
For me, i’ve bought some modules i’m interessed in from a scrapyard or on ebay. Like a parking-aid-module, a door-module, aircondition module and such. I’ve also lucky to get a body control module for little money. This is somewhat like the central computer of the car. I was able to power it up and communicate with it by OBD-II. And if there is only the BCM on the CAN, all messages i see on CANhacker can only be from this module 
Yes but for anyone that has access to a factory manual it can be worth trying to see if there is a test port for the modules. I don’t recall what vehicle I was looking up but there was a jumper box where a majority of modules had their data connections go through. Was a sort of jumper box of some sort. Was intended to be a diagnostic port to test/program any of the associated modules by separating them out of the loop. With the factory manuals in hand it takes just a short time to identify if the vehicle your working on had such a port.
Wish I could remember what car I saw it on. I didn’t think much about it at the time but now makes more sense. If the car your working on doesn’t have such a diagnostic hub then there are a variety of ways to do it. Buying the modules is not a bad plan either. You can do like I did and purchase rights to a vehicle about to be towed to a junk yard and remove the modules with some wire harness to tinker with. Might be cheaper than buying each module and designing your own harness.
I paid $200 and grabbed every easy to grab module out of a 2002 Chevy S10 type Blazer. Will likely start with the Cluster and BCM and work forward from there. I got the keyless entry module, the VCIM module and like 4 other modules. Haven’t touched it since I bought this Chinese simulator and the fact I have been trying to get my truck back on the road… Far too much time tied into that trying to find a stupid coolant leak… Anyhow…
Rodney