Truck Hacking: An Experimental Analysis of the SAE J1939Standard

Yelizaveta Burakova, Bill Hass, Leif Millar, and Andre Weimerskirch

The University of Michigan{ybura, billhass, ltmillar, andrewmk}@umich.edu

Abstract

Consumer vehicles have been proven to beinsecure; the addition of electronics to monitorand control vehicle functions have added com-plexity resulting in safety critical vulnerabili-ties. Heavy commercial vehicles have also begunadding electronic control systems similar to con-sumer vehicles. We show how the openness of theSAE J1939 standard used across all US heavyvehicle industries gives easy access for safety-critical attacks and that these attacks aren’t lim-ited to one specific make, model, or industry.

We test our attacks on a 2006 Class-8 semitractor and 2001 school bus. With these two vehi-cles, we demonstrate how simple it is to replicatethe kinds of attacks used on consumer vehiclesand that it is possible to use the same attack onother vehicles that use the SAE J1939 standard.We show safety critical attacks that include theability to accelerate a truck in motion, disablethe driver’s ability to accelerate, and disable thevehicle’s engine brake. We conclude with a dis-cussion for possibilities of additional attacks andpotential remote attack vectors.

1 Introduction

Although academic research has shown vul-nerabilities in consumer automobiles as early as2010 [12], the general public has only recentlybeen made aware of such vulnerabilities throughmedia reports in 2015. Now, both industry andconsumers are paying more attention to the se-curity of their own cars. However, not much hasbeen said or done in public about the heavy ve-hicle industry.

All modern heavy duty trucks and busesin the United States use the SAE J1939 Stan-dard (J1939) for their internal networks. Moti-vation for J1939 stems primarily from a desire

to electronically control drivetrain componentsof a vehicle, which is typically the core compo-nent of a concerted effort to maximize fuel effi-ciency. Because so many different organizationsare involved in the building of heavy vehicles, astandard was needed to minimize engineering ef-fort and the complications of integrating systems.J1939 is not the first standard for heavy vehicles,but rather is the successor of the SAE J1587 andSAE J1708 standards. While standardizing thesecommunications has proven crucial in allowingvarious suppliers and manufacturers to work to-gether and cut costs, it also means that all heavyvehicles currently on the road in the US, fromsemi tractor-trailers to garbage trucks and ce-ment mixers to buses, utilize the same communi-cation protocol on their internal networks.

Heavy vehicles play an important role inour nation’s economy. In 2002, the value offreight shipments was $11 trillion, of which truckshauled 64% [3], and there were over 6.5 millionheavy trucks in fleets in the United States in2013 [20]. While physically different from con-sumer automobiles in many ways, heavy vehi-cles are similar internally in that they are com-posed of a distributed system of electronic con-trol units (ECUs) that communicate over a CAN-based network.

Additionally, as with cars, the trend forheavy vehicles is to move away from purely me-chanical systems towards more electronically con-trolled ones thanks to the promise of fuel effi-ciency, driver comfort, and safety. For exam-ple, heavy trucks are mandated in the US toemploy electronically controlled anti-lock brake,anti-slip regulation, and active rollover protec-tion systems. Furthermore, active lane keep as-sist, collision avoidance, and adaptive cruise con-trol systems are available, and a couple compa-nies are even touting their autonomous trucking

capabilities [2]. These systems bring electroniccontrol to safety critical components which ne-cessitates a focus on robustness, reliability, andsecurity.

Heavy trucks are typically part of a largerfleet of vehicles which are monitored overlong distances using fleet management systems(FMS). The FMS standard is a worldwide stan-dard developed in 2002 which combines satelliteand cellular communication to provide informa-tion about vehicle location and status. Some sta-tus messages defined by FMS include vehicle anddriver identification as well as the state of theelectronic engine controller, cruise control mod-ule, and fuel levels [6]. The FMS standard en-ables third party systems to integrate with theAPI across manufacturers which is a nice ben-efit for fleet owners, but as we’ve seen in theconsumer segment, third party devices don’t al-ways prioritize security [4]. In fact, a blogpost inMarch, 2016 [16] revealed over 1,500 third partyfleet management systems with connection to thevehicle’s internal network whose Telnet port waswide open. This indicates a viable long-range at-tack surface on heavy vehicles.

