interface in a car’s center console. These consoles often run an operating system such
as Windows CE, Linux, QNX, or Green Hills and may even run Android in a VM as well. They can support numerous features with varying levels of integration with the vehicle.
The IVI system offers more remote attack surfaces than any other vehicle component. In this chapter, you’ll learn how to analyze and identify an IVI unit, how to determine how it works, and how to overcome potential hurdles. Once you understand your IVI system, you’ll have gained a great deal of insight into how your target vehicle works. Gaining access to the IVI system will not only allow you to modify the IVI itself but also will open a door to additional information about how your vehicle works, such as how it routes CAN bus packets and updates the ECU. Understanding the IVI system can
also provide insight into whether the system phones home to the manufac- turer; if it does, you can use access to the IVI to see what data is being col- lected and potentially transmitted back to the manufacturer.
attack surfaces
IVI systems typically have one or more of these physical inputs that you can use to communicate with a vehicle:
Auxiliary jack
- CD-ROM
- DVD
- Touchscreen, knobs or buttons, and other physical input methods
- USB portsOne or more wireless inputs
- Bluetooth
- Cellular connection
- Digital radio (such as Digital Audio Broadcasting)
- GPS
- Wi-Fi
- XM RadioInternal network controls
- Bus networks (CAN, LIN, KWP, K-Line, and so on)
- Ethernet
- High-speed media busVehicles often use CAN to communicate with their components, such as modules, ECUs, IVI systems, and telematic units. Some IVI systems use Ethernet to communicate between high-speed devices, whether to send nor- mal IP traffic or CAN packets using Electronic System Design’s NTCAN or the Ethernet low-level socket interface (ELLSI). (For more on vehicle proto- cols, see Chapter 2.)
attacking Through the update system
One way to attack the IVI system is to go after its software. If your skill set primarily lies in the realm of software-related services, you may feel most comfortable with this method, and if you’ve ever researched embedded devices, such as home Wi-Fi routers, some of the methods discussed in the following should look familiar to you.We’ll focus on using system updates to gain access to the system. It may be possible to access the system through other software means, such as a debug screen, an undocumented backdoor, or a published vulnerability, but we’ll focus on gaining access through software updates because that method is the most generic across IVI systems and is the primary one used to identify and access a target system via software.
Identifying Your System
In order to fully understand your target IVI system, you must first deter- mine what kind of software it’s running. Next, you need to figure out how to access this software, which often involves looking for the methods the IVI uses to update or load its operating system. Once you understand how the system updates, you’ll have the knowledge you need to identify vulnerabili- ties and modify the system.
Before you can begin making modifications, you need to know what operating system the IVI is running. The easiest way to do so is to search
for the brand of the IVI—first, by looking for a label on the outside of the IVI unit or frame. If you don’t see a label, look for a display option on the interface that displays software version numbers and often the device name. Also, check online to see whether anyone has already researched your tar- get system and, if the system is manufactured by a third party, whether it has a website and firmware updates. Download any firmware or tools you can find for later use. Find out how the system is updated. Is there a map update service available? What other update methods are available? Even if you find that system updates are sent over the air, it’s usually possible to find USB drives or a DVD containing map updates, like the one from a Honda Civic shown in Figure 9-1.
Determining the Update File Type
System updates are often delivered as compressed files with .zip or .cab file extensions, but sometimes they have nonstandard extensions, like .bin or.dat. If the update files have .exe or .dll extensions, you’re probably looking at a Microsoft Windows–based system.
To determine how the files are compressed and their target architec- ture, view their headers with a hex editor or use a tool such as file available on *nix-based systems. The file command will report a file’s architecture, such as ARM or, as with the Honda Civic IVI shown in Figure 9-1, a Hitachi SuperH SH-4 Processor. This information is useful if you want to compile new code for a device or if you plan on writing or using an exploit against it.
If the file command hasn’t identified the type of file, you may be look- ing at a packed image. To analyze a firmware bundle, you can use a tool such as binwalk, which is a Python tool that uses signatures to carve out files from a collected binary. For instance, you can simply run binwalk on your firmware image to see a list of identified file types:
