Intro to Automotive Reverse Engineering

Introduction

This article will introduce you to new modern concepts of reverse engineering. Instead of standard systems and standard everyday computers we will learn and give a basic introduction to the automotive side of cyber security. This will introduce you with parts of a car such as the ECU, PCM, OBD(2) connectors and even network protocols such as CAN and Flex Ray. In this article we will go from the basics and introduction to automotive networks then learning about the CAN suite of hacking tools and pentesting frameworks to understanding exactly how to reverse engineer CAN-BUS. Part 2 of this article will also showing the deep depths of automotive reverse engineering.

Why

Cars are an everyday part of everyone's life, if it is not a car then it must be a dirtbike, motorbike or something along those lines that can take you from place to place everyday such as you’re work place. As cars with technology advance there are more standards and systems that are put into place to protect and really add more functionality to these systems. Ever since technology shot off the whole goal of tech was not how you did it but how you did it better and why you did it better. Well along with advancements in technology comes people who actually want to test these technologies and as a external source understand exactly how they work. Well the reason to do this is to ensure that these systems are safe and protected as much as they say they are. On the bright side this also helps technologies grow and automotive systems especially improve and get better each time.

Why learn automotive penetration testing

A lot of people do not understand that the automotive field gets larger and larger as time goes buy and gets more vulnerable each second it is not tested. Learning automotive penetration testing even if it is down to the basics such as replay attacks are something that can give you a good understanding of how automotive systems work in and out and how other more corperate technologies may work. It also can teach you how to make copies of your car key or make copies of an ignition switch and other things alike especially when you dig deep into hardware pentesting with cars. The thing with

Diving into it | The basics

Massive Disclaimer: Understanding the basics of a automotive system is 1,000 times more complex than this and goes down a million different road paths especially if you are planning to get into automotive pentesting. This article only barely explains the tip of the iceberg of automotive terms and systems.

Like all articles and tutorials if you actually want to learn something and feel like you actually understand a topic or how to it is good to go to the basics and start here. First off lets lay out some basic and simple terms before we get started.

• ECU: Otherwise known as the Engine Control Unit or Electrical Control Unit ( Depends on who you talk to and reference wise ) this is a cool little controller is a part of a car that helps with controlling or executing specific routines in a system. There is much more deeper information about this type of device but for now that is the basics.
• PCM: Also known as the Powertrain Control Module this module is a nifty little primary Electrical Control Unit of a car which allows for diagnostic logging, troubleshooting and other sub functions that it may be designed to handle.
• EDR: Otherwise known as the Event Data Recorder this is the primary part that is responsible for recording a series of events that happen within a automotive system. Most EDR’s record data based on the company that makes them. Some companies are a bit more tight on data recording while others may not. Typical EDR’s record data such as speed of the vehicle, changes in the vehicle
• CAN: Known as Controller Area Network, CAN is the base network protocol for most cars and automotive systems today. CAN allows for multiple features such as vehicle diagnostic systems and more advanced logging and data management systems. CAN was originally developed in Germany during the 1980’s. This protocol would later on change the entire way the automotive field was both developed and approached. This system primarily was designed for functionality but also took away the idea of shoving so much wires and boards into a car when you could rather have say 1 module for each functionality of the car connection to one BUS. This also helped cut down production costs of automotive systems.
• FlexRay: Another networking protocol that was designed for automotive systems but one that is more expensive and difficult to implement. Unlike can FlexRay was designed to “ ensure high data rates, fault tolerance, operating on a time cycle” and would be used for more expensive cars. Cars and automotive systems that used flex ray while limiting the resources made production much more expensive. You are more likely to see FlexRay in a BMW than you are a Acura which uses CAN. This protocol was designed to be the UDP of the automotive world thus being more reliable than CAN was at the time.
• OBD: On Board Diagnostics is a term most people in or out of cars know. OBD is a system that was designed to test and regulate/reduce the amount of vehicle emissions. OBD is commonly used to scan for information from the car itself. Say your check engine light turns on or MIL light ( Malfunction Indicator Lamp ) there is most likely a code that was stored from the network of the car ( as a basic meaning ). You can use the OBD(I/II/III) connector on a car to connect to a reader that is designed to read those codes and display a more human readable format rather than what most codes are seen as 0x022 or something alone those lines.

Threats to modern day automotive systems

In todays vehicles consists of many features such as Wi-Fi, Bluetooth support, GPS’s, customization of the car etc. However with those new busts and breakings in the realm for technology especially in cars comes more vulnerabilities. Below you will find a common list of threats to modern day automotive systems.