In this paper, we focus on what an adver-sary can accomplish physically connected to theinternal network, and analyze the impact of inse-cure ECUs in heavy vehicles that use the J1939standard. This is a topic of concern to manyagencies and parties, including various govern-ment agencies, heavy vehicle manufacturers, thefreight industry, and of course the general public.Our goal was to experimentally analyze the secu-rity of the J1939 protocol and determine whetherheavy vehicles are more or less secure than con-sumer automobiles.

1.1 Contributions

We are the first to experimentally demon-strate that heavy vehicle networks are vulnera-ble to attacks similar to those implemented onconsumer car networks. A strength of our workis that by focusing on the J1939 standard, ourresults can be applied to all vehicles using thatstandard. We summarize our contributions asfollows:

1. Using publicly available information of acommon, standardized vehicle network, weshow that it is possible to mount safety crit-ical attacks.

2. We demonstrate that safety critical systemsare vulnerable to an adversary with accessto the vehicle’s internal network through thediagnostics port.

3. We verify that attacks developed on a semi-tractor also work on a bus, providing evi-dence that all heavy vehicles with the J1939standard are affected.

4. We provide an outlook on further attacksthat are highly likely to be successful andgive recommendations for future areas of re-search.

1.2 Overview

We first cover related work, provide termsfrom the heavy vehicle industry, and present atechnical overview of CAN and J1939 in Section2. Then, in Section 3 we describe our threatmodel, and Section 4 covers our methodology.We present our results in Section 5, followed by adiscussion of the individual attacks. We end withfuture work in Section 6 and give our conclusionin Section 7.

2 Background

2.1 Related Work

Recent attention has been paid to consumerautomobile security thanks to several prominentdemonstrations of vehicle vulnerabilities on anunnamed car in 2010 [12], a Toyota Prius andFord Escape in 2014 [14], and a Jeep GrandCherokee in 2015 [15]. Notably, exploits werefirst developed and reported using a physical con-nection to the vehicle’s internal CAN networkthrough the car’s on-board diagnostics (OBD-II)port, as is the case in 2010 and 2014. Follow upresearch to the 2010 report by some of the sameauthors in 2011 [13] demonstrated a wide arrayof remote exploits thanks in part to buffer over-flows at the remote interfaces and a general lackof security on behalf of the vehicle system en-gineers. Similarly, the 2015 vulnerabilities wereextensions of the authors’ prior research in 2014,which showed they were able to remotely con-trol the vehicle across the country over a cellularnetwork. In a similar manner, we wish to firstexplore the capabilities of an adversary with aphysical connection to the heavy vehicle’s inter-nal network via the OBD port.

2

2.1.1 Terminology

Before we begin, we will define a few termsfrom the heavy vehicle industry.

• Control Area Network (CAN) Bus - Thestandard method of communication for elec-tronic modules in automobiles. The mostcommon CAN bus configuration is a twistedpair of wires which are connected to eachmodule in the vehicle that needs to send orreceive data to other modules.

• CAN Message / Frame - A completeCAN2.0B packet that contains various head-ers, an 8 byte data payload, which itselfis composed of several signals, and variousfooters as specified by ISO 11898.

• CAN Signal - An individual piece of informa-tion which is contained in the data payloadof a CAN message. It can be one or manybits in length.

• Electronic Control Unit (ECU) - One ofthe numerous electronic modules that collec-tively constitute the distributed control sys-tem of the vehicle.

• Foundation / Service Brake - The physicalbraking mechanism at the wheel ends or axlewhich uses friction to cause the truck to de-celerate.

• Engine Brake - On heavy vehicles, an im-portant aspect of braking is the use of theengine to slow down the vehicle. This is es-pecially important when going downhill, asusing foundation brakes for this task wouldquickly cause the brakes to overheat. Whenthe brakes overheat, not only do they wearsubstantially faster, but more importantly apartial or total loss of braking results (Alsoknown as brake fading).

• Original Equipment Manufacturer (OEM) -The manufacturer of the end product. Therelationship between OEM and suppliers iscomplex. Examples from automotive includeFord, Kenworth, Mercedes-Benz, and Gen-eral Motors.

• Supplier - Companies that supply OEMswith various parts or services. Suppliers maysell raw materials, individual parts, or an en-tire system they have designed and devel-oped.

• Gross Vehicle Weight Rating (GVWR) - TheGVWR is a commercial vehicle classificationused in the United States based on the max-imum loaded weight, ranging from Class-1to Class-8. A Class-8 truck is classified asa truck whose GVWR exceeds 33,000 lbsand requires a Class-A commercial driver’slicense to operate.

