11institutetext:  Korea University, Seoul, Korea
22institutetext: 22email<EMAIL_ADDRESS>
33institutetext: 33email<EMAIL_ADDRESS>
44institutetext: 44email<EMAIL_ADDRESS>
55institutetext: 55email<EMAIL_ADDRESS>
# Expanding the Attack Scenarios of SAE J1939: A Comprehensive Analysis of
Established and Novel Vulnerabilities in Transport Protocol

Hwejae Lee 11 2 2 Hyosun Lee 1133 Saehee Jun 1144 Huy Kang Kim 1155

###### Abstract

Following the enactment of the UN Regulation, substantial efforts have been
directed toward implementing intrusion detection and prevention systems
(IDPSs) and vulnerability analysis in Controller Area Network (CAN). However,
Society of Automotive Engineers (SAE) J1939 protocol, despite its extensive
application in camping cars and commercial vehicles, has seen limited
vulnerability identification, which raises significant safety concerns in the
event of security breaches. In this research, we explore and demonstrate
attack techniques specific to SAE J1939 communication protocol. We introduce
14 attack scenarios, enhancing the discourse with seven scenarios recognized
in the previous research and unveiling seven novel scenarios through our
elaborate study. To verify the feasibility of these scenarios, we leverage a
sophisticated testbed that facilitates real-time communication and the
simulation of attacks. Our testing confirms the successful execution of 11
scenarios, underscoring their imminent threat to commercial vehicle
operations. Some attacks will be difficult to detect because they only inject
a single message. These results highlight unique vulnerabilities within SAE
J1939 protocol, indicating the automotive cybersecurity community needs to
address the identified risks.

###### Keywords:

SAE J1939 Commercial Vehicle Security Cybersecurity Attack Scenarios
Vulnerabilities

###  1 Introduction

Recently, security issues in the automotive industry have emerged as a
significant challenge that can no longer be overlooked[1]. Especially for
commercial vehicles, these security issues are even more serious. Commercial
vehicles require special attention in terms of security because the damage
from accidents is greater compared to passenger cars[2]. This is particularly
the case for large commercial vehicles such as trucks and buses due to their
size and the importance of the cargo they carry from a security standpoint[3].

Interest in commercial vehicle security is showing an upward trend, as is the
active organization of hacking challenges targeting commercial vehicles such
as the CyberTruck Challenge[4]. Also, interest in commercial vehicles has
surged as autonomous and platooning technologies have advanced. These
technologies are more crucially utilized in commercial vehicles than in
general vehicles, and the security requirements associated with them require
special consideration[5]. SAE J1939 protocol is widely adopted for commercial
vehicles, while CAN is used for passenger vehicles. In addition, various data,
including the parameter group number (PGN) and data fields, are also
standardized and open to the public.

However, current security research is mainly focused on passenger cars,
resulting in a relative lack of specialized research for commercial vehicles
using SAE J1939. This implies that there may be security vulnerabilities in
commercial vehicles using SAE J1939, and such vulnerabilities can impact
various industries where commercial vehicles play a crucial role. Therefore,
commercial vehicles, having different characteristics and requirements from
passenger cars, need a specialized security approach that takes these factors
into account. This research focuses on SAE J1939 protocol from this point of
view. The characteristics of this protocol, widely used in commercial
vehicles, expand from those of the CAN protocol, making it essential to
consider security threats and attack scenarios specific to commercial
vehicles. This paper aims to provide an in-depth understanding and a new
approach in the field of commercial vehicle security by exploring the concepts
and feasibility of attack scenarios specialized for SAE J1939 protocol in
commercial vehicles. It emphasizes that responding to security threats in
commercial vehicles goes beyond a mere technical challenge, as it is directly
linked to national safety.

The remainder of this paper is organized as follows. In Section 2, we present
an overview of SAE J1939 protocol, which serves as a fundamental standard for
inter-component communication in commercial vehicles. The section elaborates
on the protocol’s architecture, various message types, and the specialized
procedures for multi-packet data exchange, along with the functionalities
offered by the protocol for commercial vehicle communication systems. In
Section 3, we present an overview of attack scenarios examined in the existing
CAN framework alongside those explored within SAE J1939 standard. Section 4
details our testbed environment, while Section 5 delineates a total of 14
attack scenarios, encompassing both those identified in prior research and new
scenarios proposed within this testbed. Finally, Section 6 concludes with a
summary of the findings and outlines directions for future work.

###  2 Background

SAE J1939 stipulates the recommended practices for trucks and buses regarding
communication between internal components in commercial vehicles. The standard
originated in the automobile and heavy truck industries in the United States,
has recently spread, and is now widely adopted worldwide. These protocols are
not only used for internal communication in cargo trucks or trailers but are
also widely applied in commercial vehicles in various industries (e.g.,
construction machinery, agricultural machinery, ships, military vehicles),
implying that vulnerabilities in SAE J1939 standard may be common to a wide
range of commercial vehicle models.

---
Figure 1: Data unit format of SAE J1939 protocol

SAE J1939 standard supports a higher-level protocol that enables manufacturers
of large industrial electronic control units (ECUs) to communicate over large,
often complex networks. SAE J1939 application protocol uses a 29-bit CAN
extended frame identifier. The arbitration identifier (AID) is divided into
several parts, including the PGN, which identifies the frame and defines which
signals are included. The first three bits of the ID are the priority bits.
What makes up the next 18 bits is the PGN. Each frame can be transmitted to a
global address or a specific address, and the PGN includes the following
related information: extended data page (EDP), data page (DP), protocol data
unit (PDU) format (PF), and PDU specific (PS). The last eight bits of the
frame contain the source address (SA). Figure 1 shows the data unit format of
SAE J1939 protocol.

(a) Command message

(b) Request and
Acknowledgement message

(c) Request2 and Transfer message

---
(d) Transport protocol transfer sequences

Figure 2: SAE J1939 message transmission sequences

PDU can be divided into PDU1 and PDU2 depending on the PF value. PDU1 is a
message that follows the peer-to-peer method with a PF value from 0 to 239. In
PDU1, PS refers to the destination address (DA). PDU2 corresponds to a message
broadcast to the specified group with a PF value from 240 to 255. In this
case, PS means group extension (GE).