• Wi-Fi: Wi-Fi by far is one of the more vulnerable protocols. While having Wi-Fi is great in a car no car truly needs Wi-Fi to be able to work with its internal systems. If a automotive manufacturer or developer builds a internal network this means the car may need external sources to communicate meaning it must be connecting to a server of some sort. In fact there was a recent security researcher that brought up something interesting about cars using certain providers ( explained in section 4 of this article titled “A break from basics | A new perspective” ). Wi-Fi is a major issue for cars because if the car requires it to be used to fetch data such as data the car may need to give readable diagnostics then well this potentially means a hacker could mess with the diagnostic system of a car. This is a very rare case but a very decent example. When implementing Wi-Fi even in modern systems some manufacturers forget that newer standards need to be required for security reasons. Due to this fault a hacker may find a working exploit for out dated or vulnerable versions of that same Wi-Fi implementation. In a more extreme cases this means that a hacker could maybe trick the car into thinking that “ it is being serviced “ by a fake Wi-Fi access point and force it to connect to that AP.
• Key Fobs: The key fob of a car is a device that is typically digital / keyless if that makes sense. In other words it is a digital remote to the car. These key fobs send signals to receivers on the car that wait for a specific signal to be sent. Devices like the flipper zero take advantage of this type of system. When a key fob sends a remote radio signal to the car or tries to send a signal a device such as the flipper zero or literally any SDR ( Software Defined Radio ) such as the HACKRFONE can record these radio frequencies and replay them back. This is known as a radio replay attack or just a replay attack.
• USB Ports: USB ports despite not seeming dangerous on the outside really are a serious issue. When a hacker or say really good developer gets access to those USB ports they can install malware on certain units of the car. This malware may be designed to either brick the car itself or just get certain information. This means the system can have malware designed to implement cell trackers, data miners, data spiders and even remote connections to this car.
• Bluetooth: Bluetooth like Wi-Fi has its own sets of issues especially in modern day implementation. You can pop open your favorite Linux Bluetooth hacking and discovery toolkit and run exploits that may damage certain units or locations on the cars.
• Hardware: This will appear in a very specific part of this article but just know that some cars and manufacturers do not intend for their users to just go around ripping hardware out of their cars. In fact manufacturers now make it quite hard to do that without special tools or mechanical equipment. This means that when hardware is installed onto an automotive system security may not be a prime worry which may lead the hardware susceptible to hardware attacks. The issue with hardware attacks is not really a major issue given not every random person is going to go looking for a car and reversing the firmware on it since it is quite difficult and pain staking. However these types of attacks like glitch attacks may allow the hacker or reverse engineer to install malicious firmware or custom firmware on the car’s system by being able to bypass security systems.

This is just to list a few threats to a modern day automotive system. Sure some attacks are quite old however mistakes happen and especially manufacturers are bound to make mistakes more common. Lets take a look at a new attack that was just recently discovered by a security researcher named Sam Curry.

A break from basics | A new perspective