• Commercial Driver’s License (CDL) - Thedriver’s license that is required to operateheavy vehicles.

2.2 CAN Protocol

The CAN standard was first developed atRobert Bosch GmbH in 1983 for the purpose ofnetworking various electronics modules withoutthe need for a dedicated computer in automo-biles.

The original standard was specified in ISO11898, which defines the physical and data linklayers of the CAN protocol. The most commonphysical layer describes a two wire differentialbus, one high and one low voltage wire, termi-nated at both ends by a 120-ohm resistor andconnected at each node to a transceiver. Thewires are typically twisted together, which givesthe bus a high tolerance for interference as bothwires will experience the same level of distor-tion, leaving the voltage difference between thetwo wires largely unaffected. The data link layerusually consists of a peripheral micro-controllerthat implements arbitration and packet framingin hardware which is controlled by the host pro-cessor.

Data is sent using frames which are also de-scribed in the specification. These packets in-clude a priority identifier, data length, data pay-load, error detection bits, and an ACK bit. Thepriority ID and data bytes are the primary com-ponents of the frame which can be controlled bythe host controller. The original specificationonly allows for up to 8 bytes of data per frameand an 11 bit ID. Since the release of CAN2.0B in1991 [5], an extended frame format was definedthat allows for a 29 bit ID. The extended frameformat can be seen at the top of Figure 1a. Re-cently, CAN-FD was defined which inter-operateswith CAN2.0B and allows up to 64 bytes of dataper frame. Larger frames will one day enable theability to include message authentication codeswith the data, but it will be at least several yearsuntil CAN-FD is widely adopted.

3

(a) Full CAN frame with 29-bit ID broken down for J1939 protocol

(b) Example SPN layout for the “Engine Temperature” PGN

Figure 1: Diagrams that describe the J1939 identifier and data fields [21]

The messages sent on the bus dependgreatly on the make and model of the vehicle.For example, the messages sent on consumer ve-hicle networks are proprietary to the OEM thatdesigned that particular vehicle and kept secret.Often times the message formats will change, notonly from model to model within an OEM, butalso from year to year. For this reason, deci-phering consumer vehicle network traffic involvesthe tedious process of reverse engineering anymessages observed on the bus to determine theirfunction.

2.3 J1939 Protocol

The SAE J1939 standard describes the ve-hicle bus used in heavy vehicles such as buses andsemi-trucks. J1939 defines five of the seven lay-ers of the OSI model, with CAN2.0B being usedfor the physical and data-link layers [11]. The 29bit ID encodes a 3 bit priority, 18 bit ParameterGroup Number (PGN), and 8 bit source address,as seen in Figure 1a. The PGN is a message iden-tifier that specifies which signals are contained inthe data payload. In most cases, the data sent fora given PGN consists of 8 bytes, but if a PGN

requires more data, a set of transport protocolmessages can be used to send up to 1,785 bytesfor a given PGN. The data bytes are grouped us-ing Suspect Parameter Numbers (SPNs) whichdefine what the data means. An example of howPGNs and SPNs relate is shown in Figure 1b .

The J1939 standard is open and used acrossmany industries that employ diesel engine vehi-cles, such as bus and train transportation, con-struction, agriculture, forestry, mining, and themilitary [18]. This is a very different model fromOEM’s proprietary application level CAN proto-cols which change across make, model, and modelyear and are heavily guarded secrets within theOEMs.

The openness of J1939 allows anyone whocan make a payment receive technical detailsabout standard PGNs, allowing a potential ad-versary to easily gain the knowledge necessaryto attack safety critical components. PGNs0x00FF00 through 0x00FFFF are reserved forproprietary use, but every attack described inthis paper uses standard PGNs that are the samefor different vehicles. Interesting messages thatare part of the standard include brake, engine,

4

transmission, and cruise control. These messagescould lead to similar vulnerabilities as seen inthe consumer automotive sector. A recent NSFGrant for a J1939 security testbed in Jan. 1,2016 [17] suggests government and heavy truck-ing industry are starting to analyze the securityimplications of the standard.

We provide supporting evidence in Section4 to say that attacks developed for the J1939 pro-tocol can potentially be used across a wide vari-ety of vehicles. While there may still be slightimplementation differences from supplier to sup-plier and some vehicles won’t have certain fea-tures implemented, we hypothesize that most ba-sic attacks will work for any vehicle that uses thisstandard.

