CAN bus - revision history

Dank: /* iproute */

2023-02-19T09:01:58Z

iproute

← Older revision		Revision as of 09:01, 19 February 2023
Line 119:		Line 119:
	** Also simple timer-based interface for cyclic RX with failure notification		** Also simple timer-based interface for cyclic RX with failure notification

	===iproute===		===[[iproute]]===
	SocketCAN devices, including virtual interfaces (<tt>vcanX</tt>), are configured with the standard <tt>iproute</tt> tool.		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>		* Get statistics: <tt>ip -details -statistics link show canX</tt>

Dank: /* iproute */

2019-05-17T08:30:57Z

iproute

← Older revision		Revision as of 08:30, 17 May 2019
Line 124:		Line 124:
	** Alternatively, look at <tt>/proc/net/can/stats</tt>		** Alternatively, look at <tt>/proc/net/can/stats</tt>
	Options for the device include:		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		** <tt>restart</tt> can be used by itself for one-time bus recovery
	** A restart will send an error frame		** 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		** 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".		* <tt>bitrate</tt>: bits per second, i.e. "125000".

Dank: /* non-socketcan */

2019-05-17T08:29:57Z

non-socketcan

← Older revision		Revision as of 08:29, 17 May 2019
Line 144:		Line 144:
	The tools above all have ISO-TP variants in the [https://github.com/hartkopp/can-isotp can-isotp] project, replacing "can" with "isotp".		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~~===		===Non-SocketCAN===
	* Can4Linux -- avoid		* Can4Linux -- avoid
	* Lincan -- best of a bad lot, might have lower latency than SocketCAN		* Lincan -- best of a bad lot, might have lower latency than SocketCAN

Dank: /* Error States */

2019-05-17T08:29:10Z

Error States

← Older revision		Revision as of 08:29, 17 May 2019
Line 88:		Line 88:

	===Error States===		===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-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.		* Error-Passive: One or both counters are greater than 127. The ECU will respond to errors with (network-transparent) Passive Error Frames.

Dank: /* See Also */

2019-05-17T08:21:04Z

See Also

← Older revision		Revision as of 08:21, 17 May 2019
Line 180:		Line 180:
	* "[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://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://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

Dank: /* See Also */

2019-05-17T08:18:08Z

See Also

← Older revision		Revision as of 08:18, 17 May 2019
Line 179:		Line 179:
	* "[http://illmatics.com/Remote%20Car%20Hacking.pdf Remote Exploitation of an Unaltered Passenger Vehicle]", Miller and Valasek 2015		* "[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://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

Dank: /* See Also */

2019-05-17T08:13:02Z

See Also

← Older revision		Revision as of 08:13, 17 May 2019
Line 178:		Line 178:
	* "[http://www.autosec.org/pubs/cars-usenixsec2011.pdf Comprehensive Experimental Analyses of Automotive Attack Surfaces]", Checkoway et al 2011		* "[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		* "[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

Dank: /* Attacking CAN bus */

2019-05-17T08:12:30Z

Attacking CAN bus

← Older revision		Revision as of 08:12, 17 May 2019
Line 149:		Line 149:
	* Proprietary -- lol		* Proprietary -- lol

	==Attacking CAN ~~bus~~==		==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.		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.

Line 160:		Line 160:
	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.		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:		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.		* 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.

Dank at 08:09, 17 May 2019

2019-05-17T08:09:41Z

@@ Line 148: / Line 148: @@
 * Lincan -- best of a bad lot, might have lower latency than SocketCAN
 * Proprietary -- lol
 ==See Also==

Dank: /* See Also */

2019-05-17T07:44:40Z

See Also

← Older revision		Revision as of 07:44, 17 May 2019
Line 157:		Line 157:
	* "[https://rtime.felk.cvut.cz/~hanzalek/publications/Hanzalek10_168894.pdf A Comparison of Linux CAN Drivers and Their Applications]", Sojka et al 2010		* "[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://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