A controlled automotive cybersecurity laboratory project demonstrating Unified Diagnostic Services (UDS) Diagnostic Session Control and Security Access over a virtual CAN network.
The project uses a deliberately weak XOR-based seed-key algorithm to show why predictable challenge-response logic and hardcoded secrets are unsuitable for production embedded systems.
The laboratory contains two Python components:
ecu_emulator.py: Simulates an ECU that supports UDS services0x10and0x27attacker_unlock.py: Demonstrates how the intentionally weak seed-key logic can be reproduced in the controlled environment
This project is designed for protocol learning, authentication weakness analysis, and automotive cybersecurity portfolio demonstrations. It does not represent a production ECU, production security algorithm, or penetration test against a real vehicle.
| Service | Subfunction | Purpose |
|---|---|---|
0x10 |
Demonstration session | Diagnostic Session Control |
0x27 |
0x01 |
Request Seed |
0x27 |
0x02 |
Send Key |
- Python 3
- SocketCAN
- Linux virtual CAN interface
vcan0 - Demonstration request ID
0x7DF - Demonstration response ID
0x7E8
Addressing is used only for the virtual laboratory and should not be treated as a vehicle-specific diagnostic specification.
The emulator calculates the expected key with a fixed XOR operation:
key = seed XOR 0xA5A5A5A5
Because the transformation is predictable and the constant is embedded in the implementation, an observer who understands the algorithm can calculate the expected response. The demonstration illustrates several embedded-security concerns:
- Hardcoded secret material
- Predictable key derivation
- Lack of hardware-backed key protection
- Lack of rate limiting and lockout behavior
- Insufficient resistance to reverse engineering
- Linux environment
- Python 3.7 or newer
- SocketCAN utilities
- Permission to configure a virtual CAN interface
sudo modprobe vcan
sudo ip link add dev vcan0 type vcan
sudo ip link set up vcan0python3 -m venv venv
source venv/bin/activate
pip install -r requirements.txtOpen three terminals.
candump vcan0source venv/bin/activate
python3 ecu_emulator.pysource venv/bin/activate
python3 attacker_unlock.pyExample exchange:
7DF 02 27 01 00 00 00 00 00
7E8 67 01 A1 BC 56 F0
7DF 06 27 02 04 19 F3 55 00
7E8 67 02 00 00 00 00 00 00
This project demonstrates portfolio-level experience with:
- UDS request and response structure
- Diagnostic session and security-state concepts
- CAN message formatting and virtual network testing
- Seed-key authentication weakness analysis
- Python scripting for embedded-security laboratories
- Translating an observed weakness into security design recommendations
A production design requires a qualified architecture and implementation appropriate to the threat model, hardware platform, safety requirements, and key-management system. Potential controls may include:
- Approved cryptographic challenge-response mechanisms
- Hardware Security Module backed key operations
- Protected key provisioning and lifecycle management
- Attempt counters, delays, and lockout behavior
- Secure boot and signed firmware
- Security event logging and monitoring
These are design considerations, not features implemented by this laboratory.
Use this project only on the included virtual CAN environment or another system you own and are explicitly authorized to test.
Do not use it to bypass diagnostic security on production vehicles, customer vehicles, or third-party systems.
No real vehicle data, OEM secrets, production algorithms, firmware, credentials, or proprietary diagnostic content are included.
MIT
Harold L. R. Watkins
Automotive Cybersecurity Engineer | Embedded Systems | Vehicle Software Verification