CAN
CAN DoS Recovery
Measures the load of a CAN bus, then proceeds to DoS the network preventing communication and causing errors. A few seconds later, the bus load is measured again to ensure that the network has returned to a normal state.
Fail Condition: If the bus load at this time is vastly different from the control measurement, this test will be marked as failed.
Parameters
| Name | Default Value | Description |
|---|---|---|
| CAN Interface | can0 | The network interface on which to interact with the CAN Bus |
| Baud Rate | 500000 | The baud rate of the CAN network (e.g. 125000, 250000, 500000, 1000000) |
Outcomes
SUCCESS: The CAN bus load returned to normal after the DoS attack, indicating successful recovery and resilience.
Recommendations:
NO_RESPONSE: The device did not respond to basic queries from the test.
Recommendations:
- Check physical connections and device power.
FAILURE: The CAN bus load did not return to normal after the DoS attack, indicating incomplete or failed recovery.
Recommendations:
- Investigate error handling and recovery logic.
- Review device/network logs for anomalies.
Example Usage
bw_cli run -a dos_recovery -p device=can0 -p baud=500000UDS Communication Control
Attempts to toggle the communication state of a module via UDS. Disabling communication of a module can cause serious issues and should not be allowed without authentication.
Fail Condition: If the UDS Server responds with success to the Communication Control request, the test will be marked as failed.
Parameters
| Name | Default Value | Description |
|---|---|---|
| CAN Interface | can0 | The network interface on which to interact with the CAN Bus |
| Extended ID | False | Whether or not to use 29 bit arbitration IDs |
| Request Arbitration ID | 0x7e0 | The arbitration ID to send requests to |
| Response Arbitration ID | 0x7e8 | The arbitration ID where replies will be sent |
| Diagnostic session | 1 | The diagnostic session (or pair) to enter for this test |
Outcomes
SUCCESS: Communication control functions were not available to the test script.
Recommendations:
NO_RESPONSE: The device did not respond to basic queries from the test.
Recommendations:
- Check physical connections and device power.
FAILURE: Communication control service allowed disabling of normal communication without proper authentication, indicating a security vulnerability.
Recommendations:
- Implement proper authentication for communication control operations.
- Restrict communication control service in production environments.
- Review impact of communication disruption on system safety.
- Implement additional safeguards against communication denial of service.
Example Usage
bw_cli run -a uds_comm_control -p device=can0 -p extended_id=False -p req_arb=0x7e0 -p resp_arb=0x7e8 -p session=1UDS IO Control
Attempts to control the IO state of a module via UDS. Controlling the IO can cause the vehicle to act in unexpected ways and should not be allowed without authentication.
Fail Condition: If the UDS Server replies success to the IO Control request, this test will be marked as failed.
Parameters
| Name | Default Value | Description |
|---|---|---|
| CAN Interface | can0 | The network interface on which to interact with the CAN Bus |
| Extended ID | False | Whether or not to use 29 bit arbitration IDs |
| Request Arbitration ID | 0x7e0 | The arbitration ID to send requests to |
| Response Arbitration ID | 0x7e8 | The arbitration ID where replies will be sent |
| Minimum DID | 0xF000 | Start of Data ID range to test against |
| Maximum DID | 0xFFFF | End of Data ID range to test against |
| Diagnostic session | 1 | The diagnostic session (or pair) to enter for this test |
Outcomes
SUCCESS: IO control functions were not accessible to the test script.
Recommendations:
NO_RESPONSE: The device did not respond to basic queries from the test.
Recommendations:
- Check physical connections and device power.
FAILURE: IO control was successful without authentication, allowing unauthorized manipulation of system inputs and outputs.
Recommendations:
- Implement proper authentication for IO control operations.
- Restrict IO control service availability in production.
- Review safety implications of unauthorized IO manipulation.
- Implement additional safeguards for critical IO functions.
Example Usage
bw_cli run -a uds_io_control -p device=can0 -p extended_id=False -p req_arb=0x7e0 -p resp_arb=0x7e8 -p min_did=0xF000 -p max_did=0xFFFF -p session=1UDS Read Memory by Address
Will iterate through memory formats and addresses attempting to read out module memory. Memory should not be directly readable without authentication.
Fail Condition: If memory contents are read, this test will be marked as failed.
Parameters
| Name | Default Value | Description |
|---|---|---|
| CAN Interface | can0 | The network interface on which to interact with the CAN Bus |
| Extended ID | False | Whether or not to use 29 bit arbitration IDs |
| Request Arbitration ID | 0x7e0 | The arbitration ID to send requests to |
| Response Arbitration ID | 0x7e8 | The arbitration ID where replies will be sent |
| Address Scan Interval | 0x100000 | The address interval that this test scans with, the lower the number the more granular the scan (which can find small memory regions), but takes more time. |
| Diagnostic session | 1 | The diagnostic session (or pair) to enter for this test |
Outcomes
SUCCESS: No memory contents were readable without proper authentication, indicating secure memory protection is in place.
Recommendations:
- Continue monitoring for any changes in memory protection.
- Verify that authentication mechanisms are properly implemented.
- Document the security posture for compliance purposes.
NO_RESPONSE: The device did not respond to basic queries from the test.
Recommendations:
- Check physical connections and device power.
FAILURE: Memory contents were successfully read using UDS ReadMemoryByAddress service, indicating insufficient memory protection.
Recommendations:
- Implement proper memory access controls and authentication.
- Review and restrict UDS service availability in production.
- Consider memory segmentation and protection mechanisms.
- Audit all accessible memory regions for sensitive data.
Example Usage
bw_cli run -a uds_read_by_addr -p device=can0 -p extended_id=False -p req_arb=0x7e0 -p resp_arb=0x7e8 -p scan_interval=0x100000 -p session=1UDS Read Memory by Did
Attempts to dynamically define a did as a memory regoin, and read memory
Fail Condition: Able to read memory
Parameters
| Name | Default Value | Description |
|---|---|---|
| CAN Interface | can0 | The network interface on which to interact with the CAN Bus |
| Extended ID | False | Whether or not to use 29 bit arbitration IDs |
| Request Arbitration ID | 0x7e0 | The arbitration ID to send requests to |
| Response Arbitration ID | 0x7e8 | The arbitration ID where replies will be sent |
| Attempted DID to define | 0xF000 | The actual did to attempt to be defined as memory |
| Attempted address to read | 0x0 | The actual address to attempt to read from |
| Attempted size to read | 0x10 | The actual size to attempt to read from |
| Diagnostic session | 1 | The diagnostic session (or pair) to enter for this test |
Outcomes
SUCCESS: Dynamic DID definition and memory reading was properly restricted, preventing unauthorized memory access.
Recommendations:
- Continue monitoring DID definition service security controls.
- Verify proper authentication requirements for memory-mapped DIDs.
- Document security controls for compliance purposes.
NO_RESPONSE: The device did not respond to basic queries from the test.
Recommendations:
- Check physical connections and device power.
FAILURE: Successfully defined a DID as a memory region and read memory contents, indicating insufficient access controls.
Recommendations:
- Implement proper authentication for DID definition services.
- Restrict dynamic DID creation in production environments.
- Review memory access controls and segmentation.
- Audit accessible memory regions for sensitive data exposure.
Example Usage
bw_cli run -a uds_read_memory_by_did -p device=can0 -p extended_id=False -p req_arb=0x7e0 -p resp_arb=0x7e8 -p did=0xF000 -p address=0x0 -p size=0x10 -p session=1UDS Write Memory by Address
Will iterate through memory formats and addresses attempting to write module memory. Memory should not be directly writable in a default session.
Fail Condition: If the UDS Server responds with success this test will be marked as failed.
Parameters
| Name | Default Value | Description |
|---|---|---|
| CAN Interface | can0 | The network interface on which to interact with the CAN Bus |
| Extended ID | False | Whether or not to use 29 bit arbitration IDs |
| Request Arbitration ID | 0x7e0 | The arbitration ID to send requests to |
| Response Arbitration ID | 0x7e8 | The arbitration ID where replies will be sent |
| Address Scan Interval | 0x100000 | The address interval that this test scans with, the lower the number the more granular the scan (which can find small memory regions), but takes more time. |
| Diagnostic session | 1 | The diagnostic session (or pair) to enter for this test |
Outcomes
SUCCESS: No memory writes were successful without proper authentication, indicating secure memory protection is in place.
Recommendations:
- Continue monitoring for any changes in memory write protection.
- Verify that authentication mechanisms are properly implemented.
- Document the security posture for compliance purposes.
NO_RESPONSE: The device did not respond to basic queries from the test.
Recommendations:
- Check physical connections and device power.
FAILURE: Memory contents were successfully written using UDS WriteMemoryByAddress service, indicating insufficient memory protection.
Recommendations:
- Implement proper memory access controls and authentication.
- Review and restrict UDS service availability in production.
- Consider memory segmentation and write protection mechanisms.
- Audit all writable memory regions for potential security impact.
Example Usage
bw_cli run -a uds_write_by_addr -p device=can0 -p extended_id=False -p req_arb=0x7e0 -p resp_arb=0x7e8 -p scan_interval=0x100000 -p session=1UDS Write Data by Identifier
Will iterate through given DID range attempting to write module memory. Memory should not be writable in any session without security unlock.
Fail Condition: If the UDS Server responds with write successful, this test will be marked as failed.
Parameters
| Name | Default Value | Description |
|---|---|---|
| CAN Interface | can0 | The network interface on which to interact with the CAN Bus |
| Extended ID | False | Whether or not to use 29 bit arbitration IDs |
| Request Arbitration ID | 0x7e0 | The arbitration ID to send requests to |
| Response Arbitration ID | 0x7e8 | The arbitration ID where replies will be sent |
| Minimum DID | 0xF000 | Start of Data ID range to test against |
| Maximum DID | 0xFFFF | End of Data ID range to test against |
| Diagnostic session | 1 | The diagnostic session (or pair) to enter for this test |
Outcomes
SUCCESS: No data writes were successful through DID-based services without proper authentication, indicating secure data protection.
Recommendations:
- Continue monitoring DID write access controls.
- Verify authentication mechanisms remain robust.
- Document security controls for compliance purposes.
NO_RESPONSE: The device did not respond to basic queries from the test.
Recommendations:
- Check physical connections and device power.
FAILURE: Data was successfully written through UDS WriteDataByIdentifier service without authentication, indicating insufficient access controls.
Recommendations:
- Implement proper authentication for DID write operations.
- Review and restrict writable DID ranges in production.
- Consider data validation and integrity controls.
- Audit all writable DIDs for potential security impact.
Example Usage
bw_cli run -a uds_write_by_id -p device=can0 -p extended_id=False -p req_arb=0x7e0 -p resp_arb=0x7e8 -p min_did=0xF000 -p max_did=0xFFFF -p session=1UDS Request Upload
Iterates through upload formats and requests to upload files from an ECU. Request Upload can expose critical information about the firmware and calibrations, it should not be allowed without access control.
Fail Condition: If the UDS Server responds with success, this test will be marked as failed.
Parameters
| Name | Default Value | Description |
|---|---|---|
| CAN Interface | can0 | The network interface on which to interact with the CAN Bus |
| Extended ID | False | Whether or not to use 29 bit arbitration IDs |
| Request Arbitration ID | 0x7e0 | The arbitration ID to send requests to |
| Response Arbitration ID | 0x7e8 | The arbitration ID where replies will be sent |
| Address Scan Interval | 0x100000 | The address interval that this test scans with, the lower the number the more granular the scan (which can find small memory regions), but takes more time. |
| Diagnostic session | 1 | The diagnostic session (or pair) to enter for this test |
Outcomes
SUCCESS: Upload requests were properly rejected and authentication was required, preventing unauthorized firmware/data extraction.
Recommendations:
- Continue monitoring upload service security controls.
- Verify authentication mechanisms remain robust.
- Document security controls for compliance purposes.
NO_RESPONSE: The device did not respond to basic queries from the test.
Recommendations:
- Check physical connections and device power.
FAILURE: Upload requests were accepted without proper authentication, allowing unauthorized firmware/data extraction.
Recommendations:
- Implement proper authentication for upload operations.
- Restrict upload service availability in production.
- Review data classification and access controls.
- Audit uploaded data for sensitive information exposure.
Example Usage
bw_cli run -a uds_request_upload -p device=can0 -p extended_id=False -p req_arb=0x7e0 -p resp_arb=0x7e8 -p scan_interval=0x100000 -p session=1UDS Request Download
Iterates through download formats and requests to download files to an ECU. Request Download can modify the firmware and behavior of a device, it should not be allowed without access control.
Fail Condition: If the UDS Server responds with success, this test will be marked as failed.
Parameters
| Name | Default Value | Description |
|---|---|---|
| CAN Interface | can0 | The network interface on which to interact with the CAN Bus |
| Extended ID | False | Whether or not to use 29 bit arbitration IDs |
| Request Arbitration ID | 0x7e0 | The arbitration ID to send requests to |
| Response Arbitration ID | 0x7e8 | The arbitration ID where replies will be sent |
| Address Scan Interval | 0x100000 | The address interval that this test scans with, the lower the number the more granular the scan (which can find small memory regions), but takes more time. |
| Diagnostic session | 1 | The diagnostic session (or pair) to enter for this test |
Outcomes
SUCCESS: Download requests were properly rejected and authentication was required, preventing unauthorized firmware/data downloads.
Recommendations:
- Continue monitoring download service security controls.
- Verify authentication mechanisms remain robust.
- Document security controls for compliance purposes.
NO_RESPONSE: The device did not respond to basic queries from the test.
Recommendations:
- Check physical connections and device power.
FAILURE: Download requests were accepted without proper authentication, allowing unauthorized firmware/data modification.
Recommendations:
- Implement proper authentication for download operations.
- Restrict download service availability in production.
- Implement code signing and integrity verification.
- Review firmware update security mechanisms.
Example Usage
bw_cli run -a uds_request_download -p device=can0 -p extended_id=False -p req_arb=0x7e0 -p resp_arb=0x7e8 -p scan_interval=0x100000 -p session=1UDS Security Access
Validates security access seed strength and failure timeout. The test will validate that Service 27 always returns a unique seed of sufficient length and is protected from brute force attacks.
Fail Condition: If duplicate seeds are obtained, or a seed of insufficient length is seen for any access level, this test will be marked as failed. If insufficient timeout is implement between seed access attempts, this test will be marked as failed.
Parameters
| Name | Default Value | Description |
|---|---|---|
| CAN Interface | can0 | The network interface on which to interact with the CAN Bus |
| Extended ID | False | Whether or not to use 29 bit arbitration IDs |
| Request Arbitration ID | 0x7e0 | The arbitration ID to send requests to |
| Response Arbitration ID | 0x7e8 | The arbitration ID where replies will be sent |
| Expected Minimum Seed Length | 8 | The minimum number of bytes the seed shall be to pass this test |
| Number of Seeds Requested | 5 | Number of seeds requested when checking for duplicates |
| Diagnostic session | 1 | The diagnostic session (or pair) to enter for this test |
Outcomes
SUCCESS: Security Access service is properly implemented with strong, unique seeds and appropriate timeout protection.
Recommendations:
- Continue monitoring seed strength and uniqueness.
- Verify timeout mechanisms remain effective against brute force attacks.
- Document security controls for compliance purposes.
NO_RESPONSE: The device did not respond to basic queries from the test.
Recommendations:
- Check physical connections and device power.
FAILURE: Security Access service returned duplicate seeds, indicating poor randomness or implementation flaws.
Recommendations:
- Fix seed generation to ensure uniqueness.
- Implement proper random number generation.
- Review seed storage and caching mechanisms.
- Test with larger sample sizes to verify randomness.
Example Usage
bw_cli run -a uds_security_access -p device=can0 -p extended_id=False -p req_arb=0x7e0 -p resp_arb=0x7e8 -p min_seed_len=8 -p seeds_requested=5 -p session=1CCP Upload
Attempts to use the CCP upload service to read device memory.
Fail Condition: If the server responds with success the test will be marked as failed with severity medium. If the server responds with an ‘out of range’ error code, the test will be marked as failed with severity low.
Parameters
| Name | Default Value | Description |
|---|---|---|
| CAN Interface | can0 | The network interface on which to interact with the CAN Bus |
| Extended ID | False | Whether or not to use 29 bit arbitration IDs |
| Request Arbitration ID | 0x7e0 | The arbitration ID to send requests to |
| Response Arbitration ID | 0x7e8 | The arbitration ID where replies will be sent |
Outcomes
SUCCESS: CCP upload operations required proper authentication and were secured against unauthorized access.
Recommendations:
- Continue monitoring CCP upload service security controls.
- Verify authentication mechanisms remain robust.
- Document security controls for compliance purposes.
NO_RESPONSE: The device did not respond to basic queries from the test.
Recommendations:
- Check physical connections and device power.
FAILURE: CCP upload service allowed data transmission without proper authentication, indicating a security vulnerability.
Recommendations:
- Implement proper authentication for CCP upload operations.
- Restrict CCP upload service availability in production.
- Review data validation and integrity controls.
- Audit uploaded data for potential security implications.
Example Usage
bw_cli run -a ccp_upload -p device=can0 -p extended_id=False -p req_arb=0x7e0 -p resp_arb=0x7e8CCP Download
Attempts to use the CCP download service to write device memory.
Fail Condition: If the CCP Server responds with an out of range response or with memory contents this test will be failed. If the server replies with out of range, the severity will be low, otherwise if memory is written, the severity will be high.
Parameters
| Name | Default Value | Description |
|---|---|---|
| CAN Interface | can0 | The network interface on which to interact with the CAN Bus |
| Extended ID | False | Whether or not to use 29 bit arbitration IDs |
| Request Arbitration ID | 0x7e0 | The arbitration ID to send requests to |
| Response Arbitration ID | 0x7e8 | The arbitration ID where replies will be sent |
Outcomes
SUCCESS: CCP download operations were properly secured and authentication was required, preventing unauthorized memory access.
Recommendations:
- Continue monitoring CCP service availability and access controls.
- Verify authentication mechanisms are properly implemented.
- Document security controls for compliance purposes.
NO_RESPONSE: The device did not respond to basic queries from the test.
Recommendations:
- Check physical connections and device power.
FAILURE: CCP download service allowed memory extraction without proper authentication, indicating a security vulnerability.
Recommendations:
- Implement proper authentication for CCP download operations.
- Restrict CCP service availability in production environments.
- Review memory access controls and segmentation.
- Audit downloaded memory contents for sensitive data exposure.
Example Usage
bw_cli run -a ccp_download -p device=can0 -p extended_id=False -p req_arb=0x7e0 -p resp_arb=0x7e8CCP Program
Attempts to use the CCP program service to program device memory.
Fail Condition: If the server responds with success the test will be marked as failed with severity high. If the server responds with an ‘out of range’ error code, the test will be marked as failed with severity low.
Parameters
| Name | Default Value | Description |
|---|---|---|
| CAN Interface | can0 | The network interface on which to interact with the CAN Bus |
| Extended ID | False | Whether or not to use 29 bit arbitration IDs |
| Request Arbitration ID | 0x7e0 | The arbitration ID to send requests to |
| Response Arbitration ID | 0x7e8 | The arbitration ID where replies will be sent |
Outcomes
SUCCESS: CCP programming operations were properly secured and authentication was required, preventing unauthorized code modification.
Recommendations:
- Continue monitoring CCP programming service security controls.
- Verify code signing and authentication mechanisms.
- Document security posture for compliance purposes.
NO_RESPONSE: The device did not respond to basic queries from the test.
Recommendations:
- Check physical connections and device power.
FAILURE: CCP programming service allowed code modification without proper authentication, indicating a critical security vulnerability.
Recommendations:
- Immediately implement authentication for CCP programming operations.
- Restrict CCP programming service in production environments.
- Implement code signing and integrity verification.
- Audit programmed memory for unauthorized modifications.
Example Usage
bw_cli run -a ccp_program -p device=can0 -p extended_id=False -p req_arb=0x7e0 -p resp_arb=0x7e8XCP Upload
Tests if it is posible to read memory with XCP Upload with STD commands 0xF5 (UPLOAD) and 0xF4 (SHORT_UPLOAD) on a common range of memory addresses.
Fail Condition: If the XCP server responds success to either request this test will be marked as failed.
Parameters
| Name | Default Value | Description |
|---|---|---|
| CAN Interface | can0 | The network interface on which to interact with the CAN Bus |
| Extended ID | False | Whether or not to use 29 bit arbitration IDs |
| Request Arbitration ID | 0x7e0 | The arbitration ID to send requests to |
| Response Arbitration ID | 0x7e8 | The arbitration ID where replies will be sent |
Outcomes
SUCCESS: XCP upload operations required proper authentication and were secured against unauthorized access.
Recommendations:
- Continue monitoring XCP upload service security controls.
- Verify authentication mechanisms remain robust.
- Document security controls for compliance purposes.
NO_RESPONSE: The device did not respond to basic queries from the test.
Recommendations:
- Check physical connections and device power.
FAILURE: XCP upload service allowed memory reading without proper authentication, indicating a security vulnerability.
Recommendations:
- Implement proper authentication for XCP upload operations.
- Restrict XCP upload service availability in production.
- Review memory access controls and data protection mechanisms.
- Audit accessible memory regions for sensitive data exposure.
Example Usage
bw_cli run -a xcp_upload -p device=can0 -p extended_id=False -p req_arb=0x7e0 -p resp_arb=0x7e8XCP Download
Tests if it is posible to write XCP memory using the Download (0xF0) service.
Fail Condition: If the XCP Server responds success to this requests this test will be marked as failed.
Parameters
| Name | Default Value | Description |
|---|---|---|
| CAN Interface | can0 | The network interface on which to interact with the CAN Bus |
| Extended ID | False | Whether or not to use 29 bit arbitration IDs |
| Request Arbitration ID | 0x7e0 | The arbitration ID to send requests to |
| Response Arbitration ID | 0x7e8 | The arbitration ID where replies will be sent |
Outcomes
SUCCESS: XCP download operations were properly secured and authentication was required, preventing unauthorized memory write access.
Recommendations:
- Continue monitoring XCP download service security controls.
- Verify authentication mechanisms are properly implemented.
- Document security controls for compliance purposes.
NO_RESPONSE: The device did not respond to basic queries from the test.
Recommendations:
- Check physical connections and device power.
FAILURE: XCP download service allowed memory writes without proper authentication, indicating a critical security vulnerability.
Recommendations:
- Implement proper authentication for XCP download operations.
- Restrict XCP download service availability in production environments.
- Review memory access controls and write protection mechanisms.
- Audit memory modifications for potential security impact.
Example Usage
bw_cli run -a xcp_download -p device=can0 -p extended_id=False -p req_arb=0x7e0 -p resp_arb=0x7e8XCP Program
Attempts to write memory using the XCP service Program (0xD0) service.
Fail Condition: If the XCP Server responds success this test will be marked as failed.
Parameters
| Name | Default Value | Description |
|---|---|---|
| CAN Interface | can0 | The network interface on which to interact with the CAN Bus |
| Extended ID | False | Whether or not to use 29 bit arbitration IDs |
| Request Arbitration ID | 0x7e0 | The arbitration ID to send requests to |
| Response Arbitration ID | 0x7e8 | The arbitration ID where replies will be sent |
Outcomes
SUCCESS: XCP programming operations were properly secured and authentication was required, preventing unauthorized code modification.
Recommendations:
- Continue monitoring XCP programming service security controls.
- Verify code signing and authentication mechanisms.
- Document security posture for compliance purposes.
NO_RESPONSE: The device did not respond to basic queries from the test.
Recommendations:
- Check physical connections and device power.
FAILURE: XCP programming service allowed code modification without proper authentication, indicating a critical security vulnerability.
Recommendations:
- Immediately implement authentication for XCP programming operations.
- Restrict XCP programming service in production environments.
- Implement code signing and integrity verification.
- Audit programmed memory for unauthorized modifications.
Example Usage
bw_cli run -a xcp_program -p device=can0 -p extended_id=False -p req_arb=0x7e0 -p resp_arb=0x7e8