Automotive Security: Reversing CAN

Reversing CAN — Introduction & Layout

Ah yes, another cool article in on my automotive series! In this article, as you can imagine, we will be talking about multiple automotive protocols such as CAN and go into the deeper underground parts! But, for now, whats the purpose in reverse engineering on cars? As i have mentioned in previous articles ( if you are following this series ), the primary purpose of being able to layout the possible points or attack surfaces in a car is to make sure we can see all the possible places where data could be flowing in and out. Reverse engineering the protocols or even systems inside of cars is important because it can help us understand how data is flowing, where its flowing, why that data is flowing to where its going and also where the data is coming from which in turn help us discover more vulnerable systems within the vehicle! This can not only be extremely helpful to our development but can even give us a good understanding of lower systems. Before we get started, its important that we can get a good layout or understanding of this article and its structure to make sure you can follow it around!

• Reversing CAN — A Small Introduction To RE: This section will talk about reverse engineering, the major parts it entails, how its helpful in the automotive world, how we can practice it, why its important for practice and logical process building and why its also a great exercise to learn!
  

• Reversing CAN — Why Automobiles?: A section that talks about the current spot of reversing engineering automobiles, something the previous section does not talk about and also speaks on downfalls to reversing the networks used in automobiles. You can look at this section as just a small extension of the previous ones.
  

• Reversing CAN — Automotive Networking: A section that talks about how vehicles communicate, we will introduce you to multiple protocols such as CAN, MOST, FlexRay, I2C, and the new coming of Automotive Ethernet, why networking is needed and more. This should give you a good base to understanding what the next section will be talking about.
  

• Reversing CAN — The Controller Area Network Protocol: A section that will talk deeper into the CAN protocol, why we are targeting it, how we can simulate it, and even talk about the amazing works of Linux!
  

• Reversing CAN — From Geek to Nerd: A section that talks about going through every tool in the CanUtils suite, explains how it works, also explains how we can use them and also why we use these tools. We will also bring up other tools and more advanced frameworks hackers may use to reverse engineer protocols and systems inside of cars!
  

• Reversing CAN — Reversing All Levels of ICSim: A section that will purely demonstrate putting out knowledge from the section “from geek to nerd” to the test and reverse engineering everything we can in ICSim from level 0 all the way up to level 3.
  

• Reversing CAN — Summary & Conclusion: A section that will summarize the article, make some decent notes on automotive security and where it is going in the future and how people / organizations such as BlockHarbor are actually here to make a huge impact!
  

• Reversing CAN — Ending Note: A end note / section that will provide you information on who I am, how you can support my road-path within this field and others, why I am in this field, resources for you to start in this field as well as a thank you note!

Before we get into the article, I would like to go over some basic terms so that you know what we are going to work with and also so you can get used to the terms. So Below, is the section for terminology.

Terms and Definitions

• IC → Instrument Cluster. I am sure you guys know what this is but if not, the instrument cluster of a vehicle is the panel and cluster of diagnostics you have on the car such as speedometer, gas gauge, oil gauge, tire pressure monitor, and more.

• INFSys → Infotainment System is the system or digital panel within a car, this you should be familiar with but I will drop an image.

• ICSim → Instrument Custer Simulator also known as ICSim is a simulator that simulates a basic CAN networks within cars and allows us to inspect how networks operate within Cars with the most basic level. This allows us to also understand how to reverse engineer systems. We will get a basic understanding of this later and we will also be using this to practice reverse engineering.
  

• Reverse Engineering → Also known as RE, reverse engineering is the process or action of taking a computer application or system or concept such as a game and then dumping the internal functionality of it to modify or view and even understand the internals of said system to put it lightly.
  

• CAN → Also known as Controller Area Network is a commonly known automotive protocol used for systems such as the diagnostics systems within a vehicle. In short, this protocol exists in automobiles to make it easier to communicate with modules within the car.
  

• FlexRay → A much more expensive, complex automotive networking protocol which can be known as the “luxury protocol” due to the types of cars that utilize this protocol (Audi A5, Mercedes, Lamborghini).
  

• CU → CU is a term I am using to refer to the CanUtils suite within Linux. This is a suite of tools used for working with the CAN protocol and also the set of tools we will be using to reverse engineers cars and systems.
  

• BH → BH in the context of this article mentions BlockHarbor which is an automotive security research company that fully dedicates their time towards automotive security research. We will get more into them at the end of this article.
  

• CH & CL → These are going to be the different speeds of CAN. CH stands for CAN High which is a much more higher speed part of CAN and CL stands for CAN Low which is a much more lower voltage version of CAN.
  

• OBD (2/II) → OBD also known as On Board Diagnostics is a diagnostics system that implements the Controller Area Network (CAN) protocol and is how automotive researchers can understand how a car works and how mechanics are able to see directly what is wrong with a car in much more deeper detail.
  

• ECU → In this article, we will be referencing to ECU’s as Electrical Control Units but there is another type of ECU known as an Engine Control Unit which is a module within a car to put it in short terms that works around the engine. Engine Control Unit is used in the next definition. Note that the use of these terms depends on the context of the sentence and the person ( mainly the way they use the term, so pretty much context).
  

• DTC → Also known as Diagnostic Trouble Codes is a set of diagnostic codes that are spit out by the ECU ( Engine Control Unit ) when something goes wrong or when a test is made within the car. We will get more into this later but this is a good overall idea of what DTC means in the context of this article.
  

• TPMS → Tire Pressure Monitoring System, the name is literally the system.

Now that we have gotten terms out of the way, let’s go ahead and start this article and actually get it over and done with!

Note: At the end of the article I will be listing resources and some basic stuff to get you started in the automotive security world and also talking about some groups that are making quite the effort in the automotive security world. So if you are looking for a base or some general idea of resources, that is listed at the very bottom of this article. Its also important to note that we will be working with reversing the protocols using Linux since the utils suite and the protocol implementation is primarily on Linux. In terms of OS specifics we will be using ParrotOS ( Architect Edition ) for the reversing which comes standard with utilities. When it comes to setting up ICSim for our reverse engineering we will go ahead and do so. For demo’s and just basic videos and walk through without deeper explanations, you can go ahead and look at the SkyPenguin-Labs YouTube channel run by Totally_Not_A_Haxxer ( the primary author of this article ) which demonstrates some basic abilities going through the different levels of ICSim without explanation and walk-through. Again those videos are used for EDUCATIONAL PURPOSES ONLY and are also supposed to be used as just a quick reference. Now, without further to do or further to state, lets get into this!

Reversing CAN — A Small Introduction To RE

Before we can hop into everything especially hop deep into reverse engineering, it would be a good idea that we get a good understand of what reverse engineering is, how it works, why we need it, where it becomes useful in the automotive sector of things, the different fields and so on from there. As mentioned before, this article is primarily aimed and focused on reverse engineering the CAN protocol, so we are in a different type of reversing but still can get a good idea of the field in general. So, what is RE? RE is exactly what its name implies, you are reverse engineering the internal functionality of a application, protocol, system and really whatever. For example, say you have a proprietary protocol such as AirPlay which is used by Apple’s AirTunes systems and is a screen mirroring protocol primarily. What if we want to truly know how it works? Well, in today’s world there are more than a few people who have successfully documented and reverse engineered the protocol, but what exactly did they do to reverse it? There are many steps they have taken or may have taken, but what they in a general sense did is try to understand the protocol using systems that used it, sniffing data from those systems, creating sessions and watching how they work, trying to get the protocol to send out specific signals and even using a strong sense of logic to get things to a more deeper understanding. The purpose of them doing this was to reveal how Apple’s proprietary protocols and systems worked. Not only did this help security researchers exploit and understand flaws within the protocol but also understand why they wanted to keep it hidden! How about now? Can you guess exactly what reversing is by this point? If not, the general idea of reverse engineering is just picking something apart to learn about its internal functionality, what it does, how it works, why it works and it is all done for various reasons.

Now, as far as reversing engineering goes, what type of fields use reverse engineering? Well, below I have listed some fields that may use reverse engineering and why. Note that all of the fields listed below are not generalizing fields of work but rather fields or groups that may be apart of RE or use RE.

• Automotive Security: The topic of this article is all getting you interested and used to the world of automotive security, so why not start there. The realm of automotive security revolves around MANY different fields such as web security, protocol security, hardware security ( in rare but some cases ) and various other fields. This is because as technologies grow, cars do with it and for most if not every new feature that comes out in the automative world ( the world dedicated to researching new ways to automate specific tasks in a humans daily life ) a car might implement it. We see this constantly growing every single day in the newer cars that come out! So, because of all the different systems, automotive security just includes a ton of research fields because those systems that are exploitable using different methods. However, in order to understand how those systems work without documentation especially if it is proprietary; automotive security researchers need to use reverse engineering on multiple systems! For example, say a automotive security researcher is trying to exploit a more complex flaw in a system and also understand the system from the lowest point possible. The security researcher would end up dumping the firmware or software on the vehicle then reverse engineering it to see if they cant find any sort of secrets, directional information and even understand how the systems in the car are built. This can help in the general research because if the attacker can get a good understanding of how the systems work from a lower perspective, they may be able to understand how the system works on a higher level much more easily. Reverse engineering is also used in other aspects of the automotive security world, but that is just one good example.
  

