Automotive Security: CAN | Introduction && Layout
As you have imagined, in my automotive security series, we were eventually going to have to talk about automotive protocols! So here we are hahaha. In this module actually, we are going to be talking about many different protocols around CAN. This is because CAN has so many different sub sets and examples of what the protocol is but the primary focus will be CAN. To better define this article I have laid out everything we will be going over below!
Automotive Security: CAN | Terminology: A section that will talk about the terms and specific definitions or names we will be using in this article followed by a brief explanation of what they are.
Automotive Security: CAN | Automotive Networking: We have already in previous articles talked about how automobiles network on a base level. But this time we are going to be going a bit deeper, referencing protocols such as CAN, FlexRay, MOST and other protocols that are commonly used in conjunction with each other.
Automotive Security: CAN | The CAN Protocol: This obviously as it states will go over a base introduction to CAN and what it is as a protocol, how it works, standards and systems such as OBD (II/2). We will also talk about tools hackers or general testers may use to sniff and even manipulate the networks in automobiles that use CAN.
Automotive Security: CAN | The CAN-FD Protocol: A smaller explanation about a secondary “version” or rather implementation of CAN known as CAN-FD.
Automotive Security: CAN | The Common ISO-TP Protocol: Since this article is talking about CAN, why not bring up the overly popular and well known, closely associated protocol known as ISO-TP or the ISO Transport protocol!
Automotive Security: CAN | How It Parties!: A section that talks about the tools that hackers use to work with CAN messages and logs and why they may need them to manipulate the protocol!
Automotive Security: CAN | Why Security Is Important: This section will talk about the physical attacks that typically involve reverse engineering the communication protocols and how easy it is.
Automotive Security: CAN | Getting Real: This section will be the technical aspect of CAN such as going over its frequencies, how its found via meters and readers, and technical details about the packet layout. This is an extension of the Automotive Security: CAN | The CAN Protocol but instead we go more into the protocols technical aspects like its frame and more deeper components.
Automotive Security: CAN | Summary && Conclusion: A conclusion to the article as well as a small ending note which trails into our next section.
Automotive Security: CAN | Ending Note: A note where you can find all information about me as far as finding me, supporting my page, figuring out some resources as to how to advance your knowledge in the realm of automotive networking.
Now, I will try to keep this article under 40 minutes as that would be a good target, but if it goes over then I apologize- I talk ALOT :D (LOL)- Alright, lets get started! Whoop!
Note: Occasionally throughout this article, you will find frequent authors notes to express specific feelings or states for the reader such as telling you to hydrate and back off the read for a second XD! So, expect a GIF or two throughout this article that may be of a cat in burritos, general cat, maybe a dog flying a plane or something out of wack. I do this to also keep the articles more interesting and to hopefully make the reader laugh while they can and give that brain a slight break.
Automotive Security: CAN | Terminology
Vehicle / Communication BUS: A communication bus is the type of system or communication network in a vehicle that allows different electronic components and systems within the vehicle to exchange specific sets of information.
ECU → Electrical Control Unit: This context gets people, but an electrical control unit is just a unit or module in a car that controls a specific electrical system within a car or automobile. We use ECU in this article but you may also come across ECM which stands for Electrical Control Module. This is because the term ECU can be hard to understand especially for beginners or at least easily mixed up with a engine module which is known as an ECU. See, that got confusing did it not?
ECU → Engine Control Unit: The engine control unit or engine control module is a module that works directly with the electrical components of an engine.
FR / FlexRay: A communication protocol used frequently in luxury cars: we will go over this more in the article.
CAN: Also known as Controller Area Network or just CAN is a communication protocol that is frequently seen in vehicles all around the world. This is the focus of this article.
OBD (II/2): Also known as On Board Diagnostics is a type of system for diagnostics logging within cars which heavily relies on the CAN protocol as well as other various protocols depending on the general implementation of OBD ports and systems.
LIN: Local Interconnected Network is a much more smaller and slower network used for lightweight automotive tasks.
MOST: Media Oriented Systems Transport protocol is a protocol that is designed for media in automobiles and other various systems.
KWP2000: Also known as the KeyWord Protocol 2000 was a protocol or is a protocol that came out in the early 2000’s which is used in close relation to OBD.
ISO J1850 BUS: A communication BUS or protocol that is used for diagnostics and data sharing applications in vehicles. As you can imagine, we will also be coming across this protocol when talking about OBD2.
CANH: Controller Area Network High ( this is described later just keep a look out for the direct meaning )
CANL: Controller Area Network Low ( also described later )
HS-CAN: High Speed Controller Area Network
LS-CAN: Low Speed Controller Area Network
MS-CAN: Mid Speed Controller Area Network
ECM: Engine Control Module
CAN-FD: Controller Area Network Flexible Data-Rate is a much more advanced and enhanced version of the traditional Controller Area Network protocol (CAN).
AE: Automotive Ethernet
ISO-TP: The ISO-TP also known as ISO 15765–2 or ISO Transport Protocol is a protocol that plays quite the important role in enabling the transmission of longer messages over the CAN bus.
Automotive Security: CAN | Automotive Networking
Alright, lets talk for a moment. You right now ( the reader ) may have some form of newer car, something like a 2012–2019 model and think that your car truly is not “Digital”. Well, obviously, the point in this section is to show you how wrong you might be on that assumption. So, what do I mean by this? Well, every single car to date uses something known as a communication bus. If you have not heard that term before, in the context of this article — a communication bus, as the name implies, is a way of sending data using a specific network type such as CAN. The name “bus” can be commonly associated with the idea of transferring or moving data. Pretty much, a communication bus is a network protocol. But why do cars need these? Why does, anything moving need it anyway? Lets think about this for a second and put this in some form of scenario. Say you have a car that is considered more “smart” and has a combustion engine in it so its not directly EV fully. Your car in some shape or some form needs to make sure that it can properly transfer diagnostics data to your cars meters, also that it can do it quick and the same goes for fetching radio stations, music, even something down to your turn blinker! To basically clear that up a bit, each automobile and even something as small as a plane may need some form of communication bus to ensure that it can actually properly transfer data throughout the car! This is because instead of every electrical control unit also known as an ECU or just electrical module such as the ECU ( Engine Control Unit ) and TCU (Transmission Control Unit) sitting on one giant central module ( which will clutter space, make the system super slow and not so performant ) they need to be split up on the same network so they can collect their own data and information and send them through the network which then could be passed to another module.
To break this down in more simpler terms — with cars even older cars having so much systems that rely on some form of communication to make the car much more faster ( in terms of diagnostics and general controls ) and much more performant,you can not just slap it all into one electrical module, you have to spread them out on some form of network or communication protocol. That is the lightest way I can put this for now anyway haha! But, why do I keep referencing protocols? Well, as you imagine, like every other standard network such as WiFi networks, comes a set of unique protocols that can be used. Well, since each communication bus is the protocol implementation, there are quite the amount to use! Below I have made a list of commonly known protocols that are used within automobiles today and are used in general networking.
CAN: The first communication bus or protocol to talk about as the topic of this article is, is CAN. CAN is one of the most frequently used and talked about protocols and almost everyone knows about it. But what makes this protocol so nice and popular? For starters, this protocol was one of the very first protocols for the automotive world and not only was cheap but was extremely performant! This protocol did many things because its general base implementation is not that complex, one of those things was saving space and money for developing or pumping out cars! This was at a time where cars were still made very durable, where cars were extremely well built and designed and are sadly not found today — that is right, I am talking about the 80's! Specifically, CAN was developed in 1986 in a German multinational engineering and technology company named Robert Bosch GmbH. This protocol was again made quite cheap, and improved the automotive world not just for the drivers and users of the cars but also the manufacturers who needed a unique way to produce vehicles without the insane cost of copper wiring for vehicles! This protocol is just cheap but also really easy to work with and much more performant, plus it was the earliest protocol that was fully adopted by automotive manufacturers! This is also the protocol that again we will be focusing on primarily that has so many different unique sides to it!
FlexRay: The second most used and popular protocols is a protocol type of luxury cars pretty much. This protocol is commonly used with cars that are along brands like Audi, Mercedes, Lamborghini, Bently, and other various vehicles. Woah- slow the role, why is it only used in more luxurious cars? I have adopted the term “luxury” protocol because it is the one protocol that not many car companies use which is primarily due to how costly it is to implement. See, FlexRay is a protocol like no other! This of course comes with a downside — adaptability. The FlexRay protocol is not only much more structured but also much more safer, performant, advanced, time unique, and more! What does all of this mean? This protocol is unique in its own way and one of those ways is its time uniqueness and performance as it perfectly times every single instruction and discards it if it is not on time whilst also using specific systems to make the network go much more faster! The issue with this is again, complexity. Complexity especially in today’s world is just- through the roof, so, automotive manufacturers do not really want to add MORE complexity onto a vehicle where it becomes the MOST ( pun intended ) complex and expensive car to produce, especially if they want to make money from the vehicle they are selling and seriously throw themselves out there. But you might be asking, why would some automotive manufacturers such as Audi and Mercedes even use this protocol if their cars especially newer ones are already complex enough? This is a good question that has a ton of bias and is never truly answered ( its a huge debate ), but the general idea is surrounded by how much funding the company is willing to put into vehicle development as well as how much their cars usually run for and if its a company like Audi — then simply because, they were the ones that made it. Here is a historical background for you, FlexRay was not developed by one man, or class, or group or company — it was a join protect between multiple automotive manufacturers in the early 2000’s such as Mercedes, GM ( General Motors ), Audi, BMW, Volkswagen, and Daimler as well as two other primary companies. This joint project was not only heavily researched but had the end goal of creating something much more sophisticated, proprietary, secure, fast, technical, and every other word culture could possibly imagine at the time for the word “advanced”. This is why the protocol is not used in many cars, because too much advances and too much complexity can be a pain for a company to implement if they were not exactly the ones that decided to invent the protocol — but other vehicles also use it such as Bently and Lamborghini especially in the Huracán. Concluding this protocol, FlexRay is much more complex, expensive and harder to both manipulate but is very much worth the safety and unique systems that FlexRay has in place.
LIN: LIN also known as Local Interconnected Network is a different type of protocol. If you are familiar with networking, this name may get you quite well and easily. As the name implies, like all other protocols in this list, LIN is a local and much more inexpensive automotive protocol that is much more easier to implement. This — this protocol is the reason I went over CAN and FlexRay hoping from cheap to expensive, simply to make this point. The LIN protocol is a much more cheaper option to CAN, but you may be thinking — why use LIN a much more cheaper protocol with most likely less safety and systems than something like CAN? Because implementing CAN on every single automotive operation would just make the protocol overly expensive and would not be worth the time, this is where LIN and hybrid automobiles ( not in the EV sense, I mean in the general network world, hybrid, meaning it works with both protocols or systems rather than one; in this article anyway. ) come into play. LIN is a protocol that was designed purely for secondary implementation, something that can be used to lighten the load on automotive manufacturers because of how expensive cheaper protocols such as CAN are to implement on every single operation and system. There is not much to go into about this protocol, but the primary idea is that it is a unique, smaller more lightweight and cheaper option for tasks that do not necessarily require top notch speed and synchronization and do not need any heavy loading or transferring. This makes LIN a fantastic alternative to CAN in very specific scenarios.
MOST: The MOST protocol also known as the Media Oriented Systems Transport protocol is a type of network protocol that is also in count with luxury protocols but is typically used for infotainment consoles. I do sometimes count this in the realm of luxury protocols even though its a very very very VERY low branch of it. This is because the protocols implementation typically depends on the systems complexity and what you are using it for and how much you are actually going to use it. The reason MOST is good for infotainment consoles is because it does really well with having a high and versatile data transfer all of which makes it really good for audio and video streaming especially if its from device to device! This protocol is also unique and is typically not used for primary network holds or actions but has been before ( sadly as its name is literally for media based systems) but regardless, it is a quite well used protocol in the automotive world and helps quite well!
There are tons and tons more protocols that are all used for different things. But, these protocols are all important for their own reasons and they all exist for a reason! But, lets focus on the bigger deal. When it comes to automotive security, why should you understand the protocols that cars may use especially the most popular ones? There are some good reasons as to why this may happen and why someone may want to understand it and the primary reason is to attack the physical aspects of the car, see if there is anything extra or hidden in the cars network, understanding how to reverse engineer networks and protocols as well as just understanding how data in the automobile or car in this context can be manipulated. This is also super useful because it sharpens our knowledge of automobiles and how they work in and out which can also reveal more information in the future for reverse engineering maybe a new protocol, new version of a protocol and even understanding how to gain access to a automobiles network as we will talk about in this article. Why physical access? Because typically, when working with automotive communication buses, you need physical access to the network in some shape or form in order to sniff the data, analyze it and reverse engineer or log important aspects of the data within the automobile.
Note: I know I am changing between terms ‘car’ and ‘automobile’ but note that when I reference ‘automobile’, for the context of this article, I am purely referring to cars as that is the focus of the security world.
Right, back to it shall we? Lets actually talk about the protocol itself, how do they work, how do they exist, and how could one say get physical access to a network such as CAN?
Automotive Security: CAN | The CAN Protocol
This section will actually be a bit shorter than you thought, this is because I want to ensure that we get a basic idea of how the protocol works, what its primary job is, its historical background in a bit of a deeper detail and then talk about the different formats. For the readers time, I have broken this section down into its own primary subsections.
The CAN Protocol: Who, What, Why → A section that talks about who developed it giving you a bit more of a understanding of who developed it ( history ), What exactly CAN tries to achieve on a higher level and also what exactly CAN fails at doing best that other protocols may have done better and finally Why the protocol exists.
The CAN Protocol: Digging Into Diagnostics → A section that talks about the physical parts of CAN, where it becomes helpful, how it becomes helpful and talking about OBD and using scan tools as well as other alternatives. In this section we will be going over DTC’s as well. We will finally end on how hackers use these ports to gain access to specific systems in automobiles! Note that this section will be a primary sub section because of how deep it goes into OBD tools and utilities as well as the different protocols. We will talk about the different forms of CAN which come in CANH and CANL.
The CAN Protocol: Summary Of Section → Summarizes and concludes the point of this section.
Now, the first thing I would like to give you is the brief background of CAN and a bit more on the side of why it exists other than saying “ah yeah man trust me, its just high speed and cheap!”: I actually want to tell you about it on a deeper scale LOL.
The CAN Protocol: Who
We all know why you are here, so lets get into it. As mentioned before, the CAN protocol was invented or actually initially started in 1986 by a German multinational engineering and technology company named Robert Bosch GmbH. Cool, We got that out of the way. I know, small right? Because honestly, its not like we need to go deep into who invented it, more or less about why and what. However, its always good to have a good understanding of where things come from sometimes LOL.
The CAN Protocol: What & Why
Lets make this section short. The CAN protocol also known as Controller Area Network protocol is a type of network communication protocol that is commonly used in cars. That is the similar definition of it anyway. But really, in smaller terms — CAN is the way most vehicles ( at the time of writing ) communicate data between each other digitally. CAN exists for many different purposes- but lets go back long before the days of CAN and actually during its development.
During the time of the development of CAN and even before, cars relied HEAVILY on tons and tons of electrical units, modules and all this wiring and fancy ( at the time ) electrical systems to do a majority of the heavy loading. The issue with this is that any system or module would be purely mechanical and not really have any form or sense of actual transforming of data that could be fast, concise and much more unique. At the time, it was not too much of a problem given how easy it was to produce hard core steel vehicles and systems that were just unique given the economy of the world and the also small amount of population. As the population started to increase and tech started to grow, systems had to be mass produced, systems and cars especially needed to implement new systems up to the current standards, this also meant that to meet the demand of all these systems and all the population they also need to make ends meet financially. The issue with this is that you can not produce steel cars for the world because steel in itself is quite expensive, so as we saw with the steel cars — they had to cut a bit of funding and had to move to cheaper materiel. The same happened within the cars modules, someone somehow needed to find or figure out a unique solution that could solve an issue for the mass demand in copper wiring for automotive manufacturing across the world! Well, the people over at Robert Bosch GmbH were the ones to actually step up and solve multiple problems. I know this is kind of all over the place, so lets tidy it up a bit. Take the following list of primary issues back then with cars without automotive protocols or unique systems to aid the car.
Too Much Material To Produce: As with anything, companies as we mentioned above needed to start cutting ties to not only lighten how heavy and deadly cars can be but also for the simple factor of how much wiring using materials like copper was needed back then for each module and system. The method of trying to tie each module within the car just became too complex for the time being given that technology especially with cars was just at the point of breaking and completely skyrocketing!
Too Complex For Mass Production: Because of the amount of material is needed to produce a car, not to mention work with diagnostics systems that were in the car, new mechanisms and safety features, the production became WAY too complex for companies to continue on. Well, lets put it this way, they could always have gone forward but it would have not been beneficial in the end.
Not Enough Diagnostics systems: While diagnostics systems partly existed in terms of getting small amounts of data such as the gas reading on cars and even the RPM’s and MPH’s the car was going at, this was not enough. In the event of a crash, forensics experts could not always figure out everything in a car that they needed to in order to make the investigation more structured and the same went for mechanics trying to operate on a vehicle. Not to mention, if it was electrical, it might have taken more out of the mechanics to operate on the vehicle.
There are some others that we could point out, but lets now go through how CAN exactly solved this issue. The following list shows the title of the above sections + some other added sections. If the section name was previously declared in the section above or point above, then it will have a tag saying [fix] indicating that said tag tries to show or tell you how the invention of the protocol fixed the problem described.
Too Much Material To Produce[fix]: CAN was able to fix this for multiple reasons but primarily in the realm of wiring complexity. As mentioned before, wiring in cars was a huge problem the more cars became much more complex and started to have all of these unique systems in place. CAN was able to fix this in the regions of modules because of how CAN introduced a two-wire bus system, which reduced the amount of wiring required and simplifying the overall vehicle electronics architecture. It pretty much eliminated point-to-point communication which is what vehicles used to use prior to the invention of CAN. This helped because it limits how much wiring is used for each module and system in place.
Too Complex For Mass Production[fix]: As mentioned before in the previous point, CAN fixed the wiring complexity, but how was this at all a problem other than the factor of being too much to produce? Remember how we talked that the primary reason FlexRay was not used as commonly as CAN is because the protocol requires a ton of complex systems, specific requirements, required engineers and more? This is the same idea. With the systems in vehicles becoming more complex, so did wiring along with it. This lead to much more annoying wiring systems and much more hard-to-mass-produce issues. CAN solved this because it cut at least half of the wiring in automobiles. The primary solve here was that it improved mass production processes and lowered the potential for wiring-related issues.
Diagnostics [fix/new]: This was something that already existed in cars as data was actively recorded and then sent to meters or specific systems in cars on a base level anyway. CAN on the other hand would do some thing similar but much more technically advanced and digital! For starters, as we mentioned before, when it comes down to getting diagnostics data within an automobile at least before CAN; mechanics had to use very specific tools for each module and would also become quite tasking. Because of the unique systems that CAN introduced such as DTC ( Diagnostic Trouble Code ) standardization and also allowed the use for specific modules to connect and send data to each other, the only thing needed is a singular tool anymore to get most of the information needed in terms of diagnostics. Not only does this cut down on time but it also cuts down on electricity and usages and other various important factors.
Scalability and Flexibility: As you are pretty familiar with already, the more cars became more unique and technologically advanced the more modules and sensors would be added to a car. Without a protocol that was as easy and flexible as CAN, there would not be a good or safe and cost effective way of being able to integrate new components.
That is the base idea to give you a good reason as to why can does and should exist. However, as this article and series goes over, we understand clearly that automotive protocols are just vulnerable. But we also understand that giving them up is a risk we can not take and the whole world would take years and years or might not even be able to properly adapt! So, to answer the question of “why” especially when it comes to “why use them if they are vulnerable in some aspects or can be deadly” is because using it is the lesser of two evils. Now not to mention, even if we did want to work with cars without CAN, that would kill 90% of the systems used in CAN at this point. This is because without protocols such as CAN, there would be no possible or direct way to properly manage so much priorities in the automobile. Lets put this in deeper terms, each protocol needs a way of making sure that some data is priority on the chain of messages if one or more messages are sent at a time. CAN does this in multiple ways and it does this because if one message is say an emergency diagnostic, then it may need to be sent first before another message within the vehicle to make sure the driver gets a good notice of what is happening. The primary point here being that when it comes down to automotive networking and protocols such as CAN, they exist because they improve transportation in so many ways and NOT JUST automobiles but even exist in factory equipment, drones, and many other means of robotics that automate and improve human life day after day. Sure, like everything, CAN will have its downfalls, but every system has its downfalls. Speaking of, lets go ahead and make a good note on what CAN does best and what it does worst in terms of why there are so many different protocols.
I am not sure if you ( the reader ) are a programmer but I assume if you are in a security research field especially something as big and huge as automotive security, then you understand some form of programming. Did you know, that there are over approximately 250–2,500 programming languages in the world? If you did not, the question or fact might be a bit confusing to you, “why so many”. Well, similar to automotive protocols, every single programming language has its own use. Some programming language’s may deal better with memory than others and others may do better at networking. For example, Golang is great for web and networking whilst something like Rust might be better for embedded development and vice versa with Crystal. Each language has its meaning. Well, in the context of this article, CAN also has its own unique pros and cons list and there are protocols such as FlexRay that just do so much more better than CAN in specific area’s. For example, MOST exists because it is designed for media systems like infotainment consoles. While CAN could kind of do the job, its good to have a protocol dedicated purely to media systems instead of relying on one protocol entirely. Same reason that LIN exists. Below I have given a good pros and cons list of the CAN protocol.
Cost: As we have went over more times than we can count, the protocol cuts down manufacturing costs due to how light or actually how medium weight the protocol is. Not to mention because of its flexibility ( another point made in this list ) CAN is much more affordable and easier to implement.
Speed & Reliability: Another major point for CAN is that it is quite a reliable and well-built network protocol. For example, when we look at CAN and its implementations, we may nice that the order and timing of messages is quite easily predictable. You may be thinking, how and in what way is this good? Well, to put it lightly, This is crucial in safety-critical applications like vehicle control, where precise timing is essential, lets look at some basic examples here and see if we can get this down. When we look at anti-lock braking systems also known as A-B-S, each wheel’s speed sensor must communicate with the control unit in real-time ( which CAN do quite well with, in other words, has quite speedy real-time information collection). Because of the predictable nature of CAN’s communication this can guarantee that speed readings are updated at consistent intervals, allowing the ABS system to make split-second decisions and optimize braking performance especially in the case of emergency! Now aint that something? Not to mention, CAN is reliable because it was literally built for the automotive industry and tom solve so many other problems in today’s world!
Prioritization Systems & Flexibility: As we mentioned in the section above, the way CAN allows specific messages through its arbitration ID system to be prioritized not only makes driving much more safer but can also act for much more faster transportation of messages within the network for specific diagnostics readings or even internal system responses. This kind of system is really important for more important builds
Now I have also given a CONS list of CAN.
Limited Bandwidth: One of the primary issues with CAN despite other idea’s and re-builds per of CAN is its limited amount of bandwidth. Because of this limitation and with the advanced and modern-day systems in cars this can become a constraint as modern vehicles incorporate more sensors, cameras, and advanced features requiring higher data transfer rates which is also why you may see CAN be used with other protocols or forms of CAN anyway.
Not Enough Security Systems: Despite CAN being a well-structured protocol, it really does not have nearly enough security. The more advanced cars get and the more networks and unique features we end up with, the more attack-able and the more hackers are going to become attracted to the security world of cars. The issue with that is because of how well used CAN is, there are very limited mitigation's to prevent the idea of hackers being able to manipulate the networks.
Message Length Limits: Another major issue with CANs original design was that it had quite the amount of length limits in messages. In sum, this basically means that large data transfers and operations that require more data might need to be fragmented, leading to increased overhead and potential delays as well as some other complications along the way.
Latency: Latency is another huge thing with CAN. CAN is a great protocol and its quite fast, however, in modern worlds, it may struggle with lower-latency demands in certain applications such as vehicles that incorporate real-time features like autonomous driving, ultra-low latency communication becomes crucial. This is why other protocols also start being used, because they may be able to support this.
Regardless, CAN is a good protocol and has a ton of good implementations. But, this does not mean that it may be lacking in today’s standards. As you can see by now, going back to the whole programming language analogy — each protocol has its pros and cons but CAN is slowly starting to become easily defeatable with new systems and protocols coming out. Now you may notice that protocols like FlexRay are much more safer as they implement very tight and compact systems, but the issue with FlexRay is again it over complicates and makes everything so overly complex which makes it expensive. What the automotive world needs is a protocol like CAN that is faster, newer, safer, stronger but also strives to create a sense of reliability that is also cheap and affordable.
The CAN Protocol: Digging Into Diagnostics
By now, you should understand how the protocol works on a smaller level and how the actual protocol is laid out. But lets get something down, we kept mentioning something about physically accessing a car's network through hardware and tools or how mechanics use scan tools to get data from the modules of the car. Well, this section will teach you how that works using the OBD(2/II) system! In this section we will break down what OBD is, give you a deeper explanation to its pin layouts, ports, systems and other various protocols and implementations of OBD2. SOOOO lets get to it!
Introduction To OBD: This section should give you a good understanding as to how OBD works. We will also be diagnosing a car using OBD2 scan tools and understanding specific code sets such as DTC’s.
Pinouts and Protocols: This section will talk about the different protocols and systems that are used in OBD such as KWP2000, CANH, CANL, HS-CAN, MS-CAN, LS-CAN, SAE H1850 and other various protocols. Here we will also go over the pinouts of the port and even talk about how they differ.
Note: When we get to talking about OBD, I should make a note that while the general concept of OBD stays the same; the implementation will differ based on the manufacturer or company and what their goal is for the primary use of OBD.
Without much mote to say — lets get into it! First lets start off with trying to understand exactly what OBD is for those who may not be so familiar with it!
Introduction To OBD
On Board Diagnostics also known as OBD is a type of diagnostics system for automobiles which allows mechanics and even car owners to quickly diagnose and understand specific problems or information within the vehicle. I am sure you have seen it before as almost every car and looks like the one in the image below.
You may also be familiar with other types of ports as well as feels and cases that you may have seen around! But regardless, this little amazing port gives mechanics access to the cars entire network! Well, not really. As we have discussed before, one of the primary issues with CAN is how extremely susceptible it can be to physical attacks due to the lack of security mechanisms and systems. Well, these OBD ports at least in modern times and cars are not attached to the central network which means that at most you could probably mess with the diagnostics, and some other features but most likely have to get passed another system before you can even gain access to the automobiles physical central network. The way this works is where a module such as OBD has connections to very specific modules which will also pull data from specific systems. Now, what exactly can be pulled from the OBD port if someone does have physical access to it? Well there is quite a load of systems and different diagnostics someone could grab from an OBD port. However, as mentioned in the note before this section; the implementations of what OBD stores and grabs will change depending on the manufacturer but you can still get some general information like the following list which is universal ( typically ).
DTC’s: Diagnostic Trouble Codes are a set of codes that come from different modules within the car such as the PCM ( Powertrain Control Module ) and other modules. These codes record specific faults in the vehicle within its systems and will report them if something goes wrong. We will touch on more of this later.
VIN: Most readers I assume know what a VIN is which in the context of this section means Vehicle Identification Number which is a unique number to identify vehicles.
Sensor Readings: Most cars today that use specific sensors will store and record data such as oxygen levels, temperature and pressure levels within the automobile.
Engine’s RPM and Vehicle Speed: Another common data stored is the engines RPM and Speed ( MPH’s typically ) which can help diagnose problems related to transmission, drivetrain, and speed sensors.
Emission Control Data: This is to ensure that the vehicle is within the general regulations and rules for emissions which typically records the vehicles performance.
Vehicle Identification Info: Outside of the VIN there is many other networks and systems that are logged which are used to identify the vehicle!
There is also a plethora of information that OBD actually stores but that is just a list to get you an idea. Of course I could also talk about how it reads gas, deeper emissions data, coolant temperature and why but then this module would just be way too long.
So about physical access, why would a car hacker or automotive security researcher may want to have physical access and use of the OBD2 port other than f*cking with the diagnostics? A very good question that can be answered in multiple ways. The first way is that regardless of the separation, if there is a configuration or false implementation or broken security control that there could be a flaw that could be exploited as a result to that execution. The second one would be that it is a good starting point for malware dropping similar to USB ports. So this is where learning how to actually get access to these systems work out just fine! First, we need to know where a OBD2 port is located. Typically, these ports can be found on the back left, back right, top left, or top right underneath the steering wheel. To better visualize this I have given you a good example diagram followed by two examples of real cars.
Still confused? Alright, let me give you a good example of where two were located.
OBD2 Port Location — 2009 Chevrolet Tahoe LT ( underneath the steering wheel almost directly )
Front view of the OBD port
Messy Backview of the OBD port
OBD2 Port Location — 2003 Ford Focus: The demo below shows both the behind the OBD2 port from underneath and a front view of the port itself located on the bottom left of the steering wheel.
Front Example: Cover literally says “OBD”
Trashy but older example of OBD wiring (behind the socket)
As you can imagine and do clearly see here, there are many different placements where OBD2 ports can be located and in even deeper scenarios you may see different types of OBD ports. Now, how exactly do we gain access to said port and how can we begin sniffing data? Woah, thats already a far jump. Below I have listed two common methods that I have made up / titled myself in terms of directions.
Note: When you read the Automotive Security: Reversing CAN you will notice that these methods and some screenshots have been re used. So, if you are reading this as intended to be a full module or set of modules; then note that this section is skip-able when you reach the reversing CAN module. Primarily because we will be working or re-discussing CAN and OBD2 in those sections but this article already gives you what you need. I choose to include it because in the case the reader reading the reversing article did not know much about OBD2. But anyway, the research and info was gathered through the same methods between both articles. YOU WILL also notice that some of the writing was re used but I highly suggest that you do finish this article because we deeply explain specific protocols that we did not really tackle such as KWP2000 and other forms of CAN such as HS-CAN, MS-CAN, LS-CAN and others. So without much more to note, lets get into it.
The “hold my beer” method: Access OBD2 for some people can be too expensive, since getting the necessary hardware is quite expensive and diagnostic tools on their own are extremely expensive if they are built well and are built for direct modification of a vehicle or rather just information. So, some people prefer a method I like to know as the “hold my beer” method. This method is basically talking about the kind of people that have your standard legacy thinkpad with Debian installed on it and pull out a very janky but very professional OBD2 →USB connector and plug it into their laptop. Then using third party software and some random hardware to interface with the data, they can analyze codes and diagnostics quite easily and even brute force specific DTC’s on a car. This method is not recommended for multiple reasons and the first one being that you might fry your OBD2 connector given how much power your laptop could draw or could be putting into the port when committing operations such as DTC brute forcing and even sniffing data on the network.
The “I have the money or just have some cool connections” method: Also known as the more professional and proper method upon reading and accessing data on the cars network would be to use diagnostics tools that were developed to read data from the network and were developed in professional environments. The kind of tools I used I had laying around since one of my family members happened to have one just- sitting in a shed, so I used that one, which makes me the “I had a unique connection” person and did not have to spend a few bucks which in today’s age is up to $100 for a basic non-fry your OBD port reader hahaha! But no on a real note, I would not worry too much since most tools are power efficient and have much more mechanisms in place, but I also would not shoot too cheap either.
These methods are both great ways to operate with OBD2 and are a good example of how exactly we can gain access. Now again, gaining access to an OBD port can give us a ton of information about a vehicle and may even allow us to log as much information about the vehicle as we can for our investigation or general exploitation road-path!
So lets start digging into this. The first time I plugged this in, I had to turn the ignition on and start the engine for the tool to work. For some reason, not sure why it wanted me to do that because I am pretty sure some tools only need you to be in “accessory” mode, but regardless, I simply plugged the tool into the port and got to working!
Below is a screenshot showing the tool plugged into the vehicles OBD port
I feel like this needs more context so let me explain, in this demonstration I am using the ANCEL AD310 Classic Enhanced Universal OBD II Scanner which you can literally find on amazon for 20 bucks. Again, this is the cheaper method- not recommended if you are doing this for everyday knowledge and testing but you can use it if you are only there for a quick minute. AYE! HUSH! I hear the judgment from a mile away, I WORK WITH WHAT I GOT ALRIGHT?? So, in the menu I went immediately to the DTC systems to see exactly what was going on within the system. I recall that a few days ago the AC just stopped working and blowing but then kicked on again. From my knowledge of cars, DTC codes are stored even if the problem from a humans perspective resolves itself and is not gone until they are erased.
Note: The ANCEL AD310 like most OBD tools allow you and give you the option to erase DTC’s in a cars module. But I want to first start this by saying, if you want to do this go ahead, but I will say that this is a federal crime in the U.S and if a mechanic spots that you have erased the DTC’s or even other diagnostics within the system they may or may not report you. This is a serious issue because people will use tools like this so when they sell a car, even if the car has an issue it might not show up right away when being checked by a mechanic. However, most modern systems no matter how or when you erase it will just restore the code in memory when the car is started up and still sees the problem. Either way, do it at your own risk.
ANYWAY! Moving on. Lets go ahead and see what the car wants to complain about and see if there are any HVAC issues.
as expected, the car complains about some HVAC issue and displays a code at the top left and lables is a generic code. What exactly are these codes? What you are seeing actively in use right now is what the tool was able to pull from the saved DTC’s in memory. Now, to my knowledge, the code it is giving me is from the PCM or power train control module. How do we know this? Lets go over DTC’s for a second.
DTC’s are a bit wacky but lets get a base as far as how they work. When it comes down to DTC’s, the PCM typically stores them in the PCM’s RAM, that is for what is considered more softer codes. See, DTC’s are stored based on how they are categorized, for example, if the fault is much more complex; the code will be stored in a place that can be retrieved after the car is killed or electricity from the battery is disconnected, if the fault is minimum and smaller, the DTC’s are stored in the PCM’s RAM and will be lost when connection to the battery is lost. In order for mechanics to figure out if a trouble code is complex, they need to first erase the codes on the car and then test drive the car a bit. When they erase the codes they are basically seeing if the problem re occurs. If the they are driving and the code re appears, this may be considered a more harder fault, because it is a fault that will not go away without intervention or some sort of fixing. In sum, if a mechanics sees that a fault has re-appeared, then the fault will be considered a hard fault, if else it is a softer fault and one that was most likely due to user error such as a missing cap. When DTC’s are stored, the PCM will snapshot all the relevant engine data which is commonly referred to as freeze-frame-data. Freeze frame data includes many different forms and types of information but generally have the 5 listed below.
Engine Load: The engine load is similar to a computer’s CPU load which is basically saying the amount of stress placed on the engine which is usually expressed as a percentage of the engine’s maximum potential power output.
Vehicle Speed: Vehicle speed is another one, typically this info can be extremely vital when diagnosing certain issues related to speed-dependent systems.
Fuel Trim Values: Fuel trim data is recorded because it helps assess the air-fuel mixture and the correction applied by the PCM which can provide more insights into potential fuel systems.
Engine RPM: The engine’s Revolution Per Minute (RPM) is also recorded which indicates the speed at which the engine’s crankshaft is rotating. RPM data is recorded because it helps better understand the engines speed at the time of a DTC recording event.
Coolant Temperature: This is kept and saved because it is used for determining if the engine was running at operating temperature when the fault occurred and was recorded.
Going back to DTC’s, how did I know this was being recorded from the powertrain? Well, this is indicated by the DTC layout which is shown below.
This chart could explain everything perfectly. When reading our code from the tool that reads P0451 this indicates that our issue works with the power train control module. Sure, this may be an AC unit but HVAC systems typically operate within the vehicles PCM which is why it has a P at the start of the code. Now, lets keep exploring!
The screenshot above shows a different screen that seems to be showcasing the calibration ID which is the CAL ID also known as Software Calibration Identification Number is a unique number that identifies software that was installed within the ECU’s or other diagnostic control units within the vehicle. This can also reflect the software version of the installed software on the ECU. There is much more information we could give on this type of mode but we will skip this for now.
Pin-outs and Protocols
Now that we have a basic understanding of how OBD works, lets talk about the pin-out of the OBD2 connectors! For example, take the example of the connector for the OBD2 tool that we used in our examples as shown below.
Notice how the pins all have their different numbers? The numbers on the pins all indicate different slots which is good to know in the case that we are trying to locate specific communications. It is important to note that the OBD2 pin-outs are manufacturer specific and change per manufacturer. So, we will go ahead and give you some basic demonstration of what each pin means. When we are done with this I will talk about how you can locate CAN High and CAN Low.
Alright, this is where shit gets really fucking wacky LOL. So lets step through it and walk through the different forms of the pins vertically from left to right. So, we are going to start with the SAE-J1850 Communication BUS.
Note: Some of these sections will all be divided into the most important ones. For example, we will be talking about SAE-J1850 first as a protocol due to its priority, then we will talk about KWP2000 and ISO9141
Automotive Security — SAE J1850 Communication BUS
I can already see what you are thinking right now, as is something I also had to think about — all these damn numbers . Yeah, I know — but do not worry! For I am here to try my best to explain it- no promises though! Alright, lets get through this as fast as we can so we can go ahead and move on from OBD2. In short the SAE J1850 protocol is a protocol that was adopted in the early 90’s ( 1994 ) and was used for general diagnostics. These protocols are used for onboard diagnostics and communication between different vehicle components, such as the engine control module (ECM/ECU), transmission control module (TCM), and other electronic systems within the vehicle. Wait, did we say, “these protocols”? Yeah, so basically SAE J1850 is more of a set of protocols that defines two different serial communication protocols known as PWM and VPW. I will try to go over these in a basic description- make it as simple for you to understand.
> Prepare for a very dry explanation — sorry 😭
Pulse Width Modulation (SAE J1850 — PWM): The Pulse Width Modulation protocol also known as the PWM protocol holds its own format at pins 2 and 10 on a standard OBD2 port. This means that we are going to see the PWM+ and PWM- communication versions. Typically the PWM protocol operates at a much more higher rate of speed ( 41.6 Kbps ) and a higher voltage ( sitting at 5V [Volts]). The data of this protocol is encoded using variable-width pulses which has a pulse represented by either a binary 0 or a binary 1. The duration or the width of the given pulse will actually determine whether or not the data bit is a 0 or a 1. This data also has its own bit encoding format to specify how the pulses are encoded to represent the data bits! Typically, a PWM frame consists of 41 bits which are divided into three primary sections that include the Header, Data Bits, and Checksum, all of which you will be more familiar with when we reach CAN but are all general terms.
Variable Pulse Width (SAE J1850 VPW): The Variable Pulse Width protocol which is commonly referred to as VPW or Bus- / J1850- line is the wire that carries the data signal using the series of pulses. As you can imagine, based on the name, this protocol sits on pin #2 only and is a single wired communication bus. This communication bus sits a bit differently bit still acts using PWM because it also uses the variations in the pulse widths to encode the data. However, the key difference between these two during the modulation factor is that VPW, unlike PWM, uses a fixed set of pulse widths to represent different binary values! The communication speed of VPW is also quite similar to PWM where the VPW protocol operates at a relatively low communication speed which is around 10.4 Kbps
There are some key downfalls to both protocols and there are also some advantages and limitations! So, lets at least state one advantage and disadvantage of both protocols in comparison to each other.
Advantage of VPW: One key advantage of using VPW is how considerably simple it is in terms of its interpretation. Because the VPW protocol uses a fixed set of pulse width, the process of interpreting the data can be much more simplified.
Disadvantage of VPW: Like most of the older protocols, the VPW protocol has quite the limited flexibility and this is a downfall when it comes to dealing with data that requires more nuanced encoding or adaptation to specific communication scenarios.
Advantage of PWM: A good thing that comes with using PWM is that unlike the VPW implementation, PWM has much more flexibility around its pulse widths which comes quite advantageous in situations where the data encodings may need to adapt to specific requirements.
Disadvantage of PWM: Less Standardization is one downfall which is mostly due to the variable nature of pulse widths. Because of this nature, there might be a slightly less standardization in terms of the specific pulse width values used across the quite literally tons of implementations which in turn leads to compatibility issues within the system.
Note: SAE J1850 Communication BUS is not really used much anymore, I mean you can still find it in other vehicles but its not commonly used anymore as it has been replaced with protocols such as CAN due to how considerably “unstable” J1850 can be in the wrong implementation. Not to mention there are other systems out there that just do better. But, I figured we would go over it because in the end you see it in almost any OBD2 diagram you look at and its important to at least know what the protocol is, how it works on a smaller level and why it is used or the importance it has.
Automotive Security — KWP-2000 Auto-Communication
The KWP protocol is another protocol that has its own road paths, so I will also try to explain this one a bit and as much as I could touching on it in the most basic way possible! In short, the KWP2000 protocol whos lines sit at pins 7 and optionally 15 you may also see called ‘ISO 9141–2 or the KWP K-Line [ its actually a variation of ISO9141–2 more than it is an exact name for KWP]’ is another communication protocol commonly used in automotive diagnostics, specifically for communicating between an external diagnostic tool and a vehicle’s electronic control units (ECUs [notice the contextual usage of the term ‘ECU’]) through the OBD2 port or other diagnostic connectors that may exist within the vehicle you are connected to. Now, you might be asking right now
“Another communications protocol? Wtf WHY- WHY MUST WE CREATE SOOOO MUCH”
Yeah I know I know I get your pain, but as we talked about before, each protocol is used and implemented for various reasons. The reason KWP2000 was developed was to address the limitations of the older ISO9141 protocol and provide a much more advanced and flexible method for communication between modules. This protocol basically allowed for much more faster data transferring rates, had more improved error detection and correction systems and also had much more sophisticated levels of communication capabilities between the diagnostics tools and the vehicles ECU’s ( Electrical Control Units ). Now, similar to SAE J1850 there were two primary variants to KWP2000 which are defined for you nice and snuggly below!
KWP2000 FINIT: Also known as KeyWord Protocol 2000 Fast Initiation was a variant that was used to establish a communication within the automobiles ECU’s much more faster which could reduce the initialization time! Typically, you will see this variant used for functions that require quite the rapid data retrieval.
KWP2005 5-BAUD-INIT: As you can imagine, this is the slower version and slower initialization process and variant which would come in handy when you need to work with functions in a automobile that do not require useless rapid data transfer such as (re)programming ECUs!
Both of these also had their own systems and like other OBD protocols, the KWP2000 protocol allowed for mechanics, automotive programmers, automotive technicians and researchers to access and manipulate various aspects of a vehicles electronic system which can also be for their own reasons. As you may imagine this data would be used for diagnostics, maintenance, research and other various systems. However, note that the wrong usage of this protocol can lead to so much more security risks and unauthorized access to the vehicles systems again given there is a vulnerability or miss-configuration and protection mechanisms are not put into place.
Automotive Security — CAN (H/L/MS/LS/HS)
Wait what the fudge nuggets did I just spell out? Well, yes, more protocols / systems / designs to go over- fun right? LOL. Alright for real, below is what this section will go over.
Can High (H), Can Low (L), Mid-Speed CAN (MS), Low-Speed CAN (LS), High-Speed CAN (HS).
Right so I am going to try to break this down as simple as I can for you starting off with the CAN High and CAN Low signaling wires.
So to start off with, CAN High and CAN Low both sit at pins 6 and 14 on the OBD2 port and all have their own reason to exist. To put it lightly, CAN uses a signaling system known as differential signaling which is a method for electrically transmitting information using two complementary signals. I will not get deep into the electronics of it since the main focus is to just get you used to the idea of it. The reason differential signaling within networks like CAN exist is because the environment needs to be fault tolerant to noise which is quite helpful during manufacturing of said automobiles. A good way to represent this is that every time CAN sees a signal come in or out, CAN will raise the voltage on one line and drop the other line in an equal amount! ( Car Hackers Handbook demonstrates this better ). Can High and Can Low all operate under their own wires which are basically descried in the weirdest way possible.
Okay Explanation: CAN High is known as the dominant or recessive bit value within the CAN signal where as low complements the CANH signal and helps in determining the bit value. This differential nature of the signal can reduce the noise and interference whilst also being able to enhance the noise immunity of the network which can help maintain signal integrity!
I felt that the explanation above was not the best but again I am seriously trying to cut short on time and not extend this more than it already has hahah! Now lets discover some differences between low, mid and high speed CAN and why they are different.
HS-CAN: High speed CAN also known as HS-CAN as the name implies operates at a much more higher data rate and as you can imagine is used for transmitting critical real-time data ( CAN’s specialty and ‘wow’ factor) such as engine and transmission data, safety information, and other extremely important diagnostics. This is because if you think about it, in some odd emergency scenario, you seriously would want that data to be priority and be sent much more faster instead of slower. HS-CAN typically operates up to 1 Mbps.
MS-CAN: Mid Speed CAN also known as MS-CAN operates at a much more moderate on-the-fence data rate which is typically up to 125 Kbps and serves as an intermediate between HS and LS CAN. The reason MS CAN exists is to work with applications that require a proper balance between the speed and reliability of the protocol such BCM ( Body Control Modules ) which may include door modules, seat modules, environmental modules and lighting modules.
LS-CAN: Low Speed CAN also known as LS-CAN is the complete opposite of high speed CAN and operates at a more lower data rate which is approximately 0 kbit(s) to 125 kbit(s) and is used for operations that are less time-sensitive and non-critical forms of data such as interior lighting and infotainment systems.
This perfect balance of high speed, low speed, mid speed and even the different voltages all make CAN the protocol of wonder it truly is and actually makes it extremely useful. Not to mention the factor that it improved every so often is nice see in a protocol and brings much more trust into the system.
HOLY FUDGE NUGGETS WE ARE FINISHED WITH PROTOCOLS AND OBD2! YAY- FINALLY!
Now, lets go ahead and end this section right and summarize the OBD2 section of things.
The CAN Protocol: Summary Of Section
This section was not too long but it could have been a bit shorter, so future apologies for forcing you to read a bit more hahaha! Anyway, the CAN protocol as you can imagine has grown over the years, the multiple standards, versions, types, implementations, designs and re-builds of the protocol are quite interesting to see. But what is important to note is that this protocol still seriously comes in handy all the time and is one of the reasons your car can properly operate ( unless you have a fancier car ). The thing with CAN is that right now despite AE ( Automotive Ethernet ) rising ( at the time of writing ), CAN still manages to rule over most protocols because of its major and key benefits. Basically, we can summarize that CAN is most beneficial in the following areas.
Speed
Reliability
Flexibility
Cost
This protocol also has its flaws, but it is important that we keep a good and well-structured knowledge base on the protocol and how it works. I also would like to make a note that some of the information I can imagine was a bit longer than you expected and was also a bit confusing, so my advice would be to see if you can find any other external information that this article may not have included, sorry, *cough*, module. But this is not the end- we still have more HAHAHAH! You have been tricked!
Automotive Security: CAN | The CAN-FD Protocol
We have one more unique protocol to go over before we can send you off to the more direct portion of this module! That protocol is known as CAN-FD which stands for Controller Area Network Flexible Data-Rate. You may see or assume that this protocol is a much more advanced or enhanced version of CAN, and you are actually correct on that! While CAN is still used today, some people who may work with different types of transportation and even automotive vehicles may work with CAN-FD on some shape or form which is primarily due to the modernization of technological systems within vehicles that need a much more unique protocol. So basically, we can say that the primary reason CAN-FD was built was to address the increasing data communication requirements of the modern vehicles. As we discussed, CAN, also referred to as Classical CAN had a ton of limitations in terms of its data rate and payload sizes. The issue with that is when newer systems come in place and require not only much more data at faster speeds but also require bigger sets of data, CAN is going to have to fragment the data ( as we discussed ). This can lead to many issues down the road and over all is just a bit of a pain. So, how does CAN-FD solve this? Well, generally speaking: CAN-FD allows for much more higher data rates, larger data payloads, and different systems that can all make it much more suitable for those newer applications that require some form of communication! Below I have listed a few primary points within CAN-FD and why it may be more used. Note that the first two points are going to go over what we already talked about but better define what we mean by this.
Larger/Increased Data Rates: CAN_FD typically operates with data rates of up to approximately 5 Mbps and can even go higher compared to the standard or classical CAN which operates at 33.3 Kbit(s) which is a much more faster rate than standard CAN. Because of this, CAN-FD can be used for much more modern day systems since due to the higher data rates it can enable much more faster data communication and transmission of larger not only smaller amounts of data. As you can also imagine, this can be helpful when we need to work with more sophisticated and complex systems!
Larger Data Payloads: Larger data payloads are a big one. The more systems become more advanced the more data is going to need to be fed to them in order for the system to work the way it needs to, this also means sending the data all at once or in specific parts. Classical CAN has a maximum payload size of 8-bytes, CAN you ( pun intended LOL ) imagine how small that is for systems that may require much more unique information or messages that are larger? CAN-FD fixed this by improving the data payloads by allowing it top support entire payloads that are 64 bytes long! That is quite the size haha! Because of this larger payload size, not only is message fragmentation reduced by ALOT but the general and overall performance and communication efficiency is also massively improved! In turn, this means systems can be much more accurate and well understood!
Better Error Detection & Handling: Error detection is one of the most import systems in any form of protocol, application, receiver or just computer known to man. Without proper error handling something could fault and go totally wrong with transmission and kill that data ( in a more general sense of course ). So, CAN-FD fixes this by creating a more robust error detection system and mechanism that uses CRCs ( Cyclic Redundancy Checks ) and ACK ( Acknowledgement ) to ensure the data’s integrity during transmission. These mechanisms have been bound to contribute to the reliability and the over all accuracy of communication!
Flexible Bit Timing: I do not think we can go super deep into this because its- so long and goes into so many depths but I will break it down for you. CAN and other protocols use a system known as bit-timing which is a timing system that govern the transmission and reception of individual bits within a data frame within specifically timed parameters. As we have talked about before within this module, protocols act on the factor that data is transmitted in the form of individual bits, which are binary units that represent either a high or low voltage level on the wire. The timing of these bits is important for proper communication between the sender and receiver. Each of these timing sets have their own parameters which include the Bit Rate, Bit Time, Synchronization segments, Phasing segments and other various segments that all make up these parameters. Now, you may be asking, how exactly did CAN-FD address the problems in classical CANs bit timing system? Let alone, what even were the primary issues? The primary issue with classical CAN was that it has a fixed and deterministic bit timing configuration, which might not be suitable for all network conditions, cable lengths, and physical layer characteristics. All of these characteristics all make up what bit timing is and can become a problem within the system later down the line. CAN-FD fixed this by making this type of system much more flexible in terms of the bit-timing parameters. This allowed for a much more better and unique adaptation to different network conditions and environments such as the cable lengths and physical layer characteristics that we mentioned above. This can also improve the overall performance and the reliability of the protocol. CAN-FD is primarily used also because of this point here and due to its application in today’s world!
Backward Compatibility: One thing we forgot to mention deeply was the compatibility with CAN. You may notice or hear that some automobiles may use different implementations of CAN and protocols, but if there is different types of CAN, might that cause compatibility issues in the future? You would think right? But protocols like CAN-FD actually have an amazing system and was designed for partial backward compatibility in mind. This means that CAN-FD nodes can co-exist on the same network as other CAN nodes. However there is a ‘but’ here. The issue with this type of system is not more about its support but more about the factor that the compatibility requires negotiation between the CAN-FD and classical CAN nodes in terms of the data rate that can be used for the communication between the nodes and modules. This is not too much of a problem but in the end, the primary point is just to say that CAN-FD makes some attempt at working with CAN properly to make sure that it does not make developers requiring an immediate replacement for all nodes. This is super helpful also in the factor that some systems may require some features that CAN-FD has with the wired support of CAN; in smaller terms anyway.
D/S Channel Config ( Dual and Single ): This is another confusing one that we may need to break down a bit. The first thing right off the bat is the single-channel configuration. Traditional CAN operates in a form of communication configuration known as a single channel. In a basic summary, these types of configuration are for the physical communication medium used to transmit and receive data between nodes on the network! The single channel configuration as the name implies is where only one communication channel is used for transmitting and receiving data which is actually quite a cost-effective because it requires less materiel to reproduce and is much simpler to manage. Dual-Channel configuration on the other hand is where those two physical communication channels operate in parallel which can provide redundancy and fault tolerance on the network, a major benefit to using dual-channel configuration. Classical CAN as I noted before could only operate in single-channel communication, however, CAN-FD improves this by being able to support both dual and single-channel communication configurations! It is worth noting that CAN FD networks provide the same benefits of redundancy and fault tolerance as in traditional CAN networks, but with the extra added advantage of higher data rates and larger payload sizes.
Newer More Enhanced Frame Types: So this is a given with this section and as the name Flexible Data-Rate in CAN-FD implies but CAN-FD introduces a whole new frame type which includes the Classical and FD frames. For context, classical frames are similar to the standard CAN frames while the FD frames take advantage of the higher data rate and larger payload size that CAN_FD implements. Choosing between these frames and their types will add some complexity since you may need to go based on communication types and pinpoint what needs more flexibility but that is a good example!
Improved Efficiency: The last point on this list that about sums up everything here is how much more efficient CAN-FD is compared to classical CAN. Because of the higher data rates, improved error handling, and larger payloads within the protocol, CAN-FD highly increases in its communication efficiency.
In the end, CAN-FD is quite important and is a huge advancement when it comes down to the standard or classical CAN protocol. You might start coming across CAN-FD more in today’s world because of the need for systems in automobiles to rely on the heavy functionalities of the network due to being more power-hungry and data-hungry. In the sum of this section, the whole point is to show you that other protocol alternatives have been developed and they all will have some form of workaround but as we mentioned at the start of the article, there are so many protocols and systems that are put into place because we can not always keep using older standards for modern technology. Same with the evolution of the computer, we could not use older software on newer systems, we needed to find a way to tie and bridge them together!
So now that we have a decent understanding of protocols and physical aspects of cars, let's move onto a more unique section that talks about physical cyber security using tools and then leads into our last and final section about physical security directly.
Automotive Security — CAN | How It Parties!
The one thing that would also be worth getting down is the factor of tools and how hackers can actually reverse engineer the networks and let alone how they gain access to cars to even start testing them. So let's go over a few sections that will describe different tool sets, how hackers test automotive networks, and so on.
Note: I will not be going over every single tool within the can-utils framework as that will be within the next article where we put some of those tools to use. This section is here to talk to you about ways hackers may test protocols such as CAN, CAN-FD, ISO-TP and other communication protocols and systems within cars that may be helpful to a security researcher. Without much more to say, lets get started.
Tools, Lets Talk | CAN Tools
The world of CAN is where every unique automotive security researcher starts, yes, even today. But why? This is because that CAN is by far the most well-known protocol but also the most open-sourced protocol and talked about protocol due to its amazing capabilities! Which again you are familiar with. In order for people such as hackers to work and manipulate this protocol, they need to make sure they can actually start devices and work with the network directly, so what are some example tools? Well, this is more a suite of tools that can be used but the first one right off the bat is can-utils. The can-utils suite is a unique set of frameworks and applications that are built for manipulating both the ISO-TP and standard CAN messages. These tools allow hackers or reverse engineers to do the following.
Replay Log Files: This will allow hackers to take a pre-existing CAN traffic and network log file and then replay the traffic to inspect it more.
Send Traffic Over The Bus: This will allow attackers to create noise on the network, send malicious signals over the bus or even trigger and change some bytes in the buses stream. Tools like isotp-send and cansend are all tools in this suite that allow you to send data over a specific interface and network in both formats.
Sniff The Current Network: As you will see in the next article in this series, we will be utilizing sniffer tools or network analysis programs to dump and sniff data on an interface that we have connected to a virtual CAN bus. This will allow us to analyze specific actions on the network and figure out the arbitration ID and location of that system in the network.
Data Conversion Utilities: There is a tool that converts ASC files to CAN-LOG files. For context, ASC stands for “ASCII Sequence Chart,” and an ASC log file contains a record of communication events and data exchanged over various communication networks, such as CAN (Controller Area Network), LIN (Local Interconnect Network), and other automotive protocols that we have touched on in this module. This will come in handy when we need to replay the traffic, store it in a much more compact format, need to use it for custom scripting, use it for data integration, and more.
These are just some good examples of what the can-utils suite among other frameworks may be useful to an automotive security researcher or hacker that is focusing on automotive targets. However, hackers may need to also use their own tools ( as we saw with the Audi Q8 FlexRay Intercept / MITM attack) other than the standard ones that come with some penetration testing operating system or the standard can-utils package. So how exactly do hackers make their own tools? Well, Linux-based operating systems have an amazing library and framework of drivers to help developers operate under their own tools for working with the CAN protocol. This is how simulators such as ICSim are created. This unique framework and set of libraries is called SocketCAN. So in technical terms and more direct terms SocketCAN is a set of open-source software components and drivers that provide a standardized socket-based interface for working with CAN. The following list is a list of components that SocketCAN uses and includes which is a major help for software developers!
CAN Drivers: The first and most important part of them all is going to be the drivers for CAN which allow you to interface with many different types of CAN hardware devices such as Serial Link CAN. These drivers provide a much more unique and standardized interface for applications to send and receive interfaces.
Network Devices: Along with the drivers, SocketCAN also includes a standard for specific devices or CAN hardware devices. This standard uses standard network programming techniques to allow applications to interact with the CAN bus. When using CAN, the type of device you open will define its naming conventions. For example, if it is a Serial-Link (SL) CAN device you will see slcanX where X is the number of the interface. When setting up Virtual CAN or VCAN you will see interface names like vanX where again X is the number of the interface. In regular cases you will just see canX and you get the idea of X by now.
Socket API’s: Another unique thing that this framework holds is the ability to interact directly with CAN buses. Basically the API provides a function set for programmers to combine, set, send, bind, create and even receive CAN frames.
Baud Rates & Timing: As mentioned, CAN needs to make sure that baud rates and timing parameters are set quite well. Well, SocketCAN allows developers who are working on CAN supported applications to configure CAN bus BAUD rates and timing parameters which can ensure proper synchronization and communication between the modules or devices within the vehicle!
There are also other amazing and unique features to SocketCAN but in general, it is a good example of what people can utilize when they want to work with CAN on a new level! But what if they need newer tools? More modern frameworks? What if they do not want to build their own systems and tools? Well, this is where the following comes in…
Yeah that is right! Hackers may need to also use external resources and platforms such as GitHub and SourceForge to find unique and newer programs or software and even cracked enterprise software that they can all work with to gear more towards the modern standards and security systems of CAN as the CAN-Utils suite is not too too old but its definitely not new. Some hackers may also want a more graphical solution to map and trace CAN information and even be able to properly parse and generate CAN log information and even do more advanced protocol analysis and security auditing on the automobiles network. Modern systems as we talked about have pretty limited access and are quite hard to get into the works with but Its also worth it to at least understand it if you want to mess around with CAN log data, and tamper around with network protocols for the hell of it!
Automotive Security: CAN | Authors Note
Hey there nerd :)! I know you have been reading this module for quite some time by now and I suggest that you take a moment to yourself and go outside and exercise, heck maybe if you cant then go get away from the screen and chill out! This article is super long and I know it is a pain to go through, but just make sure you are staying hydrated. The literal child whos writing this article (Totally_Not_A_Haxxer) is just slamming energy drinks and encouraging you to NOT repeat what he is doing LOL! This article is supposed to be highly energetic and fun, so please, do not burn yourself out. I also would like to mention that I hope you are actually enjoying the format in which this module/article is made. Because I personally feel that adding more personality and true energy behind this field is exactly whats needed! Who wants to read some boring word for word article without CANy puns ( Get it? Instead of corny we use CANy because of- CAN- and the article? I know that one was bad ) hahaha!
Automotive Security: CAN | Why Security Is Important
Now let's get back to the whole purpose of this part of the series. The whole goal of this series is to show you exactly whats going on and how it all works as well as whats going on with the physical security aspects of the automotive security world and talk about the protocols because, in the next 80–90 minutes article, we talk about reverse engineering cars in multiple ways! But, in the end, why is this research important? Okay you already know that and if you do not then please definitely go back to the starter automotive security article that started this series off! In this section, we are going to be primarily focusing on attacks on automotive protocols but just go over genuine accessing and why the security research is important.
Below are some sub-sections that make up these primary sections.
Why VSec Is Important: Busting CAN → A section that will talk about how reverse engineers reverse CAN and can manipulate vehicles by exploiting cars and even abusing the OBD2 port on automobiles.
Why VSec Is Important: Attacking Complex Protocols → A section that gives a demonstration about a MITM attack that was executed on a FlexRay network using specific hardware chips.
Why VSec Is Important: Defining VSec → A section that sums all of the information here up and actually ends with talking to you about what vehicle security is, how you can prevent attacks and more!
Now, lets dive into this and finally end this section so we can move into our final section which talks in more technical detail about the classical CAN frame layout. That will be the ending point.
Why VSec Is Important: Busting CAN
When it comes to CAN, there are multiple ways hackers have been able to manipulate the protocol and the automobiles that use this protocol by gaining physical access to the vehicle itself. But lets actually go over something for a second. You may hear commonly of people hacking into cars then spinning up a virtual simulator ( as we will to demonstrate our knowledge of reverse engineering in the next article ). This type of simulation is supposed to give you an idea of what it is like to hack or reverse engineer the protocols on the automobile network. In today’s world, this kind of becomes useless and becomes quite a pain to do because hijacking automotive networks require a ton of hardware and specific knowledge in fields. While the research is valuable, they are again just too complicated for most to bother attacking as the real threats lie in the automobile's remote third-party systems. I would like to make a note on something which has been noted below as a sub-sub-section.
Block Harbor’s VSec Courses: For a decent amount of time at the writing of this article I have been familiar with a company that dedicates all of their time into automotive security research. This company currently is hosting its own CTF ( at the time of writing ) and also has its own free access to anyone Vsec course that gives you an introduction. In one of the course pages, they give some amazing incite on the point I am trying to also make on vehicle attacks on the network and attacks that can potentially damage users or drivers. That point has been noted below. There is other information I could share and quote from the courses but will not due to my respect for the company wanting people to pay for specific courses and in the case of their free courses want you to at least sign up. The knowledge shown below is general knowledge and is not anything private to the course or company specifically.
Credit — BlockHarbor VSec FREE Course [The Plunge]| In Short: Other than CAN (and maybe Ethernet?), physical networks are mostly too hard to hack or not worth the effort. OBD (and therefore CAN) access is mandated by federal law, except for a few electric vehicles. Any other bus requires more skills and instrumentation to expose the wires, making it less likely to be accessed in a vehicle attack.
I would also like to make a note that BlockHarbor is a good company for general resources relating to automotive security and are a pretty well-known group of well-structured nerds! So I definitely suggest that you go and check them out!
Now lets get back into it. Of course its not the access that is also the issue due to wireless dongles that plug into the OBD2 being directly available and something people use all the time ( which once connected could allow hackers to easily utilize tools on a laptop to then make a Bluetooth device a specific Virtual-CAN device then use other tools to sniff the data off of that interface). Regardless, its important to understand some form of level of attacks that hackers can commit if they gain access to the protocols within the vehicle. Below I have a good list of attacks that are commonly associated with the hardware within a vehicle and the attacks that you might see frequently!
Can Bus Flooding → Controller Area Network BUS Flooding is a type of attack that acts as an automotive DoS attack that can overwhelm the network. You may be familiar with this type of attack and why it may happen on something as much as standard computers and networks, but why on vehicles? The primary purpose of CAN-DoS or CAN Flooding is to make sure that an attacker can disrupt the communications between the various electronic control units ( ECUs) within the vehicle. In regular systems, a company can completely crash because of a DoS attack and can actually completely ruin the company's revenue and its branding even reputation! But in a car, this is especially bad because it can render the vehicle completely useless and inoperable. This is because that when you overwhelm a automobile network that communicates within you are going to be bound to cause malfunctions within the modules and if its targeting or overwhelm a very specific system, then you are 100% bound to cause damage and possibly harm a persons life. I am sure that you are getting an idea of where this is going.
CAN Bus Spoofing & Injecting → Controller Area Network BUS Spoofing is another really well known attack among automobiles! Basically this is where an attacker can send malicious and forged CAN messages to impersonate legit ECUs which will eventually cause confusion and even potentially influence the behavior of the units which may change the vehicles speed, disable safety features and even manipulate any form of steering and breaking systems. This can be even more dangerous because if this can be successfully done remotely without an attacker needing any form of physical access to the car then this can exploit primary systems within the vehicle and may be the reason for a multiple car collision if it happens in terms of terrorist motive. Now again, these kind of attacks have very small and light proof of concept but the factor that it can even happen should show you the possible damage that in the wrong hands, a terrorist could do to multiple people. This also falls under the same realm of CAN Bus Injection attacks which are basically where an attacker can inject malicious messages onto the bus to trigger unintended behaviors. For example, if the network is super unprotected and does not have much modern protection mechanisms or migrations, then a hacker could potentially inject signals into the automobile and say force stop the breaks or force airbags to trigger with specific messages. As you can also imagine, this type of attack if done remotely and even physically could potentially harm the occupants within the vehicle.
ECU Firmware Tampering → This type of attack is much more sophisticated and requires a ton of utilities. But, if a attacker could gain access to the OBD2 port of a automobile they might attempt to modify the firmware of a given ECU with the right data they collected. The issue with this is that it could allow them to flash or install modified versions of ECU firmware that may give them remote access to specific functions of a vehicle and allow it to control various systems such as steering and breaking. This is a very rare case and to my research has not been a full fledged validated reason as to why OBD2 is vulnerable ( when I mean research I mean a full fledged report that would be pretty non technical gated towards beginners not using the term `research` for general security research. Apologies if that is confusing). In general this can be dangerous if done properly with the right intent and sophisticated systems! Its also important to note that some attackers will even go as far as using key auto programmers which can program a key of a specific model or vehicle to match and work with the engine on the inside since keys now are not just fully mechanical but instead depend heavily on the network that runs on the vehicles key systems. That is a way to put that lightly anyway.
General Reverse Engineering: This is not this much of an attack more than it is a topic and something that goes around with different attacks but the reverse engineering of the protocol is also something that will come into play. This is because when we gain access to the OBD2 port of the car and connect it to a laptop or something where we can use specific tools to analyze the network and reverse engineer it by being able to send and inject signals into specific ID’s of systems that we may have found or located on the network. This can be dangerous because it allows hackers to view and gain information about a vehicle's internal communication which can lead to automated exploitation or injection in some scenarios.
Replay Attacks: Oh jeez — the community right now can not get enough of these. General replay attacks are almost existent on any form of network and you can see them in the form of general radio frequencies (RF), WiFi networks, Bluetooth networks and in this case CAN networks. In the case or context of automotive security, an attacker may be able to intercept messages and then record them and replay them later to achieve specific outcomes. This kind of world is one of the more easier things to do and is the reason why cars can easily be hijacked. Radio Frequency attacks are another major attack for cars when it comes to the key fob that everyone uses to lock/unlock the car and even start the engine. The issue with this is that despite these keys being unique, an attacker can easily record the frequencies being sent to the automobiles sensors and then replay them to start and stop the engine or remotely lock and unlock the cars. A good example of this is say an attacker wants to steal a specific car that uses a key fobb to start the engine remotely. Well, hackers can record the person unlocking the door to make sure that the hacker can gain access and also can then record the engine starting or the frequency to start the engine. When they have recorded it they just have to wait for the right time for the person to walk away and then remotely start and unlock the vehicle.
There are many other physical attacks that can exist on cars and even with the new realm of AE (Automotive Ethernet) we may see much more cars become attacked more easily! Now, lets go over one attack we missed- MITM.
Why VSec Is Important: Attacking Complex Protocols
Why are we creating an entirely new section for this? Because this is actually about a story that involves an Audi Q8 and reverse engineers that were able to commit an attack known as a Man In The Middle MITM attack on the vehicles network. So, what is a man in the middle attack? As the name implies, MITM attacks allow an attacker to sit between two parties and listen and eavesdrop on information being transferred between the parties and also intercept specific messages as we will see today. For starters I am going to link the article to you which you can see here.
But, I am still going to go into my own format of the article and research that might actually help you understand it a bit more.As we have talked about, the FlexRay protocol is one of the most common protocols used among Audi and they are quite complex to hijack and remotely send signals to due to their unique timing and verification system! However, there was quite a unique way a group of hackers were able to execute. This process would lead to them completely controlling the steering wheel! But how did they do it? Well lets start off with the basic information, as mentioned above; the automobile the hackers were targeting was an Audi Q8 which uses FlexRay as a protocol and a system known as LKAS which stands for Lane Keeping Assist System. in order for the security researchers to properly reverse engineer and manipulate the FlexRay messages that were utilized by the system, the team needed to develop a very unique and specific solution that involved FPGA (Field-Programmable Gate Array) systems acting as a bridge between FlexRay and CAN. Note that they are bridging CAN and FlexRay together, but why? In order to extend the functionality and in order to properly inject their own systems, not only would building an entire framework to inject those messages be quite hard and complex but it also would not allow for the extend-ability that bridging CAN might have. Now, the reverse engineering process started by them first recording the messages on the cars stock system using a unique tool called a logical analyzer or just logic analyzer. For those who are not familiar, a logic analyzer is an electronic instrument that captures and displays multiple signals from a digital system or digital circuit. In their case, it helped them capture the signals that were being transmitted throughout the automobiles primary network that they were hooked onto and were able to better understand those signals by quickly analyzing them in a more graphical and human readable format.
They also developed a FlexRay packet decoder for the analyzer to properly interpret those packets and messages a bit more which actually produced a much more shorter amount of research time for them and made the research process easier. When they were analyzing the data from the decoder, they came across a specific set of bytes that closely matched existing CAN steering messages from other vehicles. Now, this starts to come in handy because when you notice specific patterns in a system, all it takes is previous knowledge and understanding of that pattern to be able to properly take advantage of it. When they found this pattern they then found a way to modify the messages which happened by developing a circuit ion the FPGA they were using that would split the bus and allow messages to pass through unchanged. You might be asking, why do they need to allow it to pass through unchanged? This is simply more of a safety and functionality concern than anything. Basically before injecting their modified messages, the team needed to ensure that the normal operation of the vehicle’s systems would not be disrupted by allowing messages to pass through unchanged. Because of this they were able to ensure that critical vehicle functions and communication between ECUs would continue to work properly. Using the packet decoder or protocol decoder they were able to modify specific bytes in the messages that were being sent to the destination by again being in the middle of the two parties directly which resulted in them being able to change parameters such as the torque. Given the modifications they made, they were able to completely control the steering of the automobile through a joystick connected to a panda device which was the interface to send CAN messages to the FPGA (Field-Programmable Gate Array) that was used to modify FlexRay messages and inject steering commands.
This story was kind of all over the place but I tried to summarize it the best I could and also fit it to the topic of the article. This is a good example of how complex some attacks can be but also a good demonstration of physical MiTM attacks on automobiles and what they could do. Now this does not directly prove anything other than the fact that there is another way to inject malicious commands into the steering system but even for this research team — it was extremely hard for them to recreate and took expensive hardware, a ton of programming and ALOT of development behind them and skill before they could even think of that idea. But, this is where it all comes together and starts to show you the point in automobile security research on the physical networks as well as just in general.
Why VSec Is Important: Defining VSec
In the previous sections we talked directly about the protocols in cars and ways they can be manipulated as well as some key security features that may prevent this. But what exactly does this have to do with telling you how and why VSec is important? Well, okay we already got passed the political points in the previous article, but why should we continue it? You may have noticed a common theme within the points and vulnerabilities talked about when working with vulnerabilities in CAN and if not then that point was the following — Its human life . This is not some basic database, some small company’s data being compromised- this is actual human lives that are at stake. While every bit of security research is important, automotive is going to be one of the most important fields of security research out there. This is because again in the end, when you think about it deeply — every single person has a car or lets say 90% of people ( generally speaking not direct statistic ). This means that most people are driving 2–4 ton+ death machines that are a driving around with the brightest red flag and target mark on them ever ( digitally ). If there were not ethical security researchers that were doing automotive security research such as the ones that were behind the jeep hack research then 100% a terrorist would have caused a MASSIVE amount of damage because they could have automated the exploit and done that to almost every car that utilized the same system! So vehicle security, the primary point and reason for doing it and carrying forward with it sums up to a ton of points but the few main ones below.
Human Life
Its Completely BADASS
Why Not
The last two points are just — they do not need to be explained. But anyway, that is the reason as to why its important! I know some of the sections that I threw in there are just lame and not really talking about the sections idea but it had a reason for being there — to show you some good examples of what automotive security looks like and how bad and detrimental it can be while trying to convey a massive point. But for now, lets go ahead and end the article with one last section. As we mentioned, w need to talk about CAN one last time and this is about its packet layout!
Automotive Security: CAN | Authors Note
The next section about CAN is going to be seen in the other article talking about reverse engineering CAN as well. You may again be wondering why some sections repeat and it is mainly due to the factor that some sections do not need to be re-written and are only re-used because of the readers context. Some people may not be following the series properly and others may just be here for quick information so it is worth going in with it anyway.
Automotive Security: CAN | Getting Real
Each CAN packet contains its own unique set of fields, as we mentioned before there are multiple types of fields that all have their own reason of data. Take the example full standard CAN frame which is shown in the most blown up way possible.
As you can see, there are a few primary points and sections to this packet. First, its important to understand that most protocols or packet demonstration you will see will be separated into three primary parts which are the Header, Payload and Trailer. All of these are separated into their own sections. Lets go through these categories and split this packet up a bit.
SOF (Start Of Frame): SOF stands for Start Of Frame and is an indicator to let a receiver know and the constructor know that this is the start of the frame being read.
Identifier (Arbitration Field): The identifier of the frame is pretty understandable. This helps identify the data within the frame as well as the priority of the data. This field is 11 bytes long for standard packets. Note that in other demonstrations, the identifier is known as the arbitration ID of the packet. The arbitration ID is a way of saying “broadcast message” that identifies the ID of the device that is trying to communicate over the wire. When we mean there is a higher priority, we are basically saying that in the sense a device is communicating and sends two individual CAN packets at the same time then the one with the lower ID will be the highest in priority and taken care of first.
Control: The control of the frame is field within the data frame that is typically 6 bytes long which act as an indication for the amount of data within the data/message within the frame.
Data: The data field within the frame can hold approximately 0 to 8 bytes of data and holds application specific data which then carries information for the recipient controller.
CRC: CRC also known as Cyclic Redundancy Check is a field that is 15 bytes in length and contains a checksum which is used for error detection and ensures data integrity during transmission.
EOF: End Of Frame marks the end of the frame.
There are also parts within that frame that exist between individual sections. For example, in the CRC field, there is a CRC delimiter and other various fields that can also help define the length of specific sections such as the Data Length Code or DLC. All of these fields make CAN the way it is supposed to be, a very lightweight, fast and easy to understand protocol whilst also being cheap. I have a separate article that should be released by the end of this one, and if it is not then its been canceled for various reasons; but that article talks about the FlexRay protocol in much more depth. When you look into the FlexRay protocol and data frame which is shown below
that FlexRay as a protocol just by a basic example of the data is a much more complex protocol and you can already see the major differences between FlexRay and CAN. This is what makes CAN just convenient, FlexRay has a whole communication cycle and a very very unique format and work around while something like CAN is just not that hard to work with.
As mentioned before, CAN also has its own different types, which is our next section.
CAN we go deeper | CAN — Extended Packets
You can think of the extended version of CAN as a much more longer version of standard CAN. As the name implies, EXTENDED- extends the capabilities and storage of standard CAN packets. So, I have listed the major differences between EXTENDED and STANDARD CAN
Data Frame Format: The standard data frame format for CAN specifies that data within the format will use 11-bit identifier while the extended format uses a 29-bit identifier, which increases the address space and enables communication between different CAN protocols.
SRR vs RTR: Standard CAN data frame format specifies the use of Remote Transmission Requests (RTR) while the extended specification uses SRR or also known as Substitute Remote Request.
IDE Set: The identifier expression which helps the system understand the identifier type in extended mode will be set to 1 while in standard mode will be set to 0.
There are a few other differences, but a common misconception or rather question that sparks when people understand extended vs standard is- “what if one controller or say node sends a standard CAN packet to a node that excepts extended CAN packets?”. This kind of question is pretty easy to answer with the factor that extended and standard CAN frames are backwards compatible! So this issue is not much of a problem.
So, now we have some basic knowledge as to how CAN works, now why did we need to go over it? I always like to tell people that when working with reverse engineering the protocols even on a virtual environment- it is important that we get a base understanding of how the protocol works internally and we know what we are looking at. So, lets get a bit deeper and actually start getting our hands wet with the whole reverse engineering side- Finally, I know!
Reversing CAN — Conclusion And Summary
Yet again, another dictionary or book of an article- I know. I wanted to make sure I actually summarize this article in some way that we could so lets end it like this. From my current experience in the automotive security world It seems that people barely understand the protocols in cars yet want to go fourth with writing about reverse engineering them. My end goal was to always put effort into the education I put out there and show you guys that there is much more than some people make it out to be! After this article you may also come across an article known as Automotive Security: FlexRay which is a smaller article that talks about FlexRay and the protocols specifications, deeper sides of it and more. There is something I would like to mention about automotive protocols. By far just actually with testing in this world, without sponsors or funding it is extremely hard to get your hands on some good education and even simulators that mock networks. That being said, do not let that discourage you from researching into this field! This is where I tie it all together. I write the “modules” if you will on medium and other platforms for free and do not get paid because I believe that if I can take some readers hand and hook them onto this road path- make it fun and unique, then they will see the deeper sides of this field and see where this goes. When I see people type 5 minute articles I say to myself they are showing commands, but do they actually know whats happening? and when I ask said person the questions they just seem to loose a slight bit. So, I want to make sure that I can hopefully inspire people and be the very few resources out there that can get you to understand that this field is much more badass than just simply pasting a bunch of commands — trust me when I say this, this field especially in the networking side and hacking side of things is MUCH more than you think it is!
So, lets conclude this article. As the world of automotive systems become more and more complex, we will start noticing many more solutions to the CAN protocol or rather alternatives to the CAN protocol and may be able to realize that CAN has many flaws. However, this does not mean CAN is completely worthless- in fact its one of the most important automotive protocols to date because of how intensely adopted and flexible the protocol is. Not to mention, when you go into reverse engineering it; you will see a side of CAN that not many do until they get their first hands on experience with CAN. Anyway, I hope that if you have read this far and have actually bothered to take the time to read all of this- know that it is deeply appreciated. I spend a ton of time writing these articles simply because it is a personal outlet and I do it for the love and the pure hate I have for an industry that wants to overly price and scam people out of hundreds of dollars just to talk about an industry standard or some protocol like CAN- I assure you, its not that hard to just Google something and THAT is why I write. I also write because it is a huge outlet for things personally in my life- whenever something happens, just hit the keys about something you are passionate about. Sure, I may be lost in space like the dog you have been seeing in the GIF throughout this article, but that says a ton about me as a writer.
Authors Note: I want to make note of something. I spent so much time in my career searching for this external and even internal validation holding back from being myself, holding myself from selling or creating content that was my own- holding back so much of who I was as a human being that it completely destroyed me. I want the reader of this article to know that it does not matter if I get banned here, I could give a fuck less about some BS external and industrial validation from a stranger- that is by far as a writer, author, youth educator and motivator the ONE thing that completely ruined my career and forced me to grow used to things I hated. SO THAT BEING SAID — I say this to the reader with love and respect, be yourself, if a job wants you to be the opposite- then they clearly are not it for you and its not a good work environment. Get out when you can. The same goes for people in your life that want to limit you, people that want to bring you down and people that tell you that you absolutely have to be so and so person, be someone your not just so they can feel happy being around you. Its a fucking delusion hahah! Anyway, stay cool my friends :D
Ending Note — Extra’s, Resources, Support, Thanks
Alright nerd, you get the idea of this section. Its simple just a section that will give you some resources and summarize the other sub-sections here!
Ending Note | About Me → This section will talk obviously about me, who I am, why I am doing this, current projects etc.
Ending Note | Thank You → A section thanking you for reading this article and explaining why I value community.
Ending Note | Ways To Support → A section talking about ways you can support me with currency!
Ending Note | Where To Find Me → A section that talks about where you can find me and how you can follow me.
Ending Note | Resources To Advance Your Knowledge → A section that explains some basic resources used to help you.
Below, sections are listed and talked into!
Ending Note | About Me
Hello there nerd! My name is Ryan and I am commonly known as Totally_Not_A_Haxxer! I am a 16 year old security researcher and developer with quite the experience primarily in development (50+ language’s including working on my own) and take a huge interest in automotive security! I write the articles I write especially in length as well as books because I believe that knowledge is for everyone and should not really be charged so much. For example, I saw someone write a Golang tutorial that was like 10 hours of content and charged over 1K for it- I thought it was a complete waste of time so I started my blog page to not only do what they were doing but do it better and for free! I also have multiple projects going on around education such as $1 Courses which are courses on various topics in tech or even general that get sold off for a single buck! That is a small about me, you can find more which we will get into in quite a second hahaha!
Ending Note | Thank You
I want to also thank you for reading the article and coming this far, I know these articles are extremely large and take a ton of time but I hope they were worth it. I do try my best to actually go and put the time and effort into the articles by ensuring that I can actually help educate people and go deep into the topics I talk about for free! So, if you have made it this far, I appreciate giving the effort back as far as reading the article and hoped it helped :D!
Ending Note | Ways To Support (Financially)
Currently I am not in the best of situation with money and I do not have the proper funding to afford good equipment for security research even something as much as a laptop where I could do remote work. That being said, I have always been used to saying “I do what I do with passion, and I will stop at nothing to do so”. Even though I do not have the direct resources, I always do try my best to deal with what I have and do what I want to do with said resources that I do have. With this, I ask that if you can bother to donate or do have the extra to spare, this will make my development, skill and more go much MUCH more faster and also make me much more motivated to continue doing what I am doing! Below I have listed my cashapp and venmo as well as crypto wallets!
Venmo:
Venmo | Totally Not A Haxxer hacker Venmo is a digital wallet that lets you make and share payments with friends. You can easily split the bill, cab fare…account.venmo.com
CashApp:
BitCoin Address: bc1q45ctj3cwl8zr2qdw4xceukr58cdnayxuutymt8
Ethereum Address: 0x466BA936E2bdbEab74c8cd048CC43279fE712E54
USDC Address: 0x466BA936E2bdbEab74c8cd048CC43279fE712E54
Tether Address: 0x466BA936E2bdbEab74c8cd048CC43279fE712E54
XRP Address: r4s8FeyYCBHJQGJRGuDuPeM2YLMwRCZP4R
Ending Note | Where To Find Me
This sounds weird to say, but you can find me on a few places; social media is one of them. Below I have listed some links of where to find me but I will say this. Often in discord servers, communities and even other platforms: some people always ask me for links and I can get tired of constantly pasting social media links on days where I have a bunch of stuff to do and given social media is not on my phone ( at this time, working on a study / ghost month ). SOOOO, that being said, Google is a good place to go literally search “Totally_Not_A_Haxxer” and some of my socials should pop up + look at it this way, you get more OSINT experience.
Instagram
Medium:
Totally_Not_A_Haxxer — Medium Read writing from Totally_Not_A_Haxxer on Medium. Cyber Security Educator, Developer, Social media manager, Author…medium.com
Blogger:
Hakin9 Articles / Research point
GitHub
TotallyNotAHaxxer — Overview Single Developer of the red rabbit project, leader of the scare security team, and Single developer of the Grizzly…www.github.com
Google: https://www.google.com/search?q=totally_not_a_haxxer&sxsrf=AB5stBjHLrW6iWuxLvuh7jKHebe6L-BTGQ%3A1690923815850&source=hp&ei=J3PJZJqkL-nakPIP7dqCgAo&iflsig=AD69kcEAAAAAZMmBN09YHcUlW2STp8BofYjoKR1t0GgH&oq=tota&gs_lp=Egdnd3Mtd2l6IgR0b3RhKgIIADIHECMYigUYJzIEECMYJzIHEAAYigUYQzIHEAAYigUYQzIHEAAYigUYQzIHEAAYigUYQzIHEAAYigUYQzIHEAAYigUYQzIOEC4YgAQYsQMYxwEY0QMyCBAAGIAEGMkDSMYGUABY1QJwAHgAkAEAmAGtAaABhQWqAQMwLjS4AQPIAQD4AQHCAg0QABiKBRixAxiDARhDwgIIEAAYigUYkQLCAhMQLhiKBRixAxiDARjHARjRAxhDwgILEC4YigUYsQMYkQLCAg0QLhiDARixAxiKBRhDwgIKEC4YigUYsQMYQw&sclient=gws-wiz
Ending Note | Resources To Advance Your Knowledge
This article, like most articles, was quite deep- We talked about automotive standards, automotive systems, automotive networks, automotive idea’s, how cars work, ECU’s, monitoring systems, diagnostics systems, simulators, Linux utilities for CAN and more! So, I have a few really good resources for you to advance your knowledge on cars!
CAN-BUS: https://en.wikipedia.org/wiki/CAN_bus
Introduction to CAN: https://www.ti.com/lit/an/sloa101b/sloa101b.pdf?ts=1691111604880&ref_url=https%253A%252F%252Fwww.google.com%252F
CAN Notes: https://www.eecs.umich.edu/courses/eecs461/doc/CAN_notes.pdf
Book Tech: https://copperhilltech.com/blog/controller-area-network-can-bus-message-frame-architecture/
Book #1: A comprehensible guide to Controller Area Network
Book #2: Automotive cyber-security
Book #3: The Car Hackers Handbook
Book #4: Network fundamentals
The FlexRay Protocol: https://en.wikipedia.org/wiki/FlexRay
FlexRay basic introduction: https://www.influxbigdata.in/flexray
FlexRay Protocol:https://piembsystech.com/flexray-protocol/
GMLAN Protocol: https://en.wikipedia.org/wiki/General_Motors_Local_Area_Network
GMLAN Intro: https://www.atechtraining.com/products/automobile/gmlan-network-system
GMLAN CORE PDF: https://atracom.blob.core.windows.net/gears/2010/2010-04/2010_4_22.pdf
MOST Protocol: https://en.wikipedia.org/wiki/MOST_Bus
MOST Solutions: https://www.microchip.com/en-us/solutions/automotive-and-transportation/automotive-products/connectivity/most-technology
LIN: https://www.ni.com/en-us/shop/seamlessly-connect-to-third-party-devices-and-supervisory-system/introduction-to-the-local-interconnect-network-lin-bus.html
LIN PROTOCOL: https://en.wikipedia.org/wiki/Local_Interconnect_Network
CAN-FD ISO Standard: https://www.iso.org/standard/45677.html
Systems CAN-FD: https://www.peak-system.com
Possible articles on CAN-FD [extra where to look]: https://www.kvaser.com/
Vector Group: vector.com/us/en/
Jeep Hack: https://www.wired.com/2015/07/hackers-remotely-kill-jeep-highway/
Audi Q8 FlexRay Intercept: https://comma-ai.medium.com/hacking-an-audi-performing-a-man-in-the-middle-attack-on-flexray-2710b1d29f3f
Yorumlar