u/baconbbqburgerr

Captured a few minutes of passive CAN traffic on a 2016 Mercedes C300 (W205) using an ESP32 + MCP2518FD logger.

No active probing, no UDS requests just listening.

Found something interesting: the full 17-character VIN is broadcast in plaintext on CAN ID 0x071.

Pattern:

byte 0 → sequence (0, 1, 2)
bytes 1..7 → ASCII characters

3 frames → 21 chars
strip 0xFF padding → 17-char VIN

Example:

00 → 55SWF4J
01 → B9GU161
02 → 604

→ 55SWF4JB9GU161604

Consistent across 100+ observations in a single capture.

---

Method used to surface it:

- group frames by CAN ID
- look for ASCII-printable density
- flag candidates
- reconstruct multi-frame sequences

This also surfaced other signals in the same capture (brake, gear state, etc).

---

What’s interesting from a system perspective:

- VIN looks like a public identity signal for module coordination
- security likely handled elsewhere (immobilizer, encrypted channels, etc)

So the CAN bus ends up carrying a mix of:
- public identity (VIN)
- system state
- protected control signals

---

Curious if others have seen similar plaintext VIN broadcasts on BMW / VAG / Ford, and whether CAN ID / cycle rate tends to stay consistent across platforms.

Captured a few minutes of passive CAN traffic on a 2016 Mercedes C300 (W205) using an ESP32 + MCP2518FD logger.

No active probing, no UDS requests just listening on the bus.

Found something interesting: the full 17-character VIN is broadcast in plaintext on CAN ID 0x071.

---

Pattern (see whiteboard in the photo):

byte 0 = sequence (cycles 0, 1, 2)
bytes 1..7 = ASCII characters
3 frames → 21 chars
strip 0xFF padding → 17-char VIN

Frames:

00 → 55SWF4J
01 → B9GU161
02 → 604

→ 55SWF4JB9GU161604

Verified across 167 observations in a single capture — fully consistent.

---

Method used to surface it:

1. Group frames by CAN ID
2. Score byte positions for ASCII-printable density
3. Flag IDs with high printable ratios
4. Concatenate and check for 17-char patterns

This heuristic also surfaced other signals in the same capture (brake, gear state, etc).

---

What’s interesting is how this fits into system design:

- VIN appears to act as an identity signal for module coordination
- Other messages (e.g. immobilizer) likely handle actual security using encrypted data

So the CAN bus ends up carrying a mix of:
- public identity (VIN)
- system state
- protected control signals

---

Built a small web analyzer to speed up the workflow:

log → mark event → correlate → surface candidate signals

instead of manually digging through graphs.

If anyone wants to try it on a real capture:
https://smartcan.ameriuse.com/analyzer?demo=real

(no setup needed, runs in browser)

---

Curious if others have seen similar plaintext VIN broadcasts across OEMs (BMW / VAG / Ford), and whether the CAN ID / cycle rate tends to stay consistent or varies per platform

Captured a 2016 Mercedes C300 (W205) CAN log and found the full VIN being broadcast in plaintext.

No UDS requests
No challenge/response
No security access

Just sitting on the bus at ~10 Hz.

---

Structure (whiteboard in photo):

byte 0 = sequence (0, 1, 2)
bytes 1..7 = ASCII chars
3 frames → 21 chars
strip 0xFF → 17-char VIN

Frames:

00 → 55SWF4J
01 → B9GU161
02 → 604

→ 55SWF4JB9GU161604

This is my actual VIN (my own car).

Verified 167 occurrences in a single capture — perfectly consistent.

Anyone passive-listening on the bus gets this for free.

For comparison:
Ran the same process on a Toyota Sienna 2011 — completely different story.

Toyota K-platform (pre-2019) uses proprietary KWP (0x21) for secondary modules
(TPMS 7A0/7A8, SRS 780/788), not standard UDS.

Different layer, different game.

Curious:

- Seen plaintext VIN broadcast on BMW / VAG?
- Is 0x071 consistent across newer Mercedes (W21

Been working on a portable CAN bus logger as a side project —
wanted something cheap, battery-powered, with a screen, that
just works for long captures.

Hardware:
- ESP32-2432S028R (CYD board, ~$15 with TFT + touch)
- MCP2518FD CAN controller on VSPI
- SN65HVD230 transceiver
- microSD for logging

Plugged it into my 2011 Toyota Sienna's OBD port and let it run
for ~3 hours.

Result on the photo:
- 1027 fps sustained
- 10,727,750 frames captured
- 0 dropped frames
- 188 MB written to SD

The hardware is mostly off-the-shelf — the interesting part was
getting the firmware to handle sustained throughput without
dropping anything. Ring buffer sizing, SD write batching, task
priorities — that took the most iteration.

Anyone else doing portable logging on ESP32-class hardware?
Curious how others handle the SD write timing without dropping
frames at higher bus speeds.

I’ve been working on a CAN bus analyzer and wanted to try a different approach to signal identification.

Instead of manually scanning graphs and guessing which byte corresponds to a real-world action, this workflow is:

1. record a CAN log

2. mark an event (like brake press)

3. run correlation

4. see which CAN IDs / bytes reacted

5. jump directly into graph + byte/bit inspection

So instead of:

“this might be brake…”

you can do:

“press brake → see what actually changed”

(video below)

Curious if anyone here has tried similar approaches or has a better workflow.

Been working on a CAN bus tool and wanted to share it here for feedback.

If you've worked with CAN data, you know how messy it gets:

raw frames, no context, hard to decode.

I built something to simplify that:

- live CAN capture in browser

- real-time frame table

- signal hints from a growing community dataset

- log analysis + export

Here’s what it looks like in real-time (see screenshot).

Demo:

https://smartcan.ameriuse.com

Try:

- /live (demo mode works without hardware)

- /analyzer (upload logs)

- /decode (community signals)

Would love feedback:

what’s missing or what would make this actually useful for you?