• Malware Analysis: I am sure you all are really familiar with this already, but malware analysis is another really popular field that sparks and screams reverse engineering. This is because malware analysis typically revolves around trying to understand, mitigate and even explore and document malware developed for specific situations that were developed to be hidden and developed very specifically in a different style. Now in order for a malware analyst to directly understand how malware works, they need to isolate it in a sand-boxed environment and figure out how the internals of it works by using reverse engineering tools to help them gain a more advantageous grip on the attacker or need to release research or reports on it. Malware analysis goes extremely deep and there are a million different ways to explain it but, for now this should give you an idea of why RE is useful in malware analysis.
  

• Exploit Development: Exploit development is an interesting one, some people commonly believe that exploit development is reverse engineering when it actually just uses reverse engineering heavily. For those who are not too knowledgeable on it, exploit development is as the name implies; the development of exploits for a specific system. Lets take game cheating for an example, everyone screams “hacker” when they see a cheater inside of a game, but why is that? Well, game hacking revolves deep analysis of the games internals, understanding how the game works, understanding how data is stored in the game and in the case of more popular games; how the anti cheat systems work. In order to hack a game and develop cheats such as aimbot, ESP ( Extra Sensory Perception: A cheat that adds more “sensory” to the player such as the ability to see when a player is looking at them, see enemies through the wall, and more), as well as understanding how to even start testing that cheat; the developer MUST know the internals of the system. This is because they need to exploit flaws in the game and the anti cheat system to be able to properly write their code or cheats. This requires again some heavy reverse engineering, without reverse engineering or a general concept of it, then game cheaters would not be able to even exist.

Cool, we have the most simplistic idea of what reverse engineering is and where it is applicable. But, the bigger question, is why do we need it? Like okay, we have already explained that in the automotive security world, but what is the general reason and purpose to learning it outside of that? When it comes down to the world of hacking, the one thing that aids you the most is experience, and experience builds logical training. Wait say that again? Yeah, logical training. I should have expressed this more and I do stress it in my articles, but in cyber security especially when attacking systems, having a good logical base will help you not only read into newer vulnerabilities a ton more easier but also give you a good way to explore systems that are not documented. But now what do I mean by experience?

We all have known for decades that you can take a million tests and still not know HOW to do something. That being said, experience and knowledge helps you, but how does experience build logic? lets put it in the following example.

Say you read and take a few exam’s on SQL injection (SQLi) and you then start tackling some boxes and CTF’s to help you practice. The thing about CTF’s is while they are fun, they are not real world, but they do give you some hands on experience dealing with that vulnerability. When you hop into the real world, you will know that the systems you are dealing with can be much more complex and require much more knowledge, but the logical processing that you gained from practicing and taking exams ( which takes core knowledge of the concept ) will be able to guide you into exploring that system. You already know how to find the flaw and exploit it, you just need to know how to properly apply your skills into other systems and how to get around more advanced systems by learning around with them.

The same flows for reverse engineering; reverse engineering is something a ton of fields in the cyber security realm use. Learning it for specific cases such as binary applications, protocols, other systems, etc will all help you build this logical structure that can guide you into easily understanding systems in the future and even learning how to exploit systems. I talk more about the in the article shown below that talks about reverse engineering and concept logic ( the logical state of concepts, understanding how they work really ).

Reverse Engineering: Conceptual Logic A very detailed article which shows you around game cheating concepts on a much deeper mathematical way also explaining this…read.martiandefense.llc

Lets get back onto target and subject of the article, given reverse engineering is always decent to at least understand, what is its direct usage in the automotive world? As mentioned before, we made an entire point as to why it works and why we use it, but we failed to talk about specific areas where it is useful and also the failures in today’s world with it.

Automotive Security — Reversing CAN | Breakpoint Section

I know this article is quite big, so I will be placing these break point sections throughout the article so you can know when to take a proper break and when I think it may be much more logical. I do this for general health hazard because even as a writer- I am one fast dude- I will write these types of articles in under a singular day with all the proper research and resources- but even I admit, this sh*t is HARD! I would be completely surprised if I do not have carpal tunnel by 18 alright 😂. So please, for the sake of your health, take a damn break dude.

Reversing CAN — Why Automobiles?

When it comes to automotive security, there are many applications to reverse engineering, but why and where do we use reverse engineering in this world? As we gave you previously, it allows security researchers to reverse engineer the firmware of a car, but lets go ahead and go even deeper: The networks. You may not think it, but cars today are heavily equipped with networks, anything from gas and breaks to radio systems and diagnostics systems are all powered by a network and a specific protocol. Each brand has their own implementation of this protocol, sure the structure stays the same and so does most of its usage, but where the data is and how / why it is needed will change or rather how its processed. Of course again, the idea and core concept stays the same, but like everything, the implementation does change. Lets look at the example below which is a graphic of a car and what the network may be operating with.

This is a small example of how the systems and modules in a car are tied together, maybe its not the best example of protocols but its a good example for the base and surface of this section. Each network has its own purpose, each system and each module also has its own purpose, but they all need to work together and communicate with each other without not only taking up so much resources but also not failing so much due to the smallest physical issue. Automotive security researchers require reverse engineering because they need to be able to reverse engineer specific protocols, or systems that interface with this network in multiple forms! For example, lets take what we will be doing today. The task at hand and the todo of this article is to not only understand how automobiles network but how to also send signals over the network using the CU suite. But in order to understand how we can do that, we need to use other tools within that suite to reverse engineer the network, understand how the protocols work and more. In the case of general research especially in the automotive world, reverse engineering really comes in handy for multiple purposes such as again, figuring out how proprietary systems work.

Lets roll back a second and talk about our end goal. The purpose of our end goal is to simulate how cars can be manipulated simply by having physical access to the cars ports or systems. In the real world, hackers are not always going to be directly going straight for the systems, and there is a reason for this. Companies over time have realized the amount of security flaws when working with specific easy to understand non-secure protocols such as CAN- that is, how extremely easy it is to access on every car. Every car has something known as an OBD port which we will get into deeper later on the CAN protocol, but in a smaller sense for the scope of this section; OBD is used by manufacturers and mechanics to test and read data from the cars diagnostics systems. However, as the simulator we are using today demonstrates, if the diagnostics module is not separated from the main network, we can actually go ahead and just send signals to the network that go un-verified such as locking or unlocking a car. There is a reason this method does not fully work despite sometimes working now, that is because those companies have went forth with the action of separating the diagnostics module from the primary network and modules. They do this to ensure that the protocol can still be used without easy manipulation right away. Not to mention, physical attacks on cars are just not as helpful to an attacker as they are extremely time consuming and take so much knowledge of the system. Lets roll forward and end this section off by answering the question — if it is not a common method, why practice it?

Reversing the CAN protocol using simulators is just a good way to practice and understand how bad and how easily exploitable cars CAN (pun intended) be if security is not properly implemented and also just to give yourself a good example of how things work. In general, when we do practice reverse engineering can especially physically, it can give us experience with systems, understanding ways to access systems within cars and even give us an understanding of why reverse engineering is important in the automotive security realm.

Note: I apologize for the spottiness in this section, I felt that this one along with the previous one was super un organized simply because they were not so user friendly towards the concepts especially if you are new. Hopefully the next topics talking about networking and protocols in automobiles can give you a much more structured sense of the section above and the points that were made. If you have made it this far, thank you :>

Reversing CAN — Automotive Networking

The goal of this section is to make sure that before we talk about the CAN protocol, that we actually understand why, how, and what automotive networks work and are. This section may be a bit technical, so make sure you at least have a general understanding of what a network is before you walk into this hahaha! But, I also felt like separating this section into subsections to categorize how this all will work. Below is a list of bullet points that will label the subsections.

• Automotive Networking | Why Networks Are Needed: As the name implies, the goal of this section is to teach you why these networks exist, their purpose, also why there are so many different protocols and also give you a good understanding of just “why”.
  

• Automotive Networking | How Networks Work: A more detailed section as to how these work, an introduction to the communication modules and other systems in cars. This section will also talk about the different protocols in the section of automotive networks. These protocols will not be explained deeply and have their own article, but we will be speaking about CAN on a deeper level.

Starting with the first section, why are articles needed?

Automotive Networking | Why Networks Are Needed

As mentioned in other sections, the world of automobiles is quite large. Millions of cars have networks in them, they also have support for Bluetooth, WiFi and other forms of communication. But in the end, why are these systems needed? The simple answer is just that these ways of communication are nicer for the end user, but wait- we are not talking about that type of network are we? No we are not :D