The meaning and role of a SAE J1939 message can be interpreted through PGN.
Figure 2 shows a typical communication method in SAE J1939. A Command (various
PGNs) message is a message in which the sender commands the receiver to
perform a specific operation such as torque and speed control. This receiver
is defined in the parameter group. A Request (PGN 59904) and an
Acknowledgement (PGN 59392) messages form a pair. The sender can query the
receiver as to whether to use a specific PGN using the Request message. The
receiver sends the Acknowledgement message in response. Lastly, there are
Request2 (PGN 51456) and Transfer (PGN 51712) messages. When the receiver
receives a request for data related to a specific PGN through a Request2
message, the response is sent as a Transfer message. Multi-packet data
transmission is possible in SAE J1939 standard communication. A connection
setup process must precede it. This process is based on a transport protocol
connection management (TP.CM, PGN 60416) message. There are five types of
TP.CM messages: request to send (TP.CM_RTS), clear to send (TP.CM_CTS), end of
message acknowledgment (TP.CM_EndOfMsgACK), connection abort (TP.Conn_Abort),
and broadcast announce message (TP.CM_BAM). The type can be distinguished by
the control byte (16, 17, 19, 255, 32), which is the first byte of the
message. The first four types are messages involved in establishing a
connection when transmitting multi-packet data. During the connection
initiation process, the sender transmits a TP.CM_RTS message to the receiver.
In TP.CM_RTS, the SA field corresponds to the sending node and the DA field
corresponds to the receiving node. The message includes the total message
size, the total number of packets, and the PGN of the packeted message.
Additionally, the maximum number of packets of a single TP.CM_CTS to be
received from one receiving node can be limited. If the same TP.CM_RTS message
is received multiple times from the same SA, the most recent message is
applied and the previous messages are ignored. In the connection established
process, in contrast, the receiver sends a TP.CM_CTS message, a connection
acceptance message, to the sender in response to the TP.CM_RTS message. The
TP.CM_CTS message contains the number of packets that can be sent, the next
packet number to be sent, and the PGN of the packeted message. At this time,
the size of the message to be sent must not exceed the maximum size as
stipulated by TP.CM_RTS. If multiple TP.CM_CTS messages are received while the
connection established is completed, the connection is interrupted. If a
timeout occurs, the responder can terminate the connection or send a TP.CM_CTS
message to maintain the connection. Subsequently, the sender transmits packets
according to the number of packets requested. A large message is divided into
several individual transport protocol data transfer (TP.DT, PGN 60160) packets
and transmitted. Global DA (255) is only allowed in TP.CM_BAM messages cannot
be used during general TP.CM_RTS/CTS multi-packet data transmissions. Finally,
when the receiver receives all packets, it sends TP.CM_EndOfMsgACK message to
inform the sender that the entire message has been successfully received and
the connection is terminated. The TP.CM_EndofMsgACK message contains the total
message size, the number of packets the receiver has received, and the PGN of
the packeted message. However, if the sender or receiver wants to close the
connection for any reason for disconnection, they can stop the connection by
sending a TP.Conn_Abort message. The message includes the connection abort
reason, the role of the sender, and the PGN of the packeted message. A
TP.CM_BAM is used to notify all nodes in the network that a message will be
broadcast. This message includes the total message size, the total number of
packets, and the PGN of the packeted message. After the TP.CM_BAM message is
transmitted, the TP.DT messages are broadcast, setting with the Global DA
(255).

###  3 Related Work

Table 1: Various attacks on CAN protocols and related research.

Attack Type | Description | Authors
---|---|---
Fuzzing | send random data to the CAN bus, causing system errors. |  [6], [7], [8], [9], [10]
DoS | overwhelms the network with excessive messages, disrupting its normal functions. |  [6], [7], [8], [9], [11], [12]
Spoofing | involving the transmission of false messages to manipulate the behavior of the vehicle. |  [6], [7], [8], [9], [10], [12], [13]
Replay | deceives the network by resenting captured legitimate messages. |  [7], [10], [12]
Suspension | interferes with system functionality by blocking or delaying specific messages. |  [7], [8], [10], [14]
Masquerade | alters the data part of messages to disguise malicious intent. |  [7], [8], [10], [13]

####  3.1 CAN protocol Attack Scenarios

The CAN protocol is a core communication technology extensively used in
vehicle networks in the automotive and other industrial sectors. This protocol
enables efficient exchanges of data between various ECUs within vehicles,
thereby enhancing vehicle performance and safety. However, the CAN protocol
inherently lacks security features, posing the risks of network intrusions and
data manipulation by external attackers. Recent researchers are focusing on
exploring various attack scenarios that exploit these vulnerabilities and on
developing security measures to counteract them.

The CAN protocol within vehicles is vulnerable to various attacks, primarily
classified as fuzzing, denial-of-service (DoS), spoofing, replay, suspension,
and masquerade attacks. Fuzzing attacks involve sending random data to the
network to induce system errors. This type can be used to explore system
vulnerabilities or as a stability test. DoS attacks are carried out by sending
excessive messages to the network, disrupting the normal functions of the
vehicle. Spoofing attacks manipulate vehicle behavior by sending false
messages, which may appear normal but actually convey incorrect information.
Replay attacks use retransmitted captured messages to deceive the network,
allowing the execution of unwanted commands. Suspension attacks disrupt the
normal operation of vehicle systems by blocking or delaying specific messages.
Finally, masquerade attacks are carried out by altering the data portion of
messages to disguise malicious content by making it appear legitimate. These
attacks can be difficult to detect and are accomplished through subtle changes
in the messages. Research conducted on each attack technique is briefly
presented in Table 1.

####  3.2 SAE J1939 Attack Scenarios

SAE J1939 standard is commonly applied to commercial vehicles in various
industries and supports a high-level protocol for large-scale network
communication. This standard uses a 29-bit CAN extended frame identifier to
enable multi-packet data communication and peer-to-peer communication. These
unique characteristics of SAE J1939 can provide a new attack vector different
from that in the CAN communication environment. Based on this, studies have
recently attempted to stage vehicle network attacks targeting commercial
vehicles and discuss possible countermeasures against new attacks and the
impacts of such attacks.

First, attack demonstration studies in SAE J1939 environment were conducted,
inspired by network attacks in the existing CAN communication environment.
Burakove et al. [15] demonstrated an attack targeting three attack vectors
(instrument panel, powertrain, retarder) in the application of SAE J1939
protocol. Attacks that could pose a significant threat to safety when a truck
is driven were demonstrated, such as those that control the instrument panel
gauges, randomly manipulate the engine RPM (Revolutions Per Minute), and
disable engine braking. This attack demonstration was conducted on tractors
and school buses, showing that SAE J1939-based attacks targeting large
vehicles can commonly affect such vehicles from multiple industries. Mukherjee
et al. [16] demonstrated three DoS attacks that disrupt the normal operation
of the vehicle by injecting messages into the bus. The three attacks were
classified according to the message type (Request, TP.CM) and exploit type
(implementation issues, specification issues) used in the attack. Jichici et
al. [17] conducted an experiment based on a simulation model connecting the
Simulink environment and the CANoe environment to address adversary actions
and countermeasures in the control systems of large vehicles. Recent studies
have proposed and demonstrated original attacks by taking advantage of the
fact that the characteristics of SAE J1939 protocol differ from those of the
existing general CAN communication environment. Murvay and Groza [18]
suggested that vulnerabilities in SAE J1939 could lead to critical attacks on
vehicle safety (impersonation, DoS, distributed DoS) and demonstrated attacks
that could occur in SAE J1939 environment using a CANoe-based simulation tool.
Three of the attacks demonstrated in their study were inspired by the fact
that SAE J1939 performs address claims. One attack relies on the fact that the
standard supports the transmission of data packets longer than eight bytes,
and when transmitting multi-packets, the establishment of the type of
connection takes place between the sender and the receiver. It was shown that
a TP.Conn_Abort request can be made after the connection. The remaining attack
steps target the working set supported by the standard, but these were not
demonstrated due to the limitations of the CANoe simulation. Chatterjee et al.
[19] conducted five attack demonstrations and undertook hypothesis
verification targeting actual large vehicles. The first two scenarios verify
previously proposed attack hypotheses, and the latter three scenarios present
possible attack vectors that can be exploited in SAE J1939 network. Each
attack test was conducted on four testbeds and in an actual truck environment.
The three newly proposed attack scenarios are limited in that they succeeded
in only one of the four testbeds, including the old engine control module
(ECM), and failed to demonstrate the attack in the remaining three testbeds
and in actual vehicles.

