🤦🏽 🗺️ 👩🏽‍🔧 Decryption of data in the CAN bus VW Polo sedan ⬛️ 🍹 👨🏻‍🎤

Today we will talk about methods for decrypting CAN bus data using the example of a 2019 VW Polo Sedan car. On the Internet, such articles are often called CAN Bus Hacks, but I don’t like this name.

The article describes the methods of finding the necessary data in the CAN bus of the car, examples of the application of these techniques on the VW Polo Sedan. Vega MTX is used as equipment for connecting to a CAN bus. Let's talk a little more about telematics. Under the cut a lot of pictures on the topic, several gifs and videos.

A few words about yourself.

My name is Alexey Fokin, at the moment I work for Vega Absolutevega_absolute. The central office in Novosibirsk, but I work in Moscow. One of our directions is telematics. We make equipment for tracking commercial vehicles, car sharing, taxis, etc. My job is that I collect data from cars and turn them into settings for our equipment.

Now to the car.

Connection to the CAN bus was made in two places: behind the dashboard (500 Kbit / s bus) and behind the radio (100 Kbit / s). There is also one redundant connection - connecting to the OBDII connector directly on the connector (500 Kbit / s).

From the tools used: Vega MTX vehicle monitoring unit equipped with a CAN scanner. To configure it on a PC, the Configurator 1.27.14 program.

More information about connecting to a car and MTX can be found in the video at the end of the article.

When connected to all CAN buses, we will see the following picture:

In this data stream, you need to find those bits and bytes that are responsible for the parameters we need.

The screenshot below shows how many sensors are currently registered in the telematics block, and this is not a complete list. You can go even deeper and look for even more sensors. Some of these sensors in real time sends readings to the server, which allows you to see the status of your car at any time.

Telematics is a topic for a separate article, so we will not dwell on this here in detail.

The question immediately arises - why do I need to search for data in a stream if I can see it through ELM327 or other diagnostic devices?

The question here is why we need this data. In our case, we need the data for telematics, and in order not to interfere with the CAN bus and not send any data to it, we look for them in the stream. Vega MTX has a special mode for working with the CAN bus - the “listening” mode. The mode speaks for itself, the equipment only listens to the bus and does not send anything to it, thereby minimizing any impact on the regular car system.

For example, a sensor for opening a door. If we ask him a request, then we can only do this with the ignition on. After the ignition is turned off and the CAN bus falls asleep, this sensor will not be available to us. If we find this sensor in the CAN stream, then we will see it all the time when the CAN bus is working. And, when you open the door, CAN will wake up automatically.

It should also be understood that all of the examples below are only relevant for the Polo Sedan connect. In others, the equipment may not have any of the sensors listed, but for other makes and models of cars the data will be in completely different IDs.

I draw your attention to the fact that by default in the Configurator there is a display of values in the HEX format. In the future, we will have to translate data from the HEX format to decimal values more than once. The easiest way to do this is to use the Calculator application built into Windows 10. We translate it into the “programmer” mode and we have a choice in which number system to enter data, and they are duplicated in other number systems.

By the search method, I divide all the sensors in the car into several types:

Binary sensors.
Quickly changing sensors.
Temperature sensors.
Car mileage.
Level sensors.
Indication sensors
Sensors with requests.

Now let's move on to the methods with which you can find each type of sensor.

1. Binary sensors

Let's start with the simplest binary sensors.

These sensors include door sensors, seat belts, brake (whether brake lights are on), hand brake, buttons are pressed, etc. Their value is placed in 1 bit, that is, it can be 0 (the door is closed) or 1 (the door is open).

Finding them is simple, but requires care. To search for a driver’s door, open / close the door and watch what changes in the CAN bus.

The configurator highlights in red those data in which there have been changes in the last few seconds.

In our case, the driver’s door is responsible for the zero bit of the first byte of the message with ID 470.
In the same byte are the sensors of all the other doors + trunk sensor.

2. Quickly changing sensors

Quickly changing sensors are similar to binary sensors, only their value is more than 1 bit. We can act on these sensors and immediately see changes in the CAN bus.
These sensors include most position sensors: gas pedal position, glass position, automatic transmission position, ignition key position. In addition to these, these are sensors of speed, revolutions, sensors of acceleration of the steering wheel, acceleration of the gas pedal, etc.

To begin with, we’ll deal with position sensors using the example of the gas pedal position sensor.