A common misconception in the universe of human beings is that cars that are not EV or have combustible engines are cars that do not have any networking capabilities and also do not have any capabilities of being attacked by hackers. Sadly, that is not true, even your car from 2004 might be attackable. This is all because automobiles every since the early 2000’s going as far back to the 90’s have used automotive networking systems. But what are these systems and why do they exist? As cars and time went on, people always expected more from technology especially if it was to improve their life. With this improving rate of technology and need for something new to improve life, people also wanted their cars to improve with it ( which worked anyway ). So the more advancements came along, came new tech inside of cars, new fancy systems such as automated and assisted breaking systems, environment adjustments, warning systems, diagnostics systems such as tire pressure diagnostics, RPM and more! But wait, cars could also do some of this without these networks right? That is correct, cars could, but they were much more expensive to produce. This is kind of the same concept as just making cars all steel, over time the need for cars became much more larger because the population grew which means manufacturing cars or automobiles using pure steel inside and out was just too cost worthy. Similar to the metal issue, wires also became an issue, however a German organization found a way around this by inventing and implementing / researching into the idea of automotive networking systems. Cars back then had so much wiring in them and just became too much to produce, so the protocols and idea’s with networking became implemented in cars and cut down production cost by ALOT and not to mention, why spend the time wiring every single possible thing in a car together when you can wire a series of modules that just connected everything together?

Lets put this into a bigger perspective to show you why they are also a huge benefit. Below is a clumped list of 30 systems exactly that are commonly found in today’s cars that operate all through the network of a car.

• Systems commonly seen in todays cars that operate through a network → Engine Control Unit (ECU), Transmission Control Unit (TCU), Anti-lock Braking System (ABS), Electronic Stability Control (ESC), Airbag System, Tire Pressure Monitoring System (TPMS), Climate Control System, Infotainment System, Power Steering Control Unit, Adaptive Cruise Control (ACC), Lane Keeping Assist System (LKAS), Blind Spot Monitoring (BSM), Parking Sensors, Rearview Camera, Keyless Entry System, Central Locking System, Power Windows and Sunroof, Bluetooth Connectivity, Voice Recognition System, Digital Instrument Cluster, Adaptive Headlights, Rain-Sensing Wipers, Hill Start Assist, Electronic Parking Brake (EPB), Start-Stop System, Collision Avoidance System, Fuel Injection System, Electric Power Steering (EPS), Vehicle Dynamic Control (VDC), Advanced Driver Assistance Systems (ADAS).

Can you imagine these systems without a network? Not only would some of them not be truly possible to fully implement, it would take almost quadruple the amount of wiring, triple amount of the money it took before, would require much more hands and machinery for manufacturing, would be slower during production and would be EXTREMELY slow during execution. Automotive networks and protocols exist to not only cut production costs but make it much harder for systems to fault and faster to respond to an issue. Another good example is just of how computers work; computers in today’s world can self diagnose problems and fix them if they have the proper mechanisms put in place. With cars its a similar deal, if there is an issue with the car or the network, it might self diagnose and figure out the problem or will send a diagnostics message to the dashboard alerting the driver that something is wrong with the car. Now again, without networks, this stuff is possible, but because of innovation and technological growth- automotive manufacturers have not only been able to save money but improve the lifestyle of millions of people. From the security aspect, like every other technological system especially networks in cars, there is a downfall when you mass produce a system and just get it out of the door. Now lets dive a bit more deeper, lets talk about “how”.

Automotive Networking | How Networks Work

As we mentioned in the “why” sub-section, in order for automobiles to properly work together, they need some way of communicating and networks are just that. But how do they necessarily work physically? Well, as cars become more sophisticated, just like wire and material production the production and need for ECU’s also goes up. As also talked about, ECU’s are an extremely important module in automobiles especially in todays world! This is because ECU’s have the primary task of managing everything from your infotainment systems to even small tiny comfort features within a car! Wiring all these together just becomes overly annoying and impossible to manage at such high production rates not to mention performance crashes! So, we need a way to network these modules together! In order to do that though, these modules need some form of communication architecture! For those who are not so keen on these terms, a communication architecture is also referred to as a network architecture which is a structured framework that defines how different components ( such as an ECU ) within a system or network will communicate and exchange information. In order for ECU’s to properly work the way they need to and communicate with other systems, they need to be able to have a set definition of rules, protocols and mechanisms that govern all of the data flow within the different elements of the system. For automobiles, the communication architecture is quite vast, and similar to standard networking, there are many different protocols that cars use in today’s world. So we can get a bit more of an understanding of what the communication architecture is, lets outline some key details that can help you really outline everything! Below are some basic points that can help us understand exactly what this architecture entails.

• Communication Protocols: Each type or form of networking and communication architecture has to include some form of protocol, I mean, after all…that is how networks work! Cars have their own sets of protocols which all have their own need and purpose and are all implemented for various reasons. For example, your most well known protocol is the CAN protocol while your more over the top and “less known” protocols in cars are ones like FlexRay. However, there are many others such as I2C, MOST, LIN, AE (Automotive Ethernet) and other various protocols. All of these go really deep, but, we will not be going deep into them right now until we reach the section that specifically goes into it. In short, these communication protocols are the set of rules and conventions that govern how data is formatted, transmitted and received between the ECU’s or modules of the car!
  

• BUS Topology: This is something that often confuses people, but a vehicle-bus also known as Vbus is defined as a internal communications network that interconnects components inside a vehicle and each bus has its own topology or rather physical layout of the communication network. A bus topology, for example in CAN-BUS connects all the ECU’s and modules along a single communication bus which allows them to share messages. Similar to standard network topology, bus topology also have their own methods of implementations such as star or ring topology. If you are not much more into networking, I suggest looking into those a bit!
  

• Data Prioritization: Remember how in the list of systems that work with a network in a car, airbags was one of them? Well, in an automotive network architecture certain data depending on the system must be given a higher priority than other data to ensure real time communication and a much more prioritized and rapid response from the network! This is to ensure that systems such as ABS are able to quickly respond when the time is needed and are not left behind because something such as the TPMS was trying to communicate data over the network.
  

• Error Handling: Like some other network or communication architecture, some form of error handling needs to happen. In automobiles, this is a MUCH MORE LARGER priority. The reason this needs to exist is so that the network can properly relay what issues are happening within the network and all of this is done through error codes or diagnostics codes within the system! Because of this, systems are not only able to self correct but also all internally make sure that everything is okay before throwing some crazy warning or making that dash light up like a Christmas tree!

There are many other parts of the communication architecture but this is just a general idea of the design that goes behind it! Now lets answer a more commonly asked question, why are there so much dang protocols? Well, like traditional networking, some protocols are just better and safer, others are cheaper, and all have their pros and cons. Below I have listed a brief description of each protocol and explaining why one might be better than the other.

• CAN — Controller Area Network: This protocol is one of the most commonly used and cheaper protocols to implement that exists in almost every car today. This is because not only did it get more attention faster and was cheaper but was one of the only plausible solutions at the time it was invented. Here is a general overview of everything and a general idea of the protocol. The CAN protocol was a project started at Robert Bosch GmbH also known as Bosch is a German multinational engineering and technology company headquartered in Gerlingen, Germany. They originally came up with the project and statrted it in the early 80’s specifically in 1983. The idea was to build a protcol and system in cars that could not only make manufacturing automobiles much more easier but safer and also make them much more faster in terms of communication. In 1986 the protocol was released and the implementation was made and concluded that it saved more space and was much more accurate than traditional wiring systems in cars. Later in the 20th century (1991) the protocol was fully implemented into a car known as the Mercedes-Benz W140 and was used to control systems such as the EMS, TCU, CCS, ABS and other various systems including diagnostics and troubleshooting systems! After its release and implementation, the CAN protocol got a ton more attention and even got its own standard from the ISO ( International Organization for Standardization ) which was titled ISO11898 and later restructured into two different parts! This protocol, was the new hots on the block hahah!

History and general timeline from the Automotive Security Presentation I did in a community discord server

• FlexRay: FlexRay is a much more complex protocol than CAN and was developed later in the mid 2000’s as a join project between multiple popular car companies! The FlexRay protocol is a protocol type i like to call “fancy” or “Luxury” protocol. Unlike CAN, the FlexRay protocol was much more expensive to implement; but was much more safer, much more complex, nicer, was much more timed and had a better structure than CAN. The only issue is again the expenses to implement the protocol. Despite the power and performance behind the protocol in comparison to protocols such as CAN — It gained popularity quite slowly and died off very quickly. There are some cars that still use it such as the Audi-A5, Audi-Q8, Lamborghini Huracán and other more expensive and luxury cars. The protocol was also much more secure given unlike CAN, instructions that are executed or passed through the modules all have their own time and even the smallest bump in that time the instruction is just thrown off the list of execution and gets discarded.

FlexRay Protocol Slide | History and general information on the protocol from the Automotive Security Presentation I did a while back

