Blog

Reverse engineering a vehicle is a process of interpreting the meaning of message data without the aid of the design documents or database files. It involves a deep understanding of ECUs, in-vehicle network, and access to the necessary tools.

Reverse Engineering an automotive vehicle

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. It’s essential to note that reverse engineering a vehicle network may be subject to legal and ethical practices. Almost all vehicle data can be found in 2 types of messages:

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

Onboard message Reverse Engineering strategies

• Monitor all messages and in-vehicle network buses.
• Exercise the vehicle to make a change in the data you want. Next, monitor those changes by connecting an in-vehicle network analysis tool, such as Vehicle Spy. This will help in capturing and analyzing the data effectively. Now, monitor those changes in the message traffic window of the tool and try to relate them to the action performed on the vehicle. Example: Press brake paddle and see which messages (data bytes) are changing during that 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 Kvaser and Vehicle Spy tools to perform Reverse Engineering:

And another one:

Diagnostic Tool Strategies

• Use OEM Diagnostic tool (Example BMW’s EDIABAS) 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

• Some ECUs implement security measures that require an ‘unlock sequence’ to enable a positive response. Specifically, this 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. Therefore, accessing data of 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. 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): 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. These attributes help interpret and display the data correctly.
7. Network Nodes: 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. Also, specify the frame format (standard or extended) used in the network.
9. Documentation: 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

1. Vehicle Access: Gain legal and ethical access to the vehicle’s CAN network. This may involve using diagnostic tools or accessing manufacturer-provided interfaces.
2. Data Logging: To capture CAN messages while the vehicle is in operation, use a CAN interface tool, such as a CAN bus analyzer or logger. This ensures accurate data collection for analysis. Ensure that you capture a wide range of vehicle states and conditions.
3. Message Identification: Analyze the captured CAN data to identify the messages and their meanings. Look for patterns and relationships between messages, signals, and vehicle functions.
4. Signal Decoding: Decode the individual signals within each message by analyzing their values as they change in response to vehicle events.
5. Documentation: Document your findings, including message IDs, signal definitions, scaling factors, and any other relevant information.
6. Validation: Verify your reverse-engineered data by comparing it with known vehicle behaviors and states. Validate that your DBC file accurately represents the vehicle’s CAN network.
7. Ethical Considerations: Ensure that your reverse engineering activities comply with legal and ethical standards. When accessing and analyzing vehicle CAN data, always respect privacy and security considerations. Consequently, ensure that data handling practices are compliant with applicable regulations and standards.

Conclusion

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. Therefore, always ensure compliance with relevant laws and regulations throughout the process.