###  4 Experiment Setup

To validate the proposed attack scenarios, we employed Au SAE J1939 simulators
(Generation II), integral in product development and validation processes,
encompassing SAE J1939 product line testing, receipt inspection, and
commercial demonstrations. These simulators are capable of generating SAE
J1939 signals for up to three controller applications related to the engine,
anti-lock brake system (ABS), and transmission. Furthermore, the Au SAE J1939
Message Center System (MCS) was utilized to facilitate comprehensive data
transmission and reception configurations. The simulation involves 27 PGNs
representing a total of 234 signals, all of which communicate via TP,
including Request and Acknowledgment messages.

The experimental setup is depicted in Figure 3, illustrating the testbed
constructed for the purpose of this study. Laptop 1 has installed a GUI to
monitor the simulator’s signal values, as shown in Figure 4. Laptop 2 is
utilized for CAN bus monitoring and to perform the role of an attacker. The
CAN bus is monitored using a Kvaser USBcan Pro 2xHS v2. Python scripts are
developed to inject the attacks, utilizing the CANlib provided by Kvaser. For
clarity in the experimental procedure, two laptops are used; however, it
should be noted that the same operations can be conducted using a single
laptop without affecting the outcome. Because, in this study, we predicate on
the assumption that an attacker will gain unauthorized access to the SAE
J1939-based in-vehicle network. Such access can be obtained from the on-board
diagnostics (OBD)-II port through physical intrusion or in-vehicle telematics
such as infotainment systems [10]. Additionally, attackers may exploit a
parked vehicle by leveraging a CAN dongle tapped into an exposed rear camera.
Both the Au SAE J1939 Simulators (Generation II) and the Au SAE J1939 MCS are
connected to the CAN bus, which facilitates packet transmission and reception.
The CAN bus configuration for each simulator necessitates a 12V power supply.

---
Figure 3: J1939 attack simulation testbed setup. Laptop 1 monitors the CAN bus
and Laptop 2 acts as the attacker within the SAE J1939 network, comprising Au
SAE J1939 simulators (Generation II) and Au SAE J1939 MCS.

(a) Au SAE J1939 simulator 2.00A remote terminal

(b) Au SAE J1939 message center 1.00A

Figure 4: Graphic user interface for SAE J1939 network. This screenshot shows
the tool’s interface used for monitoring.

###  5 Experiment

(a) Out of memory using
TP.CM_BAM attack

(b) Overwrite memory using
TP.DT attack

(c) TP.DT spoofing attack

Figure 5: Selected attack scenarios in SAE J1939. They are showcasing 3 of 14
scenarios with notable impact. Comprehensive details on all discovered attack
scenarios are shown in the appendix.

In this section, we describe the attack scenarios dedicated to SAE J1939,
excluding attack scenarios commonly working in the CAN bus (e.g., fuzzing,
DoS, spoofing, replay, suspension, and masquerade attacks). Specifically, we
only consider the scenarios involving the Request and TP. We exclude scenarios
involving Request2, as they are defined by the manufacturer. We develop 14
attack scenarios and conduct experiments in a testbed environment. Among them,
seven scenarios have been previously proposed in existing research, while we
introduce other seven scenarios as new proposals. This chapter describes each
attack scenario and its results. In Figure 5 and Figure 8, messages from
normal ECUs are shown in blue, while messages from attackers and those
generated by attacks are in red. Additionally, normal messages that should
have occurred but did not are represented by dashed lines. Figure 6 shows the
results for each attack. During all attacks, injections are made such that the
testbed baud rate utilized only 20-50% of the maximum capacity of messages,
not 100%. During normal operation, approximately 20% of the baud rate is
utilized. This controlled injection rate is used to avoid the typical DoS
attacks observed in CAN, where messages are injected at a high rate with
elevated priority AIDs, pushing normal messages out of the bus due to baud
rate saturation. By injecting fewer messages, we can confirm the effects are
due to the newly proposed SAE J1939 attack scenarios and not pre-existing
ones. We do not alter priority when injecting attacks, retaining the priority
used in the existing testbed. Since changing SAE J1939 priority will alter the
AID, which could be easily detected. Even if viable, such attacks are excluded
from our study due to their low risk. All tests are conducted in a black-box
environment without access to the source code or debug information.
Furthermore, as actual ECUs are not in operation, no information is exposed,
even in a buffer overflow.

####  5.1 Request Overload Attack

#####  5.1.1 Attack Scenario and Testing

The first attack scenario is a DoS attack, as proposed by Mukherjee et
al.[16], where the attacker paralyzes the target ECU using a flood of Request
messages. Figure 7 (a) illustrates the Request overload attack. To determine
if a PGN is currently in use, a message is sent using PGN 59904. In the
testbed, specific ECUs periodically send Request messages inquiring about the
use of PGNs 65227, 65253, 65254, and 65260. We target PGN 65263 for our
attack, which periodically transmits engine fluid information, as the target
ECU. This PGN is not originally receiving Request messages in the testbed. It
is expected that PGN 65263, receiving a flood of Request messages, will be
unable to provide normal services.

#####  5.1.2 Results

During normal operation, PGN 65263 transmits messages at an average interval
of 0.5 seconds. Upon the injection of the attack, the simulator displays
engine fluid information with a reading of 0, indicating a failure to provide
accurate information. Figure 6 (a) shows that the message generation interval
for PGN 65263 changed and is between 0.27 seconds and 0.72 seconds upon the
attack injection. The higher the injection speed, the more pronounced the
effects of the attack. This indicates that the effects are due to the attack.
Injecting the attack at very high speeds to occupy most of the baud rate also
results in a reduced frequency of PGN 65263 messages, similar to findings by
previous researchers. However, as this proposes an attack scenario difficult
to detect by intrusion detection models, the message delay is considered an
effect of the attack. The capability to target specific ECUs and the potential
for significant damage even with such delays, especially at high speeds,
suggests an effective attack scenario.

####  5.2 Malicious Acknowledgment Attack

#####  5.2.1 Attack Scenario and Testing

The second attack scenario introduces a new method where an attacker
manipulates and sends an Acknowledgment for a Request message. This scenario
aims to exploit communication process vulnerabilities by issuing
Acknowledgment messages that may not match authentic Request messages,
potentially leading to unauthorized activities or data breaches. Figure 7 (b)
illustrates this malicious Acknowledgment attack, showing how an attacker can
compromise the communication protocol’s integrity and possibly disrupt or
weaken the security of the networked system. In SAE J1939, Request messages
are utilized to identify active PGNs. Such information is crucial for
directing messages to specific PGNs and ensuring that other ECUs do not use
duplicate PGNs. Consequently, if a PGN is reported as inactive or unresponsive
when in use, it can halt message transmission to that PGN or lead to its use
by another ECU, thereby causing network confusion. Our experiment focuses on
PGN 65263, which typically receives Request messages under normal operation.
The goal is to dispatch false responses more swiftly than the actual response
messages. For testing, PGN 65263 must respond with 0 (ACK) in the
Acknowledgment message through PGN 59392 to indicate that it is in existing
use, but this is changed to 1 (NACK), 2 (Access Denied), and 3 (Cannot
Respond) before being sent. Misrepresenting an active PGN as inactive is
expected to prevent the ECU from receiving previously accessible messages.

#####  5.2.2 Results

Unfortunately, PGN 59392 is not utilized in our testbed, making the testing
process challenging. We attempted to forcefully insert the values 1 (NACK), 2
(access denied), and 3 (unable to respond) into the Acknowledgment message for
the Request message sent to PGN 65263, but this had no noticeable effect. This
is expected because our testbed does not consider PGN 59392, so there may be
no response. However, when only PGNs that return an Acknowledgment of 0 (ACK)
in response to periodic Request messages are communicated with, even minimal
packet injection can constitute a considerable attack threat.

####  5.3 Malicious TP.CM_RTS Attack

#####  5.3.1 Attack Scenario and Testing

The third attack scenario, similar to the scenario proposed by Mukherjee et
al.[16], involves the attacker injecting TP.CM_RTS messages to alter the
number of packets or the length of data to be transmitted. Figure 7 (c)
illustrates the malicious TP.CM_RTS attack. The attacker exploits the fact
that when multiple TP.CM_RTS messages are injected from the same SA, the most
recent message is accepted, and by timing the injections, the attacker sends
TP.CM_RTS messages significantly alter the number of packets a normal ECU
would send, either reducing or increasing the total number. In SAE J1939, when
a normal ECU needs to transmit a message exceeding eight bytes, it informs the
number of packets it will send within TP.CM_RTS to another ECU. When
establishing a connection, the receiving ECU verifies the number and length of
incoming packets, accordingly reserving the necessary buffer space. In the
testbed, During normal operation, ECU 0 sends TP.CM_RTS message to ECU 249 to
transmit multi-packets. At this moment, it is declared that a total of three
packets will be sent. ECU 249 is required to process the information from ECU
0’s TP.CM_RTS message and respond with TP.CM_CTS to facilitate the
transmission of three messages. However, an attacker targeting the same PGN
may transmit a malicious TP.CM_RTS immediately following the legitimate
message, altering the indication to send two to four messages instead.
Subsequently, ECU 249 reacts by issuing TP.CM_CTS to transmit the number of
packets as specified by the altered TP.CM_RTS. Suppose an attacker sends a
message that reduces the number of packets a normal ECU tries to send. In that
case, the receiving ECU will believe that all messages have been received,
even though fewer messages were sent, and will prematurely terminate the
session using TP.CM_EndofMsgACK. As a result, it is anticipated that packets
from the normal transmitting ECU will go undelivered. On the other hand, if
the attacker issues a message to increase the packet count beyond what the
normal transmitting ECU plans, the receiving ECU will issue a TP.CM_CTS
message to request additional packets, potentially leading to data leakage.
When sending the attack message, consideration is given to both altering only
the number of packets while keeping the message length the same and changing
the message length to match the altered packet count.

Table 2: Test cases of TP.CM_RTS spoofing attacks.

Type of Message Normal Case 1 Case 2 Case 3 Case 4 TP.CM_RTS Bytes to send 18
18 18 10 22 Total packets 3 2 4 2 4 TP.CM_CTS Packets to send 18 18 18 10 22
Next packet 3 2 4 2 4 Number of TP.DTs transmitted 3 2 3 2 3 TP.CM_EndofMsgACK
Bytes received 18 18 - 10 - Packets received 3 2 - 2 -

#####  5.3.2 Results

During normal operations, the transmitting and receiving ECUs synchronize on
the number of packets to be sent, guaranteeing a smooth exchange and
preventing packet loss. However, the results after the injection of the attack
are shown in Table 2. Regardless of the change in packet size, if the attacker
transmits a TP.CM_RTS message specifying a reduced number of packets, only two
packets are sent instead of the expected three, leading to a loss of
information. If the attacker modifies the number of packets to larger
quantities, transmitting ECU sends three TP.DT packets and then send a
TP.Conn_Abort message to forcibly close the session. This consequence likely
originates from the programming of ECU 0, which limits it to sending a maximum
of three packets and triggers a TP.Conn_Abort message in response to any
unexpected messages. This consequence is expected from the programming of ECU
249, which limits it to sending a maximum of three packets and triggers a
TP.Conn_Abort message in response to any unexpected messages. These
observations indicate that the effectiveness of the attack is maintained,
irrespective of whether the manipulated number of packets is higher or lower
than anticipated.

####  5.4 Connection Exhaustion Attack

#####  5.4.1 Attack Scenario and Testing

The fourth attack scenario, as proposed by Mukherjee et al.[16], involves the
attacker periodically sending TP.CM_CTS messages to maintain a session. Figure
7 (d) illustrates the TP.CM_CTS DoS attack. While a normal ECU needs to
establish a session with the receiving ECU to send multi-packet messages, the
attacker continually sends messages to occupy the session. Only one session
can be established at a time. In SAE J1939 protocol, a session is requested by
sending TP.CM_RTS, and subsequently established and maintained with TP.CM_CTS
to facilitate the reception of multi-packet messages. A TP.CM_CTS message sent
within 1250 milliseconds after data transmission indicates either a failure to
receive a specific multi-packet or a request for its retransmission, thus
ensuring the continuation of the session. Consequently, if an attacker
occupies a session intended to receive multi-packet messages, the legitimate
information fails to be received. In the testbed, ECUs 0 and 249 usually
establish a session and exchange information at 45 to 60 seconds intervals.
When sustaining a session through a packet retransmission request, the request
must be sent before the arrival of the next TP.DT message to maintain the
session. Therefore, the attack period is set within a 50-millisecond window.
During the attack, since additional sessions for multi-packet transmission and
reception cannot be initiated, it is anticipated that ECU 249 will cease to
receive the messages it normally receives periodically.

#####  5.4.2 Results

Upon the execution of the attack, ECU 0 and ECU 249 are observed to be unable
to initiate a new session, resulting in the cessation of their regular
information exchanges. If a significant volume of multi-packets is transmitted
and received within the testbed, the time until the complete cessation of the
session could be prolonged. It presents the opportunity to carry out attacks
over extended intervals lasting less than 1250 milliseconds. Figure 6 (b)
illustrates the modified status of multi-packet transmissions before and after
the execution of the attack. After the attack, the targeted ECU is prevented
from receiving the multi-packet messages that are normally transmitted and
received. The resumption of normal multi-packet transmissions after the attack
indicates a temporary disruption, thus confirming the effectiveness of the
attack.

####  5.5 TP.CM_BAM Block Attack

#####  5.5.1 Attack Scenario and Testing

The fifth attack scenario, introduced by Chatterjee et al.[19], extends the
principles of the fourth attack scenario specifically to target the ECUs
responsible for broadcasting messages. Figure 7 (e) demonstrates the TP.CM_BAM
block attack, which obstructs the transmission of TP.CM_BAM messages that were
previously sent periodically by occupying the session. It is identical to the
fourth attack scenario, but in this case, the target ECU is ECU 0, which is
responsible for transmitting the TP.CM_BAM message instead of ECU 249. To
interrupt the transmission of TP.CM_BAM messages by ECU 0, the attacker seizes
the communication session using TP.CM_RTS and TP.CM_CTS messages.
Consequently, ECU 0 is expected to be incapacitated and unable to continue
sending TP.CM_BAM messages.

#####  5.5.2 Results

Under normal operations, ECU 0 normally broadcasts TP.CM_BAM messages at
intervals of approximately 2.5 seconds. Figure 6 (c) illustrates the change in
the frequency of TP.CM_BAM message broadcasting before and after the attack is
executed. Observations following the attack reveal that the target ECU cannot
send TP.CM_BAM messages. The return to regular TP.CM_BAM message transmissions
after the attack validate the temporary disruption caused by the attack,
underscoring its effectiveness.

####  5.6 Memory Leak using TP.CM_CTS Attack 1

#####  5.6.1 Attack Scenario and Testing

The sixth attack scenario, proposed by Chatterjee et al.[19], involves the
attacker sending malicious TP.CM_CTS messages to cause a data leakage. This
method of attack manipulates the mechanism used by the communication protocol
to manage multi-packet transmissions, exploiting vulnerabilities within the
system. Figure 8 (a) represents this approach, illustrating a memory leak
instance through a TP.CM_CTS attack, underscoring the protocol’s vulnerability
to compromise data integrity and system stability. In SAE J1939, TP.CM_RTS is
utilized to signal the intention to transmit $N$ multi-packets. Following
this, the ECU received the TP.CM_RTS responds with a TP.CM_CTS message,
indicating readiness to receive packets from $1$ to $N$. However, an attacker
can exploit this process by sending a malicious TP.CM_CTS message that
requests packets starting from a sequence number greater than or equal to
$N+1$, thus exceeding the original packet range and potentially causing a data
leak. ECU 0 initiates a session with ECU 249 via TP.CM_RTS to send three
multi-packets in the testbed. ECU 249, intending to comply, responds with a
TP.CM_CTS message aimed at receiving three packets, starting with packet 1.
However, the scenario is compromised by an attacker who issues a TP.CM_CTS
message requesting three packets starting from packet 5, a sequence beyond the
agreed-upon transmission range. This action increases the likelihood of data
leakage, especially if the targeted ECU lacks safeguards to reject or handle
such invalid TP.CM_CTS messages appropriately.

#####  5.6.2 Results

Table 3 illustrates the sequence of packet occurrences before and after the
attack. After the attack is launched, ECU 249 instructs ECU 0 to transmit
three packets, starting with the fifth packet, resulting in the system
skipping the first and second TP.DT packets and immediately send the third
TP.DT message. Following this, a TP.CM_CTS message is transmitted, requesting
the transmission of zero packets starting with the fourth packet, without any
subsequent session termination message. If ECU 0 is to send the normal
TP.CM_RTS and ECU 249 is to respond with TP.CM_CTS during this time, the
session would abruptly end with a TP.Conn_Abort message. This result is
supposed by the limitation of the testbed, indicating a significant risk of
data leakage should such an attack be executed against actual ECUs or trucks.
ECU 249 skips the sequence of packets it is originally scheduled to send and
attempts to send from a higher number, confirming the effectiveness of this
type of attack.

Table 3: Results of memory leak using TP.CM_CTS attack 1.

Message sequence Type of message Normal Attack 1 TP.CM_RTS Bytes to send 18 18
Total packets 3 3 2 TP.CM_CTS Packets to send 3 3 Next packet 1 5 3 Number of
TP.DTs transmitted (last sequence number) 3 (3) 1 (3) 4 TP.CM_EndofMsgACK
Bytes received 18 - Packets received 3 - 5 TP.CM_CTS Packets to send - 0 Next
packet - 4

####  5.7 Memory Leak using TP.CM_CTS Attack 2

#####  5.7.1 Attack Scenario and Testing

The seventh attack scenario, as proposed by Chatterjee et al.[19], involves an
attacker sending fake TP.CM_CTS messages to induce data leakage. This scenario
shares similarities with the sixth attack scenario but differs in approach.
Instead of requesting packets starting with a higher sequential number than
originally intended, the attacker solicits more packets than initially agreed
upon, resulting in data leakage. Figure 8 (b) shows the memory leak during
TP.CM_CTS attack 2. Despite the normal ECU’s intention to transmit three
packets starting with number 1, the attacker’s request for ten packets from
the same starting point leads to data leakage. ECU 0 initiates a session
connection request with ECU 249 via TP.CM_RTS to transmit three multi-packets
in the testbed. Following this, ECU 249 aims to dispatch three packets via a
TP.CM_CTS message, starting with the first packet. The attacker intervenes by
disseminating a malicious TP.CM_CTS message that erroneously requests the
transmission of ten packets, starting with the first packet. This scenario
poses a risk of data leakage if the ECU lacks the programming to handle such
invalid TP.CM_CTS messages effectively.

#####  5.7.2 Results

The outcomes of the attack are the same as those observed in the memory leak
during TP.CM_CTS attack 1. This result is also supposed by the limitation of
the testbed. The continued attempt by ECU 249 to transmit additional packets
proves the attack’s effectiveness.

####  5.8 Memory Leak using TP.CM_CTS Attack 3

#####  5.8.1 Attack Scenario and Testing

The eighth attack scenario presents an unexplored approach where an attacker
induces memory leakage in the target ECU by sending a TP.CM_CTS message to
initiate packet transmission, even when there is no TP.CM_RTS message
originally sent by the target. This attack leads the targeted ECU to prepare
to receive data that is not legitimately requested, causing potential memory
resource issues. Figure 8 (c) illustrates TP.CM_CTS attack 3. The attacker
exploits this by issuing TP.CM_CTS messages to request the transmission of
multi-packets, aiming to cause a memory leakage without a preceding TP.CM_RTS
message. Within the testbed, if ECU 0 has not dispatched a TP.CM_RTS message,
the attacker proceeds to send a TP.CM_CTS message to instigate multi-packet
transmission. Consequently, upon receiving such a message, the target ECU is
expected to suffer from memory leakage.

#####  5.8.2 Results

Despite the injection of the attack, no impact is observed. The injected
messages include both TP.CM_CTS messages previously encountered in the testbed
and new packets that have not been observed before. Ultimately, it was
determined that in the absence of a TP.CM_RTS message, the arrival of a
TP.CM_CTS message did not elicit a response.

####  5.9 TP.CM_EndofMsgACK Interruptions Attack

#####  5.9.1 Attack Scenario and Testing

The ninth attack scenario introduces an unknown disruption technique,
terminating the session by injecting a TP.CM_EndofMsgACK message. Figure 8 (d)
shows this newly proposed TP.CM_EndOfMsgACK interruption attack. When ECUs
have established a session for transmitting and receiving multi-packets and
are ready to send data, the attacker intervenes by sending a TP.CM_EndOfMsgACK
message, forcibly terminating the session. The attacker exploits the forced
termination of the session during multi-packet transmission, thereby
interrupting the normal data exchange. ECU 0 initiates a session with ECU 249
using the TP.CM_RTS message for multi-packet transmission in the testbed. The
attacker disrupts the session during this process by injecting a malicious
TP.CM_EndofMsgACK message. This attack is expected to cause the premature
termination of the session.

#####  5.9.2 Results

While injecting the attack, ECU 0 discovers that any attempt to initiate a
session is promptly terminated, thus preventing the transmission of essential
information. Figure 6 (d) shows the impact on multi-packet transmission before
and after the attack. Following the attack’s introduction, ECU 0 cannot
continue transmitting multi-packet messages because the session is forcibly
terminated. We can confirm the attack is successful because there are no
packet exchanges between ECU 0 and ECU 249 during the attacks, and we observe
the packet exchanges are normal after the attacks have stopped.

####  5.10 TP.Conn_Abort Interruptions Attack

#####  5.10.1 Attack Scenario and Testing

The 10th attack scenario, as proposed by Murvay et al.[18], outlines a DoS
attack that leverages the TP.Conn_Abort command to forcibly terminate a
connection. This method disrupts normal communication sessions between ECUs
within vehicular networks. In Figure 8 (e), this scenario depicts the
TP.Conn_Abort interruptions attack in action. During a legitimate
communication session, where a normal ECU attempts to connect and send
messages to another ECU, the attacker intervenes by issuing a TP.Conn_Abort
command. This command effectively and prematurely ends the session, preventing
the successful transmission of messages. This attack exploits SAE J1939
protocol’s provision for session termination, using it maliciously to disrupt
normal operations and service availability, thereby demonstrating a
significant vulnerability in the protocol’s design concerning security against
DoS attacks. SAE J1939 standard includes a protocol, TP.Conn_Abort, designed
to terminate a connection for a variety of reasons forcefully. Attackers can
exploit this feature to disrupt the normal communication between ECUs by
forcibly ending sessions intended for multi-packet transmission. ECU 0
initiates a session connection to ECU 249 using TP.CM_RTS for the purpose of
sending multi-packets in the testbed. During this process, an attacker
intervenes by dispatching a malicious TP.Conn_Abort message, effectively
terminating the session prematurely. SAE J1939 protocol reserves up to 255
different reasons for connection termination, and in this experiment, each of
these reasons was tested to understand the impact of such attacks on normal
ECU communication, excluding those that are manufacturer-defined and intended
for specific use. The expectation after an attack is the forceful termination
of the session dedicated to the sending and receiving of multi-packets.

#####  5.10.2 Results

ECU 0 is compelled to terminate its ongoing session upon introducing the
attack, resulting in its inability to transmit the requisite information.
Figure 6 (e) shows the impact on the existing multi-packet transmission status
before and after the attack, highlighting the disruption caused. Following the
attack’s injection, it is obvious that the ECU is forced to end the session,
rendering it incapable of continuing its multi-packet message transmissions.
After the cessation of the attack, both ECU 0 and ECU 249 continued their
exchange of multi-packet messages, demonstrating the effectiveness of the
attack in disrupting the normal communication processes.

####  5.11 Out of Memory using TP.CM_BAM Attack

#####  5.11.1 Attack Scenario and Testing

The 11th attack scenario introduces an untried approach wherein the attacker
dispatches an extensive volume of multi-packets to the target ECU using the
TP.CM_BAM protocol. This scenario is intended to overwhelm the target ECU by
compelling it to allocate substantial resources in preparation for the receipt
of the announced multi-packet transmission. The primary objective of this
attack is to deplete the target ECU’s resources to such an extent that it
becomes incapable of maintaining its availability for normal service
operations. Figure 5 (a) shows the out of memory using TP.CM_BAM attack,
illustrating the process by which the attacker notifies the target ECU of the
impending large-scale multi-packet transmission through a TP.CM_BAM message.
ECU 249 is engaged in the transmission and reception of multi-packet data in
the testbed. The attacker exploits by sending a TP.CM_BAM message to the
target, ECU 249, signaling the intention to transmit a multi-packet message
comprising 1,785 bytes. Upon receipt of this message, ECU 249 allocates the
necessary resources in anticipation of the incoming data. This allocation of
resources to handle the specified multi-packet transmission can strain the ECU
if its resources are limited, potentially hindering its ability to maintain
normal operations and service delivery.

#####  5.11.2 Results

After the injection of the attack, ECU 249 is rendered incapable of performing
its normal services. Figure 6 (f) shows the flow of multi-packets to and from
ECU 249 before and after the attack, illustrating a significant disruption in
the communication. Post-attack, ECU 249 ceases to send critical TP messages,
including TP.CM_RTS, TP.CM_CTS, TP.DT, TP.CM_EndofMsgACK, and TP.CM_BAM, which
are previously transmitted on a regularly. Following the termination of the
attack, both ECU 0 and ECU 249 resumed their normal multi-packet message
exchanges, reaffirming that the attack successfully interfered with the usual
communication protocols.

####  5.12 Out of Memory using TP.CM_RTS Attack

#####  5.12.1 Attack Scenario and Testing

The 12th attack scenario introduces a novel method of attack during which the
perpetrator uses a TP.CM_RTS message to overwhelm the target ECU by compelling
it to allocate excessive resources in preparation for receiving a large volume
of multi-packet data. This method is intended to deplete the target ECU’s
resources, thereby rendering it unable to provide its regular services and
effectively compromising its availability. This strategy resembles the
eleventh attack scenario in that the goal is to disrupt the target ECU’s
functionality through resource exhaustion. However, it leverages the TP.CM_RTS
message as a means to trigger the excessive consumption of resources. Figure 8
(f) illustrates the out of memory using TP.CM_RTS attack. In this scenario,
the attacker sends a TP.CM_RTS message to the target ECU requesting the
transfer of a significant amount of multi-packet data. Upon receiving this
message, the target ECU allocates the necessary resources to accommodate the
expected data flow. This allocation is prompted by the reception of the
TP.CM_RTS message, potentially leading to the exhaustion of the ECU’s
resources, compromising its operational capabilities. ECU 249 engages in the
transmission and reception of multi-packet data in the testbed. The attacker
initiates the attack by transmitting a TP.CM_RTS message to the targeted ECU
249, signaling the intention to send a multi-packet message of 1,785 bytes to
ECU 249. Upon receipt of this message, ECU 249 allocates the necessary
resources in anticipation of receiving the specified multi-packet message.
However, if ECU 249’s resources are limited, the allocation for this incoming
data is expected to significantly impair its ability to maintain normal
service operations, potentially leading to service degradation or denial of
service situations due to resource exhaustion.

#####  5.12.2 Results