A security researcher known as “Sam Curry” made a major tweet on November 29th 2022 explaining how he and others were able to remotely control any car from multiple companies such as Honda, Nissan, Infiniti and Acura simply from just knowing the VIN (Vehicle Identification Number). The tweet explained that the security researcher had found out that all cars installed or had been using firmware (Telematic Service/Firmware) from the same exact distributor known as SiriusXM. SiriusXM according to the tweet had said on their page that they were a mass distributor in telematic services for automotive brands such as Acura, BMW, Honda, Hyundai, Infiniti, Jaguar, Land Rover, Lexus, Nissan, Subaru and Toyota. Wow that's a lot of cars to service! Well what exactly was the issue with this? It was said in the tweet that when they found this quote they “kicked” off scans to the website to scan for every possible domain they could find owned by SiriusXM until eventually they found a domain named telematics.net and “ began investigating “. After reverse engineering all the apps to see how they worked they were able to get a more clear picture of how the remote management from the APP worked. Once they found the website and began investigating then found out that website was meant to handle services for “enrolling vehicles” in the SiriusXM remote management functionality. During further investigation they found a large number of references to the same domain in the app called NissanConnect which is an app to remotely manage a Nissan. Eventually during inspection of the HTTP traffic of the application Sam said “There was an HTTP request in particular that was interesting: the echangeToken endpoint would return an authorization bearer dependent on the provided customerID. While fuzzing we removed the vin parameter and it still worked. It seemed to only care about customer ID”. This meant that they were able to access and now modify HTTP traffic of the given URL without being authorized and could slip past systems easily since clearly the system must have been bugged or broken. Through a mass amount of fuzzing and troubleshooting they were finally able to make an as said “obvious IDOR” which was changed from customerID to customerId. This still was giving them errors so they decided to keep digging deeper into the rabbit hole. Finally after more and more troubleshooting they found out by switching the customerID field with the vin token which had a similar format to the customerID field they could finally use the attack to leverage persons information or customer information such as the phone numbers, name, address and car details. At this point they realized they were able to execute remote commands and even mine data. Now you may be asking how could this have been taken a whole step further? In the tweet they were able to make a script to spit out information of a user, person or car given a VIN number. In a more extreme case this meant that a hacker who had malicious intent could have stolen practically the entire database of users and people if they were able to fuzz or constantly generate VIN numbers or even use open databases to parse VIN numbers of a specific brand. This also meant that you could start, stop and remotely mess with the way a car operates as long as you had the specific brand and VIN number. This is a perfect example of external vs internal resources. Typically internal resources are bound to be reversed some way some how, however that does not end the fact that external sources are not better. External sources are understandable as to why people may use them however they can cause issues later on especially if the developers forgot something or may have messed up. This ties into the article of bridging the statement of “ humans mess up “ however it is still a problem that should be fixed.

You can view the whole tweet here

Understanding environments

Environment especially when testing or penetration testing automotive system is important. So there are a few things that we need to understand before learning fully where our place is and where we can actually start here. There are multiple ways to start reverse engineering the CANBUS but two prime ones.

Virtual and Physical, well what are the differences? The difference between the two is how easy they are to setup and or do and execute. A virtual simulation of reverse engineering such as ICSim is much more diverse, sometimes complex and wild to understand but that is the glory in it all. Something that you will find yourself using is VCAN.

• VCAN: Virtual Controller Area Network is a type of interface you can use on your system to simulate a virtual controller area network. This is useful when you do not have a car to test on. This is important when you need to simulate reversing the CAN-BUS.

Before we move onto the tool suite and other information to get started with reverse engineering we should also understand what the difference is between a virtual environment and physical. A physical environment for automotive reverse engineering poses so much difficulties but learning experiences especially if you are making your own test benches. The list below shows the major differences between the two.

• Diversity: While physical environments are good so that you can familiarize yourself with the inner workings of a car there really is not that much diversity. This means that most likely you are limited to 1–2 cars unless you build your own test bench and get your own modules from junk yards and junk sellers. This is where virtual environments and simulators such as ICSim come in handy. Simulators will allow you to view the direct inner workings of the network in the car and can have either multiple levels, speed, traffic types, engineering and design types as well as brands.
• Understanding: This is where the two bridges start to merge. Both virtual and physical simulations and environments are really good to understand exactly what you are working with however a physical environment may be more techy for you. This is because when working with a car a physical car you have to understand the voltage, OBD pin outs, locations, diagnostic codes, locations of parts etc which will give a you a way better understanding and deeper understanding of cars physically and digitally. While digital are nice it is definite that a physical environment takes the cake for this type of experimentation.
• Exploitation process: In a real life situation where you are going to penetration test a car there is more than likely you will be physically there if you are not exploiting software like the research tweet and story above this section. This means that for everything you learn the data may stay different but static at the same time. For example every network packet that will be sent over the CAN wire will be sniffed but will your process of locating changed data in that packet be the same? While the concept and idea of locating the changed data will be the same the process may not. Some cars have it faster in terms of transmitting data and some cars also may have it worse and slower while also sending chunks of data. Virtual simulators can be the same however this does not mean you will have access to every brand of car you may want to test which falls under the same category and web as Understanding . In general have a physical environment may better your exploitation skills.
• Hardware: When exploiting a car’s network such as the CAN-BUS or reversing it depending on the environment you are more than likely going to need to have specific hardware such as OBD cables, certain programs, certain licenses and sometimes even some more complex applications and exploits. As discussed above exploiting a car is not always easy and most of the time the process of exploitation may change. So in some cases you may not need special hardware but in other cases you will. For people who want to test cars and what not but do not have the budget to spend say 1K on gear it may be more beneficial to land yourself into a virtual environments.