To do this, we turn off the car, turn on the ignition and, without starting the engine, press the gas pedal and monitor the change in the CAN bus.

As a rule, when the gas pedal is released, the value of this sensor is 0, and, as you press the gas pedal, it increases to some value. We see such a parameter in the first CAN in ID 280. The fifth byte changes from 0 (the pedal is released) to FA (the pedal is pressed “to the floor”).

If we translate FA from HEX to DEC, then we get the number 250. Therefore, to get the accelerator pedal pressed in percent (from 0 to 100), we need to multiply our value by 0.4.

Now let's move on to sensors that do not fit into one byte, for example, to engine speed. We gradually increase and decrease the engine speed, while watching what changes in the CAN bus. Engine revs are in the same ID as the gas pedal.

Having worked with the gas pedal, you can understand that the data here are in the reverse order. That is, the oldest part is in the 3rd byte (count bytes from zero), and the youngest in the second byte.

Next, you need to transfer the data from HEX to DEC.

Next, we need to evaluate the real revolutions by the tachometer, or by diagnostic instruments. In my case, the needle was at about 1600 rpm on the tachometer.

Next, we divide the data from CAN in decimal format (6508) by the engine speed from the tachometer (1600), we get 4.0675. Given the error in determining the revolutions by eye, round off the divider to 4. After this, you need to check the readings at several points. To do this, set the engine speed at different speeds and check them with data from the CAN bus.

In the configurator, you can substitute all the coefficients in the sensor settings and watch the changes in speed in real time.

Thus, a large number of sensors are sought: brake forces, steering wheel position, steering wheel acceleration, vehicle speed, etc.

3. Temperature sensors

It was very difficult to find the temperature in Polo Sedan. To begin with, a byte was found, which slowly changed upwards when the car was heated. After that, the search for the necessary coefficients began.

We connect the diagnostics, select the engine temperature, and compare the readings of the CAN bus and the data from the diagnostics. We build a correspondence table and select the coefficients.
As a result of the selection of coefficients, a formula for calculating the temperature appeared.

XX * 0.75 - 48
where XX is the value of 1 byte from ID 288 in the DEC.

According to the formula, it can be calculated that the screenshot had a temperature of

179 * 0.75 - 48 = 86.25 ° C.

where 179 is the decimal number B3 from the first byte of ID 288.

But this is a difficult case, in many cars the temperature is much easier to find.

Since it is difficult to transmit a negative number in the bus, manufacturers accept the value -40 ° C, -48 ° C or -58 ° C as 0 measurements. Therefore, we connect the diagnostics and see what the temperature is now. Add 40 (48 or 58) to this, and translate it to HEX. We are looking for the resulting number in the stream. We are waiting for the temperature of the machine to change by one degree and check with the found value. If its value also increased by 1, then this is the sensor we need.

It is important not to confuse the values from the CAN bus with the values of the diagnostic queries. If you simultaneously search for readings on the bus and the diagnostic tool is connected, then answers to diagnostic requests will also appear in the bus. They can be identified by ID. Usually all that goes over 700 IDs are diagnostic requests and answers.

Also, the temperature of the coolant can always be made a request, about this method will be described below in the section on sensors with requests.

You can use another method to search for temperature: physically we find the coolant temperature sensor (DTOZH) on the engine, turn it off and connect a variable resistor to the car wiring. Then, rotating the resistor and following the CAN bus according to the method of searching for rapidly changing data, you can find the engine temperature readings.

In practice, I didn’t use this method, since ALT was always either in the stream, or they asked the machine for a request.

4. Car mileage

One of the most important parameters for telematics.

First you need to evaluate what size we are looking for a number. If you take 2 bytes (16 bits) of data, then the maximum number FF FF = 65,535 will fit into them. The car can clearly travel over 65 thousand, which means that the vehicle must have a minimum of 24 bits long. There will already fit 16 million km., Which is clearly enough for a run.

But then again, in different cars in different ways. In Polo Sedan, the mileage is written in km, in some French it is transmitted with an accuracy of 100 meters. then the number can occupy 32 and more bits.

Further for the search you should take the mileage from the dashboard of the car and transfer it to HEX.

In our case, it is 5732 km. We translate it into HEX and get 16 64. Next, search you need to find the line where this combination will occur. You need to search by one byte, that is, first search for 16, then in the options found, see if there is also the number 64 next to the number 16. The number 64 can be either to the left or to the right of the number 16. Since the mileage in this car is not large, then most likely, next to the number 64 there will also be 00. In the Configurator there is a convenient search (CTRL + F), if you use another tool, you will have to manually search for this data.