3 Threat Model

In contrast to the consumer car segment,there is more incentive for an adversary to at-tack the heavy vehicle industry due to the size ofthe vehicles and the variety of goods they carry.The biggest motivation for an attacker is usuallyfinancial, and the freight transportation indus-try contributes nearly 10 percent of the UnitedStates GDP [19]. When you add other poten-tially affected industries such as construction andagriculture, that number only goes up. So our ad-versary can be anyone who could stand to makea profit off manipulating the vehicles, be it fromhijacking their goods, adversely manipulating acompetition’s fleet, extorting fleet owners anddrivers, or selling their tools and services on theblack market. Another type of adversary we con-sider is one who wishes to cause the most harmand damage as possible, such as a terrorist ornation state.

We assume that our adversary has the abil-ity to transmit arbitrary messages on the ve-hicle’s J1939 bus. This is most readily ac-complished with physical access to the vehiclethrough the OBD port. Given that CAN hard-ware is common and easy to obtain, we can as-sume that someone with physical access also hasaccess to the correct hardware. With a smallenough dongle, an adversary with brief physicalaccess could gain persistent access to the vehicle’sbus since the OBD port is commonly located outof sight under the dash and is not part of theCDL pre-trip inspection. Alternatively, a moresophisticated attacker could inject malware intoother ECUs on the network leaving no external

trace anything is amiss. A common argument tothe physical assumption is that an adversary canalready cut the brakes or loosen some nuts withphysical access, but we think that argument takesa nearsighted view of the threat model. With afoothold in the car’s internal network, vehicle sta-tus or external events can be monitored to trig-ger various behaviors, and the software can avoidforensic analysis by erasing itself.

While our research focused on direct phys-ical access through the OBD port, there are acouple other attack vectors common to heavyvehicles that are worth mentioning. First, isthe trailer in a semi tractor-trailer configuration.Typically, there is a bridge between the J1939network and the trailer network as can be seenin Figure 2, which if exploited could be a viableattack vector. Second, are fleet management sys-

Figure 2: Tractor-trailer network configuration

tems (FMS) which can be found in many com-mercial vehicles. They are used by fleet ownersto wirelessly track and log various statistics of agiven fleet, from GPS, speed, and brake usage tonotifications in the case of an accident or airbagdeployment. FMS should be read-only from theJ1939 network, but they are complex systemswhich could provide a wireless attack vector.

It’s reasonable to assume that given a phys-ical exploit, a remote exploit will soon follow.Many cases of remote attacks in the consumervehicle space derive from physical exploits [13,15, 4]. There has even been at least one docu-mented vulnerability of hardware that is specif-ically used in trucks today [16]. This particu-lar security flaw was due to an open Telnet portaccessible without authentication on the publicIP space. It’s not news that embedded deviceshave open ports [1], so we can reasonably expectthat this is not the only instance of a telemat-ics unit with an exploitable default configuration.Like FMS, telematics units are used widely in thetrucking industry to track vehicles and many areconnected to CAN to report diagnostics back tothe base.

It takes more sophisticated knowledge ofthe protocol to understand what messages to

5

modify or send in order to get some kind of de-sired behavior, but the fact that J1939 is an openstandard means that anyone with enough techni-cal skill can craft attacks before even connect-ing to a vehicle. This differs from consumer ve-hicles, where the proprietary CAN standard re-quires significant reverse engineering and narrowsthe possible attackers to people with access to thespecific vehicle’s protocol version. On top of that,an adversary attacking consumer vehicles wouldneed to modify their attack for different modelsof cars, whereas an attack on heavy vehicles canremain unmodified and work on a variety of ve-hicles, from trucks to buses.

4 Methodology

All of our experiments specifically exploitmessages present in J1939 without the use ofbackdoors or software vulnerabilities. We fo-cused primarily on a Class-8 2006 model yearsemi tractor, and we had limited access to a 2001model year school bus. Since both use the J1939standard, our hypothesis was that the exact sameattacks should work on each vehicle, and on anyother vehicle that uses the standard. All of ourattacks were first developed on the semi truckwhile idling in neutral with the parking brakeapplied, then tested on a closed track with a cer-tified CDL driver while the truck was driven un-der normal conditions. Then, for each of our suc-cessful attacks, we also tested them unmodifiedagainst the school bus while parked and idling tocheck our hypothesis.

