Hacking into an automotive control module far enough to retrieve its current firmware and configuration is really just the beginning of the adventure. At this point, you probably have anywhere from 4KB to 4MB of raw machine-ready code, with a mixture of various parameters and actual code that forms the program the processor will run. Let’s say you have a binaryblob in the firmware from one of the hacks in this blog or the another blog of car repair and reverse engineering, can bus analyzing in this section of our car repair and CAN bus sniffing blog. Next you need to disassemble the binary.First, you must know which chip this binary is for. There are several free decompilers for different chips out on the Internet. Otherwise you can drop some money and buy IDA Pro, chip programmer and reverse engineering which supports a large variety of chips.These tools will convert the hex values in the binary into assembler instructions and decompile it. The next step is to figure out what exactly you are looking at.When you’re just starting to analyze raw data, a high-level understanding of the function and the functionality of code of the devices you’re reverse engineering will be key to knowing what to look for. You can follow a number of breadcrumbs, or clues, for starters; these breadcrumbs are almost guaranteed to lead you to interesting and useful material. Next, we’ll look at a few specific examples of how to use common automotive controller functions to gain insight into their operation, which will hopefully allow us to change their behavior.
Finding Known Tables
Self-Diagnostic Systems
Every engine controller has some type of self-diagnostic system that typically monitors most critical engine functions and operations , and analyzing this is an important thing to do in order to understanding firmware. A good first step in investigative disassembly is to identify the location of these procedures. This will give you insight into the memory locations involved in all of the sensors and functions that are checked for errors. Any modern vehicle should support OBD-II,OBD-I packets, which standardize the diagnostic data reported.
Even controllers created prior to OBD-II standards have a way to report faults. Some have a system where an analog input is shorted to ground and either an internal LED or the “check engine” light flashes out the code. For example, knowing that code 20 refers to a failed intake air temperature (IAT) sensor means you can find the piece of code that sets error code 20 to help you identify and detect the internal variables associated with the air temperature sensor.
