Test Cases
VSEC Test provides a free test set as well as others you can subscribe to. This page will detail the cases available to all users through VSEC. You can browse the test sets in the left navigation pane to see test sets available for subscription.
UDS 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=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=0x7e8