Our test setup is pictured in Figure 3. Weconnected a laptop to the Vector and PEAK toolsdescribed in Section 3.1 which were connected tothe J1939 OBD port via a Y-cable in order to col-lect and transmit data. The CANoe applicationproved to be the most useful for packet snoop-ing thanks to a publicly available CommunicationDatabase (DBC) file which enabled messages tobe parsed and inspected in real-time based onthe J1939 standard. We were quickly able toidentify PGNs that controlled various functionsof the truck as we manipulated them from withinthe cabin. The PEAK tool on the other hand wasmuch easier to use for packet injection thanks tothe simple, intuitive user interface. By injectingpackets with the PEAK tool and snooping withthe Vector tool, we were able to easily verify ourinjected messages.

In order to gather data while the truck was

Figure 3: Example setup for experimentation.

under normal driving conditions, we used pub-lic roads due to the limited availability of test-ing facilities. For these tests, we put our toolsinto listen-only mode so no data packets couldbe injected onto the CAN bus. These sessionswere aimed at gathering data only to be storedfor later analysis. Once we had collected thatdata, we went back to the parked and idle setupto replay the sequence of messages we recorded.Using this method, we discovered a reaction bythe powertrain and other electronic systems.

Finally, we needed to test our attacks whilethe truck was in motion in order to realizethe true impact of our findings. For this, weused MCity - The University of Michigan Mobil-ity Transformation Center’s 32-acre closed-coursetest track. All of the experiments were carriedout at low speed on a slight uphill gradient withlarge roundabouts at either end so that the vehi-cle could be put in neutral and coast to a stop incase of an emergency.

4.1 Tools

We used a variety of diagnostic tools to an-alyze the bus traffic and inject our own packets.All of these tools are available to purchase andare designed for the typical mechanic or engineerto use.

Vector CANoe

The Vector CANoe is a high-cost, industry-standard CAN analysis and simulation softwaretool. It uses a hardware interface device whichallows the user to interface via USB with var-ious CAN protocols such as the J1939 standardor other proprietary protocols that use CAN. Thesoftware application allows the user to snoop andrecord CAN traffic, inject and replay CAN mes-sages, and write scripts for efficiently describing

6

complex interactions with modules on the bus.It uses a proprietary C-like event-driven script-ing language called CAPL. The application layerCAN protocols can be described in the DBCwhich can then be imported to CANoe for real-time identification of the CAN messages and sig-nals on the bus, as well as for easier creation ofscripts.

We used CANoe for data gathering, and ourmore sophisticated attacks were implemented inCAPL and executed using the CANoe system.

PEAK USB-PCAN

The PEAK tool is a low-cost alternative tothe Vector tool. It is similar in that there is asoftware application and hardware device thatinterfaces between CAN and USB. Its free appli-cation, PCAN-view, has fewer features, but it isalso more intuitive and works very well for sim-ple tasks. PEAK provides a set of libraries forinterfacing with PCAN APIs which we used withPython to create a fuzzing script [7] which enu-merates all possible data and ID fields. Priorresearch has had success with such fuzzing meth-ods, but we have not. Additionally, the lackof database files which describe the identifica-tion and purpose of various messages makes fora much less straightforward experience with thePEAK tool.

The PEAK tool was used for data gath-ering, especially while using CANoe, and ourearlier, simple attacks were implemented withPCAN-view and the PEAK tool.

Diagnostics Tool

The generic diagnostics tool we used hadcapability to retrieve diagnostic codes and gen-eral status information about the semi truck itis connected to. It uses a standard J1939 OBDconnector and is used primarily by mechanics forECU diagnostics. We found that the softwarealso has the option to update ECUs and cut offeach of the six engine cylinders, one cylinder ata time, and we found a freely available softwaremodule from the ABS manufacturer’s website forthe generic diagnostics tool which enabled us toactuate the ABS valves on the wheel ends.

We used the diagnostic tool to setup diag-nostics sessions and perform various diagnosticstasks while logging the messages with CANoe viathe Y-Cable.

5 Results

We find that an adversary with network ac-cess can control safety critical systems of heavyvehicles using the SAE J1939 protocol. The spe-cific message PGNs for each behavior are listed inTable 1. The instrument cluster attack requireddifferent PGNs to control each gauge, whereas wefound we could get a lot of control from the truckby changing the SPNs within the torque/speedcontrol 1 (TSC1) message. Not only is the TSC1message a public PGN, but the documentationprovides a detailed overview of the purpose ofthe different SPNs associated with it, making thispowerful attack relatively easy to replicate.

