Jeep Wrangler Forum banner

Hacking the OBD-II Diagnostic Port

89K views 77 replies 23 participants last post by  Kuhnkey 
#1 ·
Related to my http://www.wranglerforum.com/f202/hacking-the-can-interior-bus-466730.html thread, I wanted to start another discussion topic on Hacking the OBD-II Diagnostic Port.

A lot of us would like to use the various smartphone & tablet dashboard tools, like Torque and DashCommand, to show gauges of what the car has available, so I'd like to share that information here as it is discovered.

Additionally, in the JK, all ECUs are able to be diagnosed, flashed, and coded via the OBD-II port. This is how things like the ProCal and so forth can change tire size and other parameters.

So, stay tuned. I'd like to share as much information on this as we can get, and not have this information remain hidden away anymore.
 
#2 ·
Some background information and history on the OBD-II port and where it stands in the Jeep JK.

Without getting too far into the history of how OBD-II came to be (some of you folks on the forum probably know a lot about this - please share!), the general gist is as computers exploded their way into automotive in the 1970s and 1980s and government wanted more emissions monitoring and control across the fleets, OBD-I regulations were defined as an attempt to encourage manufacturers to develop emission control systems that lasted the useful life of the vehicle (early studies on emissions had already found that as vehicles age and were not well-maintained, their emissions went up dramatically).

Eventually, the different connectors and protocols used by the different manufacturers were not very useful for anyone, so regulations around OBD-II were developed. OBD-II defined a specific set of protocols / signaling and defined the data-link-connector port and its location in the vehicle. The end result being the 16-pin DLC that has to be somewhere near the driver's footwell (I think the regulation says within 12" or something similar) and a handful of communication protocols that are defined by SAE and other standards.

Initially, OBD-II was just used for emissions control monitoring, and most of the protocol that you'll see documented are for that purpose. Most scan tools and end-user tools like Torque or DashCommand are using this well-defined emissions-focused protocol to retrieve their information.

The OBD-II port has eventually become the primary way diagnostics, ECU flashing/programming, and option coding is done on most vehicles today, but it is not the only way. BMW's, for example, typically have multiple data connectors. My E92 3-series, for example, has a fiber-optic MOST network (used by the A/V system) and an internal vehicle Ethernet (that's available over the OBD-II port, actually).

The Jeep JK is somewhat unusual in that the OBD-II port is very simple and gives almost all (I say almost out of presumption and ignorance) control over all vehicle ECUs, and it does through one CAN bus network. The diagnostic CAN bus is connected directly to the TIPM module, which is the gateway to the rest of the vehicle. This a simple, elegant design, but also why when the TIPM takes a dump it's really bad news.
 
#3 ·
Some of the relevant standards you may hear about related to OBD-II are (there are a bunch more):

SAE J1962 and ISO 15031-3 defines the physical data-link connector
SAE J2012 defines standards trouble codes and definitions
SAE J2178 defines the message protocol
SAE J2284 defines 500 Kbit/s CAN physical and data link layers (what the JK uses)
SAE J2534 defines the pass-through protocol for flashing/programming ECUs, etc

ISO 15765 the most useful set of documents, as it reflects what vehicles sold since 2008 must provide

Many of the standards are available via SAE and ISO's own document archives via an expensive fee, but you'll find a lot of publications and even the original PDFs on the Internet if you search around. The standards body consider document fees one of their main income sources, but unfortunately it's also impossible to keep information from being shared. They'd be better off if these were just publicly available, IMO.
 
#4 ·
There are a lot of scan tools out there today. If you shop around, you'll find a ton of really, really cheap ones that allow you to connect your smartphone/tablet/computer to it using WiFi, Bluetooth, or even USB.

Almost all of these really cheap scan tools are using an integrated circuit called an ELM327. This IC was developed by Elm Electronics for scan tool manufacturers. It provides all of the smarts about dealing with the various SAE and ISO signal protocols on OBD-II ports, so that the scan tool itself could be simplified.

Unfortunately for ELM, they did not implement great copy protection within that IC, so clones sprouted up everywhere. These clone ICs can be had for pennies now, so that's why it is possible to buy a WiFi scan tool for $20 or less now. Generally speaking, if you see one of these devices for less than $50, it is probably a clone.

