Reverse Engineering a vehicle (or creating a CAN dbc file)

Reverse engineering a vehicle is a process of interpreting the meaning of message data without the aid of the database files or design documents. It involves a deep understanding of ECUs, in-vehicle network, and access to the necessary tools. This process often includes capturing CAN traffic, analyzing patterns and identifying how specific signals correspond to vehicle behaviors. Skilled engineers use techniques like fuzzing, bit-level analysis and correlation with physical events to map out unknown protocols and message formats.

Reverse Engineering

Reverse engineering in-vehicle data involves analyzing and understanding the communication and data exchange within a vehicle’s network. This helps to uncover the structure, format, and meaning of the data being transmitted. This is done without the aid of the design documents or database file (example a CAN DBC file).

This process is essential for understanding vehicle diagnostics, developing aftermarket products, analyzing a competitor vehicle, and enhancing vehicle performance. Nevertheless, it’s important to note that reverse engineering a vehicle network may, in some cases, be subject to legal and ethical considerations. Specifically, almost all vehicle data can be found in two types of messages:

1. Normal or Onboard messages which are available on the network for normal operation of the vehicle.
2. Diagnostic vehicle messages used for troubleshoot a vehicle

Onboard message Reverse Engineering strategies

• Monitor all messages and in-vehicle network buses.
• First, exercise the vehicle to create a change in the data you want. Then, monitor those changes by connecting an in-vehicle network analysis tool, such as Vehicle Spy. Consequently, this will help in capturing and analyzing the data more effectively. After that, observe those changes in the message traffic window of the tool and, in turn, try to relate them to the action performed on the vehicle. For example, when you press the brake pedal, note which messages (data bytes) are changing during that specific action.
• Try to find a Scaling factor and/or offset to determine an Engineering value from a raw value as seen in message traffic.
• Mark those changing data bytes/bits and save them in a database file (DBC) in the form of a message signal.
• By performing many such actions, you can identify a handful of signals. A collection of those signals can make a basic DBC file of that vehicle with the use of Reverse Engineering.

Here is one example of using Vehicle Spy and Kvaser testing tools to perform Reverse Engineering:

And another one:

Diagnostic Tool Strategies

• Use OEM Diagnostic tool (Example BMW’s EDIABAS diagnostics tool) to request diagnostic data and watch response messages traffic.
• Connect a Diagnostic tool from any OEM, connect an in-vehicle network tool like neoVI in parallel with a Diagnostic tool using a Y-cable. Monitor and log the message traffic.
• Monitor all Diagnostic messages.
• Try to mimic the same Diagnostic request / response.

Pitfall of Reverse Engineering

• For instance, some ECUs implement security measures that require an ‘unlock sequence’ to enable a positive response. Specifically, this process is known as Security Access or Seed-and-Key access.
• Some OEMs disable Diagnostic Data access to prevent Reverse Engineering a vehicle.
• The J1962 (D2C/OBD) connector may not expose all vehicle buses. As a result, accessing data from all in-vehicle networks might not be possible.

Creating a CAN DBC File

1. Identify the Purpose: Determine the purpose of creating the DBC file. Are you interested in decoding and interpreting existing CAN data or defining a new set of messages and signals for a specific application?
2. CAN BUS Message Identification: Identify the CAN messages that you want to include in the DBC file. This may involve researching the vehicle’s documentation, referring to existing databases, or monitoring the CAN bus in a controlled environment.
3. Signal Definition: For each CAN message, define the individual signals or parameters contained within the message. In addition, this includes specifying signal names, units, scaling factors, and signal data types (e.g., integer, float).
4. Message IDs: Assign unique message IDs to each CAN message. Ensure that these IDs adhere to the vehicle’s CAN network architecture and any addressing conventions in use.
5. Signal Multiplexing (if needed): For example, in some cases, signals may be multiplexed within a single CAN message. Define multiplexing schemes to extract the desired signals correctly.
6. Attribute Definitions: Specify attributes such as signal descriptions, minimum and maximum values, and default values. As a result, these attributes help interpret and display the data correctly.
7. Network Nodes: In particular, if your DBC file is intended for use in a multi-node network, define the network nodes and their associated messages.
8. Checksum and Frame Format: Include information about any checksums or error-checking mechanisms used in the CAN messages. Additionally, specify the frame format (standard or extended) used in the network.
9. Documentation: To begin with, document the DBC file thoroughly, including information about its purpose, the vehicle it corresponds to, and any assumptions or reverse engineering methods used.
10. Validation: Validate your DBC file by testing it with real-world CAN data to ensure that it accurately decodes and encodes messages.

Reverse Engineering a Vehicle’s in-vehicle Network

Reverse engineering a vehicle’s in-vehicle network involves several critical steps that must be carefully executed to ensure accuracy and compliance.

Ethical access to Signal database file

First, gaining legal and ethical access to the vehicle’s CAN network (dbc file) is paramount; this often requires the use of authorized diagnostic tools or manufacturer-provided interfaces, which help avoid violations of intellectual property or privacy laws. For example, technicians may use an OBD-II port with a compatible CAN interface device to safely tap into the vehicle’s network during operation.

Logging the vehicle data

Next, data logging plays a crucial role in capturing real-time CAN messages. Utilizing tools such as CAN bus analyzers or loggers allows for comprehensive data collection across a variety of vehicle states, such as acceleration, braking and idling, thereby providing a rich dataset for analysis.

After you collect the data, you identify the unique CAN IDs and analyze their correlation with specific vehicle functions. This often requires you to use advanced pattern recognition techniques and filter out noise or irrelevant messages to focus on meaningful signals.

Signal Decoding

Signal decoding further breaks down these messages by interpreting the individual parameters, such as speed, temperature, or gear position, as their values change during vehicle events. For instance, you might observe that a rise in a particular byte value correlates with an increase in engine RPM, which you can validate by simultaneously observing the vehicle’s dashboard instruments.

Documentation of identified signals

Thorough documentation of findings, including message IDs, signal definitions, and scaling factors, is essential to build a clear and reusable reference, typically formatted into a DBC file used by engineers and developers.

Validation of signals

The next key step is validation, where you test the reverse-engineered data against known vehicle behaviors to confirm accuracy. This may involve running test scenarios and comparing the expected outcomes with the decoded signals to ensure reliability.

Ethical considerations

Throughout the entire process, you must keep ethical considerations crucial. You should comply with legal standards, protect vehicle owner privacy, and ensure data security. For example, always perform reverse engineering only with explicit permission and never use it for malicious purposes.

Adhering to these guidelines not only fosters trust but also ensures that the reverse engineering work supports legitimate automotive research and development efforts.

Final Thoughts

Creating a DBC file or reverse engineering a vehicle’s network is a complex task that requires expertise in automotive electronics, CAN protocols and access to appropriate tools and equipment.

While reverse engineering a vehicle, it is crucial to consider the legal and ethical implications of working with the vehicle’s data. For this reason, always ensure compliance with relevant laws and regulations throughout the process.

Proper documentation and responsible data handling are essential to maintain safety and transparency during such activities. Furthermore, collaboration with OEMs or using publicly available open-source datasets can also support legitimate development while reducing the risks associated with unauthorized access.