PCM wireless update

[startrek]

How likely is it that FCA could send a recall PCM update thru your nav antenna without your knowledge?

 

[Brutal_HO]

Just wrap it in tinfoil.

 

[Burn'n Oil]

Unlikely, but... then again... What could go wrong?

 

[thestuarts]

I believe FCA can't update the PCM/TCM/BCM/?CM over the air in the 2019/2020 trucks. FCA can update the UConnect, maps, and possibly other systems, but not the control modules.

I will write a long story explaining why I believe that to be true.

For some back story, I was a senior software engineer on the Xbox team for 11 years. I worked on the Xbox operating system for the original Xbox, Xbox 360, and Xbox One. I also was one of a handful of developers who worked on the Xbox 360 WiFi drivers. In my personal time, I reverse-engineer firmware in hardware devices like the PS3, WiFi routers, security cameras, etc. I no longer work at Microsoft, but I still reverse-engineer software on a regular basis.

When I worked at Microsoft, we designed the Xbox hypervisor, operating system, optical disc drives, and the WiFi adapter so they can all be updated over the network, but it took a lot of engineering and testing to make that possible.

The first engineering principle is the system must support a two-phase commit. In simple terms, that means the update may fail for an infinite number of reasons, so the system has to be able to roll-back to the previous version in case of failure. In order to support a two-phase commit, the device needs enough storage to store the entire current version of the software and the entire next version of the software; both versions must exist side-by-side for a period of time. The current software downloads the new software and verifies the integrity of everything to ensure the data was not corrupted or modified by an attacker. If the new software passes all the integrity checks, the current software has to commit the new software and reboot into the new software.

The second engineering principle is the system [usually] should not support rollback after commit. In other words, the system should not let someone rollback the software version to an older version. There are many reasons this is usually a requirement, but the most common reason is that you don't want someone to be able to go from a secure version to an older insecure version.

The third engineering principle is the system should not allow a man-in-the-middle to inspect or tamper the update. If an attacker can observe what is being changed in the update, then it makes it easier for an attacker to reverse-engineer any security changes. If they understand the security changes, they can use the exploit to attack systems that haven't been updated yet.

The fourth engineering principle is the system should not allow any side-channel attacks. A side-channel attack is one that enables an attacker to figure out how the system works by observing something other than the system itself. For example, when software is running on a CPU, a certain amount of electromagnetic interference (EMI) is created. The EMI can be measured to figure out what the CPU is doing which could be used to figure out passwords, keys, etc.

The fifth engineering principle is the system must support a chain-of-trust that can be used to authenticate the software update. This ensures an attacker can't forge their own software update. Public-private cryptography is typically used to establish a chain of trust.

There are many more software engineering principles, but those are some of the main principles that must be considered when supporting updates over the air.

The primary reason I believe FCA can't update the PCM/TCM/BCM/?CM over the air is because their current design does not support a two-phase commit. Specifically, they don't have a way to safely rollback the the firmware if power is interrupted in the middle of the update. You could disconnect the battery at any time, so FCA can't guarantee the update will complete before it is committed. Even if FCA shows a message on the dashboard that says "Update in progress: do not disconnect the battery," you may not see the message, or you could intentionally ignore it. If power is lost during the update, the control module will most likely be bricked, and FCA doesn't want to accept that risk.

Tesla has shown it is possible to securely and reliably update vehicles over the air, but they engineered that feature into their vehicles from the beginning.

Having said all that, I would love to be proven wrong because I would like to receive control module updates over the air, but I also want to be able to pick-and-choose which updates get installed so my custom tunes and settings won't be clobbered unexpectedly.

 

[User_1648]

Fascinating explanation @thestuarts! Thank you from a closet techie.

 

[elephantrider]

yah, fantastic explanation for sure ! thanks for sharing that.

 

[MikeXM]

I keep reading that uconnect is on a distinct network than the truck control modules so that an attack over-the-air can't shutdown the truck. And I sincerely hope this is true.
So, it would also means there is no way for the uconnect to update the truck modules as there is no communication in between.

 

[thestuarts]

I keep reading that uconnect is on a distinct network than the truck control modules so that an attack over-the-air can't shutdown the truck. And I sincerely hope this is true.
So, it would also means there is no way for the uconnect to update the truck modules as there is no communication in between.

I've heard the same claims, and that would make sense for maximum security, but the one datapoint that seems to contradict that belief is that it is possible to start/stop the car over-the-air. So, there seems to be a limited set of commands that can cross the security gateway boundary.

In a month or so, I want to reverse engineer the firmware in the various control modules. If we can build up a library of control module firmware versions, we can accurately determine what changed in each release.

 

[Brutal_HO]

I've heard the same claims, and that would make sense for maximum security, but the one datapoint that seems to contradict that belief is that it is possible to start/stop the car over-the-air. So, there seems to be a limited set of commands that can cross the security gateway boundary.

In a month or so, I want to reverse engineer the firmware in the various control modules. If we can build up a library of control module firmware versions, we can accurately determine what changed in each release.

I have the hard copy of the full Vehicle Scan report from my last visit. Though mine is probably very up to date.

If I can keep my home desktop/server up long enough* to scan the pages, I could post it up on my Onedrive and send you a link.

* Still chasing if this is a hardware or software problem. It won't stay up long enough to finish syncing the mirrored drives or to let me continue testing CPU/Ram. About ready to kick it to the curb.

 

[MikeXM]

I've heard the same claims, and that would make sense for maximum security, but the one datapoint that seems to contradict that belief is that it is possible to start/stop the car over-the-air. So, there seems to be a limited set of commands that can cross the security gateway boundary.

In a month or so, I want to reverse engineer the firmware in the various control modules. If we can build up a library of control module firmware versions, we can accurately determine what changed in each release.

There is a difference between a communication port / LAN / Bus and discrete signals. They sure can force the truck to stop or unlock using only discrete signals between the uconnect and relevant module as this is by design (for convenience). But in no case can these be used to reprogram or access the code. It is not physically possible. So the truck can't be compromised more than the exact functions you already assigned to those lines.

A bad example would be forcing the accelerator pedal to WOT remotely by software. That would be insane if possible. You never want that to be possible by hacking the software remotely. Hence why they isolated the uconnect from the other modules.
I trust the limited (for convenience functions) are wrapped around discrete signals and therefore limited in hacking.

 

[thestuarts]

There is a difference between a communication port / LAN / Bus and discrete signals. They sure can force the truck to stop or unlock using only discrete signals between the uconnect and relevant module as this is by design (for convenience). But in no case can these be used to reprogram or access the code. It is not physically possible. So the truck can't be compromised more than the exact functions you already assigned to those lines.

A bad example would be forcing the accelerator pedal to WOT remotely by software. That would be insane if possible. You never want that to be possible by hacking the software remotely. Hence why they isolated the uconnect from the other modules.
I trust the limited (for convenience functions) are wrapped around discrete signals and therefore limited in hacking.

You are definitely correct, in principle, but the reality is mistakes can be made in the design. For example, the Tesla was hacked over WiFi.

First Tesla Model S remotely controlled by hackers, Tesla already pushed a fix

Connected cars are often talked about for their potential vulnerabilities to hackers. The idea that someone could cause an accident...

electrek.co

Here is a video demonstrating the hack. At 6:49, they demonstrate manipulating the pedals from 12 miles away.

 

[MikeXM]

My take on this is there is so much software that needs to be updated in a Tesla that this is one where all systems had be updatable remotely. They had no other choice and this is by design. And the greater benefit is they could deploy basic autonomous self driving functionality via a simple OTA update. That is cool.

But I hope the "traditional" vehicles are not built like that.
This is all my assumptions based experience in the industrial controls field and simple logic. I don't think RAM thought it was necessary to make it updatable like a Tesla with all the bad things that come with it. But again, I don't have specific knowledge of car design and manufacturing.

Just like I trust the Users' WiFi service in an airplane is 100% physically isolated from the airplane control systems.
But again, Boeing as proven a lot of people wrong...

 

[thestuarts]

My take on this is there is so much software that needs to be updated in a Tesla that this is one where all systems had be updatable remotely. They had no other choice and this is by design. And the greater benefit is they could deploy basic autonomous self driving functionality via a simple OTA update. That is cool.

But I hope the "traditional" vehicles are not built like that.
This is all my assumptions based experience in the industrial controls field and simple logic. I don't think RAM thought it was necessary to make it updatable like a Tesla with all the bad things that come with it. But again, I don't have specific knowledge of car design and manufacturing.

Just like I trust the Users' WiFi service in an airplane is 100% physically isolated from the airplane control systems.
But again, Boeing as proven a lot of people wrong...

I agree FCA most likely put considerable engineering effort into security the gateway between the UConnect and the CAN bus, but mistakes can be [and often are] made.

I know this explanation could be considered off-topic for a Ram truck forum, but I'm trying to explain how it relates to the security gateway in the Ram trucks. I will give a few real-world examples of systems that were designed to be secure and how hackers figured out how to circumvent the security. I'm not divulging anyone's security secrets because these are all public knowledge.

Example 1: The Sony private key leaked
Sony uses uses public-private key cryptography to encrypt and sign data. In the PS3 era, Sony made a very simple mistake when they were generating their public-private keys, but the mistake enabled hackers to calculate Sony's private key using simple algebra. Once attackers discovered Sony's private key, they were able to create PS3 updates and content that looked legitimate to the PS3. Sony did their best to recover from this security incident, but it was too late. This example is relevant to the Ram truck because I strongly suspect that the command to start your truck remotely is digitally signed and encrypted by FCA before it is transmitted to your truck. The security gateway verifies the signature and decrypts the start/stop request then sends the start/stop command to the proper control module. If FCA made a mistake similar to Sony's mistake, it might be possible to forge a start/stop command and send it to any vehicle.

Example 2: Side channel-attack to discover the Xbox optical disc drive authentication key
The optical disc drive in the Xbox is "paired" with the Xbox motherboard by a symmetrical key that is stored in the Xbox flash and in the optical disc drive flash. The system was designed so that attackers should not be able to extract the symmetric key out of either the Xbox flash or the optical disc drive flash. However, an attacker used an electromagnetic inteference side-channel attack to discover the symmetric key. The Xbox flash and the optical flash were not compromised directly, but the key was leaked just the same. This enabled attackers to replace an Xbox optical disc drive with a drive that has custom firmware that enables piracy. Someone might be able to use a side-channel attack to reverse-engineer the Ram firmware and discover exploits.

Example 3: The JTAG interface was accidentally left enabled on the early Xbox 360's
The JTAG interface is used to debug hardware while it is being developed. In some applications, it is desirable to leave the JTAG interface enabled so hardware can be debugged in the field, but the Xbox 360 was not intended to be field serviceable, so the JTAG interface should have been disabled in the retail console, but it was accidentally left enabled (after doing a simple modification). This enabled an attacker to debug the Xbox operating system to find other exploits. FCA could have made a mistake that makes it possible to debug their system which could lead to the discovery of exploitable software bugs. A real example is there is a protocol called UDS that most ECU's implement. UDS supports a "ReadMemoryByAddress" command that can be used to read memory out of devices on the CAN bus. The ReadMemoryByAddress command should be disabled or protected with the security gateway, but in most ECU's it isn't, or it is protected with a simple security challenge that can be brute forced. An attacker might be able to use the ReadMemoryByAddress command to read the firmware of each control module then analyze the firmware for bugs that can be exploited.

Example 4: Row-hammer memory attack
Row-hammer is a security exploit that relies on a side-channel attack to certain types of memory. The attack enables someone to read or even write to memory that is normally protected by a hypervisor, kernel, or (in some cases) a Soc (security-on-chip).

Example 5: Software bugs galore
There are countless ways software developers can accidentally introduce security flaws: buffer overruns, buffer overruns, use-after-free, stack overflow, insufficient (or nonexistent) input parameter validation, and many more. Even though the security gateway is designed to ensure only authenticated commands make it through the gateway, one mistake could make it possible to send undesirable commands through the security gateway. One recent example of a very bad bug that enabled a security exploit is the "heartbleed" bug. It enabled an attacker to remotely read the memory of a system 64Kb at a time. With enough reads, it was possible to reconstitute large ranges of memory which often contained passwords, encryption keys, and code that could be analyzed for security bugs.

Example 6: Hardware bugs
Hardware devices are not immune to bugs. Some of the more recent, prominent hardware exploits are listed here. A hardware exploit can be used to obtain the firmware which can be analyzed for software bugs that can be exploited remotely.

Example 7: Rogue employee
Sometimes, systems are secured by security that relies on human honesty. If just one employee decides to leak the source code, it can be analyzed for security exploits. There are many real-world examples of this happening.

Countless systems have been designed to be secure, but they were eventually compromised. The good news is, one of the systems I was partly responsible for securing is still not hacked. The Xbox One still hasn't been hacked! If you want to know more about how we secured the Xbox One, please watch this hour-long video that goes into low-level detail.

 

[thestuarts]

I recently purchased a Tech Authority USB drive with supplemental information on my 2019 Ram 3500. The documentation confirms the radio and the CAN bus are linked together through the security gateway. The radio is not physically separated from the CAN bus, so if the security gateway has any security flaws, it would theoretically be possible to control the vehicle from over-the-air.

---------

08 - Electrical / 8E - Electronic Control Modules / MODULE, Security Gateway (SGW) / Description
DESCRIPTION AND OPERATION
DESCRIPTION

The SGW module is a security hardware device to stop unwanted access and threats to the Controller Area Network (CAN) for the vehicle. The SGW module does not contain any drivers and therefore does not directly operate or control any vehicle components.

The complexity of in‐vehicle networking has led to the development of a variety of bus standards and protocols that are specific to their communication domains. The SGW module serves as the information bridge between these communication domains and the diagnostic scan tool and the radio. Hardware security features of the SGW module are used to prevent unauthorized bus network access.

The SGW module is flash programmable. Failure to flash a newly installed SGW module will leave it in a locked mode. When in the locked mode, the SGW module will not operate.

OPERATION

The SGW module, located on the CAN architecture between the Data Link Connector (DLC), telematics module and the radio, prevents threat to the CAN bus systems through the DLC and the radio access points. A secure connection must be present to allow authentication between the SGW module and the diagnostic scan tool. The SGW module contains up to eight dual wire CAN bus channels that comply with the industry standard CAN-Flexible Data-rate (CAN-FD) bus architecture. The SGW module does not support partial networking functionality. Since the SGW module is a frame gateway, it also does not provide signal gateway functionality.

 

[Burn'n Oil]

The radio is not physically separated from the CAN bus, so if the security gateway has any security flaws, it would theoretically be possible to control the vehicle from over-the-air.

Sadly, there will always be malcontent/s eager to exploit potential security flaws. It's a perpetual battle front.

 

[MikeXM]

The documentation confirms the radio and the CAN bus are linked together through the security gateway. The radio is not physically separated from the CAN bus, so if the security gateway has any security flaws, it would theoretically be possible to control the vehicle from over-the-air.

Well, obviously., I should have known better. It's like anything else built these day... No regards to security or reliability and just hope for the best.

 

[GotDiesel]

Thank you all for the discussion, I'm a trained geek, and a Paramedic. I find this information very relevant. As to the security and how various updates are designed to work. In my current truck 08 Duramax there are 22 computers in the truck, 11 alone dedicated to the operation of the engine and transmission.
Even to the folks that do not understand / have a deep interest in this topic, it does provide some illumination to the potential for bad things to happen. As computer processors continue to be implemented in many devices, the threat of malware/hacks becomes very real.
Cybersecurity is overlooked until something bad happens, much like being a Paramedic we are not really valued until they get sick or hurt, we then become immediately relevant.
GotDiesel

 

[startrek]

Just wrap it in tinfoil.

Really ?

 

[Burn'n Oil]

Really ?

"Beam me up, Scotty!"

 

[Brutal_HO]

Really ?

Really ?

I hope you're not wearing a red shirt.

Be advised, I'm 37% Irish and 63% Sarcasm.