ELM has continued to make new variations of the this IC with newer features and more power, but the ELM327 remains the most common one you will see out there.

One nice thing about the ELM327 chip is that it provides a serial-link connection interface that acts a whole lot like the old Hayes modem protocol. If you are old school and remember typing in "AT" commands to your modem in the 80s and 90s, then that's the general idea. What the ELM327 did was provide a nice, simple command-set that you could use like that, and all the grunginess of the various OBD-II signaling protocols are taking care of by the IC itself. That means you can ask a Ford, GM or Honda for the ambient air temperature and you'll get back an answer, even though they all used different communication protocols under the covers.
 
#5 ·
Awesome. I'm currently digging into how to read out transmission temp and tire pressures. Only progress thus far is rumored PID data for trans temp. Here's what I know at the moment. I haven't had a ton of luck but trying to get transmission data into the OBD Fusion app for iOS I've seen that people using the Torque app are:
To "turn on" trans temp monitoring:
PID: 3e01
Equation: A
OBD Header: 7DF

To actually monitor:
PID: 2172 (I've also seen 22b010)
Equation: ((C*256)+C)*(5/576)-16 (I've also seen: A)
OBD Header: 7E1

Going to dig in a bit more as soon as I have something working I'll let everyone know.

I'm also looking for a way to connect my Mac to the wifi obdii adapter I bought and just get dumps of what is on the bus to do a bit more exploration. Not sure if can-utils for Linux can work for this or not. Hopefully will test some this weekend.
 
#7 ·
Let's focus in on the ISO 15765-4 standard now, which is what all cars sold since 2008 are providing over the OBD-II port. This is using a CAN bus for the data link layer, which is very simple to work with.

According to ISO 15765-4, the DLC must provide power, ground, and CAN-H and CAN-L pins. Those are pins 16, 4, 6 and 14, respectively. A note on grounds: pin 4 is chassis ground, and pin 5 is signal ground, but I do not know if those are ever actually different.

CAN is a simple, elegant network communication layer. It is broadcast based, which means every message that is written to the bus is seen by everyone. It is up to everyone listening on the bus to decide if that message is meant for them. Sometimes, the message is meant for multiple ECUs on the bus.

There are 2-different CAN variants today, one with 11-bit message identifiers, and one with 29-bit message identifiers. Otherwise they're effectively the same. When a message is sent to the CAN bus, you provide a message id and then the payload of the message. If you asked for the right thing, you'll get a message back with a well-known id and expected format.

Note: I'll continue to use the term "scan tool" but that is an over-simplification of what is happening. It is the generic term for any device connecting to the OBD-II port to collect data or to give the car new data.

For ISO 15765-4 specific messages, it works like this: messages are 8-bytes long. The scan tool sends a message using CAN message identifier $7DF, which is the standard-defined identifier for diagnostic requests. The scan tool expects a response back from message identifiers in the range of $7E8 to $7EF, which allow multiple ECUs to respond to a single request.

Let's say we want to ask for the engine coolant temperature, the message would look like this (all values in hexadecimal format, with spaces between sections):

0x7df 0x02 0x01 0x05 0x00 0x00 0x00 0x00 0x00

  1. The first 11-bits is the CAN message identifier.
  2. The 1st byte is the number of additional bytes in this message, in this case, only 2.
  3. The 2nd byte is the type of request, or 'mode' - 0x01 is 'current data', 0x02 is 'freeze frame data', etc. This is the biggest single control factor on what type of message is being sent.
  4. The 3rd byte is the PID code, where PID standards for Parameter Identifier. This is what most people are after when they talk about PID codes. PID codes are well-defined, but also allow the manufacturer to provide their own extended codes.
  5. The remainder of the bytes are either zeros or not sent at all.

The response that comes back has a well-defined format, depending upon the type of PID being requested. There is usually some math involved as well as unit conversions, but there are only a handful of different types of data format that are expected, and the standard defined PIDs are small in number.

In our example above, we would expect a response that looks something like this (later I'll actually go get this from the Jeep to get real data):

0x7e8h 0x03 0x41 0x05 0x2a


The formula for calculating the coolant temperature is A - 40, with the result in degrees Celsius. In the example above, 0x2a is 42 in base-10, so the result would be 2ºC, or 36ºF.
 
#8 ·
It is not too hard to get all of the standard-defined ODB-II information out of the car, and to discover all of the PIDs that might be available. You'll find a ton of projects and resources, and published documentation for that matter, on this. None of this is proprietary information, so worst case is you are looking at some copyrighted material from the SAE or ISO that has been shared on the Internet. But, all of that information can be published in other ways (including on this forum), so it's just a matter of presentation.

Where things get interesting are what else does the manufacturer make available that's not there as standard emissions-related PIDs? Sometimes they provide extended PIDs that are easy to get to, but more often than not, it is only available through pass-through communications through the rest of the ECU. This is where the really interesting things lie.

The extended commands and messages get much more interesting, and much more complicated. Protocols are built-on top of these low-level messages to allow for longer-messages and more flexibility for the manufacturer. For example, if you've heard of GMLAN, it is General Motor's network protocol that is built on top of the lower-level CAN bus signaling (and, for those of you that know more about that, my knowledge is limited there, so I may be misrepresenting that).

A lot of the manufacturers, including Chrysler, use multiple low-level messages to build one high-level request/response. For example, if you can imagine downloading a 512 KB ECU flash programming file over a bunch of 8-byte messages, you get the idea that there needs to be a different protocol there to control all of that.

Let's look at an older example ("Keyword Protocols 2000" standards, which everything is based on now, but obviously much older) of different kinds of messages. In the table below, each SID, or service identifier, is the same value that is sent in the "mode" byte of the messages I gave in the previous example.
  • $10 start diagnostic session
  • $11 ECU reset
  • $14 clear diagnostic information
  • $17 read status of diagnostic trouble codes
  • $18 read diagnostic trouble codes by status
  • $1a read ECU identification
  • $21 read data by local identifier
  • $22 read data by identifier
  • $23 read memory by address
  • $27 security access (this is a fun one)
  • $28 disable normal message transmission
  • $29 enable normal message transmission
  • $2c dynamically define local identifier
  • $2e write data by identifier
  • $30 input/output control by local identifier
  • $31 start routine by local identifier
  • $32 stop routine by local identifier
  • $33 request routine results by local identifier
  • $34 request download
  • $35 request upload
  • $37 request transfer exit
  • $3b write data by local identifier
  • $3d write memory by address
  • $3e tester present

So there's a bunch more, but that gives you an idea that the universe of what's available over this port is rather large. Furthermore, even if you are technical enough to deal with data at this level, you can get the idea from looking at the service identifiers above that the protocol is... obtuse, to be kind. It is a definite design-by-committee approach to trying to standardize on something manufacturers were all doing differently, so it is not as straight-forward as it could be otherwise.

This stuff, and most of SAE J2534 (the pass-through programming interface) is where my knowledge is still rather limited, so that's where I'll be focusing a lot of my research into going forward.
 
#9 ·
You might be wondering how a scan tool manufacturer gets all of this information, or how third-party diagnostic systems are even developed. The short-answer is that, it depends, but generally that information is fully available from each manufacturer.

From what I've seen so far, you can buy access to this information on a quarterly or yearly basis, but the price range is out of scope for anyone who isn't developing a rather expensive diagnostic system (tens of thousands of $$). It's also one reason why this information tends not to leak out, given the cost involved. You'll also notice that people who DO hack into ECUs, tend to keep that information private, so they can make their own engine management tuning software, etc. without making it easier for competitors to do so.

And, not every manufacturer makes it easy to get that information, either. Chrysler is one of the most controlling in that regards.
 
#10 · (Edited)
And one final note on security, then I need to go back to my day job for a while :)

There are various levels of security and encryption in vehicles. More has been added over-time.

First, there is the security on the micro-controllers within the ECUs themselves. Chip manufacturers have added copy protection over-time that makes it harder (but not impossible) to pull the software off of micro-controller directly (a lot of classic ECU tuning is done this way). Usually, this is pretty easily defeated once a hacker knows what company and chip architecture is being used by the ECU. There's usually a way to apply voltage to certain pins to be able to get the code off ("debug mode"). Newer chips are even encrypting the software as it is stored on the chip, and this makes it even harder, but not impossible.

Another level of security are the encryption-based identification systems within the car, such as the JK's SKREEM, that is what handles the security keys and so forth. These systems are what we call security-through-obscurity in the industry. That specifically means the manufactures try and hide the details of how these are implemented because they are fundamentally insecure, at some level.

Why do I say they are fundamentally insecure? For two reasons:
  1. You, or a hacker/thief, has physical access to a vehicle. With physical access, no information technology is secure given enough time.
  2. The computational complexity required to break any encryption algorithms is relatively fixed over the lifetime of a vehicle, but computational speed increases every few months for the rest of us. That means if it took 5 CPU years to break encryption in 2008, it may only take 60 seconds in 2015.

Furthermore, security by obscurity means there are likely huge, huge mistakes in the implementation of the security systems within the vehicle. When security systems are open, it allows others to examine the code and over time, bugs and holes are identified through a "crowd-sourcing" effort of people looking at the work. A lot of people have disagreed with this approach, but time has proven that it is actually effective.

As an example, in my E9x 3-series, there was a bug where someone that had physical access to the OBD-II port could program a brand new key and drive off with the car in just a few minutes. BWM released a software update to prevent that from happening. But, if you think about it, that functionality must exist for a dealer to be able to replace a lost key. All they did was limit the exposure for someone without proper access to do it, but it is not like it isn't possible. Plus, if they could open up the car and get access to the OBD-II, let's be frank, they can also flatbed your vehicle out of the way and do what they want with it. All any of these security measures do is keep the joyriders out of the vehicle for a few minutes.

As time moves on, and more knowledge is gained about vehicles, the easier it is to "crack" them. This is true even before computers. If you think back in time, 80s and 90s GM/Ford pickups are extremely easy to break into. But they weren't when they first came out... eventually enough people figured out how the lock mechanisms worked to engineer quick ways to get into them. The same idea applies to the software and hardware within the car.

I bring this particular topic up for a couple of reasons. There are always a subset of people who do not want this information researched or shared because it might make a thief's job easier. I strongly disagree, because I think the information is more useful known than hidden. Furthermore, thieves will find it out all on their own, but if they keep it within their community, the automotive aftermarket can't easily address the same issues without that same information.

And lastly, it is important to keep in mind that reverse-engineering is legally protected and is not subject to any trade-secret laws for information obtained through it. If the information was obtained through a vendor's own proprietary material, then that's a different subject (and a good reason for any of you out there with access to that to keep it away from me - I don't what to know about it). The Digital Millennium Copyright Act (DMCA) restricted reverse engineering a bit more when it came out, but generally limited to circumventing copy protection systems only. There's a bit of a gray area there, but when it comes to vehicles the ability for third-parties and consumers to repair has generally been championed by feds. I suspect that will ebb and flow a lot as cars become more and more automated (think about the self-driving cars... oy!).
 
#11 ·
I am by no means the master that DC is here but I have made some traction getting at the Trans temp. I finally found a PID setup that seems to give me consistent readings in my app that the EVIC reads out while driving around.

As mentioned I'm using the OBD Fusion app for iOS and am able to get the same results that the EVIC displays using the following settings in a user defined PID:

Module/Header: @7E1
OBD Mode: 21
PID Number: 30
Equation: one of two
- L-51 returns degrees C
- (L-51)*(9/5)+32 returns degrees F

I'm still working on getting a dashboard set up in the app to return the results but when I use the "test" on the custom PID it works just fine.

More as I progress, next I'm after TPMS data.
 
#12 ·
You'll note that mode $21 has been called both extended mode and read data by local identifier. Chances are good that anything worth monitoring will be in there.

It'll be interesting to see if the tire pressures show up there or not. I wish this weekend wasn't so packed!
 
#13 ·
Quick update. Here are the settings I've settled on for transmission temp specific to OBD Fusion.



I went back to L-50 as once I added decimal places it appears it was just rounding that was causing it to go higher. Not sure how the jeep EVIC works here but it seems it may just be truncating the decimal rather than doing actual rounding.

Hopefully I'll get this working so I have all EVIC data I could possibly want to monitor visible on a single dashboard rather than having to thumb through it.
 
#14 ·
You probably already know this - but the TCM will sent send a transmission temperature reading unless the transmission is out of park. The EVIC compensates when it doesn't have a reading by showing the engine coolant temperature.

I didn't look at the data on the CAN interior bus to know if it was actually getting that value from the TCM or if it inferred it by not receiving a value and showed the other instead.
 
#15 ·
You probably already know this - but the TCM will sent send a transmission temperature reading unless the transmission is out of park. The EVIC compensates when it doesn't have a reading by showing the engine coolant temperature. I didn't look at the data on the CAN interior bus to know if it was actually getting that value from the TCM or if it inferred it by not receiving a value and showed the other instead.
It does the same thing when I read from the OBDii port. Tranny temp is only shown when in Reverse or Drive. Otherwise it's coolant temp.
 
#20 ·
I've not a lot of time to do some brute-force hacking on this, but I did a little. It's useful to see what might be there, but I think best results are going to be done a little more intelligently.

So far, for mode $21 requests, I've found responses with the following PIDs:

0x0e
0x0f
0x10
0x30
0x40
0x41
0x42 *
0x43
0x44
0x45
0x46
0x47
0x48
0x49
0x4f
0x50
0x51
0x52
0x53
0x54
0x55
0x56
0x57
0x58
0x5a
0x5b
0x5c
0x5d
0x5e
0x5f
0x60
0x70 *
0x71 *
0x77
0x78
0x99
0x9a
0x9c
0x9e
0x9f
0xa0
0xb0
0xb2
0xb3 *
0xc0
0xc1
0xc2
0xc3
0xc4
0xd0
0xd1
0xd2
0xd9
0xdc
0xe1
0xe4
0xe5
0xe1
0xe4
0xe5
0xea
0xfb


The ones marked with an asterisk look interesting. They either returned a whole lot of data, or had data rapidly changing even with the engine off.

All of these were taking in the default tester mode, which is not where most of the interesting stuff is to be found.

I'm tempted to go after security access mode next.
 
#23 ·
Yep.


7e9 61 5c 0d d0 00 50 8e # engine running, in park
7e9 61 5c 0b b0 01 52 5e # engine running, in reverse
7e9 51 5c 00 00 02 4e 88 # engine off, in neutral
7e9 51 5c 00 00 04 44 60 # engine off, in drive


So, byte C is definitely the gear selector. I'll have to do some recording to see if indicates manual gear selection for the automatic, too.

Bytes A and B look like might be interesting, too.
 
#47 ·
So here's some new data while the vehicle was moving, and playing with the auto-stick. Pretty easy to see the gear selector indicators there.

auto in 1st = 61 5C 01 10 04 31 4B
auto in 2nd = 61 5C 02 20 04 32 49
auto in 3rd = 61 5C 03 30 04 33 61
auto in 4th = 61 5C 04 40 04 34 61
auto in 5th = 61 5C 05 50 04 35 61
 
#24 ·
Well that was disappointing, I thought LID0x5C was going to be trans temp without needing to be in a specific gear. I guess that exercise was a waste of time, it didn't buy you much over LID0x30.

I am not sure if byte C is gear selector but I think byte D is bitmapped PRNDL as it is displayed on the cluster. I am sure you will figure out A&B on a test drive.

FWIW, be careful venturing out in modes that aren't read only. If you are randomly sending commands, it is very easy to change a setting and turn your Jeep into a nice looking lawn ornament until you can have it towed to the dealer and reset.
 
#27 ·
Well that was disappointing, I thought LID0x5C was going to be trans temp without needing to be in a specific gear. I guess that exercise was a waste of time, it didn't buy you much over LID0x30.
At least according to the service manual, the actual sensor isn't sending a temperature reading unless the transmission is in gear. Why, they're not real clear on.
 
#26 · (Edited)
The OBD-II port in the Jeep implements a CAN bus, and a high-speed one at that. But, there are two other CAN bus networks in the Jeep: the CAN-interior bus, and the power-train CAN bus, or CAN-C bus.

When you're talking to the CAN-D bus (the diagnostic bus via the OBD-II port), you are not able to electrically communicate directly with the CAN-C or CAN-interior busses. The TIPM module acts as an electrical gateway between CAN-D and the other two.

This is speculation based on observation, but it appears the current TIPM in the Jeep is somewhat intelligent about what messages get transferred between busses. From what I've read, it looks like older TIPMs in Mopar products (say early-to-mid 2000s) transferred messages between busses freely.

I attached a diagram of what the busses and many of the modules within the Jeep look like at the logical level (several modules left out). It will give you an idea of what is connected to which bus, and how the TIPM is in-between everything.

I think if someone has access to the wiTECH or StarScan they can provide the real network diagram of all the modules.
 

Attachments

#31 ·
The JK is actually different on that, significantly so. There are zero messages coming across the DLC form other busses without requests. I've attached monitoring tools to all three and the CAN-D bus in the JK is quiet (and different from other vehicles I've tested with).
 
#35 ·
And just so you know that I'm not making this up :)

There are actually three separate CAN bus systems used in the vehicle. They are designated: the CAN-Interior (also known as CAN Interior High Speed/IHS), the CAN-C and the Diagnostic CAN-C. The CAN-Interior and CAN-C systems provide on-board communication between all nodes in the vehicle. The CAN-C is the faster of the two systems providing near real-time communication (500 Kbps). The CAN-C is used typically for communications between more critical nodes, while the slower (125 Kbps) CAN-Interior system is used for communications between less critical nodes.

The added speed of the CAN data bus is many times faster than previous data bus systems. This added speed facilitates the addition of more electronic control modules or nodes and the incorporation of many new electrical and electronic features in the vehicle.

The Diagnostic CAN-C bus is also capable of 500 Kbps communication, and is sometimes informally referred to as the CAN-D system to differentiate it from the other high speed CAN-C bus. The Diagnostic CAN-C is used exclusively for the transmission of diagnostic information between the Totally Integrated Power Module/Central GateWay (TIPM or TIPMCGW) and a diagnostic scan tool connected to the industry-standard 16-way Data Link Connector (DLC) located beneath the instrument panel on the driver side of the vehicle.

The TIPM is located in the engine compartment near the battery. The central CAN gateway or hub module integral to the TIPM is connected to all three CAN buses. This gateway physically and electrically isolates the CAN buses from each other and coordinates the bi-directional transfer of messages between them.
The circuit indicators make it pretty clear these are separate busses, as well.
 
#37 ·
You know what's interesting about this, too, is that it seems yet different again with the newer Jeeps. I had a security researcher contact me about the Grand Cherokee and their gateway is acting really differently than the JK's.

There's an old thread on here where a guy took apart an early JK TIPM and looked at a lot of the circuits. I'd like to do that with one of the newer ones and do some circuit tracing. That said, I'm not yet invested enough in all of this to spend a few grand on spare ECUs ;)
 
#62 ·
Hi all, I'm new here. Don't have a Jeep of any kind but I do have a Dodge Journey. I'm following this forum since it has some of the best coverage of CAN bus for Chrysler vehicles I've seen. It looks like dcgibbons leads the pack on cracking them.
You know what's interesting about this, too, is that it seems yet different again with the newer Jeeps. I had a security researcher contact me about the Grand Cherokee and their gateway is acting really differently than the JK's.
I was looking at the online wiring diagrams and the GC seems to be wired the same as the Dodge Journey. The diagnostic port has both the CAN-C and the CAN-IHS busses at the same location.

Just had a questions about the various busses and the OBD2 port. I don't have a Wrangler but have a 2015 WK2 Grand Cherokee so hoping similar enough.
My questions:
1. Based on the above is that C Bus likely to be diag or normal?
2. Is that likely to really be an IHS Bus on 3+11?
3. Do I need anything special to read the IHS bus or can I either just build an adapter to cross them into PINs 6+14 and use anything off the shelf that reads/writes ISO15765-4 or plug them into an Arduino CAN-L and CAN-H and read them using pyOBD or canutils?
Looking at the information I found on the star connectors used on the Journey, and I assume the GC as well, the real IHS buss is on pins 3+11. The star connectors have no active electronics in them just some passive components such as inductors and resistors.

Anyway I'll shut up now and just do some reading.
 
#38 ·
One thing I haven't tried yet with the CAN-D bus is requesting diagnostic access and sending tester present messages and seeing what behavior changes. I suspect there's a diagnostic mode where the TIPM will forward all traffic from the other two busses.

Most of my work has always been focused on the CAN-IHS bus, so I haven't bothered with this one too much. I'm rebuilding my rPi-based CAN system right now (the file system took a crap again) and I'll be digging into it a bit more. Doing it via those ELM327 chipsets is really limiting.
 
This is an older thread, you may not receive a response, and could be reviving an old thread. Please consider creating a new thread.
Top