Jeep Wrangler Forum banner
  • Hey everyone! Enter your ride HERE to be a part of January's Ride of the Month Challenge!
1 - 20 of 40 Posts

·
Premium Member
Joined
·
532 Posts
Discussion Starter · #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.
 

·
Premium Member
Joined
·
532 Posts
Discussion Starter · #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.
 

·
Premium Member
Joined
·
532 Posts
Discussion Starter · #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.
 

·
Premium Member
Joined
·
532 Posts
Discussion Starter · #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.
 

·
Premium Member
Joined
·
532 Posts
Discussion Starter · #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.
 

·
Premium Member
Joined
·
532 Posts
Discussion Starter · #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.
 

·
Premium Member
Joined
·
532 Posts
Discussion Starter · #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.
 

·
Premium Member
Joined
·
532 Posts
Discussion Starter · #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!).
 

·
Premium Member
Joined
·
532 Posts
Discussion Starter · #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!
 

·
Premium Member
Joined
·
532 Posts
Discussion Starter · #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.
 

·
Premium Member
Joined
·
532 Posts
Discussion Starter · #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.
 

·
Premium Member
Joined
·
532 Posts
Discussion Starter · #22 ·
0x5A=90
90-50=40°C

Assuming it isn't 40°C/104°F in Colorado, was that after it cooled down for a few hours? It looks like a reasonable value if that was the case. I bet it matches the other trans temp pid(if you put it in drive so the other one works).
So that's dead on. I did a few more experiments this afternoon with that PID.

When the transmission was in park, and the trans temp was displaying the engine coolant temp of 197ºF, the data returned from this query was 61 5c 0d d0 00 50 8e. 0x8e=142, 142-50 = 92ºC, or 197.6ºF.

When the transmission was in reverse, and the trans temp was displaying a trans temp of 111ºF, the data returned was 61 5c 0b b0 01 52 5e. 0x5e=94, 94-50 = 44ºC, or 111ºF.

So that's dead-on. I am suspecting byte C is the gear selection, too (00 = park, 01 = reverse?). Need to try that out real quick.
 

·
Premium Member
Joined
·
532 Posts
Discussion Starter · #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.
 

·
Premium Member
Joined
·
532 Posts
Discussion Starter · #26 · (Edited)
The ODBII port doesn't give you access to the CANBUS, right? From what I understand, it's a slower transport layer? Or is it all the same?
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

·
Premium Member
Joined
·
532 Posts
Discussion Starter · #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.
 

·
Premium Member
Joined
·
532 Posts
Discussion Starter · #28 ·
Oh, Dr. Google to the rescue. Here's an example vehicle (not a JK, but similar) to give you an idea of how the network looks from their point of view.
 

·
Premium Member
Joined
·
532 Posts
Discussion Starter · #29 ·
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.
For sure. I'm not a big fan of brute forcing these commands. When I was first experimenting with hacking the CAN-IHS bus, I was able to get the car to stall in the driveway a few times. Not something I'd like to do while moving.
 

·
Premium Member
Joined
·
532 Posts
Discussion Starter · #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).
 
1 - 20 of 40 Posts
Top