Understanding UDS Communication: How to Capture and Interpret Diagnostic Sessions at the Frame Level


  • Welcome to this section of the forum. This thread is intended for engineers and advanced technicians who want to go beyond fault code reading and work directly at the protocol level.

    The starting point for most reverse engineering work on modern vehicles is understanding how UDS — Unified Diagnostic Services — actually operates on the CAN bus. Not the abstraction that a scan tool presents, but the actual ISO-TP transport layer, the service identifiers, the request and response structure, and what each byte in those frames means.


    Where most diagnostic tools fall short

    Standard scan tools are built to present information, not expose it. When you send a diagnostic request to an ECU, the tool handles the session initiation, the ISO-TP segmentation, and the response parsing automatically. You never see the raw exchange. That is by design — for routine work, it is efficient.

    For reverse engineering, security research, or deep ECU analysis, that abstraction is the problem. You need to see the actual frames: the 0x7E8 response, the service identifier in byte one, the data length, the payload. You need to know whether the ECU opened a default session or an extended one, and what it returned before any interpretation layer touched it.

    Capturing that traffic directly from the bus, filtering it by arbitration ID, and reading the ISO-TP assembly correctly is where the real diagnostic picture begins.


    What this thread will explore

    • How to capture and read a full UDS diagnostic session at the frame level
    • ISO-TP single frame vs. multi-frame assembly — what it looks like in raw data
    • Identifying service IDs: 0x10, 0x22, 0x27, 0x2E and what each exchange tells you
    • The seed/key mechanism (service 0x27) — how the challenge-response appears on the bus
    • How to recognize when an ECU is rejecting a session and what the negative response code means
    • Reading and comparing proprietary PGNs across different control modules

    To open the discussion

    If you have captured a session log you cannot fully interpret, or you are working through a specific UDS service and hitting a wall, post the raw data here. Include the arbitration IDs, the byte sequence, and what you were expecting versus what you received.

    This thread is built for that kind of technical exchange.



Please login to reply to this topic!