5.1 Instrument Cluster

By spoofing the status messages that orig-inate in various ECUs of the truck, we wereable to control all gauges on the instrument clus-ter, which include oil temperature, oil pressure,coolant temperature, RPM, speed, fuel level, bat-tery voltage, and air pressure of the foundationbrake system. [8] The temperature, oil pres-sure, air pressure, fuel level, and battery voltagegauges all cause an alarm to sound accompaniedby a bright red light at each gauge when the read-ing goes above or below a certain point, and in allcases we were able to make the gauges go beyondsaid thresholds, causing the alarm to sound. Ourcontrol was precise, we could make the gaugespoint to the value of our choosing - even whilethe truck was in motion. This attack did notwork on the 2001 model year bus.

For the safety critical rating, we deemedfuel level, battery, and RPM as non-critical be-cause the driver has other indicators which can berelied on such as odometer and engine noise. Forspeedometer, oil pressure, and temperature, wegave a low rating because they are harder to ver-ify by the driver and could put the driver or othervehicles on the road in a dangerous situation ifthe underlying system fails. The service brakepressure has moderate severity because the driverhas no other indicator and needs to know the airpressure to avoid activating the emergency brakesystem which would lock up all of the wheels.

5.2 Powertrain

The powertrain attack was somewhatharder to discover, but just as straightforwardto implement. By replaying a sequence of cap-tured messages that we recorded during normal

7

Attack Messages

Behavior PGN Acronym Safety Critical

Set Oil & Coolant Temperature Gauges 0xFEEE ET1 Low

Set Oil Pressure Gauge 0xFEEF EFl/P1 Low

Set Service Brake Pressure Gauge 0xFEAE AIR1 Moderate

Set Speedometer Gauge 0xFEF1 CCVS Low

Set RPM Gauge 0xF004 EEC1 —

Set Battery Gauge 0xFEF7 VEP1 —

Set Fuel Level Gauge 0xFEFC DD1 —

Increase Engine RPM 0x0 TSC1 High

Decrease Engine RPM 0x0 TSC1 High

Disable Engine Brake 0x0 TSC1 High

Table 1: List of PGNs and attack severity

driving conditions, we observed the engine RPMincrease in a specific pattern. There were elevenunique PGNs that repeated at various intervalsrelated to the engine within that sequence, lead-ing us to believe it was a complex interaction ofmessages causing the RPM to spike. However, byshrinking the sequence and probing with specificmessages we were surprised to find that just onePGN, TSC1, enabled powertrain control. [10]

According to the specification, the TSC1message is used for engine control and retard-ing by various ECUs, such as accelerator pedal,cruise control, or power take-off governor. It isreceived by the engine or retarder and commandsa given RPM value if speed control mode is speci-fied or percentage of torque output if torque con-trol mode is specified. We ran further experi-ments while idle and found that by injecting theTSC1 message with a specified RPM in speedcontrol mode we could physically command theengine’s RPM to that specific value. Torque con-trol mode behaved similarly, but a specific RPMvalue was harder to hit.

After seven seconds of continuous control,the engine wouldn’t obey our messages and re-turned to idle, but we quickly overcame this lim-itation by pausing for 40ms before the seven sec-ond timeout expired, then repeating. With just a40ms pause, we could indefinitely hold the RPMto a given value. We did not try to blow the en-gine. This attack also worked while idle without

modification on the 2001 model year school bus.[9]

We developed a set of messages that ex-ercised edge cases of various signals within theTSC1 message for testing on MCity while driv-ing. By commanding the RPM to any value inspeed control mode, we were able to override thedriver’s input. If a high RPM value was issued(e.g. 3000 RPM) we caused the truck to veryquickly accelerate to max out the speed providedby the currently selected gear. This attack didn’twork while the truck was completely stopped orrolling backwards down an incline, but it didwork if the truck was rolling forward. By com-manding the torque percentage to a low value(e.g. 0%) in torque control mode, we were ableto override the driver’s input to the accelerator ashe was actively accelerating causing the truck’sengine to idle; effectively cutting off the engine.This even prevented the driver from acceleratingfrom a standstill. The TSC1 message also hadother side effects explained in the engine brakesection below.