Following the injection of the attack, akin to the out of memory using
TP.CM_BAM scenario, ECU 249 was incapacitated, losing its ability to perform
normal services. Figure 6 (g) shows the multi-packet communications sent to
and received by ECU 249 before and after the attack’s execution. This provides
clear evidence of how the attack impacts the data exchange with ECU 249,
highlighting the change in the communication and possibly the inability of ECU
249 to maintain normal operations post-attack.

####  5.13 Overwrite Memory using TP.DT Attack

#####  5.13.1 Attack Scenario and Testing

The 13th attack scenario introduces an unexplored method by which an attacker
manipulates a specific segment of multi-packet data. In Figure 5 (b), this
technique, referred to as the overwrite memory using the TP.DT attack, shows
how an attacker can exploit the timing of data injection. During the normal
operation of ECUs, it transmits and receives multi-packet information via
TP.DT messages, the attacker strategically times the injection of malicious
TP.DT messages. This approach allows the attacker to overwrite existing data
within the communication stream, potentially altering the intended message or
compromising the integrity of the data being exchanged between ECUs. ECU 0
initiates a connection for multi-packet transmission to ECU 249, utilizing
TP.DT for message dispatch in the testbed. Three TP.DT messages are sent in
rapid succession during this session. To compromise the data integrity of the
second or third TP.DT message, an attack message is injected at a transmission
before the normal TP.DT messages.

#####  5.13.2 Results

Table 4 presents the values of TP.DT messages during normal operation and when
an attack is introduced. Upon the injection of the attack, ECU 249 erroneously
concludes that it has received all intended data, even though the received
data does not originate from ECU 0. It terminates the session by issuing a
TP.CM_EndofMsgACK message. This demonstrates the successful transmission of
incorrect information to ECU 249 due to the attack. Such an attack is
particularly critical when vital information, such as information related to
the engine or the speed of the vehicle, is transmitted in multi-packet
formats, emphasizing the potential for a significant impact on the safety and
operational integrity of the affected vehicle.

Table 4: Malformed packet payloads used in TP.DT attack cases.

Message sequence Type of message Normal Case 1 Case 2 1 TP.CM_RTS Bytes to
send 18 18 18 Total packets 3 3 3 2 TP.CM_CTS Packets to send 3 3 3 Next
packet 1 1 1 3 TP.DT data (sequence number) 31 4D 38 47 44 4D 39 (1) 31 4D 38
47 44 4D 39 (1) 31 4D 38 47 44 4D 39 (1) 4 TP.DT data (sequence number) 41 38
4B 50 30 34 32 (2) 41 38 4B 50 30 34 32 (2) FF FF FF FF FF FF 00 (2) 5 TP.DT
data (sequence number) 30 30 30 2A FF FF FF (3) FF FF FF FF FF FF 00 (3) FF FF
FF FF FF FF 00 (3) 6 TP.CM_EndofMsgACK Bytes received 18 18 18 Packets
received 3 3 3

####  5.14 TP.DT Spoofing Attack

#####  5.14.1 Attack Scenario and Testing

The 14th attack scenario introduces an unknown approach proposed here in which
the attacker disrupts normal communication by transmitting more data packets
than the sender initially planned, leading to confusion at the receiving node.
In Figure 5 (c) illustrates the TP.DT spoofing attack. In this scenario, the
legitimate ECU intends to dispatch three TP.DT messages for its communication
session. The attacker intervenes by sending additional TP.DT packets to the
receiving node before the original session concludes. The surplus packets,
arriving unexpectedly at the receiver, are designed to create data overflow or
processing anomalies, thereby undermining the integrity of the communication
session and potentially causing incorrect data processing or system
malfunctions at the receiving ECU. This attack method exploits the
communication protocol’s handling of multi-packet transmissions, targeting the
reliability of data transfers between ECUs. ECU 0 is configured to send three
TP.DT messages to ECU 249 in the testbed. Following the transmission of the
third TP.DT message, an additional TP.DT message is dispatched immediately.
The introduction of extra data via the immediate sending of an additional
TP.DT message is anticipated to lead to a buffer overflow due to the
unavailability of sufficient buffer space to accommodate the unexpected fourth
packet.

#####  5.14.2 Results

Following the transmission of the third TP.DT message, an injection of either
the fourth TP.DT message or both the fourth and the fifth TP.DT message was
performed to observe the resultant behavior. The session concludes with the
issuance of a TP.CM_EndofMsgACK packet signified that only three packets have
been successfully transmitted, irrespective of the additional TP.DT messages
transmitted.

(a) Result of the
Request overload attack

(b) Result of the
connection exhaustion attack

(c) Result of the
TP.CM_BAM block attack

(d) Result of the TP.CM_EndofMsgACK
interruptions attack

(e) Result of the TP.Conn_Abort
interruptions attack

(f) Result of the out of memory
using TP.CM_BAM attack

(g) Result of the out of memory
using TP.CM_RTS attack

Figure 6: Attack results for each scenario. The first sub-picture illustrates
the immediate effect of an attack, where Request messages transition from
periodic to irregular transmission, leading to unstable service. The
subsequent six sub-pictures reveal a common consequence where, post-attack
injection, previously normal message communications are abruptly halted.

####  5.15 Analysis of Results

Table 5 summarizes the results of the above experiment. We test fourteen
attack scenarios on a sophisticated testbed configured with SAE J1939
simulators. Attack scenarios previously successful on existing testbeds also
achieved success on our testbed. It demonstrates that our testbed provides an
environment similar to those used by previous researchers. The proposed attack
scenarios exploit vulnerabilities identified within SAE J1939 protocol
standard. Specifically, we identify several scenarios where a single packet
can facilitate an attack. Such attacks pose a critical threat due to their low
detectability by current intrusion detection systems.

Table 5: Comparative summary of various attack scenarios in SAE J1939.

Attack scenario name Initial proposer (subsequent experimenters) Testbed
experiment Testbed impact Actual vehicle experiment Actual vehicle impact Our
testbed experiment Our testbed impact Request overload attack
Mukherjee et al.[16] (Chatterjee et al.[19]) ✔ ✔ ✔ ✔ ✔ ✔ ✔
✔
Malicious Acknowledgment attack This study ✘ Malicious TP.CM_RTS attack
Mukherjee et al.[16] ✔ ✔ Connection exhaustion attack
Mukherjee et al.[16] (Chatterjee et al.[19]) ✔ ✔ ✔ ✔ ✔ ✔ ✔
✔
TP.CM_BAM block attack Chatterjee et al.[19] ✔ ✔ ✔ ✘ ✔ ✔ Memory leak using
TP.CM_CTS attack 1 Chatterjee et al.[19] ✔ ✔ ✔ ✘ ✔ ✔ Memory leak using
TP.CM_CTS attack 2 Chatterjee et al.[19] ✔ ✔ ✔ ✘ ✔ ✔ Memory leak using
TP.CM_CTS attack 3 This study ✔ ✘ TP.CM_EndofMsgACK interruptions attack This
study ✔ ✔ TP.Conn_Abort interruptions attack Murvay and Groza[18] ✔ ✔ ✔ ✔ Out
of memory using TP.CM_BAM attack This study ✔ ✔ Out of memory using TP.CM_RTS
attack This study ✔ ✔ Overwrite memory using TP.DT attack This study ✔ ✔ TP.DT
spoofing attack This study ✔ ✘