• MOST: In between the development of CAN and FlexRay came about a protocol known as MOST which stands for Media Oriented Systems Transport and is a protocol that was developed to meet the increasing demand for multimedia integration into modern day vehicle. The protocol is not widely talked about but it is definitely used; similar to FlexRay, however, it is primarily used in “premium” and luxury vehicles such as Bently, Volvo, Porsche, Mercedes, BMW and other various vehicles. This protocol was primarily known for its ability to provide a reliable and high speed communication network specifically for transmitting audio, video, and other various data between different modules within the car. A cool and interesting part about this protocol is that it uses optical fiber as a transmission medium which ensures that data is much more faster when being transmitted! It even gives the huge benefit of noise immunity which is due to how immune optical fiber is to electromagnetic interference which is pretty common in automotive network environments and just in the whole environment which is due to the electronic components within the automobile! There are many other pros to this protocol and it is still used and has continued development but has its own issues such as being quite expensive to implement. Generally speaking though, this depends on the type of protocol and implementation because over time from the early 2000’s to its now current development, it has been quite cost-effective due to different weighing factors.

Notice that all of these protocols have their different usages and points, similar to your standard TCP and UDP argument in standard networking. In today’s world there are also more protocols that are continued to be worked on everyday as we speak such as LIN, AE, I2C, GMLAN, CCP, J1850, VAN, SENT, and other various protocols. All of these protocols have their unique pros and cons which all fall under the following few points.

• Security: As we mentioned before, the security of protocols is extremely important and if a protocol is not secure enough or does not have even some security behind it, then it is just a gateway to ruining the companies reputation when it becomes attacked and publicly exposed.
  

• Cost: The cost of automotive protocols is also something to take into account. As mentioned when we started this section, protocols like CAN exist because the idea was to not only cut down manufacturing prices but also to cut down the whole idea of wiring everything together which adds so much complexity. The more costly a protocol is plays a major role in the initial choice.
  

• Complexity: Some protocols such as FlexRay are extremely worthy and secure because of their complex and advanced timing systems and fault checking systems. But with this adds so much more complexity during the implementation. The issue with this is that automotive manufacturers need to push out cheaper cars and fast to satisfy buy/sell needs. The complexity is a massive thing that companies need to weigh to make sure they can beat everyone to the race in sales and stuff those amazing bills in their pockets!
  

• Functionality & Speed: Speed and functionality is everything for a protocol, if a automotive protocol is short on time even by a second, that can be the leading cause to a possible death in the future. If the functionality is not set correctly and the protocol was not implemented or built with the right functions, then you have another issue of not being able to properly diagnose systems because a functionality within the protocol might be broken or might not be existent.

Those are four prime examples to get you used to the idea of why there are so many protocols. Protocols are extremely important and as we have discussed, they exist for so many different reasons and all have their pros and cons! In summary, its important to also understand how these protocols work especially if we want to get to hacking them and taking something away from the security research! So, without much more to say, lets go ahead and see what truly is going on inside, what exactly does a protocol do and look like?

Note: In order to read this next section, you will need a decent understanding of computers , how networks work, basic OSI model knowledge, a decent understanding of protocols, methodologies, etc. I will be trying to explain specific concepts, but that would be an entire networking book if I spent the time deep explaining everything in relevance to the protocol we will be talking about. I also want to mention that I highly suggest you throw yourself at this section anyway even if you do not understand it all. Not because I guarantee that you will learn something but because I think especially with how I learned, sometimes throwing yourself into unknown environments with no prior experience or understanding can be extremely beneficial to how you do it and to why you do it. This is extremely important if you also just want to work with other unknown environments in the first place!

Reversing CAN — The Controller Area Network Protocol

As mentioned before, the most popular protocol to date is the automotive protocol known as CAN or Controller Area Network. This protocol is quite fast and is also quite cheap, it is common and easily accessible which also means its easy to plug into and work with. Not to mention, multiple utilities and systems for CAN exist on Linux which utilize the header files and source code files that help implement CAN. In order to be able to hack it or reverse engineer it, it is important that we at least understand what the protocol is and how we can work with it and what we are looking for. This section will be split into multiple subsections, so I have listed them below.

• The CAN Protocol | A Brief Introduction: We will start with the basics here, get you to understand the protocol on a technical level, get you also used to the idea of how can works on two different levels.
  

• The CAN Protocol | OBD(II) Introduction: Once done with the basics of CAN, we will be talking about OBD2, what is it, whats its relation to CAN and going back on the security of OBD2.
  

• The CAN Protocol | Packet Layout: Before we end this section, lets hit a bit of a networking road where we talk a bit about the protocols internal packet layout! This is so we can really get an understanding of how CAN frames work!
  

• The CAN Protocol | CANopen: A small section talking about what CANopen is. This section is not required for you to move onto the next level.

The CAN Protocol |A Technical World Of CAN & OBD2

We have already went over how the CAN protocol works and why it just works, but we have left out some technical aspects. So, in this section we will be talking about CAN and how it works on a more directly specific technical side. We will then as shown above ease into OBD2 and how that system works and what makes it so unique in its own ways then go over general packet layout of the CAN protocol. We are doing this for primarily just to get you familiar with the protocols and systems inside of cars more than we already have. This section will highlight and draw out the main idea between the CAN protocol and also help you understand OBD2 using real world examples. So, to make this section much more organized, I figured why not get into it deeply but also make sure it is easily digestible by readers in sections!

• A Technical World | Technical Intro To CAN: This section will go over CAN in a much more technical but still easy to understand way! We will first talk about the technical idea of CAN and then ease into HS and LS CAN (high speed and low speed). Then be able to take everything to the test by understanding the primary differences between HS and LS CAN.
  

• A Technical World | Diving Into OBD2: This section will bring a quite technical introduction into what OBD2 is and cover topics such as how to work with diagnostics tools, the OBD2 port inside of Cars, DTC’s (Diagnostic Trouble Codes), then finally end on diagnostics with UDS ( Unified Diagnostics Service ).
  

• A Technical World | CAN we go deeper? (Pun Intended) A section that goes a bit deeper into the packet layout of the CAN protocol which can help you understand the general format and idea of the protocol itself. We will then end on talking about the CANopen protocol.

A Technical World | Technical Intro To CAN

By now, you should already have an understanding as to why CAN existed in the first place, how networks work in cars, and a base understanding of what CAN is. But lets go ahead and recap on a more technical reason and understand CAN’s technical idea! The primary idea behind CAN is to create network that allows multiple ECU’s to interact with each other by sending data and receiving data to and from each other quite efficiently while also providing a much more fault-tolerant message delivery. Now, CAN has a bit of a different structure. Instead of P2P (Point To Point) connection or communication which is where each ECU has a dedicated connection to all other ECU’s, CAN employees a topology known as a multi-master-bus topology. This means that all the ECU’s on the network all share the same communication channel/medium which is the CAN bus! Getting the idea? As mentioned before, the older methods of P2P topologies are very task heavy and very hard to constantly mass produce due to the amount of modules a manufacturer would have to end up pulling together and also the amount of extra wiring and time it might take to implement a dedicated connection system to all of the ECU’s tied to more ECU’s. Its just, overly complex and annoying to work with in today’s world! Because CAN was designed to be robust and fault tolerant, this makes it quite suitable to real time applications. Going back to systems, such as breaking systems, airbag systems, sensory systems and more, these systems not only need to be prioritized on the network but also need to have a system that can react extremely quickly! Not only does CAN find a way to do this fast but also deliver it without full fault! One of the unique mechanisms that makes CAN just work is its collision avoidance mechanism which allows multiple ECU’s to transmit messages concurrently without data being loss during transmission. This, mixed with the unique error detection and correction mechanisms just makes CAN worthy. But lets dive a bit deeper. CAN has multiple ways of operating and all of it happens through two different types of wires which are known as CANH and CANL. This is because CAN uses a method of signaling known as differential signaling which means that the two communication lines are used to transmit complementary signals. In sum, for the most basic explanation of them; CANH and CANL are very vital components of a CAN-BUS and they work as one to enable a cool little communication system known as bi-directional communication between multiple ECU’s on the network. Recall that we mentioned that CAN is a fault tolerant protocol, this makes differential signaling better of a choice to work with especially in environments that must be fault tolerant to noise. When a bit is transmitted on the CAN bus the signal will simultaneously broadcast both 1V higher and lower. This differential voltage level between CANH and CANL is what represents the data being transmitted on the network. In sum, differential signal in terms of CAN means that when a signal comes into the network, CAN will result in raising the voltage on one line and drops the voltage on the secondary line the same amount as the raised voltage! Lets chill out for a second and try to explore CAN on a physical level. Lets explore OBD connectors.

The CAN Protocol | OBD(II) Introduction

I am sure that some of you reading this are familiar to what an OBD connector is. But for those who dont, the term “OBD” refers to On Board Diagnostics and every car that uses the CAN protocol comes with a connector that is at least in today's date known as On Board Diagnostics Connector (2/II) or Diagnostic Link Connector. The point of this module or connector is to communicate with the vehicles network and also allows people such as mechanics to read specific codes and diagnostics off of the module. But what exactly does OBD2 have to do with CAN? Well there are multiple reasons. First and foremost, OBD2 provides a way of directly connecting to the vehicles network and defines itself as a standardized diagnostic system to monitor the vehicles performance and emission related data. There are a few good things to the OBD2 connector that just make it work, a good 4 points are listed below.

