Posted on

Getting Started with CAN Bus Sniffing / What Can I See via the OBD Port?

(this is based on vehicles which use CAN; older vehicles may not have CAN busses easily accessible or at all)

First, you’ll need a CAN sniffing device and software to go with it. While the information in this post is generally not device or software specific, we will of course plug our own DauntlessOBD dongle for typical OBD port connections, or our CAN 2.0B to USB Interface Board when directly connecting to CAN wires, both of which work with the popular open source SavvyCAN software.

How do I Know if I Want to Connect via the OBD Port or Directly to CAN wires? The answer depends on what you want to do or see, and if your car has an OBD gateway module…


A gateway is commonly utilized by vehicle manufacturers to manage multiple CAN busses and relay certain traffic between them. This is done for load management, overall reliability / fault protection, and also security to some extent. It’s typical to find an OBD gateway in use on most late-2010s and newer vehicles, and certain manufacturers had them starting well before that (eg most VW/Audi/Porsche and some FCA).

Many other mid-2000s through mid-2010s vehicles had commonly exposed CAN traffic directly on the standard CAN pins of the OBD port. This would typically be the Powertrain CAN, which would also serve OBD requests, making it an easy and attractive place to access CAN traffic via an OBD dongle based CAN sniffer. It can also lead to some more problems if a poor quality, or nefarious, OBD device is plugged in.

Gateway Cons: When a vehicle uses an OBD gateway, you will see little to no CAN traffic via the OBD port, unless another OBD device is talking. This means you cannot use the OBD port to sniff, decode, or inject raw CAN broadcast messages between modules. Gateways are also commonly known to restrict access to certain modules or services, such as Service 27 for Security Access, unless you unlock the gateway and send it a proprietary command to allow your desired access. Sometimes this is for good reason, and other times it adds additional hurdles just to do a simple task.

Gateway Pros: Being that most other CAN traffic is filtered out, that makes it super easy to see what any other OBD devices are sending / receiving via the standard CAN pins of the OBD port. We’ve also found that in many cases, a gateway is actually helpful in gaining data stream and diagnostic access to modules that may exist on various different CANs, with the caveats that you may need to know manufacturer-specific info/methods to do this, and the gateway may also impose some restrictions on your ability to access more sensitive modules or functions.

Choosing the right connection for what you want to do

1) I Want to See What Another OBD Device is Doing: Connecting at the OBD port is an easy choice when combined with a Y-cable or other OBD splitter.

2) I Want to See Module-to-Module and Broadcast CAN Traffic: If your vehicle does not have an OBD gateway, and you want to see Powertrain CAN traffic, then the OBD port could be an easy choice. When a gateway is involved, or you want to see a non-Powetrain CAN, then you’ll likely need to connect directly to the wires of the specific CAN you want.

3) I Want to Communicate With a Module: In most cases you can do this via the OBD port… Certainly the OBD-compliant Powertrain modules can be accessed that way, but also in many cases other modules can be accessed there either directly (ie if your Powertrain CAN is connected to the port) or even via a gateway. When dealing with a gateway, many are cooperative in helping you talk to modules that may exist on various different CAN busses, but you’ll need to know how to do that for your specific vehicle/manufacturer and it may block or impose additional requirements on certain requests (such as Service 27 for Security Access).

Can I Sniff CAN With an “ELM327”? Maybe, but not well, and even less so on the low-quality clones that flood the market. We’ve seen that some of these clones do support the ELM327 CAN filtering and monitoring commands, while others don’t because they’re not often used by OBD apps. Typically, you’d set your filters and use “AT MA” or similar, restarting it whenever the buffer overflowed, which can be very frequent (and indicates that you’ve missed frames). Although our own DauntlessOBD dongle and CAN sniffer both offer compatibility with ELM327 commands, while offering a larger buffer and some additional capabilities, we typically recommend utilizing our compatibility with SavvyCAN for full CAN sniffing via USB, as that setup is more suited for the task.

Where Can I Find Other CAN Wires to Tap Into? Sometimes there will be additional CAN busses exposed on the optional pins of the OBD port (such as pins 3/11 for Ford). Otherwise, the wires going into a gateway module tend to have most everything available in one place. If that’s not easy to get to, then we’d usually look for the most accessible module on whatever CAN we’re targeting. Sometimes twisted-pair wiring can be a clue that it’s CAN, but not all manufacturers use this. Obtain a reliable wiring diagram for your vehicle to be sure about what you’re tapping into.

