CAN bus

(16 intermediate revisions by the same user not shown)

Line 31:

* PCA82C252/TJA1054A -- 125Kbit, highly tolerant of 11898 cable fault modes, very low EM emissions, single-wire capability (33.3Kbit/s)

* MC33897/AUS5790 -- 33.33 or 83.33Kbit/s single-wire CAN

Nodes, especially e.g. sensors, typically send their state in Data Frames on a regular period.

===CAN IDs===

Lower IDs have priority over higher IDs, and form the 11-bit "Arbitration Field" in a CAN frame (there are 2 such fields in an Extended Frame, one of 11 and one of 18 bits, separated by two bits). While transmitting a message, each ECU must also listen. If it sees a 0 while sending a 1, it must cease to transmit until the current message ends. Logical 0 is the "dominant" signal:

Line 88:

===Error States===

Each ECU maintains an RX Error counter and TX Error Counter (REC/TEC), initialized to 0. Successful operations reduce the appropriate counter by 1, though never below 0. Errors increase the counters (usually TEC by 8, ~~REc~~ by 1). Depending on the values of these counters, each ECU is in one of three error states:

Each ECU maintains an RX Error counter and TX Error Counter (REC/TEC), initialized to 0. Successful operations reduce the appropriate counter by 1, though never below 0. Errors increase the counters (usually TEC by 8, REC by 1). Depending on the values of these counters, each ECU is in one of three error states:

* Error-Active: Both counters are less than 128. The ECU will respond to errors with an Active Error Frame.

* Error-Passive: One or both counters are greater than 127. The ECU will respond to errors with (network-transparent) Passive Error Frames.

Line 118:

* SOCK_DGRAM/CAN_BCM: Broadcast Manager mode, used for cyclic transmissions typical of sensor ECUs

** Also simple timer-based interface for cyclic RX with failure notification

~~===can-utils===~~