• Data Transmission: The first good point that make OBD2 the newer and greater standard is not just because it is closely tied to one of the most commonly used protocols but also because it includes a neat reliable and efficient communication system that can easily transfer data such as diagnostic data from different ECU’s to the diagnostics port which can be then read by specific tools. The reason CAN is closely affiliated with this is not just because it is the standard on OBD2 but also because CAN has as we mentioned real-time capabilities and the complexity with simplicity making it just right to handle multiple data streams properly!
  

• Diagnostics and Troubleshooting: We will get into this a bit more when we talk about using our own tools for working with OBD2 and also reading the voltages but the one thing that OBD2 is used for is literally diagnostics. As mentioned a while back in the module, cars used to be easy to manipulate using the CAN network and a simple OBD2 →USB connector that would plug into a laptop and then where someone may use that interface to remotely start or mess with the car. But ever since then, there is a module or system that separates and protects the diagnostics module from the primary network of the vehicle. Of course various methods do exist but regardless, the one great thing about using OBD2 is for diagnostics. When an issue or faulty occurs within the vehicles systems the corresponding ECU generates a DTC ( Diagnostic Trouble Code ) and then stores them in memory. In our example today, pulling data from a Chevrolet Tahoe we noticed that the powertrain control module had submitted a code that noticed something was wrong within the HVAC system. Again, we will get this when we get to physically accessing the module.
  

• Real Time Data Access: As mentioned in the first point, OBD2 enables real time data access to monitor various vehicle parameters such as the coolant temperature, current codes and diagnostics like the engine RPM and even down to the vehicles speed if you dig deeper enough.
  

• Emission Monitoring: OBD2 plays quite the role in monitoring emissions related systems to ensure compliance with environmental regulations. Some people may complain that this is a privacy issue ( as they do with any form of general diagnostics watch ) but anyway, through the CAN BUS the OBD2 system can access data from emission related ECU’s such as the engine control module, oxygen sensors, converters and more.

As you can probably guess by now, OBD2 is pretty important and has been implemented in well over a few million cars just going based on the amount of cars being produced! Pretty crazy right? Okay cool we have been able to talk about the OBD2 system, but lets get our hands dirty!

For this next part of the section, we will need a few tools well actually only two: a voltage meter and a diagnostics tool that can plug into OBD2 ports. For this current example I will explain a bit about voltage but wont demonstrate it. Simply due to the fact that the only voltage meter my house carried was one from the 90’s that I did NOT know how to operate O_O even after using google- but I will be demonstrating the diagnostics a bit more. So, lets kick it off! I will be making primary sections out of this, so excuse the confusing organization.

Automotive Security — Reversing CAN | Breakpoint Section

If you have made it this far, please take a break, I mean it. As mentioned in previous sections, this article is long and does not get at all any shorter. So please, make sure you get up from the screen, read a book or something, hydrate and eat! Especially this summer- Jesus lord have mercy it is HOT out this year- So please…hydrate

Getting Our Hands Dirty | OBD2 Testing!

Before we get into this, I should probably show you what an OBD port looks like if you are not familiar and where to access it. So, OBD ports are typically accessible under the steering wheel of the drivers side and can either be in the middle directly under-neath the steering wheel or can be directly on the far back left or far back right of the gas and break pedals. Below are two examples of the OBD2 port in two separate cars.

• OBD2 Port Location — 2009 Chevrolet Tahoe LT

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)

In order to access this port and retrieve data from it, there are two ways we can do so; both involve a OBD2 connector. The first one is very “hold my beer” kind of thing, the second is a much more safer mechanism. So, lets get through them.

• 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.

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 labels 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 ti 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.

Now that we have a basic understanding of how OBD works, lets talk about the pinout 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 pinouts are manufacturer specific and change per menufacturer. 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.

The layout is pretty self explanatory but I will go ahead and name it out.

• pin 2 & 10 — SAE J1850 Protocol: This protocol we did not exp-lore much since the focus was CAN but its good to go over a little bit now. In general the SAE J1850 protocol that was originally and primarily adopted in 1994 and is found in some GM Chrysler vehicles. The protocol comes in two types known as PWM and VPW. The reason J1850 exists is to just provide another automotive communication protocol to enable control modules to properly communicate with each other. It gives access to real-time data and is pretty cost effective similar to CAN. There are more different formats we could explain on CAN but I will not get into that today.
  

• pin 4 — Chasis: This pin is typically known as the pin that is used for grounding the OBD2 connector. The reason this exists is because a proper ground connection is essential for accurate and reliable communication between diagnostics tools and the ECUs.
  

• pin 5: Serial Ground: This typically is talking about the ground used for exchanging data between the communicating devices. It serves as the common reference voltage level for transmitted and even recieved signals. Basically without this, communication errors can occure due to voltage differences and signal distortion.
  

• pin 6: This defines the CANH or CAN High which is one of the two differential signal lines used within the CAN-BUS as we mentioned before.
  

• pin 7: This defines another protocol known as the keyword protocol (KWP) also known as ISO 9141–2.
  

• pin 14–15: Defines CANL or CAN Low which is the second differential signal lines used within the CAN-BUS.

I know what you are thinking, “wow, I got no information out of this”, I get that O_O. I do not think this article could even go deep into it so I only really wanted to give you a general idea. But, lets solve a question.

I know when I firs started I always got confused between High Speed CAN and Low Speed CAN as well as Can HIGH and CAN LOW as I thought it was just the same. But its not!

• The Difference Between CAN-H & CAN-L and HighSpeed CAN & LowSpeed CAN: CAN High also known as CAN-H is one of the two differential signal lines used in the CAN-BUS. The other line as we mentioned before is CAN Low or CANL. High speed and low speed can are where things get different. High speed can is a VARIANT of the CAN protocol which was designed for higher data rates and is often referred to as CAN 2.0B which operates on the physical layer as standard CAN. LS-CAN also known as Low Speed CAN is another variant of CAN and is used for smaller data transfers and data rates. There is also a third variant known as MS-CAN also known as MID-SPEED CAN which is used for an “in between” data rate.

I felt like I could have explained that a bit better, but that is an okay way of putting it. There are of course differences such as the data rate in KBPS that changes but those are more technical details.

Now, lets talk about locating CAN on an OBD2 port with a voltage meter.

• Voltage Meters: Finding and Locating CAN connections within an OBD port can be quite confusing to some people. But thankfully to multiple resources which I will go over at the end of this module, finding these with a voltage meter is not that complicated. Since again, I do not have a good voltage meter at hand that is not outdated, I can not showcase this but instead will have to kind of describe it. When we talk about finding connections on the port we are going to be basically hunting down the voltage of the cables. Lets start with CAN’s resting voltage. At resting, which means it is not extremely active and not transferring information or data massively, it will sit at 2.5 Volts (V). When a given signal is incoming to the network, the network will add or subtract 1 Volt (V) which makes its incoming and active voltage at either 3.5V or 1.5V. The magic hint is here — you will often find that CAN wires will sit at 2.5V and change or fluxate between 1V.

And like that, we can conclude our section. As automotive reverse engineers, it is important that we can understand how to work with a cars internal system. Sure, most hacking in vehicles in today’s world does not always revolve around physically accessing a car as we need some shape or some form of way to show people the dangers of automotive hacking if someone can remotely control the vehicle. However, it is quite important to be able to recognize errors yourself and plus be able to understand how the networks in a automobile operate. Now we move onto a much more complex section which talks all about the internals of CAN on a new level and a much more advanced and complex setting.

Automotive Security — Reversing CAN | Breakpoint Section

Wow, you are making it far- hopefully these break sections are actually working out for you. In the next section, if you are reading this, we are going to go into CAN’s protocol internals and packet examples, we will also be talking about CANopen, so be sure to strap that seatbelt on.

A Technical World | CAN we go deeper?

I hate to say it, but we have one more section to get through on this article, and that is actually understanding the CAN protocol. This includes understanding its frames and how it works and operates digitally. So, lets get started. To start off with, there are two multiple standards for CAN packets which are standard and extended packets. There is a major difference between the two so lets break it down.

CAN we go deeper | CAN — Standard Packets

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!

Automotive Security — Reversing CAN | Authors Note

I want to mention that writing this module even for me has been a pain, I want to also let you know that oddly enough I share the suffering of reading through it- so you are not alone! I also appreciate you taking the time so far to actually chomp this module down if you are reading it as a module. So again, I appreciate you hoping in here!

Reversing CAN — From Geek to Nerd | Utilities and Tools

Alright, we have finally hit the most important section of this article, sorry, module. So, lets get into what this section is. In this section we will be going over common tools and frameworks used to reverse engineer CAN and setup a virtual environment that can help us legally practice reversing engineering and at the end even learn how we can use and leverage the systems inside of Linux to be able to create our own unique simulator.

Automotive reverse engineers and security researchers use many tools and it also depends on the type of system they are targeting. For example, I have listed a few points talking about those specific systems or tasks.

