Automotive Network Scans with Scapy

Proudly presented by:

Nils Weiss M.Sc. Ph.D.

• Apprenticeship "Electronics Technician"
• State Certified Electrical Engineer
• B.Sc. Computer Engineering
• M.Sc. Applied Sciences: "Automotive Security"
• Ph.D. Topic: "Automotive Security"

• Co-Founder of dissecto GmbH

  [email protected]

Enrico Pozzobon M.Eng.

• B.Eng. Computer Engineering
• M.Eng. Telecommunications Engineering
• PhD studies "Embedded Security"

• Co-Founder of dissecto GmbH

  [email protected]

Automotive Penetration Testing with Scapy .... continued

Agenda

• Intro
• Automotive Protocol Stack
• Transport Protocols
  • ISOTP Scanner
  • DoIP / HSFZ Scanner
• Application Protocols
  • OBD Scanner
  • UDS
    • System States
      • Sessions
      • Security Levels
      • Custom Sessions
    • Stateful Scanners
    • Stateful Fuzzers
  • Obsticales

Intro: Why Scapy for Automotive?

Acknowledgements

• Author of Scapy

  • Philippe Biondi [email protected]

• Maintainers of Scapy

  • Guillaume Valadon (@guedou) [email protected]
  • Gabriel Potter [email protected]
  • Pierre Lalet (@pi3rre) [email protected]

Automotive Diagnostic Protocol Stack

CAN / CAN-FD / CAN-XL

• Protocol release in 1986, still not dead
• Multi-master serial bus
• Two or more nodes are required
• Two wire bus
• Differential signal
• Wired AND
• Low signal (0 Bit) is dominant
• 8 / 64 bytes payload

CAN frame as transferred on the bus. Author: Dr. Ken Tindell

ISO-TP (ISO 15765-2)

• Transport protocol for data transfer over CAN, FlexRay, LIN and MOST
• Point-to-point communication
• Up to $2^{32}-1$ byte payloads
• Flow-Control management
• No re-transmission functionality

ISO-TP fragmented communication example

Protocol Control Information (PCI)

• ISO-TP defines four special frame type
  • Frame type 0: SF (Single Frame)
  • Frame type 1: FF (First Frame)
  • Frame type 2: CF (Consecutive Frame)
  • Frame type 3: FC (Flow Control Frame)

ISO-TP frame types overview

ISO-TP Scanning

We need to identify communication parameters:

• RX-ID
• TX-ID
• Extended Addressing (RX- and TX-ID)
• Padding

If one parameter is wrong $\Rightarrow$ no communication

Normal addressing

Extended addressing

Advantages:

• Detection of all ISOTP parameters, including padding
• No application layer command is triggered!
• ISOTP-Endpoints with any application layer protocol can be found

Paper: researchgate.net/publication/346656455

Scanning with Scapy (interactive Python shell)

In this example, we use vcan0 interface.

Load necessary components in Scapy

>>> conf.contribs['ISOTP'] = {'use-can-isotp-kernel-module': True}
>>> conf.contribs['CANSocket'] = {'use-python-can': False}
>>> load_contrib('cansocket')
>>> load_contrib('isotp')

Run scan

>>> socks = isotp_scan(CANSocket("vcan0"), range(0x720, 0x7F0))

Show results

>>> socks
[<<ISOTPNativeSocket: read/write packets at a given CAN interface using CAN_ISOTP socket > at 0x7f25c963ab50>]

Scanning with Scapy (from terminal)

python3 -m scapy.tools.automotive.isotpscanner --channel vcan0 --start 0 --end 100 


python3 -m scapy.tools.automotive.isotpscanner --interface vector --channel 0 \
                                               --python-can_args 'bitrate=500000, poll_interval=1' \
                                               --start 0 --end 100

HSFZ

• Transport layer protocol for UDS messages
• Only used by BMW
• First usages 2008
• 10Base-T in 2008
• 100Base-T appeared in 2015
• Supports (logical) addressing of ECUs
• OBD-Pin 8 is EthernetActivationLine
• Usually on port 6801

HSFZ Packet

>>> rfc(HSFZ)

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             LENGTH                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              TYPE             |      SRC      |      DST      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

• LENGTH is payload length + SRC and DST
• TYPE: 1 is message, 2 is echo/ack, 64 is error
• SRC: Address of Tester
• DST: Address of target ECU

HSFZ scanning

Identification with nmap

