Automotive Security — Going Over FlexRay | Introduction
As the automotive world continues to grow with the technological world, protocols used inside cars will also become more sophisticated. Because of this, we must keep our heads on a swivel for the newest and hottest thing in our industries, especially as security researchers! In today’s article, despite it not being the “hottest” protocol right now, we will be talking a bit about the FlexRay automotive protocol which is commonly used in multiple vehicles such as the Audi A5, BMW 7 Series (F01/F02), BMW 5 Series (F10/F11) and other various cards. This protocol is known as the luxury protocol, could you imagine why? Well, again; despite it not being the newest or most used protocol ( which we will get into why later ), it is a good protocol to learn about given most of the higher target cars or your more expensive cars use them. This article is going to be a bit lengthy, so I feel that it would be good to knock it out into sections.
Going Over FlexRay — Section For Newcomers! → This is a section that will be for newcomers, explain a bit more about the world of modern-day cars and how they work, address some security concerns, and also get beginners in this field a good starting point. Note that if you have not been watching this series or reading this series, you can skip this section as this section primarily emphasizes automobiles in today’s world and how they work on a more technical level.
Going Over FlexRay — Automotive Protocol Introduction → A section that talks about why cars use protocols, the hottest protocol at the time of writing, the most complex protocol / advanced protocol, and the most commonly used protocol in automotive systems at the time of writing.
Going Over FlexRay — The FlexRay Protocol → A section that talks about the protocol and some exciting idea’s about the protocol and why it exists. This section will be cut up into multiple sub-sections all talking about the protocol and its more technical systems. This section also talks about common issues with FlexRay and why most cars do not use them as a common base. We even get to talk about the key benefits of the FlexRay protocol!
Going Over FlexRay — The Soon To Be King → A section that talks about automotive ethernet, a rising and currently popular automotive protocol, and also talks about the advantages it has over FlexRay.
Going Over FlexRay — Let's Geek Out → A section that ends this article with talking about FlexRay’s packet layout and its base communications on a more technical level. We will also discuss accessing a FlexRay bus with physical utilities and explain why it may be harder to access than ports like the OBD ports used for CAN.
Going Over FlexRay — FlexRay As A Hacker → A section that will talk about a small case study done with FlexRay and what this protocol serves for automotive security researchers.
Going Over FlexRay — Ending Note: This section will talk about the end of this article, it will also summarize everything we learned today. This section also aims to talk to you about who I am and what I do for a living as well as where my knowledge comes from!
Note: This article is not like the CAN article- this is because of one primary reason which is the factor that I do not have access to a car that supports or uses the FlexRay protocol. This also breaks up into two reasons- I do not have the money nor am I of legal age to just walk out and purchase a car LOL! So bare with me on this article, not to mention I did this on little to no resources as to how the FlexRay protocol technically operates and did my best from the people and again limited resources I had.
Before we jump right into the article, I would like to knock down some basic terminology for you and hope that you can actually get some form of understanding as to where this article goes with specific terms.
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 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 its internal functionality of it to modify or view and even understand the internals of said system to put it lightly.
FIBEX → XML format describes the FlexRay, CAN, LIN, and MOST network setups. This topology map records the ECUs and how they are connected via channels. They can also implement gateways to determine the routine behavior between communication buses.
$System-By-Wire → By-Wire in the automotive realm typically describes advanced or unique electronic control systems or modules that can replace traditional mechanical linkages with electronic components. In other words, this is referred to as `X-by-wire` technology.
Steer-by-Wire (SbW) → Steer-by-Wire typically refers to a system, where the mechanical connection between the steering wheel(s) is replaced by electronic signals. For instance: IN a traditional vehicle, when you turn the steering wheel, it is directly connected to the wheels via a physical linkage (steering columns, gears, etc). However, in a steer-by-wire (SbW) system, the steering inputs from the driver are transmitted digitally to actuators that control the vehicle's steering mechanism.
Break-by-Wire (BbW) → Similar to the Steer-By-Wire, breaking is also now a wired base and is not nearly as mechanical as it was before. For instance: in traditional braking systems, when a break is applied the amount of pressure is then translated to how “hard” the brake pad squeezes onto the wheel ( in a basic example ). In a brake-by-wire system, sensors detect the force applied to the brake pedal, and electronic control units send commands to actuators that adjust the braking force at each wheel.
Drive-by-Wire (DbW) → Drive-by-wire is a system that replaces the conventional mechanical linkages between the accelerator pedal and the engine’s throttle with electronic controls. In traditional vehicles, pressing the accelerator pedal directly opens the throttle and controls the engine’s power output. In a drive-by-wire system, sensors detect the position and pressure of the accelerator pedal, and electronic control units manage the engine’s power delivery accordingly. Drive-by-wire systems are often used in conjunction with electronic throttle control (ETC) to improve fuel efficiency, and response time, and integrate with other vehicle control systems.
Twisted Pair BUS → This is a bit of a different road but it will help you in our module here. A twisted pair bus refers to a type of communication network or data transmission system that uses twisted pair cables to transmit signals. This type of cable is a common type used within networking and telecommunications because of multiple reasons such as Reduced ENU, cross-talk mitigation, signal quality, and more, all of which we will go over later.
TDMA → Also known as Time Division Multiple Access is a communication protocol used within the FlexRay protocol. This is actually one of the key principles within FlexRay which makes it quite interesting and unique! In the most basic explanation In a TDMA-based communication system like FlexRay, the available communication time is divided into fixed time slots, and each slot is allocated to a specific node or device for communication
Macrotick → This unit of measurement is typically one millisecond long and is used for perfect synchronization. So, six macro ticks are 6 milliseconds!
GSM → Also known as Global System for Mobile Communications, is a standard for digital cellular communication used for transmitting mobile voice and data services. It is one of the most widely used and influential mobile communication technologies in the world! This unique system allows for improved security among communications, more fluid compatibility, and the fact that it has quite the international standardization!
Communication Cycle → When it comes to automotive protocols or really just networking protocols, there is a communication cycle which is a sequence of events that occur in the communications system when the data or information is transmitted! It pretty much outlines and stages the process involved in successful communications Typically, when it comes to communication cycles, this outline can change depending on the type of technology. So anytime we use the communication cycle, this will be the definition. However, the word FlexRay Cycle will refer to the communication cycle within the FlexRay protocol.
Going Over FlexRay — Section For Newcomers
So, you are new here huh? First I must say that I hope that you are going to be diving in a bit more on this series because personally, I like to think that it was one of my best and most unique series on this page! So, I would like to welcome you into the series with a nice big warm hug and a shove into the world of automotive security! I started this series primarily because I wanted to make sure that everyone got some base knowledge of modern-day automotive systems and did not just up splurging or slap down $1,000 or even $300 for a small automotive course that teaches absolutely nothing that's worth that price! So, anyway, let's get into it. The world of technology has been growing constantly and exponentially rising since the mid-’90s and actually 80s! No matter if it was some weird and wacky toy that used a new system or an entire gaming console and entertainment system! With this growth, came the growth of modern-day hackers and systems which ended up becoming used in about every bit of our world. You might be asking by now, what tech am I talking about? I am pretty much trying to aim at every bit of the tech world and where it has gone within the last few decades, and trying to bring up the factor that no matter what you drive or what you are doing, everything is going to be connected; from street lamps to cars and single camera’s.
The way these systems work is by using a series of communication protocols, sensors, and more to help them communicate and exchange information with each other. Because of the communication of devices, protocols, and more, this allows devices to become much more powerful, fast, and unique which also helps cut down many safety factors that are involved. Now when it comes to today’s world, cars are literally the same thing, all of them are connected via communication protocols! Yes, even your 2003 Ford uses some form of communication protocol. However, with the advancements in technology come the advancements of the adversaries. Yes, hackers can hack cars, which is why this series is titled Automotive Security. Why does automotive security exist? The primary reason it exists is honestly due to the factor of more want than need in the automotive world. From my personal point of view [bias], everyone seems to WANT these new fancy systems and the developers WANT more money but the people NEED more secure systems and the developers NEED to be more secure during their developments. So, because of this weird weight and wacky light-weight in standards, we need to hire some form of a security research team that can go out there and try their best to hack automobiles and show people truly how deadly it can be in the hands of a terrorist. I know this section was all over the place, but that being said and concluding this section: automobiles even as far back as the early 2000s have been easy to hack and it's only getting easier. Because of this, automotive security research is vital to ensure that drivers and passengers remain safe! [ that sounded like an ad lol ].
Note: The section below is a section that will talk about automotive networking, you may see some data that has been pasted or taken from other articles IF you are following along. The data and information posted have been taken from articles directly in this series and belong to the author of the series (Totally_Not_A_Haxxer). If you are not new to this series, with all respect, you are allowed to skip this section and should not suffer any knowledge lacking. If you do, I definitely suggest going back to it.
Going Over FlexRay — Automotive Networking Introduction
Right, so, automotive networking is something I would like to go over before we just jump into everything. I know that if you are following this series, as noted above, it's not something you need but I will re-cap it to catch everyone up to speed. Let's go ahead and get into this section without anything else to say! below I have actually cut this primary section into sub-sections all of which have their own unique purpose and description.
Automotive Networking | What Is It and Why? A section that talks about what automotive networking means, why automobiles need networking, and some extra information. We will also talk about how it works here a slight bit!
Automotive Networking | Ethics & Protocols → A section that talks more about the ethical side of protocols and what protocols are out there. We will talk about CAN, CAN-FD, LIN, MOST, FlexRay, and AE (Automotive Ethernet).
Automotive Networking | Conclusion → Concludes the set of sections that we have worked on today!
This is just a warning to every reader — occasionally you will see some form of author note which will be dropped with a GIF and either give you some extra information or tell you to stop doing what you are doing and to actually hydrate for a second and step away from the article. This is because as much as I hate for me to admit it, this article will be long and will be one of the more annoying articles to get through — I mean, c'mon, its protocols- nothing too unique. Also, not to mention, FlexRay is not like CAN, it's very much more complicated and may take a second to understand. So, that being said, those authors' notes are there to tell you when to just take a second and come back later. They may also be dressed with cat memes like the one below.
Cat meme #1 for the article
Automotive Networking | What Is It and Why?
While it might seem like everyone’s got a grasp on this topic, I’ve often noticed a bit of a knowledge gap in this area. I mean, let’s be real, automotive networking is exactly what it sounds like — networking for cars, no more, no less. But the thing is, there’s often a missing piece in the puzzle when it comes to understanding the “why” behind cars needing this and why they use different protocols. So, the deal with this section is to help you wrap your head around some nitty-gritty details of automotive networking, what it really means, and why cars roll down this path. Alright, no more beating around the bush — (ugh, I’m really dragging my feet on this article right now), let’s dive in. You’ve probably heard that cars in the 90s weren’t exactly packed with systems, or so the story goes. Well, let me tell you, that’s not entirely accurate! Hold up, I’m not calling you out for believing that — because honestly, the number of systems back then wasn’t exactly staggering. But here’s the kicker: someone might’ve stretched the truth a tad if they told you that these systems (depending on the car) weren’t at least partially connected through some digital networking wizardry. The seeds of automotive networking were sown around the 1980s with the birth of a protocol called CAN (Controller Area Network). This little protocol lit a fire under the development of other automotive networks and systems, but whoa, slow down there! We’re jumping ahead way too fast.
So, what is this CAN thing? Well, let’s circle back to those systems chilling in cars and zoom in a bit. In today’s automobile landscape, practically every car comes with some sort of diagnostics system (just an example), but have you ever wondered how these diagnostics are even fetched? Now, the average Joe might think there’s this sensor hanging out in the car, quietly soaking up data and shooting it back to base. Sounds reasonable, right? But hold up, here’s the million-dollar question: how’s it shooting that data back? I mean, in the good ol’ pre-automotive-network days, cars used these modules, systems, and fancy meters all stitched together with a mess of wires and gobs of copper to sling data back to the readers (or for gas, just a direct connection — keepin’ it brief). But over time, that whole setup started feeling like lugging around a sack of bricks and costing companies an arm and a leg. So, car makers had to put on their thinking caps and figure out a slicker way to still grab diagnostics, log ’em, and then whisk ’em away to the diagnostics system without burning a hole in their wallets. And voila! Automotive networks swooped in to save the day — that’s how they shunt data over to your diagnostics playground.
Now, every car has this fancy thing called an ECU (Electrical Control Unit) which has its own gig in the grand scheme of things. This ECU is how data is actually recorded and how data is sent between a specific module. Back then, your steel toaster on wheels used to be connected perfectly with each module using wiring techniques- I mean, literally- every single module or unit for every single unique system in a car such as an engine and transmission was all hard-wired together! Aint’ that insane? As mentioned before, the issue with this was the reproduction of materials and how much it took to produce in wiring and copper especially to produce those unique little modules and then tie them together. This was actually commonly known as a point-to-point connection. Automotive networking changes this with the invention of protocols because modules could communicate with each other all through one access point. What do I mean by this? Well, in more technical terms, communication protocols enable these fancy modules to share a common communication bus, meaning they can exchange information with each other through a single access point! So, that being said; automotive networks work ( lol- networks work ) by using communication protocols also known as buses to communicate with the modules in the automobile which can send the data back and forth. Your biggest question right now is probably — Why? I always get asked why do cars even use protocols other than the fact that it got too expensive. Well, let's inspect this a bit deeper. Below are two images of a vehicle from the mid-2000s and a vehicle from 2022.
Image of a car from the early 2000’s (2002)
And the next image shows a more modern vehicle (Audi A5 2022)
Instrument Cluster from an Audi A5 2022
Did you catch the drift? Let’s zone in on the 2002 Porsche first. It’s not exactly a mind-blowing instrument cluster, mainly showing essentials like fuel levels, mileage, RPM, and which way you’re signaling. Sure thing, this is a piece of cake — no doubt about it, cars were still using networks to sling this data around. But, let’s zoom in on the snap of the car from the 2000s up there. You’re now in for a ride haha — not only is the tech looking totally different, but there’s a whole digital panel in the mix now. This thing has to juggle tons of info: actual speed, time, date, sound settings, screen info, even where you’re at on the map, the gear your ride is locked into, and a bunch more interesting sets of data. And hold up, did you peep the steering wheel? It’s rocking extra buttons that are almost cut off, but you can spot a play button and a phone button, right? These setups are just bleeding uniqueness and are a real headache to pull off. Can you even picture all of these systems and unique controls connected through the same bulky wiring? I bet you’re thinking that over time, things would start dragging their feet, huh? That’s why automotive networking rides to the rescue. Not only does it lighten the load during production, but it also turbocharges system performance, especially in cars!
Let’s zero in on the Audi A5 for a second which is funny because Audi uses the protocol we are talking about today. That beast is loaded with hundreds of systems, and a good half of ’em are all about safety — think airbags, seatbelt sensors, lane-keeping magic, plus other fancy packages they’re slapping onto their rides for that extra oomph. Now, imagine if all cars were still clinging to the same old systems. We’d be stuck trying to weave this colossal tangle of wires together, and the end result? Sluggish responses and a fat chance of those systems deploying as they should! Not to mention, imagine crashing with one of these geeked-out machines because some company that used a network system stuck in the 90’s with an overly insane amount of wiring just decided “Nah bro I do not want to work today- sucks to be you” haha! So next time you get in your car, and turn the ignition on- just sit and think for a second of all the insane amount of systems that are working in your car just to simply turn on the car- this includes verifying information, checking essentials like the network stability, checking for unique network codes, checking and pulling diagnostics and more! Then think about how all of that happens in literally nanoseconds!
Automotive Networking | Ethics & Protocols
Okay, now we get into the deeper side of things which is where the networks or rather how the networks can properly communicate — protocols. With this section, we will also go over a bit of an ethical side, something that I have sadly heard before going through people’s minds. But I will get to that at the end. For now, let's go over protocols! How do these work and what exactly are they? So, long story short, a protocol is just the way data is formed and sent over a communications system. For example, the popular TCP protocol stands for Transport Control Protocol which is a transport protocol that uses very specific rules to send and compact data over the network. Automobiles as mentioned in the previous section also have this! Let's go over some basic protocols.
CAN: The first communication bus or protocol to talk about is CAN. CAN also known as Controller Area Network is one of the most frequently used and talked about protocols and almost everyone knows about it. But what makes this protocol so nice and popular? For starters, this protocol was one of the very first protocols for the automotive world and not only was cheap but extremely performant! This protocol did many things because its general base implementation is not that complex, one of those things was saving space and money for developing or pumping out cars! This was at a time when cars were still made very durable, where cars were extremely well built and designed and are sadly not found today — that is right, I am talking about the 80s! Specifically, CAN was developed in 1986 by a German multinational engineering and technology company named Robert Bosch GmbH. This protocol was again made quite cheap, and improved the automotive world not just for the drivers and users of the cars but also the manufacturers who needed a unique way to produce vehicles without the insane cost of copper wiring for vehicles! This protocol is just cheap but also really easy to work with and much more performant, plus it was the earliest protocol that was fully adopted by automotive manufacturers! This is also the protocol that again we will be focusing on primarily that has so many different unique sides to it!
FlexRay: The second most used and popular protocol is a protocol type of luxury car pretty much and is obviously the topic of this article today. This protocol is commonly used with cars that are along brands like Audi, Mercedes, Lamborghini, Bently, and other various vehicles. Woah- slow the role, why is it only used in more luxurious cars? I have adopted the term “luxury” protocol because it is the one protocol that not many car companies use which is primarily due to how costly it is to implement. See, FlexRay is a protocol like no other! This of course comes with a downside — adaptability. The FlexRay protocol is not only much more structured but also much safer, performant, advanced, time unique, and more! What does all of this mean? This protocol is unique in its own way and one of those ways is its time uniqueness and performance as it perfectly times every single instruction and discards it if it is not on time whilst also using specific systems to make the network go much faster! The issue with this is again, complexity. Complexity especially in today’s world is just- through the roof, so, automotive manufacturers do not really want to add MORE complexity onto a vehicle where it becomes the MOST ( pun intended ) complex and expensive car to produce, especially if they want to make money from the vehicle they are selling and seriously throw themselves out there. But you might be asking, why would some automotive manufacturers such as Audi and Mercedes even use this protocol if their cars especially newer ones are already complex enough? This is a good question that has a ton of bias and is never truly answered (it's a huge debate ), but the general idea is surrounded by how much funding the company is willing to put into vehicle development as well as how much their cars usually run for and if its a company like Audi — then simply because they were the ones that made it. Here is a historical background for you, FlexRay was not developed by one man, class, group, or company — it was a join protection between multiple automotive manufacturers in the early 2000’s such as Mercedes, GM ( General Motors ), Audi, BMW, Volkswagen, and Daimler as well as two other primary companies. This joint project was not only heavily researched but had the end goal of creating something much more sophisticated, proprietary, secure, fast, technical, and every other word culture could possibly imagine at the time for the word “advanced”. This is why the protocol is not used in many cars because too many advances and too much complexity can be a pain for a company to implement if they were not exactly the ones that decided to invent the protocol — but other vehicles also use it such as Bently and Lamborghini, especially in the Huracán. Concluding this protocol, FlexRay is much more complex, expensive, and harder to manipulate but is very much worth the safety and unique systems that FlexRay has in place.
LIN: LIN also known as Local Interconnected Network is a different type of protocol. If you are familiar with networking, this name may get you quite well and easily. As the name implies, like all other protocols in this list, LIN is a local and much more inexpensive automotive protocol that is much more easier to implement. This — this protocol is the reason I went over CAN and FlexRay hoping from cheap to expensive, simply to make this point. The LIN protocol is a much cheaper option than CAN, but you may be thinking — why to use LIN a much cheaper protocol with most likely less safety and systems than something like CAN? Because implementing CAN on every single automotive operation would just make the protocol overly expensive and would not be worth the time, this is where LIN and hybrid automobiles ( not in the EV sense, I mean in the general network world, hybrid, meaning it works with both protocols or systems rather than one; in this article anyway. ) come into play. LIN is a protocol that was designed purely for secondary implementation, something that can be used to lighten the load on automotive manufacturers because of how expensive cheaper protocols such as CAN are to implement on every single operation and system. There is not much to go into about this protocol, but the primary idea is that it is a unique, smaller more lightweight, and cheaper option for tasks that do not necessarily require top-notch speed and synchronization and do not need any heavy loading or transferring. This makes LIN a fantastic alternative to CAN in very specific scenarios.
MOST: The MOST protocol also known as the Media Oriented Systems Transport protocol is a type of network protocol that is also in count with luxury protocols but is typically used for infotainment consoles. I do sometimes count this in the realm of luxury protocols even though its a very very very VERY low branch of it. This is because the protocol's implementation typically depends on the system's complexity and what you are using it for and how much you are actually going to use it. The reason MOST is good for infotainment consoles is that it does really well with having a high and versatile data transfer all of which makes it really good for audio and video streaming especially if it's from device to device! This protocol is also unique and is typically not used for primary network holds or actions but has been before ( sadly as its name is literally for media-based systems) regardless, it is a quite well-used protocol in the automotive world and helps quite well!
CAN-FD: CAN-FD (Taken from the Automotive Security: The CAN Protocol article), which stands for Controller Area Network Flexible Data-Rate is a much more advanced or enhanced version of CAN, if you guessed that you are actually correct — so pat yourself on the back! While CAN is still used today, some people who may work with different types of transportation and even automotive vehicles may work with CAN-FD in some shape or form which is primarily due to the modernization of technological systems within vehicles that need a much more unique protocol. So basically, we can say that the primary reason CAN-FD was built was to address the increasing data communication requirements of modern vehicles. As we discussed, CAN, also referred to as Classical CAN had a ton of limitations in terms of its data rate and payload sizes. The issue with that is when newer systems come in place and require not only much more data at faster speeds but also require bigger sets of data, CAN is going to have to fragment the data ( as we discussed ). This can lead to many issues down the road and overall is just a bit of a pain. So, how does CAN-FD solve this? Well, generally speaking: CAN-FD allows for much higher data rates, larger data payloads, and different systems that can all make it much more suitable for those newer applications that require some form of communication! Below I have listed a few primary points within CAN-FD and why it may be more used. Note that the first two points are going to go over what we already talked about but better define what we mean by this.
Larger/Increased Data Rates: CAN_FD typically operates with data rates of up to approximately 5 Mbps and can even go higher compared to the standard or classical CAN which operates at 33.3 Kbit(s) which is a much faster rate than standard CAN. Because of this, CAN-FD can be used for much more modern-day systems since due to the higher data rates it can enable much faster data communication and transmission of larger not only smaller amounts of data. As you can also imagine, this can be helpful when we need to work with more sophisticated and complex systems!
Larger Data Payloads: Larger data payloads are a big one. The more systems become more advanced the more data is going to need to be fed to them in order for the system to work the way it needs to, this also means sending the data all at once or in specific parts. Classical CAN has a maximum payload size of 8 bytes, CAN you ( pun intended LOL ) imagine how small that is for systems that may require much more unique information or messages that are larger? CAN-FD fixed this by improving the data payloads by allowing it to support entire payloads that are 64 bytes long! That is quite the size haha! Because of this larger payload size, not only is message fragmentation reduced by ALOT but the general and overall performance and communication efficiency is also massively improved! In turn, this means systems can be much more accurate and well-understood!
Better Error Detection & Handling: Error detection is one of the most important systems in any form of protocol, application, receiver or just computer known to man. Without proper error handling something could fault and go totally wrong with the transmission and kill that data ( in a more general sense of course ). So, CAN-FD fixes this by creating a more robust error detection system and mechanism that uses CRCs ( Cyclic Redundancy Checks ) and ACK ( Acknowledgement ) to ensure the data’s integrity during transmission. These mechanisms have been bound to contribute to the reliability and overall accuracy of communication!
Flexible Bit Timing: I do not think we can go super deep into this because it- 's so long and goes into so many depths but I will break it down for you. CAN and other protocols use a system known as bit-timing which is a timing system that governs the transmission and reception of individual bits within a data frame within specifically timed parameters. As we have talked about before within this module, protocols act on the factor that data is transmitted in the form of individual bits, which are binary units that represent either a high or low voltage level on the wire. The timing of these bits is important for proper communication between the sender and receiver. Each of these timing sets has its own parameters which include the Bit Rate, Bit Time, Synchronization segments, Phasing segments, and other various segments that all make up these parameters. Now, you may be asking, how exactly did CAN-FD address the problems in classical CANs bit timing systems? Let alone, what even were the primary issues? The primary issue with classical CAN was that it has a fixed and deterministic bit timing configuration, which might not be suitable for all network conditions, cable lengths, and physical layer characteristics. All of these characteristics all makeup what bit timing is and can become a problem within the system later down the line. CAN-FD fixed this by making this type of system much more flexible in terms of the bit-timing parameters. This allowed for a much better and unique adaptation to different network conditions and environments such as the cable lengths and physical layer characteristics that we mentioned above. This can also improve the overall performance and reliability of the protocol. CAN-FD is primarily used also because of this point here and due to its application in today’s world!
Backward Compatibility: One thing we forgot to mention deeply was the compatibility with CAN. You may notice or hear that some automobiles may use different implementations of CAN and protocols, but if there is different types of CAN, might that cause compatibility issues in the future? You would think, right? But protocols like CAN-FD actually have an amazing system and were designed with partial backward compatibility in mind. This means that CAN-FD nodes can co-exist on the same network as other CAN nodes. However, there is a ‘but’ here. The issue with this type of system is not more about its support but more about the factor that compatibility requires negotiation between the CAN-FD and classical CAN nodes in terms of the data rate that can be used for the communication between the nodes and modules. This is not too much of a problem but in the end, the primary point is just to say that CAN-FD makes some attempt at working with CAN properly to make sure that it does not make developers require an immediate replacement for all nodes. This is super helpful also in the factor that some systems may require some features that CAN-FD has with the wired support of CAN; in smaller terms anyway.
D/S Channel Config ( Dual and Single ): This is another confusing one that we may need to break down a bit. The first thing right off the bat is the single-channel configuration. Traditional CAN operates in a form of communication configuration known as a single channel. In a basic summary, these types of configurations are for the physical communication medium used to transmit and receive data between nodes on the network! The single channel configuration as the name implies is where only one communication channel is used for transmitting and receiving data which is actually quite cost-effective because it requires less material to reproduce and is much simpler to manage. Dual-Channel configuration on the other hand is where those two physical communication channels operate in parallel which can provide redundancy and fault tolerance on the network, a major benefit to using dual-channel configuration. Classical CAN as I noted before could only operate in single-channel communication, however, CAN-FD improves this by being able to support both dual and single-channel communication configurations! It is worth noting that CAN FD networks provide the same benefits of redundancy and fault tolerance as in traditional CAN networks, but with the extra added advantage of higher data rates and larger payload sizes.
Newer More Enhanced Frame Types: So this is a given with this section and as the name Flexible Data-Rate in CAN-FD implies but CAN-FD introduces a whole new frame type which includes the Classical and FD frames. For context, classical frames are similar to the standard CAN frames while the FD frames take advantage of the higher data rate and larger payload size that CAN_FD implements. Choosing between these frames and their types will add some complexity since you may need to go based on communication types and pinpoint what needs more flexibility but that is a good example!
Improved Efficiency: The last point on this list that about sums up everything here is how much more efficient CAN-FD is compared to classical CAN. Because of the higher data rates, improved error handling, and larger payloads within the protocol, CAN-FD highly increases its communication efficiency.
AE: Also known as Automotive Ethernet, is an ethernet-based protocol that is literally designed to meet direct automotive standards. This is literally just ethernet for your toaster on wheels if you can think of it that way. The reason automobiles have started to switch over to this is for the factor that basically, cars will not need any specialized systems or even need to work with other communication buses once the standard is mastered. This is because automotive ethernet has the same exact protocol support that the standard ethernet protocol supports which is protocols such as TCP and UDP. There is a few issues here and while it is cheap- those issues are going to be the downfall. I am not sure if I have yet in this series, but I did some security research on IoT devices and the primary issue was how easily discoverable other devices were on the network and how insanely easy their endpoints were to find due to unencrypted data and plain-text information being sent over the network. At the most recent DefCon event (DC31) which I sadly did not attend, I had seen on other people's Instagram stories that the automotive hacking village or car hacking village was showing Tesla testing ( as they have been for the last few days ) and just within a few frames I could see the insane amount of unencrypted network traffic that was going on within the network just hundreds of packets being labeled as ‘HTTP’ and highlighted green. This of course is quite the issue, but regardless the protocol is a bit more cheaper, it's fast and reliable, and also adds much more support for unique systems. I will be getting into these protocols a bit more in the future but this is an example as to where it can go.
Despite these protocols being used completely differently, they all have one thing in common — automobiles rely on them to properly create new functions and operate within a specific environment. These protocols are the powerhouse to modern-day automobiles and even help us implement and study newer ideas and systems that may be put in place! Now, the ethics issue I wanted to bring up. So, cool, we have all these unique protocols that can be used but there are some questions that arise both of which I will talk about one of them as pointed out below.
If protocols like FlexRay are more expensive yet are much safer and more reliable and could be the reason for a saved life in the end — why do companies still choose cheaper protocols like CAN? This question has been asked too many questions during the presentation, and my honest answer is deep in itself — so give me one moment to sum it up a bit. The first part of the answer is the factor that not every car can be 80K and people need something that is reliable and gets them from point A to point B, so despite it being slightly unsafe it just works for the client on the end because it means the car may sure have less features but will also be cheaper for them to purchase. The other one is just how much profit the company will make. Sure, the protocol will not up the car by a few grand but it will take a ton of effort and resources to implement that system due to the unique timing and design that it takes to also make it secure, not to mention the developer shops are not accessible by everyone and not every shop can even get access to specific readers for specific vehicles. That being said, this is where the logic starts to come into play — is it really an issue given companies have billions of dollars to just waste on whatever they want? I mean yeah there are still factors that come into play, but generally speaking, it could also be the need to hire engineers for that specific protocol or system!
I would like to mention that I apologize if it feels like I am rushing this, its simply because I feel that I have gone over automotive networking more times than I actually need to and might even be putting a new article that talks about it with this series since I feel like rushing it is just not what is needed hahaha.
Automotive Networking | Conclusion
To conclude this section, modern vehicles all are powered by some form of network no matter if it's the FlexRay protocol all the way down to LIN and AE — they all also have a purpose, similar to other programming languages, and why so many of them exist. Regardless, they also all have their own security and ethics-related issues that may prevent or make an automotive manufacturer choose said protocol to use it within their systems. This is just a general statement but should also give you an idea of why so many protocols also exist. It's important to understand as well that some people simply do not enjoy it, some people refuse to understand it and some people will meet this world with some form of anger! But, those people should also at least understand why those protocols exist which is the point of this conclusion- they exist not only to help out the driver but also to make it much easier to produce and manufacture!
Alright, I am done boring you — let's actually talk about the star of today’s article!
Going Over FlexRay — The FlexRay Protocol
This section is going to go quite deep into the protocol itself, due to the protocol's complexity- it would be quite hard for me to break everything down. Now you also will notice a change in the way I break things down, I do this not just to add fluidity to the article but also to ensure that readers can get a much more straightforward understanding of the topics instead of having to write in ELI5 (Explain Like Im 5) format LOL! Do expect some puns, some jokes, and unique sections though hahaha (as this article is already reached 30 minutes…kill me O_O). So, since this section is a bit bigger, I would like to separate this into sub-sections and get down to explaining it a bit more! So below shows those sections and their names followed by a description of what the section entails!
The FlexRay Protocol | What Is It? → As you can imagine, this section will go over what exactly the protocol is, why it exists, who created it, and some basics of the protocol itself.
The FlexRay Protocol | The profesh and the conesh → A section that talks about the pros and cons of the protocol
The FlexRay Protocol | Concluding → Finalizing this primary section
The FlexRay Protocol | What Is It?
The presentation slide above should give you some basic information, but I still think it's appropriate to at least go through the slide. Right, so as we have already discussed, the FlexRay protocol is a protocol that was designed as a joint project between multiple companies such as BMW, Audi, Diamler, General Motors (GM), and Volkswagen. The end goal of the project was to completely dominate already-in-use protocols such as I2C, CAN, LIN, and other various protocols in terms of speed and performance while also being good with security. Well, they did that quite well actually, more knocking performance out than dominating, but they definitely made a massive impact. This protocol is constructed to have multiple security mechanisms, timing systems, unique adapters, and wires for transferring data as well as a unique system and packet format that just makes it easier to transfer larger amounts of data faster. But, really, what IS this protocol? What? Don't look at me like that, I told you enough? Well, actually I forgot to tell you a ton of information. Anyway, the FlexRay protocol can be broken up into the following parts.
Topology And Physical Layer: Like most protocols, this is a good starting point for understanding the technical aspects of the protocol. In this case, FlexRays' first starting point would be the factor of its network topology which employs a unique dual-channel communication system that allows for redundant communication paths. This actually benefits the protocol because it enhances fault tolerance and reliability and is critical for safety-critical applications or systems within the vehicle. While also defining a network topology, FlexRay also defines a specific layer for transmission over these channels including the cable types required, types of connectors, and even signal technicalities.
Communication Cycle: The communication cycle exists in every protocol to date, but FlexRay does it a bit differently. For those who are not so familiar, a communication cycle is a unique arrangement of time slots that dictate how data is transmitted and received within the network. We will get more into this later and it will be a primary section when we talk about the technical details of the protocol, but that's a good stopping point for this bullet.
Time Division Multiple Access: This is another good point that we did define a bit and talked about. But FlexRay utilizes or implements something known as TDMA ( Time Division Multiple Access ) which is a communication and network method that enables multiple devices or users to share the same communication medium, such as a radio frequency channel or a data transmission line through allocating unique time slots within the communication cycle. This is quite heavy to implement but comes with a ton of pros where one of them is that the time division in TDMA prevents more collisions on the network which can ensure that the network is much more efficient.
Frame Structure And Channels: The general frame structure of FlexRay is pretty complex but also very unique which accommodates multiple channels which all have their own set of time slots! This approach allows for a much more slick and concurrent communication within various message types with all different priorities. Remember how we talked a little bit about how protocols and different systems need data and FAST? Well, protocols like FlexRay also have a prioritization system within them that allows data to be prioritized on the network, and given a specific rating, destination and other various factors is how prioritized the data will. This also ensures that the data exchange and flexibility are much more efficient and unique!
Unique Fault Handling: Another major part of FlexRay is how good and well-rounded it is with fault handling and redundancy which is actually one of the core features of FlexRay which is again as mentioned achieved through its dual-channel architecture! Again, we will get into the techies later. But for now, let's end with this: in the event that the protocol has a fault within the network, that channel-type architecture allows for the network to switch seamlessly between channels which ensures continuous operation and much more fault tolerance!
There are many other things that also make this protocol much more unique and make it worth the time and money to implement ( even if some do not see it that way ). Note that all of these we will also be diving deeper into later and getting a bit more of an understanding of the protocol and the way the systems work within the protocol, but for now, this is just building up to something!
The FlexRay Protocol | The profesh and the conesh
I know, already making jokes- not a good look HAHA! But anyway, we have already gotten an understanding of the protocol and should have a good amount of knowledge about its origin to be able to move on to this section. In this section, we will be going over 5 major pros and 5 major cons of the protocol and then in the end compare the results of the protocol itself and also make an ending note about getting to demonstrate FlexRay for this section. So, below I have listed 5 primary pros and 5 primary cons for the protocol!
PROS LIST —
Pro [1] — Harder To Hijack → One of the nicer things about FlexRay is due to one of its cons, unique systems, and also its timing system; FlexRay becomes one of the harder protocols to hijack and manipulate. There was a case study we will be going over that I will also link here that talked about how a group of hackers took an Audi Q8 which uses the FlexRay protocol and were able to create a very complex MiTm (Man In The Middle) attack with specific hardware but regardless, it proved how insanely hard that protocol is to even reverse engineer due to its timing and clock synchronization systems!
Pro [2] — Much More Faster → This protocol as we also mentioned is much faster due to the systems and wiring capabilities it uses. This will tie into another point.
Pro [3] — Stronger Error Handling → We also mentioned this in the way FlexRay was broken up but by far its best system and quality is its error handling and the fault tolerance that protocol has to specific scenarios. This makes the protocol much more reliable in the event of a “traumatic” issue with the car which may be direct physical damage that will trigger the network to maybe quickly record or snapshot information and send it or store it in specific locations of the vehicle.
Pro [4] — Faster Data Transfer Rates → Tying this into pro #2 is the factor that its data and communication rates are much faster. This becomes helpful when a system needs specific sets of data especially heavier sets of data pretty fast. This may include systems like airbags or safety-related systems or maybe even data recording in the event of a crash!
Pro [5] — Larger Payload Support → Along with its faster data rates, you also have the factor that FlexRay supports much larger data sets than most. As automobiles became more in need of systems that were also in need of newer and more unique sets of data faster, protocols like CAN needed to be upgraded to newer implementations like CAN-FD. This is because older protocols like classical CAN did not have the support for proper payloads which leaves FlexRay a major advantage.
CONS LIST
Con [1] — Harder To Adopt → The one issue with FlexRay is that it is too complex to implement or more or less harder to adopt. This is due to its driver complexity and the systems within the protocol that make it a good protocol but also require more costs which actually brings us to our next con.
Con [2] — Much More Expensive → Because the protocol needs specific engineers, needs specific implementations, and is also mostly hidden, it requires extra training and resources to even implement the protocol into a physical vehicle not to mention it gets more and more complex the more units you want to put inside of a vehicle. Leading to our next issue which is power consumption.
Con [3] — High Power Consumption → Protocols like FlexRay are really unique and amazing protocols and they have some unique systems and even define some interesting wiring rules, but with this also comes more power consumption from the vehicle which may also be much more inefficient for the driver who just needs specific data off their vehicle.
Con [4] → Harder To Diagnose → With the protocol's insane complexity also comes the unique systems and tools that an engineer, developer, or even mechanic may need to diagnose the automobile. That being said it also means that the requirement for tools requires much more money even for cheaper tools which in the end may become problematic for the mechanic or developers that are trying to diagnose the car directly without the proper networking tools and then when they need to diagnose a network related issue- then there is even a bigger problem.
Con [5] → Requires Researchers → Similar to con #4, requiring more training and researchers is another thing. Due to how complex and the amount of systems that FlexRay tries to implement, there needs to be people who understand the protocol more and may need extra training and hands-on experience with the protocol and its implementation depending on the usage of it. Now of course, there are much more factors that go into this point which may also make this point quite complex to fully finish, but the general idea is that the complexity does a lot.
That being said, you may have also noticed one primary theme within the pros and cons list. Was it complex? If so, then you are very very correct on that. The reason FlexRay exists was to not only become more secure, reliable, and faster than previous protocols but also to create something more unique and modern for the modern systems being put in cars. This is actually the issue, it was too performant. Have you ever heard of the Goldilocks theme? Where the porage has to be just right? Well, this falls into the same realm with automotive protocols- protocols like CAN were and are too low-end, and protocols like FlexRay despite being used are just too complex and too high-end to implement. So, this is where protocols like CAN-FD come into play ( which we get into more in another article ). So, this is where FlexRay does come into handy- while it is expensive, it is also more collected, better designed, faster, and also much safer from attacks than some other protocols.
The FlexRay Protocol | Concluding
This section was actually quite small given the time frame and the way other modules have been structured. To summarize this section: the FlexRay protocol is a really unique, strong, well-made, and designed protocol that is sadly- too unique. I feel that if this protocol was a little bit less secure and also prioritized other factors whilst also being constantly improved, it would have had a shot at being at the top and being a much nicer and unique system! This protocol also has a ton of cool sides that we will be exploring later, but keep in mind a principle that is similar to the Goldilocks story, simplicity, and complexity can ruin something but when it sits in the middle- it's just right! This is a great section to start and compare the FlexRay protocol to the possible soon-to-be king or automotive protocols- automotive Ethernet (AE).
Going Over FlexRay | The Soon To Be Kind Of Protocols
We have already introduced you very well to the well-known and actually currently used automotive ethernet protocol. But, there is a section I wanted to add and that was why exactly it is much more used over FlexRay or sorry, plans to be more used and why it gained popularity faster than FlexRay. As I have explained in previous articles and even presentations, it's weird to say that whilst gaining popularity slowly, FlexRay lost a ton of its popularity exponentially faster which hurt the reputation of the protocol greatly! Below I have listed some decent points as to why automotive Ethernet might be a much bigger and better protocol for the automotive world than the familiar FlexRay protocol.
Note: Going into this it's important to understand that every vehicle has or uses a protocol for a reason. Something like a Tesla might need automotive ethernet because of the number of digital systems and third-party systems used within the vehicle whilst something like BMW or Audi may need to use an automotive-specific protocol like the FlexRay protocol for various processes, data, and speed-heavy tasks and functions that do not rely on external communications. Basically, just keep in mind that these protocols all exist for a reason.
Right so let's get into it! LET'S GET THIS ARTICLE STARTEDDD!
Higher Data Rates and Bandwidth: Shush- yes, the first thing to knock off the list is going to be the fact that the automotive ethernet protocol offers significantly higher data rates in comparison to FlexRay which also may be due to the general weight of the protocol. This makes automotive ethernet much more suited for applications that require rapid and extensive data transfer. Similar to CAN, automotive ethernet also has support for various speeds like Gigabit Ethernet, Fast Ethernet, 10 Gigabit Ethernet, and other speeds which will all obviously change the general speeds of the data depending on which one is being used. Now, as we mentioned, with modern vehicles this speed is extremely performant for systems like advanced sensors, cameras, radar systems, and even more data-intensive features like HD video streaming. While FlexRay does have higher data transfers, it might not be super geared for specific tasks and functions that may be on the lower but higher end of the spectrum at the same time.
Standardization And Wide-Spread Adoption: As we also mentioned when introducing you to the protocol, automotive ethernet is a very unique protocol that also has an insane amount of support across the world and is also well understood. Now, without a doubt, for automobiles like a Tesla that just leave data unencrypted over the network- this can be troubling as hackers may be able to access and figure out common access points from the network of the vehicle and if even some of those can be the smallest of manipulated, then you instantly have a possible life-threatening issue. But, if you take this general security concern away and properly encrypt and protect endpoints on the network, the general standardization gives it a major boost. Not to mention the ethernet ecosystem also benefits from continued research, development, and the constant innovation that the protocol faces. Protocols like FlexRay might not also be able to adapt to future changes made to automotive systems as easily as automotive ethernet may be able to which means that it will become much harder to implement and keep up. In sum, the FlexRay protocol is a unique and well-known protocol, but ethernet has had its realm of history for quite a long time and has constantly been researched, demonstrated, and more!
Broad Industrial Support & Familiarity: I think everyone even people who are not into tech at all understand what ethernet is, I mean that just says a lot. This kind of also ties into our previous point on the protocol itself but while ethernet and automotive ethernet change, automotive ethernet is just ethernet tailored and developed for automotive needs and functions. Because of how understood ethernet is, the amount of research and the number of lessons about it as well as the tons of research papers and even people who specialize in telling others what ethernet is, it really is not that hard to say that automotive ethernet is not that different — because it really is not THAT different in comparison. That being said, because of how widely taught and understood it is, it makes it a ton easier for automotive engineers to work with and also designs especially given also how easy it is to talk about. This also makes it easier on people who may be repairing a vehicle that uses automotive ethernet since no special adapter is needed other than an ethernet cable.
External Integration: This is a HUGE one. The thing with modern-day ethernet, or really ethernet in general is the fact that it is so extremely easy to connect seamlessly with external networks such as cloud services. This as you can imagine enables so many other support beams and systems that can be implemented into a vehicle as we mentioned with a Tesla. Now, FlexRay sure is one protocol that can add much more unique systems and functionalities but it can not exactly integrate with external networks in the same way or even way at all that automotive ethernet networks can.
Systematic Integration: One of the amazing things about automotive ethernet is that it has an insane amount of support for being integrated and working with different systems such as infotainment consoles. I mean even thinking about it, automotive ethernet also allows for better and much more advanced and easier-to-access automobile diagnostics. Not to mention, another key factor to note is the support automotive ethernet has for complex sensor fusion! to create a comprehensive perception of the vehicle’s surroundings. Automotive Ethernet’s bandwidth and real-time capabilities allow for such seamless and rapid exchange of sensor data, enhancing the accuracy and reliability of sensor fusion algorithms that are used within automobile systems!
So really, the deal with automotive ethernet is pretty big and you can imagine why it might be taking FlexRay over even if FlexRay may also have support for similar systems — Ethernet just does it better and is also a bit cheaper and well worth it to implement despite the material and the standards on the protocol! So, the reason I also wanted to go over this was because I figured it was worth bringing up in the case that you may have had questions as to why automotive ethernet might be slowly taking over as you have probably heard multiple times if you are in this field already. That is a good list of reasons why it might just work better than FlexRay despite FlexRay having such a great amount of support behind it.
Going Over FlexRay — Authors Note
Hey there! It's me again, the nerd writing this article. I wanted to let you know that it is extremely important to stop the article or rather module before you continue on. The next section is highly technical and it is important that you can properly take a break and hydrate before we move on to that section! Heck, maybe go touch some grass and you might feel a bit better! That being said when you are ready to move on: the next section will go more technical into the FlexRay protocol and talk about its time management system, its unique signaling, error systems in depth, codes, and even packet layout in depth as well!
Going Over FlexRay — Let’s Geek Out
This section is going to be a bit deeper and might make the article go well over 60 minutes, so I would like to acknowledge this factor and let you know that this part of the article is by far the most technical part of the article. Despite me trying my best to knock it down to a basic level, you should have some understanding of networking and how it all works before you can read this section as it will aid you and make it less difficult than what you may be seeing! Without much more to say, I have broken this primary section into multiple sub-sections.
Warning: Some sections are just sub-sections of these sub-sections!
Let’s Geek Out | FlexRays Dual Channel Communication → This section will go into channel-based communication and try to lay out the general idea between dual-channel and single-channel communications.
Let’s Geek Out | FlexRays Communication Cycles → A section that talks about FlexRays communication cycles.
Let's Geek Out | FlexRays Data Rates And Communication → A section that talks about FlexRays data transferring and communication rates and explains what the pros and cons are of its data transfer system.
Let's Geek Out | FlexRays Synchronized Communication → A section purely dedicated to the way FlexRay synchronizes communication.
Let's Geek Out | FlexRays Packet Layout → A section that will dig into FlexRays packet layout and how data is transferred or moved as well as how data may be ranked within a system.
Let's Geek Out | FlexRay Protocol Summary → A section that will talk about FlexRay and why these details can be too much.
Note: I understand that these sections are not as fluid with emotion or unique forms of text, I just felt that adding extra emotion would have- over exerted the amount of information trying to be fed so expect the next section to be a bit- void of emotion.
Fuck nuggets- let's get into this LOL!
Let’s Geek Out | FlexRays Dual Channel Communication
Alright, this one is interesting. To start off with, this is a good place to start with “What is channel-based communication”. Well, in general, channel-based communication is just a fancy way of saying — methodized data exchange where multiple parties which in this case are devices share a common communication channel. A good example of a communication channel would be considered the Internet! Channels however, may also take different forms such as physical translation lines like wires, cables, and even fiber optics, and even take their own unique logical divisions within a shared medium such as time slots ( in the case of FlexRay ). The use of channels for communication allows a specific set of parties or even just multiple devices in this case to communicate concurrently without any issues such as network interference since each node within that party ( such as an electrical unit ) may be assigned a dedicated time slot. This is again, in the case of FlexRay when we mention time slots. There are some interesting things that are worth pointing out about channel-based communications.
Concurrency: Since more than one device can communicate over different channels simultaneously, this makes it much more concurrent and also super important in scenarios where those devices need to exchange data in real-time which is actually extremely helpful on a network.
Prioritization: As we mentioned multiple times when it comes to automotive networking, communication, or in this case channel prioritization is really important. In this case, channels will be prioritized based on the urgency of the data that is being transmitted, in turn, this allows for the implementation of QoS (Quality of Service) mechanisms to ensure that the most critical data is going to be given the higher priority!
Resources: The final point I would like to make on channel-based communication is how well resources are used. Because of the concurrent systems and even the optimization systems, general communication becomes much more efficient.
Got the idea of it? I know sometimes it may be confusing but hopefully, it was worth going over. Regular automotive protocols already implement channel-based communication, but what about dual-channel communication? The ability of a network to implement dual-channel communication is the factor that it can support and alternate between forms of communication. Let's get into this a bit deeper. FlexRay implements something known as dual-channel redundancy which consists of two completely separate communication channels which are typically labeled as A and B. The reason for having channel A and channel B instead of just A is to ensure that there is some form of backup channel.c This backup channel can help the network ensure that the data transmission remains reliable in the presence of a unique fault within the network! Remember how we discussed that one of the primary features of FlexRay was the facture of how fault tolerant it was and the complex error handling mechanisms it has? This is one of those unique systems that make it a much more reliable of protocol and also make it much more robust AND fault tolerant. So you can basically look at it like this, dual channel redundancy, and the point of implementing it is to ensure that if one channel such as A which might be the main communication channel encounters a fault that B is there to be a backup. This issue or fault can be anything from signal degradation all the way down to physical faults within the network. When this fault is encountered as we also mentioned before, the network will immediately switch to the alternate channel without disrupting critical communication. This is actually super important for us especially when safety-critical systems need to maintain communication integrity! As you may also not be surprised, FlexRay is going to go ahead and throw us into an even deeper realm that actually goes ahead and shows us the unique mechanism it has. I mean we already talked about the seamless channel switching where it just sees a fault and will switch and maintain the connection's communication integrity. But why is this existent? Well, when you look at it from another perspective, any system could be dual-channel and could enable channel switching, but seamless channel switching is where it's at. In order to make sure that connections are secure and uninterrupted we need to make sure that the transition is smooth and transparent to the rest of the network which in the end ensures that the data transmission will continue with minimal disruption. This type of switching is absolutely vital for the systems relying on the network that needs real-time communication. If we fail to implement seamless channel switching, then the possibility of a delay impacting the response of the system could be quite catastrophic to the network! But what are some of the use cases of this unique system? Glad you are interested! (self-talk LOL), but here is some good examples of the use cases of this system and where you can imagine it may actually come in handy.
Steer/Drive/Break-By-Wire or X-by-Wire Technologies: I defined these in the most basic way I could, but these types of technologies also known as x-by-wire technologies are basically types of technologies that replace the standard mechanical systems of a car such as steering with a set of sensory inputs that are then sent to a network. In systems such as break-by-wire systems, electronic signals control the breaking functions, and in order for data to be fed directly and precisely in real time and properly- we need a fast and reliable network to do this. But, the network is not the biggest issue, we also need to make sure the network does not miss or fault data during transmission. This is where the dual channel redundancy system within FlexRay comes into play. If one channel faults during breaking, then that can be completely fatal to someone in the vehicle if there is no way that data can be received if that channel fails- however, with the dual channel redundancy, we now have system or channel B to receive and maintain state during the transmission of the data within the vehicle during the specific movements. This not only ensures that the driver remains safer but also ensures that the rest of the primary functions can execute without issues.
Steering Control: This falls under x-by-Wire technologies but in modern vehicles such as a Tesla, systems such as steer-by-wire have replaced traditional steering tech. This means that the data on the wheel such as its axis is sent over the network and then commands the control modules to work in a way with the axels of the vehicle or other systems in between ( to put it lightly ). Can you imagine what would happen if you forced your car to turn or yank left and the network did not even respond? Sheesh, imagine how bad and fatal that can be when trying to avoid an accident! As you can imagine, dual-channel redundancy systems really come in handy!
ADAS → I think you should try and guess this for yourself. If you have already gotten your guess ready, then let's shoot. The ADAS or Advanced Driver Assistance Systems in vehicles require and completely rely on rapid and precise communication between eh hundreds of sensors and control units implemented into those systems. This includes collision warnings or lane departure alerts. If the system fails to transmit data on channel A, you can imagine how bad it may actually be when the system does not work and someone is not fully aware of specific conditions on the roadway ( even though they should be paying attention ). The dual-channel redundancy system helps systems like ADAS to ensure that the data reaches the designated communication and processing units without any delays.
All in all, this system is quite critical and sadly quite expensive. However, it's also important to note that other protocols also implement this feature such as AE ( Automotive Ethernet ) which makes other protocols carry the same systems but for cheaper. Regardless, vehicles that use protocols like FlexRay must have some form of system in them to ensure that data flows through the network properly.
Let’s Geek Out | FlexRays Communication Cycles
The communication cycle as mentioned is just the cycle of communication for starters anyway. This can be broken into multiple subsections, so I have listed them below which goes over the general anatomy and the data transmission process even down to the time synchronization systems.
Communication Cycle Anatomy
The communication cycle of the FlexRay protocol can be broken up into many different parts that pull it all together; so let's go through them shall we? For the remaining parts of this section, think of the FlexRay communication cycle as a container that houses distinct segments. The segments are listed below!
Static Segment: The first segment we may come across is going to be known as the static segment which is a reserved compartment within the cycle where fixed data sits. Each ECU for instance has a designated slot within this segment whose data remains constant throughout the cycle. Simple right? Seems pretty easy to remember.
Dynamic Segments: I bet you can already guess what this is! The dynamic section is the flexible area that can accommodate varying data which will make more sense the more we talk about FlexRay/c These slots are filled on a first-come, first-served basis which allows for a much more efficient utilization of available space. The dynamic sections pretty much are sections the ECUs use to transmit intermittent or less critical information.
Symbol Window: The symbol window within the bin is going to be the window that is similar to a unique or rather specialized communication channel that is employed for signaling purposes. Typically this segment remains untouched by most of the FlexRay devices but still plays quite the role in maintaining synchronization and coordination within the network! This actually brings us to our final point which is the Idle segment.
Idle Segment: Similar to the symbol window, the IDLE segment is used for aligning the timing of data transmission by representing a silent interlude designed for the synchronization between cycles. This can be super helpful when we need to synchronize the network or cycles.
All of these unique segments make up the anatomy of a communication cycle within the FlexRay protocol! So you can again look at it like this- a communication cycle is a box with 4 primary segments that define the rules and actions or data within the cycle. So now, I imagine that this kind of broke it down for you- so let's talk a tad bit about time synchronization within the FlexRay protocol.
Time Synchronization
As we have mentioned a few times, time synchronization is one of the most unique and safest methods that FlexRay implements for data transmission. But how does it work? On the mouse base level, the protocol divides time into its own units known as “macroticks” which are typically equivalent to one millisecond. All of the given ECUs are also synchronized to a common clock which will ensure that they all initiate data transmission simultaneously at the start of each cycle. So the idea of a macrotick seriously helps with the idea of synchronization. This is as best as it can really be explained.
Now lets go ahead and talk a little bit more about the data transmission process.
FlexRays Data Transmission Process
There are multiple points within the data transmission process that can all be broken down into their own points. So similar to the anatomy of communication cycles, we are going to be breaking down the data transmission process into two major systems.
Static Slot Filling: This is commonly known as the efficient data allocation side of the FlexRays data transmission process. For this section, let's think of the static segment as an organized cargo hold of a ship where specific goods are ordered in a unique way for transport! This segment is then divided into slots which all are designated for a specific set or piece of information which are then reserved for data that retains and keeps its constant value throughout the cycles. When each cycle within the FlexRay network is started, specific transmitters which are chosen during the design of the system will then act as specific loaders which will load the data into their own respective slots. Because the transmitter is aware of which slots are allocated to them, it ensures a much more smoothed process. Similar to a well-organized and kept-up warehouse, this slot-filling process basically guaranteed that important and unchanging data finds its place in the slot it was meant to be put in. The transmitters basically populate the slots with data that serves as a foundation for communication during the entire communication cycle.
Dynamic Slot Filling: Also known as Dynamic Slot Allocation happens when the cycle is currently unraveling. This cycle represents a space where data exchange is much more fluid and adaptive which also means it is kind of like a marketplace where specific people engage in these spontaneous and unique interactions based on their current needs. The ECUs within the network act similarly, they may be the vendors who are equipped with information that might be of interest to others and they seize the opportunity to transmit their data during the cycle by placing it in available dynamic slots! This dynamic allocation kind of mirrors the dynamic nature of real-world conversations where other people may also chime in as the conversation flows.
The FlexRay State Manager
FlexRay, being the unique protocol it is, operates through various distinct states, each serving a specific purpose. The FlexRay state manager describes these states which enable the network to transition seamlessly between them to ensure reliable and efficient communication! Below are some examples of states and their purpose as defined by the AUTOSAR standards.
Ready: This will act as a preparation for communication.
Wake-up: This will exit a low-power mode state.
Start-up: This mode indicates that the network is initiating communication and synchronization. Think of this as a primary initialization.
Online: Active communication state.
Online-passive: Comes about when a synchronization error occurs and no data exchange is present or happens yet the network is still online and active.
Keyslot-only: This occurs when data transmission is limited to key slots.
A low number of cold starters: This means that there is reduced communication relying on synchronization frames.
Additional States: Other states also exist such as config, sleep, receive only, and other modes to provide verbose operational scenarios.
As you can imagine, these communication states make up general communication and all have their own unique representation and information that can be shown! Ending this section off as well is what makes up a communication cycle within the protocol and also shows the system what to do and how to do it!
Let’s Geek Out | FlexRays Data Rates And Communication
This section is going to be a bit smaller but let's talk about how fast and how data is transmitted within a FlexRay environment. So generally speaking, FlexRay operates at speeds around 10 Mbit/s. Pretty high in comparison to other protocols. But how exactly does it achieve this unique operating speed despite it being quite heavy? Well, unlike most protocols out there, FlexRay has a complete rabbit hole of information and unique innovations and systems that actually help it along the way and the primary few revolve around perfectly slotting data and information as well as synchronization. Below are a few points that should demonstrate this properly and at least get you used to how it does this so well whilst also building you up to how the protocol works!
Time Division Multiple Access (TDMA): Holy fudge nuggets, this is going to be one longer one to get through so stay tuned and get buckled in! Let's make this a quick ride! TDMA also known as Time Division Multiple Access is a pretty cool communication technique that is used throughout FlexRay to organize the way data is exchanged and transferred throughout the network. This system basically makes sure that each node within the network has its own dedicated time slot for exchanging or transmitting data. Traditional network or communication protocols such as ethernet do not actually employ this system which makes it more likely to come across collisions that eventually lead to data corruption and re-transmission. I can imagine what you are thinking already, this is quite bad. Another major factor with TDMA is that it also has this unique deterministic behavior that basically allows us to say the time of the data’s set and transmission is directly known as going to be guaranteed where traditional networks are not so guarantee-able! So how is this implemented directly into FlexRay? Well the TDMA concept is actually directly implemented into the FlexRay communication cycle which is broken into segments that are either classified as static or dynamic. For reference, the static segment is further divided into mini-slots which all is assigned to a specific node for the data transmission to take place. Note that I only choose to mention static segments for right now since the whole idea of dynamic segments is purely optional as noted by Vector E-Learning
The dynamic segment is optional. It serves to transmit event driven messages and thereby supports asynchronous processes. To avoid affecting the deterministic data transmission of the static segment, the dynamic time segment always exhibits the same length. The dynamic time segment, if it is implemented, always follows the static segment.
The dynamic segment is based on the FTDMA method (Flexible Time Division Multiple Access), whose core is indeed the TDMA method. Despite this, it enables flexible communication flow. Therefore, communication in the dynamic segment is also based on a communication schedule. The dynamic messages defined in it are only transmitted in the dynamic segment if an event occurs which requires a message transmission.
Now we can go ahead and go back to the implementation. The TDMA-based communication cycle that is within the FlexRay protocol also ensures that critical messages or higher prioritized messages such as ones related to vehicular safety are transmitted with the higher priority meaning they also have a much higher precision rate. As you can imagine, this is important within the network so specific systems within the vehicle operate as fast as possible! There are many other unique systems and also the cool tech that TDMA implements in FlexRay such as reduced latency, collision-free communication and even handling support for unique mixed traffic. The TDMA system as you can already see helps with the general speed of FlexRay because of the way data is handled and properly segmented as well as the way it is transmitted. There are other various systems as well such as the next point on the whole communication cycle static and dynamic segmenting!
Static and Dynamic Communication Segmenting → As mentioned in the communication cycle side of things, FlexRay splits the communication cycle into two types of statements or segments which are known as the static and dynamic segments. Generally speaking, the static segment is the segment that is dedicated to the time-triggered or statically set time-based communication which can as you might be thinking, handle critical and time-sensitive data that needs to arrive at a specific time! While the dynamic and more flexible segment of the communication cycle can handle trigger-based event communication which handles less critical and valuable data within the network. The proper segmenting of these two data handling systems basically a classification system for data not only makes FlexRay much more safer but enables it to handle data much more safely and concurrently than most other networks or protocols do. However, as this whole article heavily emphasizes — The FlexRay protocol is very heavy and very secure but also very expensive primarily because of the systems it implements that may not work out for specific communicative environments. Sometimes, even when it comes to a network, too much exists.
Payload Length → The one other major factor that also tails on the protocol's speeds and transfer rates is how big the payload or the cycle’s length is. As you might imagine, a bigger payload and larger cycle length will cause the transmission to be a bit slower and vice versa.
These are just a few examples out of the massive handful. Overall, the FlexRay protocol maintains quite the speeds, however, do not forget that especially in protocols and systems, being too fast may not work for other systems and may only work with modern-day systems that can handle those fast data rates!
Let’s Geek Out | FlexRays Packet Layout
Alright, are you ready for this? This is actually not going to be that hard to understand because you may actually already have enough knowledge by this point to fully understand the layout. This section will lightly discuss the packet layout of the FlexRay protocol and also talk about some more technical aspects of the packet layout in comparison to others. Below is a demonstration of the packet which is then followed by a direct dissection of the protocol itself.
FlexRay‘s packets can be split into three individual segments all of which have their own unique set of information.
Header Segment
The header segment within the packet is the definition for the network to see what data is what and to also help identify the frame. The protocol defines these properties with 4 sub-segments which are shown below.
Frame ID: This is the identification number of the frame and typically it is around 11 bits and again helps the network identify the frame itself.
Payload Length: The payload length is another specification that helps the network understand what the possible length for the payload segment is. This is defined in a 7-bit sub-segment.
Header CRC: CRC’s also known as Cyclic Redundancy Check is a widely used error-detection algorithm that is used in many different network-based applications that you may see today. Basically, the CRC section is a hash value based on the data being transmitted. This error-detection algorithm is used within FlexRay because of its robustness and cost-effectiveness. Keep in mind that CRCs are error detection, not error correction algorithms.
Cycle Count: This next segment within the packet helps the network know how many times the cycle will repeat. In other words, the cycle count is a value that increments with each complete communication cycle. It's important to note that the cycle count is pretty well broadcasted over the network!
Payload Segment
As you can imagine, the payload segment of the protocol is the segment that defines the payload of the packet. That is as easy as you can put it haha
Trailer Segment
This part o the packet contains synchronization and the error-detection side of information. Similar to the header, the trailer segment can also be split up into its own unique segment which is shown below.
CRC: As we mentioned before, the CRC field contains the checksum value that is calculated from the data within the payload segment (the previous segment we talked about ). This value allows a node or controller to verify whether the data in the payload has been corrupted during its transmission! Now you can see how CRCs seriously come in handy!
Synchronization Info: FlexRay is known for its way of synchronizing data transmission, well, the trailer also adds to this factor. The trailer of the packet may or may not include synchronization bits which are also known as a sync field that can help a given node or controller ( such as the receiving ) synchronize their own clocks with the transmitted data!
All of these unique segments make up a frame within FlexRay. This is all we will be getting to talk about today since there are a ton of reasons especially resource wise that we can not go deeper ( which I will get into here in a second ). I want you to know that this information acts as a general base to get you to understand what FlexRay is on the inside and what it contains! During the making of this article, I also saw a ton of biased or confusing information, for example; someone had mentioned that the trailer segment has a section for guard bands which is interesting to look into. It basically made this note in the article “FlexRay frames include guard bands before and after the payload and trailer segments which are additional bits that provide separation between segments and help nodes accurately detect the start and end of each segment.” But doing some deeper digging led me to an article that said guard bands are a false concept that does not exist within FlexRay — so I deeply urge you to make sure that you can verify information on the packets and frames layout! Tying this into the next point, let's sum this section up so we can finish this article huh?
Let’s Geek Out | FlexRay Protocol Summary
We have summed up FlexRay in many ways and as you can imagine this section can sum the protocol up as one of the most complex protocols out there. Its time synchronization systems, error checking, and fault tolerance mechanisms, and due to its insane amount of checks make it a very unique protocol! Not only does it get to be unique and strong but it also gets to become very fast and useful for applications that require a ton of data! Now let's go onto our primary point to end this article.
Going Over FlexRay — FlexRay As A Hacker
This is a section I procrastinated on heavily, and I would be lying if I told you I did not. As an automotive security researcher who works remotely and also does not have the best funding, I feel the pain of not being able to physically work with automobiles and the networks they have inside of them. FlexRay is a good example. When I did the article on the CAN BUS I was extremely lucky to have found a very old voltage meter and a very very cheap OBD-II tool laying around for me to better demonstrate how these networks work and what goes into them physically! Heck, I do not even have a laptop to physically reverse engineer networks haha! But this was the point of this section. FlexRay is a very hard and complex protocol, so complex that it requires specific hardware and very specific knowledge of the car you are targeting, background experience in exploit development, reverse engineering, and various other topics just to even get the smallest vulnerability on the network. I also mentioned in the CAN article that physical access and reverse engineering of automotive networks is a great way to introduce people to cyber security risks within vehicles and is a great way to show people how interconnected cars or vehicles as a whole really are! But the issue is that automotive protocols physically in today’s world are either too overly complex to target and at that point can not pose a direct threat ( to some companies and automobiles ) or are not worth the time to even target. So, that being said; despite the FlexRay protocol being quite hard to exploit and even work with, it does not mean that you should avoid having hands-on experience at least attempting to exploit or reverse engineer the network. So, let's look at a little story by a few hackers that were able to commit a Man In The Middle (MITM) attack on an Audi Q8 which used the FlexRay protocol. Below is a summary of the attack and what happened which is followed by a link to the original article. Expect a weird tone for this LOL, this was pasted from my notes! This personally- took me way too long to write haha but I certainly hope it emphasizes the matter with FlexRay!
Audi Q8 FlexRay Intercept
Prepare for a delightful journey into the captivating world of automotive ingenuity, where diligent researchers embarked on a quest to unravel the enigmatic tapestry of FlexRay messages. Visualize, if you will, an FPGA, that remarkable Field-Programmable Gate Array, gracefully assuming the role of a bridge between the cryptic FlexRay and the familiar CAN. It’s like witnessing a well-choreographed dance, as individual message bits waltz along the FlexRay bus, elegantly orchestrated! Our protagonist in this tale is none other than an Audi Q8, bedecked in the finest attire of Driver Assistance opulence — adaptive cruise control, the ever-so-debonair LKAS, and a medley of other impressive features. The narrative begins with a daring expedition: the deciphering of the arcane language of FlexRay messages. Armed with a trusty logic analyzer, our intrepid researchers set forth on a noble mission to capture these elusive messages from the core of the car’s stock system. Enter the FlexRay decoder, a digital linguist translating the intricate scrolls of this vehicular dialect.
As the data unfolded its mysteries, a revelation emerged — the elusive bytes governing the steering mechanism. Yet, there’s more to the tale! A fascinating harmony revealed itself between this obscure data and the faint echoes of CAN steering messages from distant automotive cousins. To bend these messages to their will, an intricate dance of circuitry unfolded within the FPGA, much like a choreographed tango. Enter the FlexRay packet decoder, a conductor’s baton of sorts, allowing for the delicate molding of specific bytes within the messages — a true symphony of control encompassing torque and enabling flags. As this captivating symphony of alteration played out, the once-unchanging steering of the Audi Q8 transformed into a willing collaborator, swaying to the rhythm of a joystick’s gentle guidance, all thanks to the panda device’s orchestrations. And so, dear readers, the narrative crescendos, revealing the captivating artistry of injecting steering commands into the Audi Q8 through the intricate FlexRay symphony, directed with finesse by the hands of an FPGA-based virtuoso.
Now to summarize! In the grand realm of openpilot possibilities, this odyssey shines as a beacon, beckoning new vehicles to partake in the mirthful dance alongside the openpilot autonomous driving system. Kudos to the dedicated researchers who orchestrated this automotive research haha! The powerhouse to this amazing note!
Hacking an Audi: performing a man-in-the-middle attack on FlexRay Driving an Audi with a joystick by Injecting steering commands on the FlexRay buscomma-ai.medium.com
Now, going forth with the article! This section should have given you some decent information on what it is like to be a hacker with FlexRay. The issue? The funding. Physical automotive cyber security requires a ton of specific hardware, good teams that have a deeper understanding of these protocols and networks, and require a TON of funding not just for vehicles but also for the software and even systems used to sniff and parse FlexRay protocols! Unlike CAN which also has its own issues, FlexRay is just a very very difficult protocol to manipulate, and while I do usually encourage you to go explore, if you have the funding and possible connections — go for it! If not then it may be worth it to look for other plausible research area’s to get you used to it!
Going Over FlexRay — Conclusion And Summary
Welcome to the end of the article, if you have made it this far- congrats 💀 because honestly- I do not understand how you manage to do it. Anyway, let's go ahead and end this article! When it comes to automotive cyber security and general research, it is important that we manage to keep some form of knowledge in how vehicles network even when it comes down to the world of just hacking cars remotely. This is because if we can understand how an automobile works from the inside out then we can also understand what we need or may want to do to it, not to mention it also helps enhance your knowledge for the future of hacking automotive networks. Summing up on FlexRay: whilst FlexRay is one of the nicer automotive protocols out there, there is a ton of issues with it such as being too expensive and being too overly complex to work with and it crosses the line of complexity over simplicity. As a hacker, you may occasionally want to give yourself more knowledge and background experience with the protocol, but may also not have the money or the funding for the tools to do so not to mention, at the time there is no direct (good) open sourced frameworks or tools to help you reverse engineer FlexRay due to its insane complexity! That also being said, if you feel like you can be one of the few to do it and at least try to take that crown then go ahead and shoot for the stars! Now, the next section will drop a few huge segments and I want to talk about something for the general factor. When writing these articles, I do not expect people to read them at all or even bother reaching this section. But I wan you to know that no matter what, I think of the very small people that I do see reading these articles, and if that is you, then I very well do appreciate it. That being said if you would like to keep up with more content or even help support trips and other conventions or even help supply me with specific information — you can find me all over the section below which will go over who I am and why I am here as well as where you can find me.
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+ languages 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 | Where I Came From
Hey, there- not sure how I can start this other than going by the title and kind of scraping a bit on the surface. For starters, hello there- my name is Totally_Not_A_Haxxer ( ironic name ), and I am a 16-year-old automotive security researcher working with organizations such as mk.iii to produce quite an amount of cyber-security-related content! This is my short story on how I went from an outcast in school to someone who hacks cars ( legally ) for a living!
Ah, let’s rewind the clock to the good ol’ days before I became the grandmaster of car hacking — yep, you heard me right, car hacking. But before all that wizardry, I was basically the outcast of outcasts. Back in the day, yours truly was knee-deep in writing game cheats, rubbing shoulders with folks whose greatest ambition was mastering the art of game cheats and munching on a hearty selection of mood-altering substances. Ah, the exploits community, where toxicity thrives like a fungus in a damp cave — charming!
Meanwhile, I was juggling my rebellious teenage escapades, the kind that would give your average parent nightmares. Picture me, trying to squeeze every ounce of “oomph” out of life, navigating the treacherous waters of adolescence, and cultivating a personal vendetta against anything remotely associated with the school. As if that wasn’t enough, I was racking up more fights than a Rocky Balboa marathon, probably because I had the brilliant idea of being the ultimate school outcast. My so-called friends managed to forget my existence faster than a Snapchat message.
Things got so wild that my guardian, bless their heart, yanked me out of that hellhole of education and into the glorious world of online schooling — yeah before it was the cool thing to do. So here I was, a lone wolf at home, holed up with my trusty computer, delving into the mystical realm of game cheats (even though I was about as clueless as a goldfish in a maze). But hold up, don’t think my journey ended there. Oh no, dear reader, that’s when the real action began!
I swapped out my teenage angst for a newfound passion — cars, baby! Those four-wheeled marvels and their fancy tech tickled my fancy. I went all in, buying books and resources that were probably worth more than my weight in gold. From tinkering with gadgets to reverse engineering automotive networks, I went from being an irritable mini-human to a bona fide tech maestro.
In a plot twist worthy of Hollywood, my anger-fueled antics transformed into a superpower. Instead of causing chaos in the schoolyard, I was wreaking havoc on systems and networks, making even the most mischievous computer viruses jealous. So there you have it, my friend — from writing sneaky game cheats to playing tag with automotive technology, I became the quirky protagonist of my very own tech-driven saga. And yes, the cars better watch out, because I’ve turned my youthful rebellion into a symphony of circuitry and code. Who would’ve thought, huh?
I would have liked to share more but some things I just could not and plus the story would become WAYYYY too long for this segment haha! So there you have it! As of now at 16 years old I have written multiple books ( one of which is published on Amazon) and others that have been released for free! I have written my own programming language, developed my own security research community, worked with companies like Hakin9 and Pentest Mag to push out IoT security research, and even went as far as working with the best companies to research and present automotive security content! Heck, I even just built my own car-hacking simulator haha! Do also note that everything I do is completely ethical AND LEGAL WITHIN THE U.S. as it is now my job and is also highly certified!
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 situations 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 direct resources, I always do try my best to deal with what I have and do what I want to do with said resources 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 faster and also make me much more motivated to continue doing what I am doing! Below I have listed my Cash App and Venmo as well as crypto wallets!
Venmo:
Venmo | Totally Not A Haxxer hacker Venmo is a digital wallet that lets you make and share payments with friends. You can easily split the bill, cab fare…account.venmo.com
CashApp:
BitCoin Address: bc1q45ctj3cwl8zr2qdw4xceukr58cdnayxuutymt8
Ethereum Address: 0x466BA936E2bdbEab74c8cd048CC43279fE712E54
USDC Address: 0x466BA936E2bdbEab74c8cd048CC43279fE712E54
Tether Address: 0x466BA936E2bdbEab74c8cd048CC43279fE712E54
XRP Address: r4s8FeyYCBHJQGJRGuDuPeM2YLMwRCZP4R
Ending Note | Where To Find Me
This sounds weird to say, but you can find me in 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 when I have a bunch of stuff to do and given social media is not on my phone ( at this time, working on a study/ghost month ). SOOOO, that being said, Google is a good place to go literally search “Totally_Not_A_Haxxer” and some of my socials should pop up + look at it this way, you get more OSINT experience.
Instagram
Medium:
Totally_Not_A_Haxxer — Medium Read writing from Totally_Not_A_Haxxer on Medium. Cyber Security Educator, Developer, Social media manager, Author…medium.com
Blogger:
Hakin9 Articles / Research point
GitHub
TotallyNotAHaxxer — Overview Single Developer of the red rabbit project, leader of the scare security team, and Single developer of the Grizzly…www.github.com
Google: https://www.google.com/search?q=totally_not_a_haxxer&sxsrf=AB5stBjHLrW6iWuxLvuh7jKHebe6L-BTGQ%3A1690923815850&source=hp&ei=J3PJZJqkL-nakPIP7dqCgAo&iflsig=AD69kcEAAAAAZMmBN09YHcUlW2STp8BofYjoKR1t0GgH&oq=tota&gs_lp=Egdnd3Mtd2l6IgR0b3RhKgIIADIHECMYigUYJzIEECMYJzIHEAAYigUYQzIHEAAYigUYQzIHEAAYigUYQzIHEAAYigUYQzIHEAAYigUYQzIHEAAYigUYQzIOEC4YgAQYsQMYxwEY0QMyCBAAGIAEGMkDSMYGUABY1QJwAHgAkAEAmAGtAaABhQWqAQMwLjS4AQPIAQD4AQHCAg0QABiKBRixAxiDARhDwgIIEAAYigUYkQLCAhMQLhiKBRixAxiDARjHARjRAxhDwgILEC4YigUYsQMYkQLCAg0QLhiDARixAxiKBRhDwgIKEC4YigUYsQMYQw&sclient=gws-wiz
Ending Note | Resources To Advance Your Knowledge
This module went deep into automotive protocols, especially the FlexRay protocol. Sadly I do not have many resources for you as many of them are private/confidential and or were not really good resources at all and did nothing but confuse you about FlexRay. So, this article has some good pointers on where to go with basic notes and programs though!
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