CAN bus "hacking": what methods?

Hello,

'I've recently started exploring this topic. Now that I have a somewhat clear understanding of the functionality and hardware, I'm wondering how to associate the various sensors, actuators, or events with the large amount of data being generated.'

Einfach irgendwas drücken und schauen was sich im Datenstrom verändert ist nicht, dafür kommt da viel zu viel auch ohne das ich etwas betätige. Wie Okay, let's start?

Are there any universally valid CAN IDs that every manufacturer uses, or is it really completely arbitrary and distributed differently by each manufacturer?

What relationships exist between ID, period, and count? Can anything be derived from this? Do low IDs inherently relate to PCM or ABS systems, while high IDs relate to comfort systems? Can we say that everything with a repetition rate above 500ms is likely related to comfort systems? Have we typically used challenge/response mechanisms or recurring IDs when a function is active?

I've gathered a few IDs from online sources. It seems that within Ford, the same IDs are also used for the same functions across different models and production years.

As I mentioned, I'm just starting out. For testing equipment, I have a SL-CAN compatible transceiver with a PC connection via USB. Using a switch, I can connect it to any of the three vehicle CAN buses as needed. In my vehicle, the CAN buses are directly connected to the OBD interface; there is no gateway module in between that filters anything.


P.S.: There's a lot of information about Volkswagen vehicles in this forum. Am I completely out of place here with my Ford Mondeo?

Hi,

Even though you might not like my answer: Trigger events, then observe changes, and derive signals from those observations – that's how it works.

It's not always easy, of course. Inside the car, it works quite well; I trigger the window lifter myself and can then deduce the location of the signal on the bus based on the timing.

Often, the 'protein computer' (brain) helps find a solution. When dealing with multiple window lifters, I ask myself: 'How would I have implemented this?'. Then, I come up with the idea of allocating one byte for 4 window lifters. The upper nibble represents raising the window, and the lower nibble represents lowering the window. This is just an example; it might be reversed, but first, I'll look for corresponding correlations.
Then there are the comfort functions, such as fully raising or lowering the window. I would represent these using a different byte within the same message, just like the current raise/lower function.