~~The [https://github.com/linux-can/can-utils can-utils] suite implements basic programs atop SocketCAN:~~

* candump: log frames to file

* canplayer: replay logged frames to CAN interface

* cansniffer: show IDs and changing data in real time (limited to 11-bit IDs)

* cansend: transmit a CAN frame

~~The tools above all have ISO-TP variants in the [https://github.com/hartkopp/can-isotp can-isotp] project, replacing "can" with "isotp".~~

===iproute===

===[[iproute]]===

SocketCAN devices, including virtual interfaces (<tt>vcanX</tt>), are configured with the standard <tt>iproute</tt> tool.

* Get statistics: <tt>ip -details -statistics link show canX</tt>

** Alternatively, look at <tt>/proc/net/can/stats</tt>

Options for the device include:

* <tt>restart-ms</tt>: automatic restart time in milliseconds in the event of bus-off state

* <tt>restart-ms</tt>: automatic restart time in milliseconds in the event of bus-off state (default: disabled)

** <tt>restart</tt> can be used by itself for one-time bus recovery

** A restart will send an error frame

* <tt>one-shot</tt>: don't attempt to retransmit when we don't see an ACK

* <tt>one-shot</tt>: don't attempt to retransmit when we don't see an ACK (default: disabled)

** Note: when sniffing a <b>non-virtual</b> CAN interface, you must either (a) see an ACK -- requiring a connected device, or (b) be in one-shot mode, or you will not see your transmitted frames

* <tt>bitrate</tt>: bits per second, i.e. "125000".

Line 142:

Line 135:

* <tt>triple-sampling</tt>: whether to sample between each of the 4 bit quanta

* <tt>berr-reporting</tt>: control delivery of error state event interrupts (default: disabled)

===can-utils===

The [https://github.com/linux-can/can-utils can-utils] suite implements basic programs atop SocketCAN:

* candump: log frames to file

* canplayer: replay logged frames to CAN interface

* cansniffer: show IDs and changing data in real time (limited to 11-bit IDs)

* cansend: transmit a CAN frame

The tools above all have ISO-TP variants in the [https://github.com/hartkopp/can-isotp can-isotp] project, replacing "can" with "isotp".

===Non-SocketCAN===

* Can4Linux -- avoid

* Lincan -- best of a bad lot, might have lower latency than SocketCAN

* Proprietary -- lol

==Attacking CAN buses==

It is first necessary to map sniffed CAN data to a semantic model of diagnostics and commands. This is not generally difficult if one has access to the generating ECUs. Upon connection to an active CAN network, many ECUs are likely to be periodically broadcasting. Analyze their transmit periods and perform standard differential analysis on the payloads. Manipulate various inputs and observe how the traffic changes. I've found it useful to graph IDs against time in a scatterplot, using the data length to size my points, and a continuous mapping of raw data bytes to RGB values for point color.

Once the CAN messages corresponding to your desired behavioral results have been solved, it's a matter of

* Injecting them into the CAN network,

* Having them reach the desired controller, and

* Establishing dominance over a competing ECU

Injection is trivial, requiring nothing more than a physical connection and the correct data link settings (timing etc.). Reaching the desired controller is a matter of gateways and CAN networks. If a filtering gateway sits between your ingress and the target ECU, it will be necessary to render the intermediate device passive, or seize control of it via firmware modifications.

Establishing dominance is a matter of conflict; some data producer is presumably broadcasting a datum, perhaps "DOOR LOCKED". If we were to simply inject the same ID with the "DOOR UNLOCKED" message, it's likely to be quickly obsoleted by an ECU broadcast. Even if we do manage to take effect for a short time before being invalidated, the resultant behavior can range from oscillation, to lockup, to lockout of CAN-based control. There are two main strategies; more details are available from the papers linked below:

* Knock out the conflicting ECU. Given physical access, it simply can be disconnected. It might be possible to put it in a "diagnostic" or "bootrom" mode where it ceases to transmit. Flooding the bus with garbage will often knock some ECUs offline, though this can also affect the target device.

* Invalidate the conflicting source ECU's messages. Remember that an Active Error Frame will disrupt any ongoing message. If we are able to act quickly enough (almost certainly requiring hardware support, but nothing an FPGA can't solve), we can see the rival ECU emit the contested ID, and immediately invalidate their traffic. Indeed, this will usually be sufficient to cause the rival ECU to enter the error-passive or bus-off states described above.

A third strategy is to find patterns of behavior which cause the target or a gateway to ignore what seems to be invalid traffic. Some ECUs require nonces to change in order to act on a message, for instance; if we can predict these nonces, we can preempt the source ECU's traffic with our own.

==See Also==

* CiA's [https://www.can-cia.org/can-knowledge/can/can-history/ History of CAN], focusing on the early Bosch years

* Kvaser's list of [https://www.kvaser.com/about-can/can-controllers-transceivers/can-bus-transceivers/ CAN transceivers]

** Their whole [https://www.kvaser.com/can-protocol-tutorial/ CAN protocol tutorial] is best-of-breed, really

* [https://en.wikipedia.org/wiki/OBD-II_PIDs ODB-II PIDs] at Wikipedia

* Nicely HTMLized [https://www.kernel.org/doc/html/latest/networking/can.html kernel documentation] at kernel.org

* "[https://rtime.felk.cvut.cz/~hanzalek/publications/Hanzalek10_168894.pdf A Comparison of Linux CAN Drivers and Their Applications]", Sojka et al 2010

* "[http://illmatics.com/can%20message%20injection.pdf CAN Message Injection, OG Dynamite Edition]", Miller and Valasek 2016

* "[http://www.autosec.org/pubs/cars-usenixsec2011.pdf Comprehensive Experimental Analyses of Automotive Attack Surfaces]", Checkoway et al 2011

* "[http://illmatics.com/Remote%20Car%20Hacking.pdf Remote Exploitation of an Unaltered Passenger Vehicle]", Miller and Valasek 2015

* "[https://www.can-cia.org/fileadmin/resources/documents/proceedings/2012_webermann.pdf CAN Error Injection, a Simple but Versatile Approach]", Webermann and Block 2012

* "[https://rtcl.eecs.umich.edu/wordpress/wp-content/uploads/ktcho_busoff_CCS_16.pdf Error-Handling of In-Vehicle Networks Makes Them Vulnerable]", Cho and Shin 2016

* "[https://www.usenix.org/system/files/conference/woot15/woot15-paper-foster.pdf Fast and Vulnerable: A Tale of Telematic Failures]", Foster et al 2015

CAN bus: Difference between revisions

Dank (talk | contribs)

@@ Line 31: / Line 31: @@
 * PCA82C252/TJA1054A -- 125Kbit, highly tolerant of 11898 cable fault modes, very low EM emissions, single-wire capability (33.3Kbit/s)
 * MC33897/AUS5790 -- 33.33 or 83.33Kbit/s single-wire CAN
+Nodes, especially e.g. sensors, typically send their state in Data Frames on a regular period.
 ===CAN IDs===
 Lower IDs have priority over higher IDs, and form the 11-bit "Arbitration Field" in a CAN frame (there are 2 such fields in an Extended Frame, one of 11 and one of 18 bits, separated by two bits). While transmitting a message, each ECU must also listen. If it sees a 0 while sending a 1, it must cease to transmit until the current message ends. Logical 0 is the "dominant" signal:
@@ Line 88: / Line 88: @@
 ===Error States===
-Each ECU maintains an RX Error counter and TX Error Counter (REC/TEC), initialized to 0. Successful operations reduce the appropriate counter by 1, though never below 0. Errors increase the counters (usually TEC by 8, REc by 1). Depending on the values of these counters, each ECU is in one of three error states:
+Each ECU maintains an RX Error counter and TX Error Counter (REC/TEC), initialized to 0. Successful operations reduce the appropriate counter by 1, though never below 0. Errors increase the counters (usually TEC by 8, REC by 1). Depending on the values of these counters, each ECU is in one of three error states:
 * Error-Active: Both counters are less than 128. The ECU will respond to errors with an Active Error Frame.
 * Error-Passive: One or both counters are greater than 127. The ECU will respond to errors with (network-transparent) Passive Error Frames.
@@ Line 118: / Line 118: @@
 * SOCK_DGRAM/CAN_BCM: Broadcast Manager mode, used for cyclic transmissions typical of sensor ECUs
 ** Also simple timer-based interface for cyclic RX with failure notification
-===can-utils===
-The [https://github.com/linux-can/can-utils can-utils] suite implements basic programs atop SocketCAN:
-* candump: log frames to file
-* canplayer: replay logged frames to CAN interface
-* cansniffer: show IDs and changing data in real time (limited to 11-bit IDs)
-* cansend: transmit a CAN frame
-The tools above all have ISO-TP variants in the [https://github.com/hartkopp/can-isotp can-isotp] project, replacing "can" with "isotp".
-===iproute===
+===[[iproute]]===
 SocketCAN devices, including virtual interfaces (<tt>vcanX</tt>), are configured with the standard <tt>iproute</tt> tool.
 * Get statistics: <tt>ip -details -statistics link show canX</tt>
 ** Alternatively, look at <tt>/proc/net/can/stats</tt>
 Options for the device include:
-* <tt>restart-ms</tt>: automatic restart time in milliseconds in the event of bus-off state
+* <tt>restart-ms</tt>: automatic restart time in milliseconds in the event of bus-off state (default: disabled)
 ** <tt>restart</tt> can be used by itself for one-time bus recovery
 ** A restart will send an error frame
-* <tt>one-shot</tt>: don't attempt to retransmit when we don't see an ACK
+* <tt>one-shot</tt>: don't attempt to retransmit when we don't see an ACK (default: disabled)
 ** Note: when sniffing a <b>non-virtual</b> CAN interface, you must either (a) see an ACK -- requiring a connected device, or (b) be in one-shot mode, or you will not see your transmitted frames
 * <tt>bitrate</tt>: bits per second, i.e. "125000".
@@ Line 142: / Line 135: @@
 * <tt>triple-sampling</tt>: whether to sample between each of the 4 bit quanta
 * <tt>berr-reporting</tt>: control delivery of error state event interrupts (default: disabled)
+===can-utils===
+The [https://github.com/linux-can/can-utils can-utils] suite implements basic programs atop SocketCAN:
+* candump: log frames to file
+* canplayer: replay logged frames to CAN interface
+* cansniffer: show IDs and changing data in real time (limited to 11-bit IDs)
+* cansend: transmit a CAN frame
+The tools above all have ISO-TP variants in the [https://github.com/hartkopp/can-isotp can-isotp] project, replacing "can" with "isotp".
+===Non-SocketCAN===
+* Can4Linux -- avoid
+* Lincan -- best of a bad lot, might have lower latency than SocketCAN
+* Proprietary -- lol
+==Attacking CAN buses==
+It is first necessary to map sniffed CAN data to a semantic model of diagnostics and commands. This is not generally difficult if one has access to the generating ECUs. Upon connection to an active CAN network, many ECUs are likely to be periodically broadcasting. Analyze their transmit periods and perform standard differential analysis on the payloads. Manipulate various inputs and observe how the traffic changes. I've found it useful to graph IDs against time in a scatterplot, using the data length to size my points, and a continuous mapping of raw data bytes to RGB values for point color.
+Once the CAN messages corresponding to your desired behavioral results have been solved, it's a matter of
+* Injecting them into the CAN network,
+* Having them reach the desired controller, and
+* Establishing dominance over a competing ECU
+Injection is trivial, requiring nothing more than a physical connection and the correct data link settings (timing etc.). Reaching the desired controller is a matter of gateways and CAN networks. If a filtering gateway sits between your ingress and the target ECU, it will be necessary to render the intermediate device passive, or seize control of it via firmware modifications.
+Establishing dominance is a matter of conflict; some data producer is presumably broadcasting a datum, perhaps "DOOR LOCKED". If we were to simply inject the same ID with the "DOOR UNLOCKED" message, it's likely to be quickly obsoleted by an ECU broadcast. Even if we do manage to take effect for a short time before being invalidated, the resultant behavior can range from oscillation, to lockup, to lockout of CAN-based control. There are two main strategies; more details are available from the papers linked below:
+* Knock out the conflicting ECU. Given physical access, it simply can be disconnected. It might be possible to put it in a "diagnostic" or "bootrom" mode where it ceases to transmit. Flooding the bus with garbage will often knock some ECUs offline, though this can also affect the target device.
+* Invalidate the conflicting source ECU's messages. Remember that an Active Error Frame will disrupt any ongoing message. If we are able to act quickly enough (almost certainly requiring hardware support, but nothing an FPGA can't solve), we can see the rival ECU emit the contested ID, and immediately invalidate their traffic. Indeed, this will usually be sufficient to cause the rival ECU to enter the error-passive or bus-off states described above.
+A third strategy is to find patterns of behavior which cause the target or a gateway to ignore what seems to be invalid traffic. Some ECUs require nonces to change in order to act on a message, for instance; if we can predict these nonces, we can preempt the source ECU's traffic with our own.
+==See Also==
+* CiA's [https://www.can-cia.org/can-knowledge/can/can-history/ History of CAN], focusing on the early Bosch years
+* Kvaser's list of [https://www.kvaser.com/about-can/can-controllers-transceivers/can-bus-transceivers/ CAN transceivers]
+** Their whole [https://www.kvaser.com/can-protocol-tutorial/ CAN protocol tutorial] is best-of-breed, really
+* [https://en.wikipedia.org/wiki/OBD-II_PIDs ODB-II PIDs] at Wikipedia
+* Nicely HTMLized [https://www.kernel.org/doc/html/latest/networking/can.html kernel documentation] at kernel.org
+* "[https://rtime.felk.cvut.cz/~hanzalek/publications/Hanzalek10_168894.pdf A Comparison of Linux CAN Drivers and Their Applications]", Sojka et al 2010
+* "[http://illmatics.com/can%20message%20injection.pdf CAN Message Injection, OG Dynamite Edition]", Miller and Valasek 2016
+* "[http://www.autosec.org/pubs/cars-usenixsec2011.pdf Comprehensive Experimental Analyses of Automotive Attack Surfaces]", Checkoway et al 2011
+* "[http://illmatics.com/Remote%20Car%20Hacking.pdf Remote Exploitation of an Unaltered Passenger Vehicle]", Miller and Valasek 2015
+* "[https://www.can-cia.org/fileadmin/resources/documents/proceedings/2012_webermann.pdf CAN Error Injection, a Simple but Versatile Approach]", Webermann and Block 2012
+* "[https://rtcl.eecs.umich.edu/wordpress/wp-content/uploads/ktcho_busoff_CCS_16.pdf Error-Handling of In-Vehicle Networks Makes Them Vulnerable]", Cho and Shin 2016
+* "[https://www.usenix.org/system/files/conference/woot15/woot15-paper-foster.pdf Fast and Vulnerable: A Tale of Telematic Failures]", Foster et al 2015