To summarize, we were able to override thedriver’s input to the accelerator pedal and simul-taneously cause either direct acceleration or re-move the ability to provide torque to the wheelswhile the truck was in motion. We gave both ahigh safety critical rating because the CAN mes-sage directly influences the vehicle’s engine with-out operator control; the best the driver can do

8

is brake and pull over which isn’t possible in allsituations.

5.3 Engine Brake

In addition to overriding accelerator input,the TSC1 message can be configured to disablethe truck’s ability to use engine braking at speedsbelow 30 miles per hour. When we commandedthe torque percentage to 0% while the truck’sengine brakes were actively decelerating the ve-hicle, the truck’s engine brakes let off completelyand deceleration ceased. This is dangerous be-cause engine braking is heavily relied on by heavyvehicles to save the foundation brakes from over-heating, which can lead to brake fade or total lossof braking power. Even with a 30 mph thresh-old, we still give this a high safety critical ratingbecause on long and steep winding roads a fully-loaded truck has the potential for catastrophicbrake loss.

6 Future Work

We were not able to turn every discoveryinto an attack. Here we list a few possibilities forfurther research.

Other Messages of Interest

We found additional J1939 messages in doc-umentation that seem safety critical on their own,similar to the TSC1 message, which suggest net-work control of transmission and brakes.

Diagnostic Tool Spoofing

We found that the diagnostic tool can dis-able the engine cylinders and actuate the ABSvalves through the OBD port, but these messagesare sent over the J1708/J1587 network, so futureresearch will involve determining how the requestis made, and what kind (if any) authenticationthe diagnostics tool uses.

Engine Braking

Additional research is required to investi-gate how engine braking might be disabled atspeeds greater than 30 mph.

Remote Extension

Further research is needed to determine thenumber of telematics unit models available, thesecurity measures used by different models, andthe utilization rates of attacks on models deemed

insecure. Additionally, for those models that aresecure, the level of sophistication that would berequired to bypass their security enough to writemalicious packets on the CAN bus or gather sen-sitive information.

Truck Trailers

We focused on the truck tractor in our re-search, but future work could also involve look-ing into the bus of the trailer as well. There aretheoretical possibilities a la Stuxnet of how a ma-licious trailer could affect multiple tractors. Fu-ture work is required to investigate how feasiblethis would be.

Other Industries

The scope of our experiments was limitedto two vehicles from similar industries, but wewould be interested in applying the same exper-iments to trucks and buses from different manu-facturers as well as vehicles from other industries.We have shown that an unmodified version of thepowertrain attack from a 2006 model year truckworked on a 2001 model year bus, and we believethis is only the tip of the iceberg. It would not besurprising to us to see that diesel engine vehiclesfrom agriculture, forestry, construction, locomo-tive, marine, and military industries are affectedby the same or similar attacks.

7 Conclusion

There has been a lot of prior work doneto analyze the security of consumer automobiles.However, we are the first to show that some ofthe same vulnerabilities are very much presentin the heavy vehicle industry. Similar to cars,semi trucks are designed to protect against safetyfailures, but the idea of an active attacker doesnot go into the design of the safety mechanisms.

By using publicly available information ofa popular vehicle network standard, we have de-veloped concrete examples of attacks that affectsafety-critical systems of a semi-truck and a buswhich use the same standard. Since our attacksfocus on the J1939 protocol, not the software onthe truck itself, the attacks aren’t limited to justsemi trucks, and they can be implemented on awide scale. The impact of protocol vulnerabili-ties that we showed stretches across many indus-tries in the US and abroad. We only needed onemessage to implement a series of safety-criticalattacks, and while we required physical access

9

to the internal network, it is reasonable to as-sume that a remote extension to our attacks isfeasible given how similar the vulnerabilities areto consumer vehicles and the complexity of fleetmanagement systems already widely employed.

It is imperative that the trucking industrybegins to take software security more seriously.Our attacks took us less than two months toimplement and did not require any proprietaryPGNs. It is reasonable to assume that with moretime an adversary could create an even moresophisticated attack, one that could be imple-mented remotely. With Bluetooth, cellular, andWiFi, modern trucks are becoming much moreconnected to the outside world, which presentnew attack vectors. Our hope is the heavy ve-hicle industry begins to include the possibility ofan active adversary in the design of their safetyfeatures.

8 Acknowledgements