With this approach, you can achieve a lot very quickly; creating the interior of my design took me less than 30 minutes (assuming you're using powerful software).

Auf dem Antriebs-CAN wird es eckig, da man da die Ergeignisse nicht komplett steuern kann. Wie willst Du z.B. das Signal 'Schalteingriff unterbinden' des ESP auslösen? Eben, gezielt mal gar nicht. Auch Zündwinkel oder Einspritzmenge lassen sich gezielt nicht ohne weiteres Ansteuern. Bei letztgenannten Fällen hilft es, sich die entsprechenden Informationen zu besorgen, sprich, die entspr. Kennfelder auszulesen, und zu skalieren. Dazu kann man Testfahrten mit entsprechendem Mess-Equipment durchführen oder den Code der Anlage disassemblieren und verstehen. The latter is something that stingy guys like me do...

There are no overarching messages that apply across all manufacturers; each company operates independently. Of course, corporations often consolidate their brands again.
Within a manufacturer or corporation, there are often patterns that are followed. These patterns change from time to time for the interior, but they are much more stable for the powertrain – especially if the manufacturer is proficient with CAN bus technology and knows how to use it effectively, particularly regarding backward compatibility. Without mentioning any names, I don't know anything about these aspects of (even the popular) mass-market manufacturers.

Best regards,
candev

Okay, thanks! I'm looking for approaches similar to the example with the power window. I'm only interested in comfort functions; I want to stay away from anything related to the engine and its CAN bus system.

Since the CAN bus is message-oriented, you don't know which control module the messages on the bus are coming from. This information would be very helpful and allow you to focus your attention.

Unfortunately, it seems that enthusiasts working with CAN systems in Volkswagen Group models have access to significantly more publicly available information than those working with Ford vehicles.

I'm still having trouble implementing a system to check for changes in the bus configuration because, in my opinion, too much is changing constantly. I can't make sense of it. Sometimes there are hundreds of IDs active, even when I'm not doing anything. I can't even display them all on one screen.

I do have one approach: I have a navigation radio (MCA) here for testing. When I start it, I receive a lot of information on the bus from the radio itself, since there are no other participants. Although I don't know the meaning of the messages, I can clearly assign these IDs to the radio . I've attached an example of such an empty trace (Radio-Labor trace).

Then I checked the same bus using a car interface to find possible answers to the messages. As actions that could trigger these messages, I can imagine: registering the radio on the GEM/IPC, sending the current operating mode (radio, CD, USB) to the IPC, and querying the steering wheel remote control. This is included in another trace file.

I'm not yet sure how I should document my results. I haven't found a free CAN database editor yet. However, I think it would be useful to store the results in a structured way so that filters or program routines can be derived from them later. I am currently using software such as can tool, which allows you to filter out known signals and get an approximation of the data.
So, if you need only half an hour to do a complete CAN hack, I'd like to invite you for coffee sometime }.

Hi,

Back then, I couldn't find a free CANdb editor either, which is why I implemented my own.

As I mentioned, creativity is helpful when it comes to identifying signals. It's important to always be aware that any omission or addition of bus participants can lead to changes in the trace, which may not only result from the absence or presence of messages originating directly from the respective control units.

Beginners often think in terms of a mapping of functions to control units, meaning that 'n' functions are located within a single control unit. In practice, it is often the other way around: for example, a function may be distributed across multiple control units (e.g., power management, ESP intervention). This means that if one control unit fails, certain functions can be disabled, which in turn can cause messages from other control units to be missing or altered.
Certainly, a solid understanding of programming, as well as the conceptual design of control units and the software architecture, is very helpful.

Mit Ford hast Du hier natürlich weniger Freude als mit den verbreiteteren und damit auch häufiger untersuchten VAG-Fahrzeugen. Dafür dreht sich jenseits des Teichs die Lage um. Dort bin ich vor 20 Jahren sehr umfassend von den jeweiligen Entwicklern selbst unterstützt worden. Einfach mal nach passenden Mailing-Lists suchen - das WWW ist nur für Leute, die der Tastaturbedienung nicht mächtig sind.

Best regards,
candev

PS: My internal CAN bus is simpler than yours; I estimate it's around 30%.

I understand the principles of CAN quite well. Since I'm not a complete beginner when it comes to electronics and programming, I can also imagine quite a bit. However, according to your thesis, one could only truly understand a bus if they had already designed one themselves. Isn't that a classic 'chicken or egg' problem?

I understand that the learning curve is steep, but everyone has to start somewhere. I'm going to try to continue your approach using a logical method. Let me know if I'm on the right track!

I am looking for the message containing the current motor speed.
Here's the translation:

'It is very likely that such a message will appear, as the engine speed serves as a key indicator for many functions in the vehicle. At least the instrument cluster uses it for display purposes.'
The speed is determined by a timing sensor located somewhere on the crankshaft. Typically, this sensor is inductive and uses a gear to generate multiple pulses per revolution. The frequency of these pulses directly corresponds to the speed.
These impulses are sent to a motor control unit (ECU), which processes them and, together with internal timing information, calculates a speed value. This value is likely unsigned and an integer. The module then generates a CAN message on the engine bus based on this value.
The message is transmitted, possibly via a gateway, to the instrument cluster and is then converted into an analog voltage for the tachometer.

To find the message, I would need to know what data I am looking for. The speed range of an internal combustion engine is likely between 0 - 8000 RPM, while motorcycles can reach up to 14,000 RPM. These values can easily be represented using 2 bytes and even have some headroom. Negative speeds do not exist, and decimal values are also unlikely to be relevant within this range.

The engine speed is regulated, so it always stays within certain limits. I'm looking for a value that changes relatively easily. In idle, the instrument cluster shows approximately 900 RPM, which corresponds to '03 84' in hexadecimal. Due to the regulation, the desired value should be between 700 and 1000 RPM, which translates to '02 BC' and '03 E8' in hexadecimal.

'So, instead of searching by IDs, I would need to search based on these data points. If I find something that seems promising, I would need to monitor the relevant messages and, for example, change the speed to verify the result. This is all assuming that there isn't a different encoding for the speed or an offset applied.'

Assuming all of this makes sense, my logic is as follows: The smaller the data value I'm looking for, the harder it is to find; conversely, the larger the value, the easier it is. This is simply because a single changing bit occurs more frequently than a combination of 10 or 12 bits. Therefore, when hacking, one should start with the values that appear to be the largest and work their way down to the control signals.

"Hmm, unfortunately, the numbers aren't always directly provided but may need to be multiplied by a value 'x'. However, you might be able to identify a common divisor in those cases, especially if you can see the desired value displayed somewhere. For example, in my case, it was the kilometers since the last diesel particulate filter cleaning. The value would always jump up by 5 km (as seen in OPCOM, an Opel diagnostic tool), so it was also divided by 5 when transmitted over CAN."
In the worst case, even parts of a byte could result in a value. For example, this happened to me when transmitting date/time information to the OEM display (see here).

While I mostly work in the marine sector, it's very similar there.
In many cases, the datasets are even present multiple times, as there are often several engines installed (instances).

You can also easily map the changing values to that area.

I am always looking for values that are 1, 2, or 4 bytes in size. However, in the marine industry, these values are always represented as positive numbers and are also multiplied.

A temperature is transported by bus multiplied by 100, so it's always positive and accurate to two decimal places.

And as Candev already mentioned, the type of datasets that are sent by participants depends on the equipment they have available.

Very interesting!

It makes sense to increase decimal values by powers of ten in order to obtain a virtual floating-point number. For each digit after the decimal point, you multiply by 10.

It's also helpful to search for temperature values. There's an external sensor somewhere. And while the outside temperature can be easily determined yourself, it's often displayed digitally depending on the vehicle. If the temperature is transmitted in Kelvin, which is almost logical given the Anglo-Saxon origin of such systems, then the value has an offset of 273.5 compared to the temperature in Celsius.

I'm really impressed by the analytical minds of the people here. I still have a long way to go to reach that level...

I have learned that large measured values displayed digitally are easier to determine. Sometimes, there are unknown offsets due to decimal shifts or reference points. It is important to perform controlled measurement sequences in which known target values can be determined at equal time intervals. Again, the question arises: How would I transmit these values?

I'm now going to try and access the outside temperature and/or the engine oil temperature.

Okay, I've converted the data as described above into decimal values (byte value / 100) and put everything into an Excel table. The time interval between each message is a constant 100 milliseconds.

He created a diagram from it, and ACTUALLY, it's my driving profile!