Car Hacking: A Short Overview

automotive car-hacking reverse-engineering

Ever wondered about the various techniques that can be applied to hack modern cars? This post documents various ways to do so - you can use it as a cheatsheet


There are multiple ways one can interface with the software stack of a car. The easiest one is to use USB-to-Ethernet adapters in order to attach to the network of the car. It’s important to use special adapters that are whitelisted on the car’s head unit. Also, not every adapter may be supported after all. For this, it’s best to do some research to get a hold of the right devices to use. Once attached to the network, assign a static IP to the interface. Once again it’s up to the researcher to get the correct IP range. For a specific car manufacturer, it seems to be according to KeenLab [1]. It’s best to test all IP ranges not being publicly routed. Now, use some nmap to scan for services.

There can be multiple possible results:

All services may run as their own user to prevent compromising the entire system in case a vulnerability is present in one of the applications. Examine the service and fuzz it. For quick tests radamsa can be of use.

It may also be possible to create a WiFi hotspot using the car’s head unit. There may be other services available when entering the created wireless network that are worth examining. If you have a developer unit, using a debugger and examining coredumps can be of use.

From the internal point of view, using netstat, sockstat and other similar tools may reveal other vulnerable services. Potential attack scenarios can be horizontal and vertical privilege escalation, so it’s worth checking out all open ports and tracing running applications. In case more information on a target is required, perform static analysis with IDA or a similar disassembler. Be sure to have the whole package ready, including support for foreign architectures. Yes, there’s also Java on cars, so reverse engineering of these applications should be way more easier. As always when performing static analysis, keep an eye open for static keys, weak crypto and infrastructure related info. This also includes any MQTT brokers the car may be attached to. As with “traditional” pentesting, search for SUID binaries and sudo-like mechanisms that may enable privilege escalation.


Various ECUs and devices may run different operating systems you haven’t encountered before, like QNX [1]. Search for all info you can get. Evaluate the permissions of all users, kernel versions and known vulnerabilities. For example, if the system service qconn on port 8000 is running, it’s a quick win.


Cars come with their own mobile app and application servers which may be a valuable source of information. In-app purchases for cars, NFC and Bluetooth come to mind. Look out for developer menus and ways the app affects the car and the application server. How does the car unlock process work?

“Apps” also refers to services running in the car:

External Media

Some things to check:

Car Network

It may be valuable to apply the old-fashioned CAN fuzzing to uncover potential problems. Also use the internal wires and not just the OBD-II port as it may be “firewalled”. Modern cars use VLANs and IPv6, so using the traditional IPv6 attack tools can be of use. Also, issues in the network segmentation can be severe: You shouldn’t be able to open the car from a isolated network segment that controls media stuff. Hopping from one ECU to another using interfaces listed in ifconfig or devices under /dev is also possible. The worst case would be sending CAN packets from a hijacked unit.

Check for bus wires that are exposed via car mirrors and antennas!

Other Things


ShhPlunk: Muting the Splunk Forwarder

reverse-engineering c++ linux

Game Hacking #5: Hacking Walls and Particles

reverse-engineering c++ binary gamehacking

Analysis of Satisfyer Toys: Discovering an Authentication Bypass with r2 and Frida

radare2 r2 frida r2frida reverse-engineering web vulnerability