• Firmware / Binary Applications: In order to reverse engineer the firmware in automobiles or even gain access to binary applications, they must use quite some unique systems and tools such as Ghidra and IDA to reverse engineer the application and may even need to use specific equipment on the hardware of the boards to bypass or rather glitch passed the board using injection attacks such as Fault Injection which we will not get into today.
  

• Internal Networks and WiFi Networks: There are many utilities a network / protocol reverse engineer may want to use. Some of these tools we will be using actively today. The first tool right off the bat will be WireShark, however, while WireShark works on the WiFi networks within the car just fine and other various types of networks, it does not hold the best support for CAN. This means that reverse engineers attacking the automobiles internal protocol will need to know how to use tools within the CAN-Utils suite in our case today or if they are targeting more complex protocols such as FlexRay and MOST they may need enterprise or more direct and professional equipment due to the complexity of these protocols. This is because protocols such as FlexRay are much more extreme and much more hidden in terms of implementation than protocols such as CAN may be.
  

• Web Systems / Servers: Some vehicles especially in today’s world may be hosting web servers within their general network. These devices can be accessed through just a little bit of testing. However, in order for reverse engineers or security testers to actually get a hold of these systems they need to be able to use tools such as Wfuzz or Gobuster and even more complex systems such as Postman and BurpSuite for much more accurate testing. Sometimes, in the more advanced sections, you may even need to write your own tooling or frameworks to work with the system you are working on which in turn can help with better flexibility during investigations. Tools like NMAP are also used to scan for services on the machine / vehicles systems and is quite important.

Now lets get into the tools we will be using today. On ParrotOS you should have a section that defines automotive and in that section you will see a list of tools. But, I want to make it from scratch to make sure I have the most recent version. So, lets just start by installing the suite.

When you finish installing the tools, you should have that section in your operating system that should be able to show you the tools included with can-utils. So, lets get into it and see what exists on the system.

After installing, we should see a similar list.

This is again in the ParrotOS system, the following list consists of the following tools and their description. Note that we will only be using the tools that have the [used] tag in the list which we will label as important as well.

• CAN-CALC-BIT-TIMING This is a tool used to calculate the bit timing parameters for a CAN controller, such as the Baud Rate Prescaler and Time Quanta settings. Tools like this are extremely important for proper bit timing which is quite important for reliable CAN communication.
  

• CANDUMP [used]: can dump is a tool that also allows us to capture and display CAN traffic. This tool we will be using to verify and also inspect data or events that happen on the network. This cool tool allows to also highlight specific information such as changing or fluxuating bytes on the network.
  

• CANFDTEST: CanFDTest is a tool that operates with CAN-FD another part of CAN that we did not talk about as much. Basically, CAN-FD is stands for Controller Area Network — Flexible Data which is a much more different and flexible version of CAN. This tool helps us test to make sure that the correct implementation and functionality of CAN-FD exists.
  

• CANGEN: CanGen, as the name implies, allows us to generate and send periodic or completely random CAN messages. This is mostly useful when we want to test or even simulate very specific communication scenarios.
  

• CANGW: Also known as GateWay-CAN is a tool that is designed to provide functionality for CAN communication between different networks or buses. Basically it enables the use for data exchange and translation between dissimilar CAN networks.
  

• CANLOGSERVER: This tool is a bit unique in its own way. This is a tool that operates as a server to collect and log CAN messages and facilitates sharing CAN between different systems using a client-server architecture! This tool can be unique in situations where we may need a different form of listener.
  

• CANPLAYER: If we do not have a live network connection anymore, what we can do is take a CANLOG and play it back using canplayer which will help us specify the ID, data and other parameters we may want to inspect directly.
  

• CANSEND [used]: This tool allows us to send data on the network. Now as mentioned before, this is a very small real world scenario anymore due to protection systems put on the car itself!
  

• CANSNIFFER: This tool is one of the coolest tools that can come default right now! This is the one tool we will be using to sniff and inspect the network .
  

• ISO-TP TOOLS: We did not go over this as much as I wanted to, but these tools are related to the ISO 15176–2 (ISO-TP) protocol which is used for sending larger sets of data over CAN. These set of tools provide a much more larger line of functions to handle those messages.
  

• SL-CAN TOOLS: This set of tools basically are tools for Serial Line CAN adapters. In the case that you have an adapter that bridges the communication between a PC’s serial port and a CAN BUS or in this case a OBD port.

All of these tools are quite important to our toolkit and there are many other third party tools out there which may be used to track the location of vehicles based on network logs, brute force diagnostic trouble codes, and so much more!

But, sure, we have our tools, what do we do with them? The first thing we need to do is properly setup our virtual environment and kick up some interfaces on our machine. This is because when we work with the virtual simulation we are going to setup, we need VCAN ( Virtual-CAN ) interfaces to be setup on the machine before we actually can use the tools and the other programs.

So in order to setup our interfaces we need to run the following commands in step.

sudo modprobe can
sudo dmesg 
sudo ip link add dev vcan0 type vcan
sudo ip link set up vcan0

These commands really should not just be slapped at you, so lets explain them a bit.

• modprobe: In order to even start adding and working with VirtualCAN we need to make sure that we load the kernel modules or drivers for the system to work with CAN. So we can use modprobe which is a command that allows us to initiate kernel modules.
  

• dmesg: When we run this command we get a very large output from all of the system messages but the dmesg command allow sus to view any kernelbuffer messages (ring0 messages). Since we used modprobe to setup CAN we need to verify that it actually loaded. So running the command, at the very bottom we should see something like the following output. This verifies that we can then setup our devices

• Ip: Ip is a command within linux that is used for network and interface configuration. After we ensure that the module has been loaded, we need to setup our devices and use the IP command to add a new device that is of type VirtualCAN. If we were using something like Serial Link we would use a specific tool in the can utils suite to set those devices up.

These commands I have seen most people just slap in the article and do not explain anything- felt like it was needed to be explained. Now that we have our interfaces supposedly setup, we should check it with ifconfig

Cool! Now lets setup our secondary environment and download the simulator.

A total geek in the field of automotive security who is an absolute legend known as ZombieCraig or Craig Smith designed a really cool simulator for us to actually inspect and reverse engineer CAN which can possibly simulate real world environments. This simulator is a bit older though and may not fully make up modern day systems — just a fair warning.

To install it head over to

GitHub - zombieCraig/ICSim: Instrument Cluster Simulator Instrument Cluster Simulator.

Clone it and then run it! Lets go ahead and walk through the setup. Below is a screenshot from my terminals showing how I ran the file and setup the environment.

As you can see, it did not take that much work and even if you wanted to you could easily setup VCAN because he provides a unique script that automates everything for you! When we CAT that file we get the list of commands as shown below.

sudo modprobe can
sudo modprobe vcan
sudo ip link add dev vcan0 type vcan
sudo ip link set up vcan0

Now, lets explain a small example of what the simulation contains.

• Controls: In order to properly simulate the network, we need a set of controls or control panels to actually control the virtual car and mimic actions on the network. In the ICSim directory there is a file known as controls.c which will pop open a panel and listen for specific keypresses which will mimic either turning left or right and other various signals such as locking doors.
  

• Icsim: Now before we can use the controls, we need to actually start by initating the simulation and virtual environment which in this case starts with icsim.c . When this is executed, the network is activiated and starts operating.

So, lets get to executing the simulation.

Reversing CAN — Reversing All Levels of ICSim

I should not have to explain this section deeply, but ICSim has multiple levels to it each one that adds complexity. Those are listed below. Keep in mind this is based on the source code of the simulator (controls.c).

• Level 0 (most basic level): At this level, no randomization is added to the packets which means that it is much more easier to spot even in a noisy network.
  

• Level 1(NULL Padding): This level will add NULL padding to the bytes which looks like 00.
  

• Level 2 (Randomized Unused Bytes): Adds much more complexity and will actually randomize the amount and add the amount of unused bytes.

Source Code Level Definitions | Default level is 1

Now, lets go ahead and take a look at each bit of software and how we can use it.

• Controls: Lukily for us, the control panel for the simulator has quite the amount of systems and amazing flags and options for us. This allows us to specify the interface to use, debug mode if we want it on, to disable background noise, specify the model of car (BMW is the only one supported), log the traffic to a log file, setting the difficulty value and even using specific seed values to help tune the simulation towards much more advanced or basic levels!

• Icsim: The ICSIM primary simulation starter has a bit more of smaller options. The simulator panel is just there to mock data on the network and wire so lets look at the options. The icsim allows us to specify the randomization of ID’s as well as a seed value similar to the controls and also allows us to specify a model name and if we want to debug it.

Now, lets get to reversing engineering the smallest level of the network and get used to everything.

Reversing CAN — ICSim | Figuring it out

When we execute both the panels and controls we go ahead and execute icsim vcan0 and also execute controls -l 0 vcan0 which allows everything to start working. Note that we will need to execute these in different terminals or tabs at least so we can run them properly and in sync. When executing, I particularly have my terminal setup like the image shown below.

