Further Car Hacking (Part three)

Again with the wild assumptions; here I’m going to be working on the basis that you managed to complete the communication chain between the ELM327 adapter and some kind of Telnet client. If this isn’t the case then you can check the previous articles here and here.

With that out of the way, let’s review the last session. If you got to the point where you got an answer to your request (01 00) then you’re in good shape – let’s work out what that reply actually means. If you’re some kind of masochist, you can do this next bit by hand. If you’re a normal well adjusted person then other options are available to you. Notwithstanding, if you understand binary then the reply is really easy to understand. If you don’t, read about it on Wikipedia here – but be aware that his article is the worst “design by committee explanation I’ve ever read”, and that you’ll have to go all the way to the second paragraph in “binary counting” before you find the all important powers of two explanation.

My reply was 41 00 9E 3E B8 11, so we nip off the first two bytes (pairs) of the reply; which are communications based chaff, leaving us with 9E 3E B8 11. Now we take the first pair and find the bit pattern that represents that hex (not familiar with the hex number base? Read here) number – I’m using Calc, but anything that you can hack values into and see bit patterns will do:

A Microsoft Calculator instance
Using Calc for Hex to Binary

Do the same for the remaining groups and wedge the result together, this will give us a bit pattern like this:

1001 1110 0011 1110 1011 1000 0001 0001

Now we just mash the whole thing into a table, with column values ascending in hex. Wherever there is a number with a 1 beneath it, that means that you car supports querying that PID.

PID 01h 02h 03h 04h 05h 06h
Enabled 1 0 0 1 1 1
PID 07h 08h 09h 0Ah 0Bh 0Ch
Enabled 1 0 0 0 1 1
PID 0Dh 0Eh 0Fh 10h 11h 12h
Enabled 1 0 0 0 0 0
PID 13h 14h 15h 16h 18h 19h
Enabled 0 0 1 0 0 0

Oh, PIDS. Right, this bit of jargon stands for Parameter ID – essentially your first mode one request was asking what other  parameters you could call the it with. If you send the car a mode 1 request (remember, the first byte of the request? Sure you don’t need to look back at last time here?), then the second hex number can be any of the numbers which have a 1 below them.

You could of course just try a random second value for the PID – this is fact what PID scanning is, but that’s for another time. It’s generally safe, as if the car doesn’t understand you it will reply with 7F 22 11 which is vehicle speak for “Parameter not supported”. There’s a whole bundle of these response codes, with the first two bytes essentially saying “bad thing happened” and the final byte representing why the ECU wouldn’t give a response. I managed to find a full list here,  but as links tend to decay over time, I’ve copied the body of that list here for prosperity:

10 General Reject
11 Service Not Supported
12 Sub Function Not Supported – Invalid Format
21 Busy – repeat Request
22 Conditions Not Correct Or Request Sequence Error
23 Routine Not Complete Or Service In Progress
31 Request Out Of Range
33 Security Access Denied – security Access Requested
35 Invalid Key
36 Exceed Number Of Attempts
37 Required Time Delay Not Expired
40 Download Not Accepted
41 Improper Download Type
42 Can Not Download To Specified Address
43 Can Not Download Number Of Bytes Requested
50 Upload Not Accepted
51 Improper Upload Type
52 Can Not Upload From Specified Address
53 Can Not Upload Number Of Bytes Requested
71 Transfer Suspended
72 Transfer Aborted
74 Illegal Address In Block Transfer
75 Illegal Byte Count In Block Transfer
76 Illegal Block Transfer Type
77 Block Transfer Data Checksum Error
78 Request Correctly Rcvd – Response Pending
79 Incorrect Byte Count During Block Transfer
80 Service Not Supported In Active Diagnostic Mode
C1 Start Comms +ve response
C2 Stop Comms +ve response
C3 Access Timing Params +ve response
81-8F Reserved
90-F9 Vehicle manufacturer specific
FA-FE System supplier specific
FF Reserved by document

Phew. Fortunately, the vast majority of these are for ‘advanced’ things (which we will move onto together). We now know what a PID is, and we also know what the responses are if we get it wrong, but how do we know what each PID represents? Fortunately – and as a complete surprise – the law is on our side this time.

That is to say the that the mode 01 PIDs are legislated and of a known format encysted in a standard. This is brilliant for us, because that turns our list of 1 and 0’s into a collection of things with names – far easier to understand. The complete list of PIDs is shown in this rather nice Wiki article here. Incidentally, you will also notice that there are more PIDs than will  fit into the original reply we received, but further inspection of that Wiki article will reveal to you that the request is repeated every 20 hex. If you were thinking that there wasn’t enough space between 0 and 20 to fit all 32 returned PIDS in, that’s because you’re not counting in hex – go back and learn how to count in 16’s.

Let’s pick an example which is likely to be implemented on your car, coolant temperature sounds like a good starting place. We know from the standard that the PID for engine coolant is 05, so let’s ask the car to give us that data – reconnect your toolchain if required, and then enter ‘0105’. If all is well, you should get an answer like this:

A Telnet screen
A successful engine coolant request

Ok, so I missed the mode off the first time – now we trim off the comms chaff bytes at the beginning; leaving us with 82. Convert this number to decimal and we’re left with 130 degrees centigrade. That’s a bit high – even though the engine was running – I’d usually associate that kind of temperature with repair bills, but in this case there’s a good reason.

If you look in the “Formula” column of the PID table, you’ll see that quite a few of the PID’s require special handling before the number you want is actually derived. In this case our formula is (A – 40), and that means that we need to take 40 from our returned decimal value to give the final figure. The convention here is that the bytes of the response are labelled left to right A-Z, so the first (and only in this case) pair is byte A. Final temperature? 90 degrees, which is far more reasonable, and incidentally exactly the same figure that both Torque’s dials and my car’s dash indicate. Nice.

At the end of that, we’ve managed to recapitulate the process that any £30 scan-tool will do for you; but hopefully you’ve learned something along the way. Next time we’ll consolidate this by asking some more mode 1 questions of the car ECU, and then starting out into the murky world of CANBus.

Leave a Reply

Your email address will not be published. Required fields are marked *