Use great care when connecting to CAN wiring, as improper connections or settings may cause damage and faults.

We strongly also recommend using Listen-Only / Receive-Only mode whenever possible, so that you won’t crash the CAN bus if you connect at the wrong rate, etc.

How Do I Get SavvyCAN Up and Running? Once you have a compatible device, check out our SavvyCAN Quick Start post.

What does CAN and OBD Traffic Look Like? For classic CAN (ie CAN 2.0B and older), it will be a frame ID and then up to 8 bytes of data. It is common for frames to be padded to a full 8 bytes even if not all of them are actually used. Typically padding values are 0x00, 0x55, 0xAA, less commonly 0xFF. And sometimes the excess bytes are just “random” or whatever was left over in the transmitting module’s buffer from a previous operation.

1) For scantool and server/client type communications, such as OBD or UDS (ISO-14229) or ISO-14230 requests and responses, it should be encoded using ISO-15765. This means the first byte will be the PCI byte, which will indicate the frame type and following data length. These may serve large payloads (up to 4KB) that span multiple frames. Read up on ISO-15765 for more information, as we’ll only touch on the basics here.

For example, a typical OBD request for engine RPM will be sent to an address like 0x7DF or 0x7E0 (if CAN-11) and have these bytes:

02 01 0C 00 00 00 00 00

The PCI byte is 0x02, which indicates that it is a single frame message (0x0 high nybble) and 2 bytes follow (0x2 low nybble), then you have the Service ID (0x01 – PID request), the desired PID (0x0C – Engine RPM), and the rest are 0x00 padding bytes.

The response to that example would come from an ID like 0x7E8 (typical CAN-11 ECM response ID) and have bytes that look something like:

04 41 0C 12 34 00 00 00

The PCI byte is 0x04, which is a single frame message with 4 bytes that follow. 0x41 is your Service Response ID (0x01 from the request, XOR’ed by 0x40), 0x0C is the PID you’re getting data for (Engine RPM), and then the value is 0x1234 which is 1165 RPM (scaling on this PID is 0.25 RPM).

When the high-nybble of that first PCI byte is 0x1, then you have the first frame of a multi-frame payload and the other side is expected to send a flow-control frame (0x3 for the high nybble), then you’ll see a series of frames with 0x2 for the PCI high nybble, which are the remaining multi-frame payloads. ISO-15765 explains how each of these work.

Service IDs of 0x0A and below will typically be OBD requests, and anything higher will be an ISO-14229, ISO-14230, or manufacturer-specific service. Despite having a higher ISO number, ISO-14230 is generally only used in older vehicles, falling out of favor for UDS / ISO-14229 which is increasingly commonplace.

2) For CAN broadcasts and some module-to-module communications, you’ll typically have raw CAN frames that use the manufacturer’s own encoding, rather than any ISO-15765 or other common standard. As such, we really can’t offer a one-size-fits-all explanation here like we can for OBD or UDS services.

You’ll have to know (or learn) how to decode these CAN broadcasts for your specific vehicle, and in many cases there will be some commonality shared across vehicle models of the same manufacturer and era. Typically, you would find parameters encoded in this CAN data by manipulating one of the vehicle’s controls or sensors, and trying to observe that change in the CAN data. You might also notice that some bytes/bits are always changing on every frame… It is fairly common for these frames to contain counters and checksums, as these add another layer of data integrity, and is another hurdle for any message injection or replay attempts.

If you have a GM Global A vehicle (mid-2000’s through late 2010’s), it can be very useful to purchase access to GMW8762 from a legitimate source, which provides a detailed explanation of most CAN signals found on the High-Speed CANs of these vehicles. Note that the Low-Speed / Single-Wire CAN (aka GMLAN) is different, and some insights into that may be found in the open source “GMLAN Bible”.

What does each OBD or UDS Service ID do? This only applies to request/response messages, and not CAN broadcasts. You want to look at SAE J1979, ISO-14229, or maybe ISO-14230, for a complete list and details, depending on what you’re working with. There may also be additional manufacturer-specific services being used by certain scantools. Here is a brief summary that is not all-inclusive:

Service	ISO-15031-5 / SAE J1979 (OBD)
01	Request Diagnostic Data
02	Request Freeze Frame Data
03	Request Trouble Codes
04	Clear Diagnostic Information
05	Request O2 Monitor Results
06	Request Monitor Test Results
07	Request Pending Trouble Codes
08	Request Control
09	Request Vehicle Information
0A	Request Permanent Trouble Codes
Service	ISO-14230-3 (KWP2000)
10	StartDiagnosticSession
11	ECUReset
14	ClearDiagnosticInfo
17	ReadStatusOfDTC
18	ReadDTCByStatus
1A	ReadECUIdentification
21	ReadDataByLocalIdentifier
22	ReadDataByIdentifier
23	ReadMemoryByAddress
27	SecurityAccess
28	DisableNormalMsgTransmission
29	EnableNormalMsgTransmission
2C	DynamicallyDefineDataIdentifier
2E	WriteDataByIdentifier
2F	IoctlByCommonIdentifier
30	IoctlByLocalIdentifier
31	StartRoutineByLocalIdentifier
32	StopRoutineByLocalIdentifier
33	RequestRoutineResultsByLocalIdentifier
34	RequestDownload
35	RequestUpload
36	TransferData
37	RequestTransferExit
3B	WriteDataByLocalIdentifier
3D	WriteMemoryByAddress
3E	TesterPresent
85	ControlDTCSetting
86	ResponseOnEvent
Service	ISO-14229-1 (UDS)
10	DiagnosticSessionControl
11	ECUReset
14	ClearDiagnosticInfo
19	ReadDTCInformation
22	ReadDataByIdentifier
23	ReadMemoryByAddress
24	ReadScalingDataByIdentifier
27	SecurityAccess
28	CommunicationControl
2A	ReadDataByPeriodicIdentifier
2C	DynamicallyDefineDataIdentifier
2E	WriteDataByIdentifier
2F	IoctlByIdentifier
31	RoutineControl
34	RequestDownload
35	RequestUpload
36	TransferData
37	RequestTransferExit
38	RequestFileTransfer
3D	WriteMemoryByAddress
3E	TesterPresent
83	AccessTimingParameter
84	SecuredDataTransmission
85	ControlDTCSetting
86	ResponseOnEvent
87	LinkControl

How Do I Request Data Parameters via OBD / UDS? Services 01 and 22 are most common (see below). Some older vehicles also used Service 21, however the meaning the those PIDs changed much more between vehicle models and years, while Service 01 is standardized, and Service 22 contains a mix of standardized and manufacturer PIDs (reasonably stable between models, in many cases).

What are the Standard Data PIDs for Services 01 and 22? There’s a really good list in SAE J1979-DA, but many can also be found on Wikipedia. Most Service 22 PIDs are manufacturer-specific, but there is standardized stuff up in the 0xFxxx range that is explained in ISO-14229 and SAE J1979-DA. Some manufacturers will also provide Service 01 PID data via Service 22 when you send requests in the 0x0000 – 0x00FF range, however with newer UDS stuff it is becoming more common to find these PIDs served by the 0xF400 – 0xF4FF range instead.

How Do OBD Module CAN IDs Work? Although CAN broadcast IDs can be all over the place, and a manufacturer’s non-OBD modules might be too, the use of CAN IDs for OBD modules is largely standardized. You may have noticed that you most commonly see OBD requests sent to 0x7DF or 0x7E0, and then get responses from 0x7E8.

On CAN-11, the Functional OBD request address is 0x7DF, and may result in responses from multiple modules that implement that particular request. This will typically only get responses from OBD-compliant modules, which will use response addresses in the range of 0x7E8-0x7EF. There is an offset of 0x8 between the OBD Request and Response ID… To address a specific OBD module individually, use the 0x7E0-0x7E7 range, and it will respond using the corresponding 0x7E8-0x7EF address. 0x7E0 is commonly the ECM or PCM, and it will respond using 0x7E8. Other non-OBD modules may also be accessible, but the ID’s used for them, and their relationship between Request and Response ID, will depend on the manufacturer. Several manufacturers tend to put their non-OBD modules somewhere in the 0x700-0x7DE range, but not all do (eg GM Global A uses 0x2xx for requests, with responses in 0x6xx).

CAN-29 is used less frequently (mainly Honda, Volvo, and GM Global B vehicles), but offers some useful benefits. When you see an address like 0x18DA10F1, that can be broken down into 0x18DA (OBD Physical addressing mode), 0x10 (Destination module ID; 0x10 and 0x11 are commonly used for the ECM/PCM), and 0xF1 (Source module ID; 0xF1 is the scantool). To send a Functional request to all modules, the ID of 0x18DB33F1 is used, and the responses will come back using addresses like 0x18DAF1xx, where the xx byte is the ID of the responding module. To send a request to a specific module, you would use 0x18DAxxF1.