VitroBench is a comprehensive test platform involving commercial off-the-shelf (COTS) ECUs that allows arbitrary packet control over In Vehicle Networks (IVN). It allows replication of driving use cases and scenarios directly on the testbed involving COTS ECUs. This, in turn, allows us to design and evaluate concrete attacks that are directly related to a driving scenario. Our VitroBench paper is published on Vehicular Communications, Volume 43 (October 2023).
The primary objective of VitroBench is to facilitate the discovery and investigation of attacks that may impair the physical functions (e.g., display of speed, engine functionality) in a car. Capabilities such as sniffing and injection of modified packets are embodied in our test platform to control the communication in IVNs via an FPGA communication board and by hooking COTS ECUs via bare wires. The full control of the IVN communication is facilitated by bridging an ECU, intercepting any message involving the ECU and sending it to a workstation; and then send a possibly modified message back to the IVN.
The software for sniffing, injection or interception, and fuzzing or attacks is executed on the CAN Messages (CM) workstation. The sniffing software is from TSMaster. The python programs for injection or interception, and fuzzing or attacks can be obtained from this repository, VitroBench Software.
VitroBench is used for sniffing, frame injection and interception operation, fuzzing and attacks:
|All the IVNs messages are monitored and captured via TSMaster.
|A channel can be used to transmit messages to the targeted network with configurable frame interval.
|An ECU can be isolated via bridging and its intercepted messages will pass through the workstation.
|Fuzzing & Attacks
|A fuzzing program can be executed at the workstation on the injected or intercepted messages. Different programs for attacks can be explored by modifying the intercepted or injected messages.
We conduct fingerprinting to obtain the behaviour of each ECU and the testbed networks. This fingerprinting process is performed by the following actions:
Based on the observation made during our fuzzing and fingerprinting, we design attacks assuming that an attacker can physically or remotely compromise the ECU and he is able to maliciously communicate in the IVNs. The following attacks are conducted.
|Affects instrument cluster display
|Fuel Pump Attack
|Affects the fuel pump function
|Forced Car Stop
|Status of car key
|Wrong Speed Display
|Speed value for instrument cluster
|Message 0x600 to 0x6FF
|Range of diagnostic messages
The objective of this attack is to stop the message 0x1A6 to reach the Instrument Cluster, so as the display in the cluster reflects an incorrect value. Therefore, we design a flooding attack scenario by flooding messages with IDs lower than 0x1A6 (hence higher priority for transmission).
In our fuzzing case study, engine status message 0xAA from DDE is found to affect the pump control signal of EKP. From fingerprinting case study, we observed that EKP message 0x335 (i.e. PumpDutyCycle field) reflects the function of the control signal to the fuel pump. When the intercepted modified message 0xAA or injected fuzzed message 0xAA is sent into PCAN, the fuel is pumped in an irregular fashion to the engine. Since this attack impairs the fuel pump functionality of the car, this may potentially impact the engine to behave in an erratic fashion during driving.
From our fingerprinting case study, we observed that power status message 0x130 flows from CAS ECU over KCAN network. We observed that message 0x130 has three fields: CarKey, Ignition and Engine that affect the engine function. we send the modified message ID 0x130 with CarKey, Ignition and Engine set to zero to KCAN when the car is running and a specified time duration is reached. When the attack condition is ongoing, the fuel pump stops and the car eventually stops due to the attack.
From our fingerprinting case study, we observed that the wheel speed message 0xCE and the display message 0x1A6 flow from the DSC ECU over PCAN network. We discovered that the wheel speed is encoded in message 0x1A6 transmitted to the Instrument Cluster. In the first attack, the car runs normally till 40km/h and thereafter, the speed in message 0x1A6 is randomly modified. In the second attack, the car runs normally till 10km/h and thereafter, the speed message is incremented by 2/3 of the actual increased speed. For both attacks, the Instrument Cluster reflects the incorrect speed. As a result, the driver may accelerate the car beyond the imposed speed limit. This may not only result in accidents but may also have legal implications.
An example of the message ID (0x608) that passes though the JBE gateway is shown in the figure below. We observe that such penetration testing has little to no impact on the inter-frame interval (see the inter-frame timing distribution in the figure).
This research/project is supported by the National Research Foundation, Singapore, and Land Transport Authority under Urban Mobility Grand Challenge (Grant number UMGC-L011). Any opinions, findings and conclusions or recommendations expressed in this material are those of the author(s) and do not reflect the views of National Research Foundation, Singapore and Land Transport Authority.