When I started out in pentesting, the map of the world looked fairly simple. There was infrastructure testing and there was web application testing. Mobile, at a push. That seemed to be the whole available territory, so that is where I went: bug bounty, smaller engagements, more reports, more application vulnerabilities.
Then I joined Bosch and it turned out the map was incomplete.
Discovering the field exists
Automotive cyber security is a discipline you simply never hear about on a typical pentesting track. It is absent from the popular courses, rarely shows up at conferences aimed at web people, and there are almost no bug bounty programmes you can walk into off the street. Yet it is a fully fledged, enormous area of security, just hidden behind an entry barrier made of hardware and domain knowledge.
Landing at a company sitting in the middle of that ecosystem was something like entering through a side door.
The history here is worth getting right, because it is not a random place to end up. CAN, the Controller Area Network, was developed by Bosch and released in 1986. It is the bus that still forms the communication backbone of practically every car on the road. FlexRay is a slightly different story from the one people often repeat: the consortium was founded in 2000 by BMW and DaimlerChrysler together with Motorola and Philips, and Bosch joined a year later as one of the core members, contributing its experience from CAN and TTCAN. The consortium dissolved in 2009, handing the specification over to ISO, where it lives today as the ISO 17458 series.
I am not writing this for bibliographic tidiness. I am writing it because working somewhere these protocols were built changes your perspective. CAN stops being an abstract diagram in a slide deck and becomes something whose behaviour the person next to you understands from the design decisions made forty years ago.
How this differs from web pentesting
This was the most interesting part of the switch for me, so I will spell it out properly.
There is no authentication layer where you expect one. A classic CAN bus is a broadcast medium. Every node sees everything on the wire, and historically there was no built-in mechanism to confirm who actually transmitted a given frame. The protocol was designed in an era when the threat model assumed that anything attached to the bus was trusted by definition. The entire modern security layer, including frame authentication mechanisms, was bolted on later, onto a foundation that never anticipated it.
The consequences are physical. That sounds trite until you see it. In a web application, the worst outcome is a data leak or account takeover. Here you send a message and a mechanical component moves. I remember the first time I issued a command directly to a controller and saw a real physical reaction on the other end. It completely changes your relationship with what you are doing. There is no undo button, and a mistake can mean damaged hardware worth a great deal of money.
The feedback loop is slow and expensive. On the web you have Burp, you push a hundred requests a minute and see the response instantly. Here you need a bus interface, a correct network description, a properly assembled bench, sometimes an entire vehicle, and every test cycle takes time. Vector-class equipment, which I worked with, is highly capable and highly expensive, completely out of reach for someone tinkering at home after hours. That is one of the main reasons this field is so thinly staffed.
The documentation is closed. On the web you have RFCs, MDN and OWASP. Here the key network descriptions and signal mappings are manufacturer property and covered by agreements. Without them you are left with traffic observation and inference, which is reverse engineering in its purest form.
And that last point turned out to be the thing that hooked me hardest.
The toolkit
Without going into project specifics, since those are covered by confidentiality, the set of skills I built at the time looks like this:
- Fuzzing scripts in CAPL for testing ECUs, running in the Vector environment. This was the main focus of my work and also the most interesting part of it.
- Working with CAN and FlexRay buses, including traffic analysis and communicating with control units on test benches.
- ECU testing, meaning verifying how a unit behaves in situations its designer did not necessarily anticipate.
- Reverse engineering bus traffic, meaning reconstructing the meaning of signals without access to the official network description.
A few words on fuzzing in CAPL
CAPL is a language specific to the Vector environment, strongly event-driven, designed around handling bus events. It fits scenarios of the form "send a sequence, wait for a condition, check the reaction" very well, and with some work it also serves for building test input generators.
Fuzzing an ECU is conceptually the same as fuzzing any other software: you feed inputs that deviate from what the implementation expects and observe whether it still behaves correctly. The differences live in the details, and the details are what make it interesting.
The oracle is a problem. In classic fuzzing you have sanitizers and a clear signal in the form of a process crash. Here the controller is a black box on the other side of the bus, so you have to construct your own definition of what "something went wrong" means: no response, a response inconsistent with the specification, entry into a fault mode, a reset, or a behavioural change only observable on physical outputs.
Throughput is bounded by physics. The bus has its speed, the controller has its response times, and after a failed iteration you often need to return the device to a known initial state. The number of test cases per second is orders of magnitude lower than fuzzing a library on a development machine, so the quality of the generator matters far more than its raw speed. Blindly randomising bytes simply does not pay off.
State matters. A controller lives inside a state machine: diagnostic sessions, access levels, conditions that depend on whether the vehicle is stationary or moving. Interesting behaviour usually sits not in a single message but in a sequence that moves the device into a state where the next message is handled differently from what the designer assumed. A fuzzer that does not model state bounces off the first wall and never goes deeper.
Reproducibility is mandatory. A finding that cannot be reproduced is worthless to the team that has to fix it. Logging the full run, preserving ordering and timing, matters just as much as the generator itself.
Worth adding: fuzzing is not a research curiosity in this industry, it is part of the normal process. The ISO/SAE 21434 standard treats this kind of testing as part of security verification, so manufacturers and suppliers do it because they have to, not because someone insisted.
I will call out reverse engineering of bus traffic separately, because it is the skill that transfers most broadly. Once you learn to look at a stream of seemingly random bytes and systematically narrow down hypotheses about what they mean, the same method works on binary protocols, file formats and firmware.
The project that taught me the most because we never finished it
Now a story I will tell in general terms, and I will explain why in a moment.
I once had a very concrete, very mundane idea. In a certain popular SUV there is an audible alert feature that can be deactivated from the menu, but the setting does not survive an ignition cycle. After every start the vehicle returns it to the default state. A classic case where a feature formally exists but is useless, because the state is not persisted.
The question was: where does that state actually live, and why is it not being written.
A more experienced colleague and I took a car and started digging. It was a very instructive project, though not for the reason I expected, because we never finished it. Three things stopped us, and each deserves its own paragraph.
Time. Working in free windows between projects means every restart begins with rebuilding context. In an analysis where all the value lies in accumulating understanding of a system, that interruption pattern kills momentum.
Hardware risk. This was an ordinary used car, not a test bench. Knowing that a careless action could brick a module worth as much as a decent second-hand car is a very effective way to cool your enthusiasm for aggressive attempts. So we limited ourselves to observation, without intervention, and that was the right call.
Legal considerations. This is why I am not naming the make, the model, or any technical specifics. The licence terms of the infotainment system prohibited reverse engineering. That is a contractual obligation, entirely separate from the fact that EU copyright law provides certain exceptions for software analysis aimed at ensuring interoperability. On top of that, driver warning functions are in some jurisdictions subject to type approval requirements, so publishing instructions for permanently disabling them is problematic from a completely different direction.
To summarise: the fact that something is technically interesting, and that it is your own car, does not automatically mean you can publish a full write-up about it. That distinction is worth internalising early, ideally before you write the post.
Two takeaways stayed with me. A technical one: a great deal of apparently irrational behaviour in a car is not a bug but a design consequence, following from where state is stored and who is permitted to write it. And a professional one: in this field, the legal boundary is part of the craft, exactly like the ability to read traffic on a bus.
What I cover in talks
I present some of this material at speaking engagements, because automotive security has the advantage that the examples land even with people outside the industry. Everyone holds some mental model of a car, so it is easy to show where that model diverges from reality.
Vehicle theft, the part after which people go check their own driveway
The device in a Game Boy shell. In 2021, West Yorkshire Police arrested three men who had stolen five Mitsubishi Outlanders worth more than 180,000 pounds in total. The tool they used looked like a Nintendo Game Boy, complete with a counterfeit Supreme case, and was valued at around 20,000 pounds. It unlocked and started a car in a matter of seconds. According to later reporting, the electronics came from an outside supplier and were repackaged into the console shell.
This is my favourite slide, because it demolishes two myths at once. First, that such attacks require a laboratory, given that this one fits in a pocket. Second, that this is the work of geniuses, given that the perpetrators simply bought a finished device and filmed themselves using it on a phone.
CAN injection, the suitcase and the headlight. An even better story, because it is genuine detective work. Someone twice tore apart the headlight on Ian Tabor's Toyota RAV4, which looked like pointless vandalism. Three months later the car was gone. Tabor, together with Ken Tindell of Canis Automotive Labs, traced the diagnostic trouble codes and reconstructed the method, which they named CAN injection. It was assigned CVE-2023-29389.
The core of it is this: a headlight today is a control unit, not a bulb on a switch, so it sits on the same bus as the smart key module. A thief does not need to reach the key module itself. It is enough to reach any point on that same bus, and the headlight is simply the most convenient one, because it sits behind the bumper. The device then impersonates the messages of the smart key module. The hardware was sometimes concealed inside a Bluetooth speaker casing and sold as an "emergency start" tool at prices in the thousands of euros against a parts cost measured in dollars.
And here comes the line I build the slide for: this is not one manufacturer's defect. It is a consequence of CAN having been designed as a network in which anything attached to the bus is trusted by definition. Tindell pointed out that a software update can mitigate it in the short term, but the real fix is a zero trust approach to the bus, meaning cryptographic authentication of messages.
The Tesla Model X and its key fob. In 2020 the COSIC team at KU Leuven demonstrated unlocking and driving away a Model X within minutes by exploiting weaknesses in the key system. Tesla patched it in software release 2020.48. I include this example because it shows the problem is not confined to older designs, and it also illustrates the significant advantage of being able to push a fix wirelessly to an entire fleet.
Researcher footage: youtube.com/watch?v=clrNuBb3myE
The Jeep on the highway, the moment the industry grew up
You cannot tell this story without this example. In 2015, Charlie Miller and Chris Valasek remotely took control of a Jeep Cherokee travelling on a highway, with a Wired journalist behind the wheel, entering through the infotainment system and reaching vehicle control functions from there. The result was a recall covering roughly 1.4 million vehicles.
That event did for automotive security what the Morris worm did for network security. It proved the matter was not theoretical, and it set off the chain of events that ended in regulation.
Footage: youtube.com/watch?v=MK0SrxBC1xs, the Wired write-up: wired.com/2015/07/hackers-remotely-kill-jeep-highway
The thought experiment that quiets a room
You are on a German autobahn, on a derestricted stretch, doing 300 kilometres per hour. At that moment a control unit impersonating the braking system transmits a full braking command.
This is a hypothetical scenario and I say so plainly from the stage, because I have no interest in cheap sensationalism. But it is not fantasy. It follows directly from the direction the industry is heading. Steer-by-wire and brake-by-wire replace a mechanical linkage with a message on a network. Once there is no longer a physical connector between the pedal and the caliper, message integrity stops being a comfort feature and becomes a functional safety matter in the most literal sense.
Which is why the whole talk is not really about car theft. Theft is a financial loss. This is a different category of problem.
The same pattern in the air and on the water
The last thread, and usually the one that opens people's eyes: this same pattern repeats outside the automotive world.
Aviation. Airbus aircraft fly on a fly-by-wire architecture, where sidestick deflection is a signal to onboard computers rather than a mechanical link to control surfaces. The underlying principle is shared with automotive by-wire systems. That said, it is only fair to be clear about the differences, because aviation approached this quite differently: different buses such as ARINC 429 and AFDX, mandatory redundancy, the principle of dissimilar design in which the same task is handled by independently engineered systems, and dedicated airworthiness security standards, DO-326A and ED-202A. On top of that, the in-flight entertainment domain is separated from the control domain at the architectural level, not by good intentions. The widely reported claims some years ago about an aircraft being commandeered through the entertainment system were never substantiated, and that is worth stating plainly.
Yachts and marine vessels. Here the analogy is almost literal, because the NMEA 2000 standard, used for communication between navigation instruments, autopilot and engines, is built on CAN. The same layer, the same properties, the same absence of built-in authentication. With the difference that the marine market faces far less regulatory pressure than the automotive one, and has far fewer researchers looking over its shoulder.
That last observation is a good bridge to the next point.
Why this ground is still so lightly explored
Automotive security is narrow because the barriers are real. You need hardware, access to vehicles or benches, knowledge spanning electronics, embedded systems and classic security, plus patience for a discipline where a single test cycle takes longer than an entire web application assessment.
The consequence is that the ratio of researchers to attack surface is incomparably more favourable here than on the web. A modern car is a network of dozens of controllers, and well over a hundred in the premium segment, with cellular connectivity, Bluetooth, Wi-Fi, over-the-air updates, a mobile app, a manufacturer backend and an entire supplier chain, each contributing its own code. That is an attack surface the size of a decent enterprise, except it drives down the road.
Then there is regulatory pressure. UNECE R155 and R156, along with the ISO/SAE 21434 standard, mean manufacturers must have documented cybersecurity and update management processes to obtain type approval in many markets at all. That translates directly into demand for people who can test these systems, and demand well in excess of supply.
Manufacturers outside the automotive sector have their own version of that pressure in the Cyber Resilience Act, which works on the same principle: no documented process, no market. Whether a given product falls under it is settled by the five question test.
In other words: this is a niche where a great deal is still left to find, and few people are looking. A rare combination.
How to get in without access to a lab
I am not going to pretend it is easy, but several things can be done on your own budget.
- Learn the fundamentals of in-vehicle networks from the theory side. CAN, CAN FD, LIN, FlexRay, Automotive Ethernet, plus the diagnostic layer. Understanding why CAN arbitration works the way it does tells you more about possible attack classes than any ready-made guide.
- Start in simulation. Linux has a native SocketCAN stack with virtual interfaces, so you can practise with tooling and write your own parsers with no hardware whatsoever.
- Cheap hardware exists. CAN interfaces for the price of a takeaway meal, and salvaged controllers bought for very little, are enough to build your own bench. A controller on a desk cannot hurt anyone, unlike a controller in a moving vehicle.
- Do not experiment on a car you drive. Seriously. This is not a disclaimer, it is practical advice about money and safety.
- Treat embedded reverse engineering as a base skill. Firmware analysis, binary formats and protocol work pay off in this field immediately.
- Read industry publications. The community is small and a lot of the valuable material circulates in conference talks and academic papers rather than blog posts.
Open to collaboration
If you are looking for a person or a team for an automotive security project, whether that means security analysis of built-in vehicle functions, bus communication testing, or building a product in this space, get in touch. I am particularly interested in work where something has to be figured out from scratch, without ready documentation.
That happens to be the part I enjoy most.
The scope of testing I run is described under services. Automotive work is quoted individually rather than from a day range, and how much a penetration test costs explains why. If you have a project that needs figuring out from scratch, get in touch.
Closing thought
I started with web applications because I assumed that was the whole available world. It turned out there is a field where the same instincts, questioning the designer's assumptions and checking what a system does in a situation nobody anticipated, lead to something that then physically moves.
And honestly, that physicality is the most addictive part of it. A vulnerability in an application is an abstraction on a screen. Here the coupling between what you send and what happens in the world is direct and immediate.
Which is also, incidentally, the best possible argument for doing this responsibly.
Worth a look
- Standards: ISO 11898 (CAN), ISO 17458 (FlexRay), ISO 14229 (UDS)
- Regulation: UNECE R155 and R156, ISO/SAE 21434
- SocketCAN in the Linux kernel, for practising without hardware
- Proceedings from conferences focused on embedded and automotive security