###  6 Conclusion and Future Work

To the best of our knowledge, this is the first attempt to investigate attack
scenarios while examining all parts of SAE J1939 from the perspective of
weaknesses in network protocols. This study highlights vulnerabilities in SAE
J1939 security and the urgent need for enhanced protection measures. By
detailing specific attack scenarios, our work will be helpful in developing
more robust security frameworks.

Our future work will develop and implement practical solutions, like network-
based intrusion detection systems (IDSs), which can provide real-time
monitoring and detection capabilities specific to SAE J1939 protocol. Although
end-to-end encryption could theoretically offer robust security, the
computational demands can be challenging for the resource-constrained
environments found in vehicular networks. Therefore, centralized network-based
IDSs could provide a more practical and efficient approach to detecting
attacks. In the future, we aim to design and implement IDSs to detect the
attacks illustrated in this study, providing a feasible method to
significantly enhance the cybersecurity of SAE J1939-based systems.

## References

  * [1] Rising security weaknesses in the automotive industry and what it can do on the road ahead.  https://www.trendmicro.com/vinfo/us/security/news/cybercrime-and-digital-threats/rising-security-weaknesses-in-the-automotive-industry-and-what-it-can-do-on-the-road-ahead, Dec. 2023.
  * [2] Freight cybersecurity.  https://nmfta.org/cybersecurity/, accessed Feb. 11, 2024.
  * [3] What are the most dangerous cyber attacks in the transportation industry?  https://nmfta.org/most-dangerous-cyber-attacks-in-the-transportation-industry/, accessed Feb. 11, 2024.
  * [4] CyberTruck Challenge.  https://www.cybertruckchallenge.org/, accessed Feb. 11, 2024.
  * [5] The reality of hacking threats in connected car systems.  https://www.helpnetsecurity.com/2024/01/22/ivan-reedman-ioactive-connected-vehicles-cybersecurity/, Jan. 2024.
  * [6] Fabio Martinelli, Francesco Mercaldo, Vittoria Nardone, and Antonella Santone.  Car hacking identification through fuzzy logic algorithms.  In 2017 IEEE international conference on fuzzy systems (FUZZ-IEEE), pages 1–7. IEEE, 2017.
  * [7] Ulf E Larson, Dennis K Nilsson, and Erland Jonsson.  An approach to specification-based attack detection for in-vehicle networks.  In 2008 IEEE Intelligent Vehicles Symposium, pages 220–225. IEEE, 2008.
  * [8] Miki E Verma, Michael D Iannacone, Robert A Bridges, Samuel C Hollifield, Pablo Moriano, Bill Kay, and Frank L Combs.  Addressing the lack of comparability & testing in CAN intrusion detection research: A comprehensive guide to CAN IDS data & introduction of the ROAD dataset.  arXiv preprint arXiv:2012.14600, 2020.
  * [9] Eunbi Seo, Hyun Min Song, and Huy Kang Kim.  GIDS: GAN based intrusion detection system for in-vehicle network.  In 2018 16th Annual Conference on Privacy, Security and Trust (PST), pages 1–6. IEEE, 2018.
  * [10] Seonghoon Jeong, Sangho Lee, Hwejae Lee, and Huy Kang Kim.  X-CANIDS: Signal-aware explainable intrusion detection system for controller area network-based in-vehicle network.  IEEE Transactions on Vehicular Technology, pages 1–16, 2023.
  * [11] Ivan Studnia, Vincent Nicomette, Eric Alata, Yves Deswarte, Mohamed Kaâniche, and Youssef Laarouchi.  Survey on security threats and protection mechanisms in embedded automotive networks.  In 2013 43rd Annual IEEE/IFIP Conference on Dependable Systems and Networks Workshop (DSN-W), pages 1–12. IEEE, 2013.
  * [12] Hyun Min Song, Ha Rang Kim, and Huy Kang Kim.  Intrusion detection system based on the analysis of time intervals of CAN messages for in-vehicle network.  In 2016 international conference on information networking (ICOIN), pages 63–68. IEEE, 2016.
  * [13] Kazuki Iehira, Hiroyuki Inoue, and Kenji Ishida.  Spoofing attack using bus-off attacks against a specific ECU of the CAN bus.  In 2018 15th IEEE Annual Consumer Communications & Networking Conference (CCNC), pages 1–4. IEEE, 2018.
  * [14] Andrea Palanca, Eric Evenchick, Federico Maggi, and Stefano Zanero.  A stealth, selective, link-layer denial-of-service attack against automotive networks.  In Detection of Intrusions and Malware, and Vulnerability Assessment: 14th International Conference, DIMVA 2017, Bonn, Germany, July 6-7, 2017, Proceedings 14, pages 185–206. Springer, 2017.
  * [15] Yelizaveta Burakova, Bill Hass, Leif Millar, and André Weimerskirch.  Truck hacking: An experimental analysis of the SAE J1939 standard.  In 10th USENIX Workshop on Offensive Technologies (WOOT 16), 2016\.
  * [16] Subhojeet Mukherjee, Hossein Shirazi, Indrakshi Ray, Jeremy Daily, and Rose Gamble.  Practical DoS attacks on embedded networks in commercial vehicles.  In Information Systems Security: 12th International Conference, ICISS 2016, Jaipur, India, December 16-20, 2016, Proceedings 12, pages 23–42. Springer, 2016.
  * [17] Camil Jichici, Adriana Berdich, Adrian Musuroi, and Bogdan Groza.  Control system level intrusion detection on J1939 heavy-duty vehicle buses.  IEEE Transactions on Industrial Informatics, 2023.
  * [18] Pal-Stefan Murvay and Bogdan Groza.  Security shortcomings and countermeasures for the SAE J1939 commercial vehicle bus protocol.  IEEE Transactions on Vehicular Technology, 67(5):4325–4339, 2018\.
  * [19] Rik Chatterjee, Subhojeet Mukherjee, and Jeremy Daily.  Exploiting transport protocol vulnerabilities in SAE J1939 networks.  In Proceedings of the Network and Distributed System Security Symposium (NDSS). https://www. ndsssymposium. org/wp-content/uploads/2023/02/vehiclesec2023-23053-paper. pdf, 2023.

## Appendix

(a) Request overload attack

(b) Malicious acknowledgment attack

(c) Malicious TP.CM_RTS attack

(d) Connection exhaustion attack

(e) TP.CM_BAM block attack

(a) Memory leak using
TP.CM_CTS attack 1

(b) Memory leak using
TP.CM_CTS attack 2

(c) Memory leak using
TP.CM_CTS attack 3

(d) TP.CM_EndofMsgACK
interruptions attack

(e) TP.Conn_Abort
interruptions attack

(f) Out of memory using
TP.CM_RTS attack

Figure 8: Explanations for 11 out of the 14 discovered attack scenarios not
illustrated in Figure 5