In our case, the mileage was found in 520 ID

00 16 64 = 5732 km.

To check, it is advisable to drive a few more kilometers and check the value of the sensor found.

In the same way mileage is searched before refueling. In this car, the dashboard does not transfer the mileage to the gas station to the tire, so it is made by request.

6. Level sensors

The second most important sensor for telematics is the fuel level sensor. You can find it either in the stream, which is preferable, or by request (less preferable, but in some cars it will not work differently).

First you need to find the fuel level readings in the diagnostic tool. My fuel level was found in the instrument cluster (17 block). In the instrument cluster, the readings from the level sensor are in liters.

Now the car has 21 liters of fuel.

We translate 21 from DEC to HEX and get the number 15. By searching, we try to find it. The stream contains the given number in ID 320. If the number is not found, then you should try to look for values one or more. In some cars, fuel comes with an accuracy of half a liter, so you need to look for a value 2 times larger.

Once the fuel level is found, it is necessary to pour a few liters of fuel into the car and look at the result.

You can also disassemble the gas tank, pull out the FLS from the tank and move it, following the CAN bus readings. Or remove the connector from the FLS and connect a variable resistor there. Rotating it and following the changes you can find the fuel level sensor. If you decide to disassemble, then the fuel level should be sought by the method of searching for rapidly changing sensors.

Also, when searching, data with IDs over 700 should not be taken into account. These are diagnostic queries. After disconnecting the diagnostic equipment, this data will disappear. We will deal with the requests in more detail below.

For example, the answer to the queries of the diagnostic equipment of the fuel level from the dashboard looks like this.

Also, the fuel level (in percent) can be found in standard OBDII queries, but on the VAG group they do not always show the correct data. On the Skoda Rapid and Skoda Oktavia with a full tank, the diagnostics show a fuel level of 85%.

6. Indication sensors

Indication sensors are very similar to binary sensors, and they should be searched by the same method. These sensors include a variety of icons on the dashboard. For example, the status of the Check Engine icon is in the first byte of ID 480. When the ignition is turned on in this sensor 2C.

After starting, when the Check Engine (CE) icon goes out, there will be 00 in this sensor.

Now the question remains, which bit is responsible for the CE icon. We translate 2C to BIN and get the number 0010 1100.

Next, copy the entire 480 ID, change the first byte to 2C (0010 1100) and try to send this packet to the car.

Attention!, sending data to the car is not always safe, you can break something, or wind up the mileage. It is worth resorting to this method only if the sensor could not be found by searching for binary sensors.

In my case, I sent to a wound-up car (which is not recommended) and my CE and EPC icon blinks on my tidy.

Then we send instead of 2C (0010 1100) 08 (0000 1000). On tidy CE blinks. Therefore, 3 bits is responsible for this icon.

If you send 04 (0000 0100), the EPC icon blinks.

7. Sensors with requests

Not all data can be found in the stream. For example, in a diesel VW Transporter T4 there is no engine temperature in the stream. She is not on the tidy. Therefore, you have to ask the car about these parameters. The same applies to the fuel level on the Rio \ Solaris.

In this example, let's try to ask the fuel level of the Polo Sedan. We go to block 17, as we did in the paragraph about the search for the fuel level, and ask the dashboard. After analyzing the requests, we see that the diagnosis asks for the fuel level with the following command:

And in response it comes to her:

Next, copy ID 714, turn off the diagnostic tool and try to send a request to the car. If ID 77E receives the same answer as it was when the diagnostics were connected, then we received a packet with a fuel level (4 bytes. HEX 15 = DEC 21) 21 liters.

Vega MTX has built-in tools for working with sensors with queries. There you can configure that requests would be sent after the ignition is turned on at a certain interval or under certain conditions.

This concludes with the methodology for searching data in the CAN bus. If anyone else knows what methods to find the necessary data on the CAN bus or share their experience, then I will listen to them with pleasure.

Before writing this article, I made a video on this topic. The video contains more information on connecting to the vehicle’s CAN bus, working with the Configurator and the file server

Link to the Configurator

The server has settings for some cars, trucks and agricultural machinery. All files are encrypted, you can see which sensors are visible in the vehicle’s CAN. When connected, the sensor values will be visible, but it will not work to see the addresses.

To be continued.

Decryption of data in the CAN bus VW Polo sedan