These are just some base ideas in terms of the major difference that the two have. It really boils down to the situation, what you want to learn and how you want to explore. Next up we have to discuss before part two of this article and before this article sums up would be the toolkits used for reverse engineering and understanding of how CAN transfers data.

The CAN suite

CAN is a widely used protocol and with the factor of it being widely used there is always going to be some form of exploit or exploitation process behind automotive systems and its protocols such as CAN. Well instead of diving deeper into physical environments and understanding how a car works on the fullest extent lets dive deeper into a more cyber/virtual environment. When penetration testing cars (Virtual or Physical) you want to ensure you have a goo set of tools that you can use that can help you identify changed data. More advanced automotive system security testers will use more enterprise/Corporate tools rather than free and open source tools. However given the factor that everyone starts at the bottom there is a toolkit to mess around with called the CAN suite. CAN Suite is a suite of tools open sourced to everyone taking advantage of the CAN.h file which incorporates multiple tools for automotive reverse engineering. In this suite is a containment of over 29 utilities within the suite that can get you to locate, replay, record, generate, measure, test and load CAN traffic. The CAN suite even has major support for protocols such as the ISOTP or J1939 protocols.

• ISO-TP: A protocol standard for setting up, sending or listening for packets over the CAN bus that may exceed the byte limit of CAN which is 8 bytes. Something to note is that all automotive protocols like standard networking protocols have a byte limit of data. I will discuss more on this in a article that talks about a smooth introduction to CAN
• J1939: A set or list of standards defined by SAE that are used in more heavy duty vehicles such as construction loaders, construction builders and trucks.

The CAN tools we will get familiar with this is of the following

• CanDump: This is a utility that allows you to display, record and filter CAN traffic over a given interface. This tool is used in the discovery and understanding part of the exploitation process. This will help us determine the packets we want to replay back to the network.
• CanPlayer: Can player is a utility that can be used in the mid exploitation part of the process. Instead of having to constantly look out for new data and get a live recorder we can use CanDump to record a session to a CAN log file which CanPlayer will be able to replay constantly. This helps us determine our target faster.
• CanSend: This is the main tool that powers our entire attack. This tool allows us to be able to send packets to a given wire or over a specific CAN-BUS. This will be used when say we record our data and want to create a replay attack. Of course this is just a simple replay attack and nothing to sophisticated but for right now as a base introduction it might be smart to stick to the basics of the exploitation / reversing process.
• CanGen: Can gen is not a utility that will be used mainly during the exploitation process but comes in handy any time we want to check our interfaces or inspect and understand how CAN works. CanGen is a tool that allows us to generate random CAN traffic which again helps when we want to inspect CAN traffic to grab a better understanding of it.
• CanSniffer: CanSniffer is one of the more important tools in this process. During the process of reverse engineering the CAN-BUS you must first be able to view and record data. Well CanSniffer allows us to sniff the changed bytes. I did not mention this but when we go to view CAN data it is more than likely we will be looking at a hex dump like the following below.

So we will need to have a deep understanding or moderate understanding of how CAN traffic works and what we will be looking at. In the image above this is CanSniffer sniffing the traffic on a CAN-BUS verifying what bytes may have changed and what have not changed. This will help us determine what we really want to target and the address or ID we will be targeting when we create our replay attack.

These are the tools we will be using part 2 of this section. The CANUTILS suite is a very important suite in linux for people who want to start understanding how the CAN-BUS works without fancy SDR’s or devices such as the flipper zero.

What we learned ( Part 1 )

We learned the basics of how automotive systems can be attacked such as identifying common threat models then went onto addressing the basics of Environments and penetration testing automotive systems. We finally ended on the very very smallest bit of the linux CAN UTILS suite which allows us to attack vehicles and automotive protocols.

Conclusion

Sorry to end this article a bit too early however there will be multiple articles and this will be an entire series on how to reverse cars. The next few articles on automotive systems will be about CAN, an introduction as to how some networking protocol work and being able to identify and setup virtual interfaces. I hope this article was able to help you understand how CAN works and how most automotive systems work. This article again really was just a base touch and could really give you an idea of where this was going.

~ Totally_Not_A_Haxxer out!

If you like and enjoy more content like this don’t forget to shoot me a follow or check my Instagram page! The support goes a long way

Development organization

Scare-Security

Development page

ArkAngeL43 — Overview

Instagram page

https://www.instagram.com/Totally_Not_A_Haxxer

Cash APP

Pay me on Cash App

Venmo

Venmo | Totally Not A Haxxer hacker