$ sudo nmap -sT 192.168.17.151 -Pn -p 6801
Starting Nmap 7.70 ( https://nmap.org ) at 2021-10-05 13:18 CEST
Nmap scan report for 192.168.17.151
Host is up (0.00024s latency).

PORT     STATE SERVICE
6801/tcp open  acnet

Nmap done: 1 IP address (1 host up) scanned in 0.15 seconds

HSFZ Vehicle announcement message

Iterate through all ECUs behind a gateway

>>> load_contrib("automotive.bmw.hsfz")
>>> load_contrib("automotive.uds")
>>> pkts = list()
>>> for i in range(0x100):
...:     with UDS_HSFZSocket(0xf4, i, "192.168.17.151") as sock:
...:         pkts += [(i, sock.sr1(UDS()/UDS_DSC(b"\x03"), timeout=0.05))]

Show results

>>> [x for x in pkts if x[1] is not None]
[(16,
  <UDS  service=DiagnosticSessionControlPositiveResponse ...>),
 (64,
  <UDS  service=DiagnosticSessionControlPositiveResponse ...>),
 (223,
  <UDS  service=DiagnosticSessionControlPositiveResponse ...>),
 (224,
  <UDS  service=DiagnosticSessionControlPositiveResponse ...>),
 (240,
  <UDS  service=NegativeResponse |<UDS_NR  ...|>>)]

DoIP

• Dagnostic over IP
• Transport layer protocol for UDS messages
• Specified in 2012
• Features:
  • vehicle announcement and vehicle discovery
  • vehicle basic status information retrieval
  • connection establishment, connection maintenance and vehicle gateway control
  • data routing to and from the vehicle's sub-components
  • error handling
• Supports (logical) addressing of ECUs
• Usually on port 13400
• Communicates over Ethernet 100 Base-TX
• Uses TCP and UDP dependent on the payload type
• Pinout on OBD-Connector is usually identical to HSFZ
• OBD-Pin 8 is EthernetActivationLine
• Fully supported by Wireshark

Identification with nmap

$ sudo nmap -sS 192.168.17.75 -Pn -p 13400
Starting Nmap 7.70 ( https://nmap.org ) at 2021-10-05 15:06 CEST
Nmap scan report for audi_cgw3_ecu (192.168.17.75)
Host is up (0.00013s latency).

PORT      STATE SERVICE
13400/tcp open  doip-data
MAC Address: 00:1A:37:BF:EE:E4 (Lear)

Nmap done: 1 IP address (1 host up) scanned in 0.96 seconds

Scan for supported tester addresses

>>> resps = list()
>>> for i in range(0x10000):
>>>     sock = DoIPSocket("192.168.17.137", activate_routing=False)
>>>     resps.append(sock.sr1(
...:        DoIP(payload_type=0x5, activation_type=0, source_address=i, reserved_oem=b""),
...:        verbose=False, timeout=1))
>>>     sock.close()
>>>
>>> print([x.logical_address_tester for x in resps if x.routing_activation_response])

Communication

>>> sock = UDS_DoIPSocket6("2001:16b8:3f0e:2f00:21a:37ff:febf:edb9")
Routing activation successful! Target address set to: 0x4010
>>> pkt = UDS() / UDS_RDBI(identifiers=[0x1000])
>>> resp = sock.sr1(pkt, timeout=1)
>>> resp.show()
###[ UDS ]### 
  service   = ReadDataByIdentifierPositiveResponse
###[ ReadDataByIdentifierPositiveResponse ]### 
     dataIdentifier= 0x1000
###[ Raw ]### 
        load      = '@Tr00pers22'

Communication (IPv4)

>>> sock = UDS_DoIPSocket("169.254.117.238")
Routing activation successful! Target address set to: 0x4010
>>> pkt = UDS() / UDS_RDBI(identifiers=[0x1000])
>>> resp = sock.sr1(pkt, timeout=1)
>>> resp.show()
###[ UDS ]### 
  service   = ReadDataByIdentifierPositiveResponse
###[ ReadDataByIdentifierPositiveResponse ]### 
     dataIdentifier= 0x1000
###[ Raw ]### 
        load      = '@Tr00pers22'

OBD (SAE J1979)

• On Board Diagnostic
• Different communications ways, we only care about CAN based communication
• OBD uses ISOTP as transport layer protocol
• 10 diagnostic services can be used for data gathering
• OBD can only readdata from ECUs
• OBD standard request ID 0x7DF (0x18DB33F1), response ID 0x7E8 (0x18DAF111)

OBD Scanner

>>> load_contrib("automotive.obd.obd")
>>> load_contrib("automotive.obd.scanner")
>>> load_contrib("isotp")
>>> socket = ISOTPSocket("can0", tx_id=0x7E8, rx_id=0x7DF, basecls=OBD)

>>> s = OBD_Scanner(socket)
>>> s.scan(timeout=10)

UDS

• Originated from KWP2000 (ISO 14230)
• Application layer protocol
• Transported by ISOTP (DoCAN) or TCP (DoIP or HSFZ)
• Use-Cases:
  • Configuration of ECUs
  • Execution of test routines
  • Software-updates
  • Information retrieval
  • Reading of DTCs
• Vehicle acts as server
• Computer / Tester can be treated as client
• Communication is driven by the client
• Communication is request / response driven

Stateful UDS Scanning ... Why?

Stateful UDS Scanning ... Why?

• Depending on the state, the RTT for an answer of the ECU is completly different
• Reason: Entirely different firmwares (Bootloader / Application) are executed depening on the state
• Stateful scanning is important to identify critical services and functionalities

Services that modify the system state

	UDS		GMLAN
10h	DiagnosticSessionControl	10h	InitiateDiagnosticOperation
11h	ECUReset
27h	SecurityAccess	27h	SecurityAccess
28h	CommunicationControl	28h	DisableNormalCommunication
31h	RoutineControl
		34h	RequestDownload
3Eh	TesterPresent	3Eh	TesterPresent
		A5h	ProgrammingMode

Sessions

diagnosticSessionTypes = {
        0x00: 'ISOSAEReserved',
        0x01: 'defaultSession',
        0x02: 'programmingSession',
        0x03: 'extendedDiagnosticSession',
        0x04: 'safetySystemDiagnosticSession',
        0x40: 'vehicleManufacturerSpecific_40',    # proprietary
        0x41: 'codingSession',                     # proprietary
        0x42: 'SWTSession',                        # proprietary
        0x43: 'HDDDownloadSession',                # proprietary
        0x7F: 'ISOSAEReserved'
}

Security Access

• Challenge - Response Authentication Procedure

• Categories of security access functions:

  • Simple Arithmetic Operations[1, 2]

    $$key = \neg seed$$

  • Mathematical Operations

    $$key = (seed * secret1 + secret2) \bigoplus (seed * secret3 + secret4) \bigoplus secret5$$

• ... continued ...

  • Proprietary XOR-Shift-Loops[3]

  • Cryptographic Operations

    $$key = RSA_{sign}(MD5(seed~|~salt), {private\_key})$$

• More examples: https://github.com/jglim/UnlockECU

Software-Update-Process

UDS_RDBI.dataIdentifiers[0xf100] = "activeSessionState"
UDS_RDBI.dataIdentifiers[0x100A] = "EnergyMode"
UDS_RDBI.dataIdentifiers[0x100e] = "ExtendedMode"
UDS_RDBI.dataIdentifiers[0xf186] = "activeDiagnosticSession"

{
    # diagnosticSessionType == 3
    3: {   # activeSessionState
        0x00: 'Bootloader',
        0x81: 'ExtendedSessionEnergyModeFlash',
        0x82: 'ExtendedSessionDTCOff',
        0x83: 'ExtendedSessionNDCDisabled',
        0x84: 'ExtendedSessionFlashModeActivated',
        0x85: 'ExtendedSessionFlashExit',
        0x86: 'ExtendedSessionStarted'
    }
}

Custom Sessions - Entering Bootloader

Custom Sessions - Entering Bootloader

Custom Sessions - Entering Bootloader

Detecting states

• protocol definition
• RTT for request and response
• reverse engineering, either firmwares or repair-shop testers
  • $\Rightarrow$ State identifiable by request and response
• changable RDBI identifiers, ideally with correlating changes to UDS requests
  • $\Rightarrow$ State identifiable by a RDBI query

Stateful Scanners in Scapy

• Request and Response $\Rightarrow$ New State / Node
• Request $\Rightarrow$ Transition Function / Edge

A system state machine $M$ is a directed graph $(S, E, \Delta)$, with the following properties:

• $S = \{s_0, s_1, \dots, s_n\}$ is a finite set of nodes, each node represents a system state.
• The state $s_0$ is defined as the default system state after the power-up of the system.
• $E = \{(v, w) \in S^2\}$ is a set of ordered pairs of nodes, called directed edges.
• $\Delta = \{\delta_0, \delta_1, \dots, \delta_k\}, \delta_k : S^2 \mapsto S, \delta_k(v, w) = z$ is a set of transitions functions for each $e \in E$.
• For each state $s_i \in S \setminus \{s_0\}$ a reset function $\delta_k \in \Delta, \delta_k(s_i, s_0) = s_0$ is given through the power cycle of the system.

Implementation

• The protocol (Packet):
  • defines state changes / Nodes
• A TestCase:
  • generates requests (Packet)
  • evaluates the response and estimates a new state
  • therfore, generates Edges
• An Executor:
  • stores Nodes and Edges in a graph
  • can toogle a reset
  • can modify the targets state according to a path in the graph

Implementation - Protocol

@EcuState.extend_pkt_with_modifier(UDS_DSCPR)
def UDS_DSCPR_modify_ecu_state(self, req, state):
    # type: (Packet, Packet, EcuState) -> None
    state.session = self.diagnosticSessionType  # type: ignore

@EcuState.extend_pkt_with_modifier(UDS_WDBIPR)
def UDS_WDBIPR_modify_ecu_state(self, req, state):
    # type: (Packet, Packet, EcuState) -> None
    if self.dataIdentifier == 0xf15a:
        dh = hash(req.fingerprint)
        state.fingerprint = str(dh)

Implementation - TestCase

class FingerprintTest(UDS_Enumerator, StateGeneratingServiceEnumerator):
    _description = "Fingerprint supported"

    def _get_initial_requests(self, **kwargs):
        # type: (Any) -> Iterable[Packet]
        return [UDS() / UDS_WDBI(dataIdentifier=0xf15a) / 
                bytes.fromhex("16 07 26 8f 04 d2 01 00 00 10 00 00 00")]

    def get_transition_function_description(self, edge):
        # type: (_Edge) -> str
        return "Fingerprint"

Implementation - Executor

with ISOTPNativeSocket(interface1, tx_id=0x6f1, rx_id=0x640, basecls=UDS) as sock:

    tc = [UDS_DSCEnumerator,
          UDS_TPEnumerator,
          FingerprintTest]

    s = UDS_Scanner(sock, reset_ecu_handler, test_cases=tc,
                    UDS_DSCEnumerator_kwargs={"scan_range": [1, 2, 3]})

    s.scan(timeout=60)

• An Executor (UDS_Scanner) can take an abitrary list of test cases
• A reset function gives a scanner the possibility to power cycle the target
• The scan can be done over ISOTPSockets, UDS_DoIPSockets or UDS_HSFZSockets

Stateful Fuzzers

class FingerprintFuzzer(UDS_Enumerator, StateGeneratingServiceEnumerator):
    _description = "Fingerprint-fuzzer"

    def _get_initial_requests(self, **kwargs):
        # type: (Any) -> Iterable[Packet]
        return [UDS() / UDS_WDBI(dataIdentifier=0xf15a) / bytes(RandBin(13))]

    def get_transition_function_description(self, edge):
        # type: (_Edge) -> str
        return "Fingerprint"

Results - Small Search Space

Results - Bigger Search Space

Results - Bigger Search Space

Results - Bigger Search Space

Things that affect the speed of the scan

• Number of enumerators
  • Every combination needs to be tested, exponential!
• Time it takes to reset
  • Should be optimized to the minimum possible
• Delays after session changes
  • Entering some sessions requires rebooting into a new firmware
  • Can lead to wrong state estimations, if delay is not respected
• Order of paths
  • Depth-first could be weak to aliased states. Random order can have more luck

State estimation

• General Problem: Lack of information.

  • Example: after entering a new diagnostic session, what is the current level of security access?

  • Specific ECUs might report state information through RDBI

• Hidden state

  • Example: some ECUs will only allow a programming session if energy mode is not in power-saving mode, but energy mode is not part of the UDS standard

• State aliasing

  • The scanner could detect two different states but they might actually be equivalent.

Documentation

• https://scapy.readthedocs.io/en/latest/layers/automotive.html
• https://scapy.readthedocs.io/en/latest/api/scapy.contrib.automotive.uds_scan.html
• https://www.researchgate.net/publication/351483528
• https://www.researchgate.net/publication/346656455

Scapy (Mainline)

• https://github.com/secdev/scapy

References

[1] Jürgen Dürrwang, Johannes Braun, Marcel Rumez, Reiner Kriesten, and Alexander Pretschner. Enhancement of Automotive Penetration Testing with Threat Analyses Results. SAE International Journal of Transportation Cybersecurity and Privacy, 1(2):91–112, 11 2018. doi:10.4271/11-01-02-0005.

[2] Yuefeng Du Sen Nie, Ling Liu. FREE-FALL: HACKING TESLA FROM WIRELESS TO CAN BUS. 2017. https://www.blackhat.com/docs/us-17/thursday/us-17-Nie-Free-Fall-Hacking-Tesla-From-Wireless-To-CAN-Bus-wp.pdf (accessed 2021-04-14).

[3] Jan Van den Herrewegen and Flavio D. Garcia. Beneath the Bonnet: A Breakdown of Diagnostic Security, pages 305–324. Volume 11098 of Lecture Notes in Computer Science. Springer International Publishing, 2018. URL: http://link.springer.com/10.1007/978-3-319-99073-6_15, doi:10.1007/978-3-319-99073-6_15.

Thank you for your attention!