We would like to thank the Universityof Michigan Transportation Research Institute(UMTRI) for providing access to the truck andbus, as well as the Michigan Mobility Transfor-mation Center (MTC) for allowing us to test onMCity between construction crews. Specificallywe thank Steve Stachowski and Russ Bielawskifor discussions over coffee and help getting setup, Ken Winzeler for being our CDL certifieddriver, and Regina Ferguson and Lindsey Scheerfor helping with logistics.

References

[1] Botnet, C. Port scanning /0 using insecureembedded devices. http://internetcensus2012.

bitbucket.org/paper.html, aug 2012. Accessed:2016-03-17.

[2] Davies, A. The world’s first self-driving semi-truckhits the road. http://www.wired.com/2015/05/

worlds-first-self-driving-semi-truck-hits-road/,may 2015. Accessed: 2016-02-01.

[3] Felix Ammah-Tagoe, U.S. Department of Trans-portation, O. o. T. A. Freight shipments inamerica. http://www.rita.dot.gov/bts/sites/

rita.dot.gov.bts/files/publications/freight_

shipments_in_america/pdf/entire.pdf, 2004.

[4] Foster, I., Prudhomme, A., Koscher, K., andSavage, S. Fast and vulnerable: A story of telem-atic failures. In 9th USENIX Workshop on OffensiveTechnologies (WOOT 15) (Washington, D.C., Aug.2015), USENIX Association.

[5] GmbH, R. B. Can specification version 2.0.http://www.kvaser.com/software/7330130980914/

V1/can2spec.pdf, 1991.

[6] Group, H. . B. W. Fms-standard description,version 03. http://www.fms-standard.com/Truck/

down_load/fms_document_ver03_vers_14_09_2012.

pdf, sept 2012. Accessed: 2016-04-18.

[7] Hass, B., and Burakova, Y. Pyfuzz can. https:

//github.com/bhass1/pyfuzz_can.

[8] Hass, B., Burakova, Y., and Millar, L. Videoof attack on instrument cluster. https://youtu.be/

HZmNKkdlYmM.

[9] Hass, B., Burakova, Y., and Millar, L.Video of attack on schoolbus. https://youtu.be/

nZDiCRBdSF0.

[10] Hass, B., Burakova, Y., and Millar, L. Video ofpowertrain attack. https://youtu.be/ZfXkDPU3WMQ.

[11] Junger, M. Introduction to j1939. http://vector.

com/portal/medien/cmc/application_notes/

AN-ION-1-3100_Introduction_to_J1939.pdf, 2010.

[12] Karl Koscher, Alexei Czeskis, e. a. Experimen-tal security analysis of a modern automobile. IEEESymposium on Security and Privacy (2010).

[13] Karl Koscher, Stephen Checkoway, e. a. Com-prehensive experimental analyses of automotive at-tack surfaces. Usenix Security (2011).

[14] Miller, C., and Valasek, C. Adventures inautomotive networks and control units. http:

//www.ioactive.com/pdfs/IOActive_Adventures_

in_Automotive_Networks_and_Control_Units.pdf,2014.

[15] Miller, C., and Valasek, C. Remote exploita-tion of an unaltered passenger vehicle. DEF CON23 (2015).

[16] Norte, J. C. Hacking industrial vehicles from the in-ternet. http://jcarlosnorte.com/security/2016/

03/06/hacking-tachographs-from-the-internets.

html, mar 2016. Accessed: 2016-03-17.

[17] NSF. EAGER: Collaborative: Toward a TestBed for Heavy Vehicle Cyber Security Exper-imentation. https://www.nsf.gov/awardsearch/

showAward?AWD_ID=1619690. Accessed: 2016-03-02.

[18] SAE. The SAE J1939 Communications Net-work. http://www.sae.org/misc/pdfs/J1939.pdf.Accessed: 2016-03-17.

[19] U.S. Department of Transportation,O. o. T. A. Economic characteristics ofthe freight transportation industry. http:

//www.rita.dot.gov/bts/sites/rita.dot.gov.

bts/files/data_and_statistics/by_subject/

freight/freight_facts_2015/chapter5, 2015.Accessed: 2016-03-17.

[20] U.S. Department of Transportation, O.o. T. A. National transportation statistics.http://www.rita.dot.gov/bts/sites/rita.

dot.gov.bts/files/publications/national_

transportation_statistics/index.html, 2016.Accessed: 2016-04-17.

[21] W., V. Sae j1939 serial control and com-munications vehicle network. http://www.

esd-electronics-usa.com/online-seminars.html.

10