I also have a terminal in the top left, but at the time the screenshot was taken it was not there due to it being shrunk. Now we can obviously see the controls and the simulator. The controls are bottom left and the simulator is top right. Now in order to work with this simulator and test to make sure its working, you should see the needle in the MPH gauge kinda “glitching” or going up and down which just indicates that it is at 0.

When we click and start messing around with the control panel we should start to see information change. Below I have listed controls for you to try out.

• Turning the left signal on: You can do this by pressing your left arrow key. When you release, it will turn off and stop sending traffic to that ID.
  

• Turning the right signal on: You can easily do this by pressing and holding the right arrow on your keyboard. Taking your finger off will turn the signal off.
  

• Accelerating: In order to get the needle on the speedometer to change and move, you can use the top arrow on your keyboard and hold it to continuously see the needle go up more and more.
  

• Unlocking Doors: This is quite an easy operation and does not require much knowledge. To do this, simply hold the shift followed by the letter of door you want to hit. For example, holding LShift + A will lock the front driver-side door (U.S). Below I have listed combinations for the control panel.

(Lshift + A) = Lock front left door
(Lshift + B) = Lock front right door
(Lshift + Y) = Lock back right door
(Lshift + X) = Lock back left door

Reversing CAN — ICSim | Reversing Level 0

Now that we have figured out how to use the simulator, let's actually get deeper and start listening on the network using cansniffer. So, we are going to be doing a few things. Below when running the command you will notice red filter. The command we are going to be running is cansniffer -c vcan0 . Its important to note that while candump and cansniffer are a bit more or similar tools they are a bit different. cansniffer is much more helpful for our case today.

Executing the program we will see something similar to what is in the following screenshot.

As you can already imagine, the ID is the arbitrary ID of where the data is coming from or being sniffed on. Note that for our current situation, these ID’s will not change. But right away, you may notice that some data is changing and others is just staying static. The reason we may notice data changing much more frequently is because we used a --color/-c option when running the command which tells cansniffer to color the output of changing bytes within the stream! This kind of ability allows us to split and figure out our target! Lets mess with the signals a bit, just constantly hold down left and watch the terminal as we are doing it.

When we start messing with the signals, we notice that an extra row of data was added that caused a shift ( downwards shift ) in the table. This causes us to continue holding down the signal button and see if we can find anything static. Notice that in the screenshot above every single row has some form of changing ID? When we release our finger from the signal or control, we may notice that we see a row all green with 00 00 00 as shown below above ID 18E

When we start turning the signal on, we notice that the first byte switches to a 1, when we flick the right signal, we notice that a 02 replaces the first byte position as 00 so we can map the following data out.

• Signal: The signal has four modes, left on, right on, off and ??. The off state has a byte array of 00 , the left on state has 01 and the right on state has 02 but what if the signal is 03 ? The only way we can test this is by sending the data over the wire and the bus. So lets go ahead and do that.

In order to test our hypothesis, we can use the cansend program to constantly send this to the network. The cansend program makes us specify the data we want to send in a specific format which means we have to specify the ID and the data we want to send to that ID followed by our Controller Area Network interface which in this case is VCAN0.

We can do this like so.

cansend vcan0 188#03000 

Picking this command apart, cansend calls the cansend program, vcan0 tells the program where to send it over the wire, 188 in 188#03000 specifies the ID to send it to and the other bytes 030000 which split by byte pairs looks like 30 00 00 specifies the data we want to send to that ID. When we do this we notice something interesting.

Notice how they both actually turn on? Pretty cool right!

Congratulations! You have just reverse engineered your first level of ICSim! But wait, how do we get this to continue to do it forever and permanately write the bites until we terminate the network? Simply just write a while loop.

while true; do cansend vcan0 188#030000; done

when we execute this command, on my end at least, the signals do not even blink because it is happening so fast! We will also notice that row 188 will stay at a static 03 00 00 and will not change!

We can also do the same for the doors, so lets do that! All we have to do now is take the logic and watching we did in the previous section to inspect how the car doors lock/unlock and what that looks like on the network finally applying it to the command and cansend program.

So for me, when unlocking the door I notice that a new row appears again. This is a side note for cansniffer. A cool thing about this program is the fact that if there is no outgoing or incoming traffic to that ID or part of the network, it wont be outputted or displayed on the network. This helps us greatly because we can see if setting a specific state of the simulator triggers a new row to appear.

Looking at the network we can then see the following data ( when the door is being unlocked ).

The new row that appears is 19B which holds the end state of 0E which indicates that the door is open. When we close it and lock the door, the state becomes 0F . So, lets see if we can unlock this working with cansend.

• Driver Side Door ( Front left ): The door as mentioned before is locked and holds the state of bytes 0f but when it is open it is 0E . So, when we run the command cansend vcan0 19B#00000F we should lock the door.

As expected, when running the command in a loop, the door has shut and has locked. You can easily spot the

row in the screenshot that is being edited.

Now, what about the speedometer? The speedometer might be a bit more of a challenge to find because of how fast it goes up and down, our goal here is to figure out the max reading of the speedometer in bytes and then send that to the network once we locate the ID where the data is stored and sent. So, we can apply the same logic we have for this entire section and as we mentioned before, we should easily be able to find it. Do not let your eyes deceive you, as our logic will tell us that the MPH reading will be a larger value and may take up more than one byte position.

This screenshot shows 7 rows all of which have a changing value in them. Based on what I told you, I assume

that the first row that catches your eye is 1AA since it is the first row that has two sets of bytes changing out of the constant singular set of bytes. This is not the one we are looking for, the row we want to look at is the one at the very bottom labeld ID:244 . When we inspect this row, we notice that this row existed in previous screenshots and had a static value with one changing set of bytes which was 00 00 00 01 <fluid> . The tag <fluid> at the end indicates that the set of bytes at that position are constantly changing and do not represent a specific value that we are looking to change. In this case, we can accelerate and see this value change.

When we want to change this value, we notice that the spedometer is going from 1–9 on the first half and then goes from 1A-1F since hexidecimal can only be represented in A-F and 1–9. When the speedometer reading reaches about 65MPH it will instantly make the next number 2A in hex.

So, if we want to constantly make the network read this, we can throw the following command into that loop we made which looks like the one below.

while true; do cansend vcan0 244#0000002A; done

You notice how the data we send it 00 00 00 2A and then we completely leave out the other gap? This is because when sending data on the network, we only need to padd the data we want to send to the very left and get to change the direct value at the specified byte position in the network in order to change the value of it. Unless these values on the left make our value on the far right change, then we wont need to fill the data in there. So in this case, the payload we want to send to ID 244 is 00 00 00 2A .

When we do this our speedometer will be stuck at 65 MPH.

Automotive Security — Reversing CAN | Breakpoint Section

Hey man- look, you have made it far enough. If you feel like it, feel tired, or its 3 AM and you are saying “I NEED TO FINISH THIS”, I suggest you take a break and chill out for a second. I have thrown a ton of information at you almost enough to fill multiple chapters of a book. So, lets go ahead and actually take a second to break off. I also want to note that the next level, level 1 I will not be explaining. This is because in the previous section, you have learned quite the basic fundamentals to get you through the second level of the simulation. I assure you man it is not really that hard, it seems like it, but its not.

Reversing CAN — ICSim | Reversing Level 2

Thats right buddy! Hahaha straight to the big leagues now! This section will be a bit more different. We will still use the same methods that we used before but will also be tackling a completely different model and level of simulation which may be considerably more advanced and confusing for you. So lets go ahead and restart our simulator and then run them with the specified options.

• Controls: We will be telling the controls to level it up to 2, use a seed from the ICSim and be reflecting the BMW model.

./controls -s 1691093355 -l=2 -m bmw vcan0

• ICSim: Similar to controls, we will be specifying a model and telling it to randomly generate a seed for us.

./icsim -r -m bmw vcan0

When we run this code everything starts up, but ICSIM will output a seed like the one we gave controls. So, I suggest you run ICSIM first before you run controls because you will need a seed for these levels or you can use the same one.

Looking at the data you may notice a few things

• Rapid: The data on this level is much more rapid and much more fluid than the levels before.

• Null Padding: The amount of bytes that have null values is pretty wild.

Now, the bigger question, what did changing the model do? When we chose to change the model from a default car to a BMW, we changed some systems. According to the source code shown below, we changed the way the speedometer works with its speed and data.

So, lets get into that and see if we can not easily reverse engineer the speedometer easily. Remember, we are in a much more faster/louder environment and may be working with different forms of fluid data. I mean it is all the same “form” but what I mean by that is the way its all changing. Anyway, moving from the technical aspect, regardless; we need to make sure that we keep our eyes on the data that might seem close to us. So if we inspect the rows in the screenshot below, you notive that all of them change, and if we mess with the spedometer, no row gets add, nothing is stayying the same for us to match it- so we need to actually work a bit differently. Instead of watching if something changes from a static 01 or 00 to a newer value or if a row gets added, we just have to closely analyze the row we suspect might be changing the most.

There is one thing interesting literally hiding in plain sight especially if you are running a live demo you should be able to see. Do you see it? There is a specific row that only has one uniquely placed changing ID. So let me guide you a bit.

