Welcome dear NetworkSecLearners to this new tutorial in which we are going to talk about one of the most important events in the history of Automotive Cybersecurity which is the remote hack of a Jeep Cherokee in 2015. 😊
If you work in this field, you probably already know this story. But I would bet that many of you have only heard the headline version: “two guys hacked a car from their couch”. The full story is far more interesting than that and honestly, it is one of the best Cybersecurity case studies I know because everything is in it. An exposed service, a weak trust boundary, a firmware rewrite, a journalist on a highway, a recall of 1.4 million vehicles and in the years that followed, a much stronger industry focus on Automotive Cybersecurity.😉
As a Cybersecurity Engineer working in the Automotive sector, I can tell you that this case is particularly interesting to me because it became one of the events that pushed vehicle Cybersecurity into the public spotlight. Before 2015, Automotive Cybersecurity research already existed and important remote attacks had already been demonstrated by researchers. However, the Jeep Hack showed the problem to the general public and the Automotive industry in a spectacular and very concrete way : a Cybersecurity vulnerability could potentially become a safety problem.
This point is important because the Miller and Valasek paper itself discusses automotive security research going back to 2010 and remote vehicle compromise research in 2011.
In this article, I will tell you what really happened, how they managed to attack a vehicle remotely, the consequences and the lessons the industry learnt from this. 😊
So grab your coffee, get ready and let’s get started. 😉
1. What Actually Happened
In July 2015, two Cybersecurity researchers called Charlie Miller and Chris Valasek agreed to show their hacking work to Andy Greenberg who is a journalist from Wired. The setup was simple and insane. Greenberg would drive a Jeep Cherokee on a public highway near St. Louis and the two researchers would attack the vehicle remotely from Miller’s basement roughly sixteen kilometers away.
It started simply with the air conditioning switched to maximum on its own. Afterwards, they remotely turned on the radio to a hip-hop station at full volume and the volume knob stopped responding. They also managed to display their picture on the multimedia screen and at last turned on the windshield wipers and washer fluid sprayed across the glass.
Then it stopped being funny when on a highway with no shoulder, the researchers cut the transmission. The accelerator stopped responding and the Jeep slowed to a crawl while traffic came up fast from behind. Later, in a car park, they proved they could disable the brakes entirely and Greenberg rolled the Jeep gently into a ditch.
If you have been here since the beginning, you have probably come across one of my articles that already dealt with that Jeep Hack case study. Indeed, in my article on Introduction to Automotive Cybersecurity, I shared with you a link to a video demo of this Jeep Hack. If you don’t remember, since I am nice, I will give you again and the link of the article.😉 Here is the article link : Introduction to Automotive Cybersecurity
Take a moment on that. The driver was pressing the pedal and the car was ignoring him. Not because of a mechanical failure but because someone kilometers away had decided otherwise.
And here is the part that made the whole industry go pale. This was not a trick against one specific car parked in a lab. The researchers discovered that vulnerable Uconnect systems could be reached remotely through Sprint’s cellular network. An Attacker connected to the Sprint network who discovered the IP address of a vulnerable vehicle could potentially communicate with it from a considerable distance. Their scanning also demonstrated that vulnerable systems could be discovered at scale.
This changed the nature of the problem. It was no longer only about proving that one particular Jeep could be hacked. The same remotely accessible attack surface potentially existed across a much larger population of vehicles equipped with affected Uconnect systems.
Illustration 1 : Remote Jeep Attack Overview
The original research explains that telematics was especially interesting precisely because cellular connectivity gives an attacker a much greater potential range than short-range interfaces such as Bluetooth or Wi-Fi.
2. How They Got In
Now let’s follow the technical chain because this is where the real lessons live. And the striking thing is that no single step is exotic. What is frightening is that they could be chained together at all.
2.1 Step 1 : Exploitation of an Exposed Port of the Multimedia System
The Jeep’s head unit was a Harman Uconnect system running QNX connected to the internet through a Sierra Wireless modem on Sprint’s 3G network. The Uconnect 8.4AN/RA4 system contained a Texas Instruments OMAP-DM3730 processor and handled several functions including infotainment, navigation, Wi-Fi, applications and cellular communication.
When the researchers port-scanned it, they found something they could hardly believe : several open ports and among them port 6667. That port is historically associated with IRC but here it was something else entirely. It was D-Bus, the inter-process communication system of the head unit exposed over the network. And it accepted anonymous authentication. They could simply open a TCP connection to port 6667 using a Telnet client, send AUTH ANONYMOUS and begin interacting with the exposed D-Bus services.
Think about what that means. A component designed for processes to talk to each other inside the device was reachable from the cellular network with no credentials. A vulnerable Uconnect system was therefore exposing powerful internal functionality to other devices capable of reaching it through Sprint’s network. And those addresses sat in known ranges, so they could be scanned. Check the illustration figure below :
Illustration 2 : Initial Access
2.2 Step 2 : Code Execution on the Head Unit
Through that open D-Bus service, the researchers found methods that let them execute code on the system.
And here is where the story becomes even more interesting. During their research, Miller and Valasek found that one of the D-Bus services, NavTrailService exposed extremely powerful functionality, including an execute method capable of executing commands. Therefore, once they could remotely communicate with the exposed D-Bus service, obtaining code execution on the OMAP became surprisingly straightforward.
From there they could upload an SSH key, start the service and simply log in to the car.
At this stage, an Attacker can already do a lot like controlling the radio, the volume, the air conditioning, the display and track the vehicle by GPS. At this stage, this is distracting for a driver but not yet life-threatening and this distinction matters because it comes from the Vehicle architecture.
Indeed, compromising the Uconnect head unit did not automatically give them the ability to inject arbitrary CAN messages. Another security boundary still had to be crossed.
This distinction is explicitly made by Miller and Valasek: although the radio was connected into the vehicle architecture, remote compromise of the head unit did not directly provide CAN access so that further exploitation stages or steps were required.
2.3 Step 3 : crossing into the CAN bus
This is the crucial part so be ready and stay focused. 😉 The head unit runs on a Texas Instruments OMAP chip and that chip physically cannot put messages on the CAN bus. Between the connected world and the vehicle’s networks sits a separate microcontroller, a Renesas V850 which the system calls the IOC.
Under normal operation, the OMAP can talk to the V850 but it cannot make it forward arbitrary CAN frames. There is a functional boundary there. So Miller and Valasek did something elegant and alarming. Indeed, the head unit contained a utility, iocupdate whose legitimate job was to flash new firmware onto the V850. They reverse-engineered the V850 firmware, modified it to relay arbitrary CAN messages coming from the OMAP and flashed their own version onto the chip.
Nothing stopped them because the firmware update path had no signature verification. The chip accepted whatever it was given. The researchers point this out directly in the paper: cryptographic signatures on that firmware would have shut their method down.
Once their modified firmware was running, the OMAP could hand a CAN message to the V850 over SPI, and the V850 would faithfully put it on the bus.
Illustration 3 : Attack Delivery Overview
The original vehicle architecture is particularly interesting because the radio was associated with both CAN-C and CAN-IHS, with safety-relevant modules such as ABS, EPS, PCM and PAM present on CAN-C.
The CAN bus as many of you know was designed in the 1980s with no built-in cryptographic sender authentication.
This means that classic CAN does not provide a cryptographic mechanism allowing an ECU receiving a frame to verify which ECU actually generated it. If an Attacker manages to inject correctly formatted messages using expected CAN identifiers and valid application-level information, a receiving ECU may therefore process those messages as legitimate.
However, this does not mean that every injected CAN frame is automatically accepted. Some ECUs can implement plausibility checks, state-dependent restrictions or detect conflicts between messages. And this actually became important during the Jeep research.
There is one honest nuance the paper insists on, and I will pass it to you because it matters.
For some of the most dangerous actions, such as steering, the researchers had to put an ECU such as the Parking Assist Module (PAM) into a diagnostic session so that it stopped transmitting its legitimate messages. They could then inject the messages required for the attack without competing with the legitimate traffic.
The researchers also observed that these diagnostic operations were generally restricted to low vehicle speeds, approximately 5–10 mph depending on the operation.
So the “kill the brakes at 110 km/h” image is not the whole truth. Some physical attacks were constrained by vehicle speed, ECU state and diagnostic behavior. Other vehicle functions could nevertheless be manipulated through CAN messages without following exactly the same procedure. The safety impact was real even if Hollywood simplified it.
Illustration 4 : Why CAN Injection Wasn’t Automatically Enough
If you summarize the whole chain in Cybersecurity terms, it reads like a textbook: an exposed network service gives Initial Access, a firmware rewrite gives lateral movement across a trust boundary and unauthenticated CAN gives the Attacker a path toward physical Impact. If you have read my article on the MITRE ATT&CK Framework, this structure will be very familiar to you. 😊 If you haven’t, no worry, here is the link to the article : Introduction to the MITRE ATT&CK Framework
And one detail that matters to me professionally: the researchers reported the D-Bus exposure to Chrysler back in October 2014, and the full chain took them close to a year of reverse engineering to build. This was not a weekend project.
The researchers followed a disclosure process over several months. According to their paper, the D-Bus exposure was disclosed in October 2014, the ability to reprogram the V850 and inject CAN messages was disclosed in March 2015, and the cellular accessibility of the D-Bus service was disclosed in May 2015.
But it only has to be built once, and then an attack technique may potentially be reused against other vulnerable vehicles sharing the affected architecture and software.
3. The Consequences
The reaction was fast and expensive so that on July 24, 2015, Fiat Chrysler recalled around 1.4 million vehicles covering Dodge Vipers and Ram trucks from 2013 to 2015, the Jeep Cherokee and Grand Cherokee and Dodge Durango, and several Chrysler and Dodge cars from 2015.
And here is the detail that tells you exactly where the industry stood. The fix was distributed on a USB stick mailed to owners who then had to plug it into their own car or drive to a dealer. There was no reliable over-the-air update.
Imagine discovering a critical vulnerability in a fleet of over a million connected devices and having to mail the patch on physical media, one envelope at a time.
This is in my opinion, the most underrated lesson of the whole affair. The vulnerability was serious. The inability to remediate it at scale was arguably worse.
What actually closed the exposure fastest was not the recall at all. It was Sprint who blocked port 6667 traffic across their network including between devices on the same cell tower.
In other words, the emergency stop was pulled by a mobile operator not by the carmaker.
The researchers explain that after Sprint implemented this network-level filtering, the remote cellular attack path they had demonstrated was effectively blocked. An unpatched vulnerable vehicle would then require a much more local attack path, such as Wi-Fi or access through a femtocell.
That tells you how unprepared the ecosystem was to fix its own product.
4. What the Industry Learned
Welcome to the last section, and the constructive one. Indeed, Cybersecurity became a safety problem, officially. The Automotive World had spent decades building real discipline around functional safety with ISO 26262 and the ASIL framework. But that discipline was built for random hardware failures and design faults not for a thinking Attacker.
The Jeep Hack provided a very visible demonstration of something Automotive Cybersecurity Engineers now take very seriously: a Cybersecurity attack can ultimately produce a safety-relevant physical effect.
Of course, the Jeep Hack did not single-handedly create all the Automotive Cybersecurity technologies, standards and regulations that exist today. Automotive security research existed before 2015 and the evolution that followed resulted from many researchers, manufacturers, suppliers, regulators and other incidents. However, the Jeep demonstration became one of the landmark cases showing why these protections were necessary.
Here are the main lessons we can take today from that Jeep Hack :
4.1 Trust Boundaries and Segmentation Stopped Being Optional
The direct architectural lesson is that a component connected to the internet must never share a trust level with the powertrain. Modern designs use Security Gateways and domain separation to control and filter communication between externally connected systems and safety-critical vehicle networks.
It sounds obvious now but In 2014, the head unit had connectivity into both CAN-C and CAN-IHS, although additional exploitation of the V850 was still required before Miller and Valasek could perform arbitrary CAN injection.
The researchers themselves found the architecture particularly interesting for exactly this reason.
4.2 Secure Boot and Signed Firmware or Secure Reflash Became a Baseline
The V850 accepted unsigned firmware, and that single gap is what turned a compromise of the infotainment environment into a path toward CAN injection.
Today, a Secure Reflash mechanism should cryptographically verify the Authenticity and Integrity of a firmware image before allowing it to be installed. Depending on the architecture, Secure Boot shall also be implemented to ensure that only trusted software is executed during startup.The authors themselves named cryptographic signing of the V850 firmware as an important mitigation.
This is a perfect example of why software authenticity matters just as much as protecting the communication channel used to transfer the software.
4.3 CAN Authentication Became Increasingly Important
Since the CAN protocol cannot be redesigned overnight across a global industry, higher-layer security mechanisms can be used to protect critical in-vehicle communication. One important example is AUTOSAR SecOC or Secure Onboard Communication. SecOC can provide authenticity and freshness protection by combining authentication information such as a MAC with freshness information.
It does not fix everything and it costs bus bandwidth but a receiver implementing the appropriate SecOC verification can reject a protected message when its authentication or freshness verification fails. And suddenly the lesson from the Jeep becomes obvious: Getting access to the CAN bus should not automatically mean that an Attacker can impersonate every ECU connected to it.
4.4 Secure Over-the-Air Updates Became a Requirement
The USB-stick episode made it undeniable : a vehicle you cannot patch efficiently and securely throughout its operational lifetime becomes much harder to protect as new vulnerabilities are discovered. Modern Automotive Cybersecurity therefore also has to consider the complete update lifecycle : Authenticity of the software package, Integrity verification, Authorization, rollback protection, secure installation and the ability to deploy security fixes at fleet scale remotely using the Secure Flash Over The Air (FOTA) technique.
4.5 Regulations Adoptions Became Necessary
Several years after the Jeep Hack, Automotive Cybersecurity became much more formally integrated into international engineering standards and vehicle regulations.
In August 2021, ISO/SAE 21434 “Road vehicles-Cybersecurity Engineering” was published, defining how to manage Cybersecurity across the whole product lifecycle including the TARA, the Threat Analysis and Risk Assessment at concept phase which is a large part of my daily work, the developmennt, production and the post production.
In parallel, UNECE WP.29 adopted UN R155 on Cybersecurity Management Systems or CSMS for short and UN R156 on Software Updates Management Systems or SUMS for short in 2020 and they entered into force in 2021.
These should not be understood as regulations created sbecause of the Jeep Hack. Instead, the Jeep Hack belongs to a broader history of research and real-world demonstrations that showed why connected vehicles needed systematic Cybersecurity engineering, Vlnerability management and Secure software-update processes.
This is perhaps the real legacy of the Jeep Hack. A demonstration on a Missouri highway became one of the landmark examples that Automotive Cybersecurity Engineers would continue discussing years later while the industry moved toward standards such as ISO/SAE 21434 and regulatory frameworks such as UN R155 and UN R156.
If you want the details of that regulatory landscape, I covered it in my article on the Automotive Cybersecurity Standards Landscape you can find here:
Conclusion
Thank you for reading this article till here. 😊 The 2015 Jeep hack is remembered as a spectacular stunt and it was. But what makes it worth studying more than ten years later is how ordinary each step of it really was. There was no single Vulnerability that gave the researchers complete control of the vehicle. Instead, they chained several weaknesses together: a remotely reachable service, powerful internal functionality exposed through D-Bus, a firmware update path without cryptographic signature verification and an in-vehicle network without built-in cryptographic sender authentication.
Individually, each weakness represented a security problem. Combined together, they created a path from a cellular network all the way to cyber-physical actions inside a vehicle.
Illustration 5 : The Entire Jeep Hack in One Picture
That is the part I want you to keep and it reaches far beyond cars. Your system is not secured by the strength of its individual components. It is secured by the trust boundaries between them and by someone actually asking what happens when one of those components is fully under enemy control.
My personal advice especially if you are aiming for a career in Automotive or Industrial Cybersecurity is to go and read the original paper by Miller and Valasek. It is publicly available, is remarkably clear and it is one of the most instructive technical documents in this field. You do not need to follow every line of assembly.
You can then see how they move from one step to the next and how often the next step was possible only because someone assumed it never would be.The paper is called Remote Exploitation of an Unaltered Passenger Vehicle, and it was written by Chris Valasek and Charlie Miller.
And no, cars are not unhackable today because vulnerabilities are still found regularly. The difference is that now there are established Automotive Cybersecurity engineering processes, standards, regulatory requirements and dedicated Cybersecurity teams working throughout the vehicle lifecycle.
I hope this article helped you understand why this story still matters. As always dear NetworkSecLearners, keep learning, stay curious and stay secure! 😊
If you enjoyed this one, please share it with someone who still thinks car hacking is science fiction, leave a comment below telling me whether you would like a deeper technical article on the CAN bus and subscribe to my newsletter so you never miss the next tutorial. It really helps the blog grow and it means a lot to me. 😊
References
Miller, C. & Valasek, C. (2015). Remote Exploitation of an Unaltered Passenger Vehicle.