GM/GMC – CAN Response ID Offset for Module Access

• A

  Alex.c

  3/5/26, 6:57 PM

  I am working on a reverse engineering project involving ECU emulation and CAN diagnostic communication on a GMC vehicle (GM/GMLAN architecture), and I have noticed something interesting regarding module response IDs. For some modules such as the ECM and TCM, when the scanner sends a request to the physical ID (for example 7E0), the module responds with an offset of +0x08, resulting in the response ID 7E8, which matches the typical OBD/UDS diagnostic behavior. However, when attempting to access other modules in the vehicle, that same offset does not seem to apply, or a different offset appears to be used, which makes it difficult to correctly determine the response ID when trying to emulate an ECU or communicate with different modules on the network. I am trying to understand how GM defines the offset between request and response IDs for different modules (ECM, BCM, EBCM, TCM, etc.), and whether there is any known rule or table within the GMLAN / Global A architecture that can be used to calculate these offsets. If anyone has experience with GM diagnostics, CAN reverse engineering, or ECU/module emulation, or happens to have CAN logs from real diagnostic sessions, I would greatly appreciate any information that could help clarify how these response IDs are determined and how to properly access the rest of the modules on the network.

  0 likes 0 likes Liked Like

  ---

  2
  Posts

  24
  Views

  Reply

  ---

• 

  Moderator

  Moderator

  VIP-Moderator

  INPRONIC Admin

  3/6/26, 11:42 AM

  Great observation, Alex — you've spotted one of the more nuanced aspects of GM/GMLAN architecture.

  The +0x08 offset rule (request 0x7E0 → response 0x7E8) is part of the ISO 15765-2 / UDS standard for 11-bit CAN IDs, and it does apply consistently to the primary powertrain modules (ECM, TCM) because GM follows the standard functional addressing range (0x7E0–0x7EF) for those.

  However, on GMLAN / Global A architecture, not all modules use the UDS physical addressing range. Here's how GM actually structures it:

  • Primary powertrain modules (ECM, TCM): Use the standard 0x7E0–0x7EF range with the +0x08 offset rule — exactly what you observed.

  • Body/chassis modules (BCM, EBCM, HVAC, etc.): GM assigns proprietary physical IDs outside the standard UDS range. These modules often use IDs in the 0x100–0x5FF range depending on the platform and model year. The response ID offset is still +0x08 from the physical request ID, but you have to know the correct physical ID for each module first.

  • Functional addressing: GM uses 0x7DF for broadcast requests — any module that supports the requested service will respond, which is useful for discovery when you don't know the physical IDs.

  The practical approach for mapping unknown modules:
  1. Send a broadcast request on 0x7DF with service 0x10 (DiagnosticSessionControl)
  2. Capture all response IDs — each responding module will reveal its physical address (response ID minus 0x08)
  3. Build your module address map from those responses

  For GMLAN specifically, GM's MDI documentation and the Global A UUDT tables list the physical IDs per module per platform — but those are not publicly available. In practice, the sniffing/broadcast method above is the most reliable approach for reverse engineering.

  The INPRONIC Trainer is actually well-suited for this kind of work — you can capture and analyze real GMLAN frames in the PRO Edition software, filter by ID range, and map module responses in real time when connected via OBD-II.

  Hope that helps clarify the structure. Happy to go deeper on any specific module or platform.

  1 likes 0 likes Liked Like

  ---