• 1: Notice how each row ends in a changing byte which fluxiates its speed if we just sit idle. Well, okay- cool.
  

• 2: When you look at the rows that all have one singular changing byte, where is it located? At the very end.
  

• 3: Now pay attention to rows that have a changing byte somewhere other than the end of the row and actually look to see if they have an ending byte that changes. You will notice that every single one has a changing set of bytes placed either in the middle or the end or the start of the row. But here is where things get wacky. Every row that has a changing byte set ends in a changing byte set, but, the only row that doesnt is the ID 4ED

There is a changing byte set there, but it is only changing in the middle of 3 sets of bytes on the left and right side and the start of the left row with the end of the right row do not have a changing set of bytes. It is only the 4th position smack in the middle of the left and right side. This can be a target for us so lets go ahead and actually mess with the speedometer.

When accelerating and forcing the data to change we may notice that this data and row starts to change. If we pay attention to it closely, we can see the data change like so.

When inspecting the data on row 4ED you may have also noticed that the value on the right side of it starting with a D changes for every 10th increment. But wait, lets inspect this closer- every-time the needle on the speedometer reaches a new position on the speedometer, for example at each 20 and 40 the value will change- we have made a mistake during our research. But this is okay because the analysis still actually got us to understand that this value needed to change but was only read differently. So, lets go ahead and see if we can change this data a bit.

We know that every-time the network changes the value of the 5th set of bytes that it will increment by one every time a new 15 MPH increase is met. So we can go ahead and predict that setting that value to D3 will make the speedometer read 55 MPH.

Lets test this by throwing the cansend command into the loop. But wait, isn't that changing value going to be needed in order for this data to read properly on the network? No actually, we can pad this with a bunch of null bytes!

We can also force the speedometer past the allowed limit by adding Fto the value replacing 9. So, this looks like DF

Note: (this is like 6 + 9 because F is the 6th position in the support hexadecimal letters and 9 is the max. So add the maximum by the position of the second letter and vice versa then you have your values. So if we wanted our meter to read ≈225 || > ≈225, we would do 9 + 6 then multiply that by 15. This example has been shown below )

Congratulations! You have properly been able to break the speedometer on a car and broken past multiple nosier and extra layers of protection on the virtual simulator! Pretty cool huh?

Now, let us take the wheel for a second.

Reversing CAN — Building It Yourself

This section is if you are interested in general development and just building your own software. There are many people out there who have built their own tools for working with automotive networks such as DTC brute forcing systems, diagnostics reading systems, traffic manipulation systems and even something as much as MITM attacks and hardware for those attacks. This world is absolutely flooded with underground developers who work constantly to produce next level systems. But here is an issue, the issue with this is that despite there being people building OSINT systems, there is not NEARLY enough people working on Simulators for specific protocols and if they are they are certainly not doing well enough because they are heavily over charging. There are two companies that I can name that have made some good decent solutions for automotive simulation and all of them did quite well. So, what is my point here?

Well, as I indicated heavily, Craig used the X11 graphics system on Linux to create the GUI and used the open sourced header files and libraries for CAN development on Linux. Through this, he was able to build an entire set of controls and systems simply with the basic knowledge of how the library works, and you can too. I highly suggest that you take a look at the can-utils toolkit suite and the protocol’s library specification and build your own system. It is a goal of mine to use C++ as well as my own programming language to build an automated network and system all to help people understand how the network works inside of cars and even have idea’s to possibly use it in real world scenarios! Not to mention, it is super cool to be able to build your own systems and I highly recommend you do it just to see if your skills carry past what you think they may! Without much more to say lets go ahead and say goodbye friends!

Reversing CAN — Final Section | A goodbye…

This article has a conclusion and summary if you want to read go for it ( resources are also listed down below ). But I wanted to talk about something for quite a moment. I have been in the automotive security world for a while now, about half of my experience was primarily spent there because I always had an interest in automotive systems and how they worked and was obsessed with how horribly easy it can be to take them. However, recently I have been building much more of a connective road path here and in this roadpath discovered various groups of people as well as companies. But I will be saying something directly, recently I came across a group of people that were not focused on shoving money in their pockets with courses and over pricing content, not focusing on a million other fields and who were genuinely amazing people. That company and group of people are known widely as BlockHarbor. From the time I have spent in this world, and the time I have also spent working with smaller groups, I have not found a better team and group of people to just talk to as much as they were. Not only were they solely focused on a mission but they were there for the hell of it and have the experience. It has taken me, what, 100 different calls and 50 more conversations? just to simply find a group of people that actually knew what they are doing and knew what they wanted to do. So I would like to say that they are by far one of the most helpful groups out there, not to mention, they inspired me personally to write this article and even had resources from their website that helped me greatly during the time of this article because I was able to verify my knowledge that was given to me by other people in the field that I was also not to sure of. Turns out, most of those other people were wrong. Also, I would like to make a secondary statement and say that groups like this are the reason there are people that do know what they are doing because they are a good group of people willing to help out and willing to educate as much as they can and those groups- are the best to be around!

This article has a conclusion and summary if you want to read go for it ( resources are also listed down below ). But I wanted to talk about something for quite a moment. I have been in the automotive security world for a while now, about half of my experience was primarily spent there because I always had an interest in automotive systems and how they worked and was obsessed with how horribly easy it can be to take them. However, recently I have been building much more of a connective road path here and in this road path discovered various groups of people as well as companies. But I will be saying something directly, recently I came across a group of people that were not focused on shoving money in their pockets with courses and over pricing content, not focusing on a million other fields and who were genuinely amazing people. That company and group of people are known widely as BlockHarbor. From the time I have spent in this world, and the time I have also spent working with smaller groups, I have not found a better team and group of people to just talk to as much as they were. Not only were they solely focused on a mission but they were there for the hell of it and have the experience. It has taken me, what, 100 different calls and 50 more conversations? just to simply find a group of people that actually knew what they are doing and knew what they wanted to do. So I would like to say that they are by far one of the most helpful groups out there, not to mention, they inspired me personally to write this article and even had resources from their website that helped me greatly during the time of this article because I was able to verify my knowledge that was given to me by other people in the field that I was also not to sure of. Turns out, most of those other people were wrong. Also, I would like to make a secondary statement and say that groups like this are the reason there are people that do know what they are doing because they are a good group of people willing to help out and willing to educate as much as they can and those groups- are the best to be around!

Reversing CAN — Conclusion And Summary

Wow hahahah! What a hefty article ( again I know I know ), I am quite sorry to give you so much to read O_O! Anyway, summing up this article: automotive security is a forever growing field and honestly I hate to say it but there is not many people that actually know what they are doing here nor is there near as enough education. For example, spotted a class that was on automotive security but more or less about CSMS (Cyber Security Management Systems), SUMS (Software Update Management System) and other systems and even standards like ISO/SAE 21434 for well over a grand- I think my jaw dropped when I saw that price. I do not directly understand it and my brain instantly goes to “scam”, because I do not need to even read or watch 13 hours of content to understand especially with my experience that charging THAT much to talk about a bunch of standards is just scammy! Anyway, besides the point, excuse my complaining. Automotive security is an important field, the more technology increases and becomes more mass produced, the less taken into consideration of cyber security even comes to a thought. Now without a doubt, there are standards, systems, protection mechanisms, but there is not nearly enough funding for the actual security research side of things. Its important to stay on top of our toes with this because this is literally human life and is nothing more than that! Its a race to who can exploit the death machine first, researchers or terrorists? Lets- beat the terrorists to it. In other words, we talked a ton about the automotive world, was able to explain how automobiles network, why they need it, specific protocols such as FlexRay, MOST, LIN, CAN, and other protocols. We also threw in some advice on how to get started reverse engineering the protocols and even getting into more stages after this! I know this article is long, it can count as a few chapters of a book, but, I did this because of my extreme side and competitive machine in me. The one that looks at a course that is charging over a few grand for stuff you can google and just says “I will do better, I will compete, I will win, and I wont stop until I do”. Because that kind of competition gives me a reason to spread the knowledge I have obtained!

Anyway, below is an ending note thanking you for making it this far! So I do appreciate it and if you would love to support me, please throw this around!

Ending Note — Extra’s, Resources, Support, Thanks

Typically I never do like promoting stuff but I figured it was worth a shot. This section will provide you with basic information about me, some socials you can follow me on, how you can support me and some resources that were used to build this article / module. Apparently my articles are so long people are calling them “modules” so I will go with that for now hahaha! Below are some bullet points that showcase extra sections.

• 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:

Pay $TotallyNotAHaxxer on Cash App Instantly exchange money for free on Cash Appcash.app

• 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

https://www.instagram.com/Totally_Not_A_Haxxer

• 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:

Blogger Weblog publishing tool from Google, for sharing text, photos and video.www.blogger.com

• Hakin9 Articles / Research point

https://hakin9.org/external-understanding-dissecting-apis-inside-of-iot-devices-part-1/

• 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=J3PJZJ

• qkL-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 cybersecurity

• 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