Category Archives: Car hacking

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.

Next Steps in Car-hacking

I’m going to make the wild and unwarranted assumption that you have come here via my previous article; if you haven’t then I’d recommend having a gander here. Let’s talk about the ELM327 adapter first and what it’s actually doing for us.

The Learning Bit

The history of car hacking is relatively new, but it all starts with some emissions regulations which demanded a set and specific way (or ways, legislation being what it is) of getting important information from an engine management unit about how it’s getting on – in terms of emissions largely. This then bought together all of the manufacturers individual homespun on-board diagnostics into a common framework – the OBD (on board diagnostics) standards. Once it was embedded in law, well, handy wiring shouldn’t be used for a single purpose right?

As a result, car manufacturers began linking together all sorts of things on the bus that they had been made to provide for OBD. Whether or not they stick to the standard for communications for extra devices over and above the legislated minimum is up to the manufacturer, and indeed a lot of the security of these systems is through obfuscation.

As an additional complication, there are lots of ways that the vehicle bus can be implemented on a signal level:

ISO 15765 CAN

ISO 9141-2

KWP2000 (ISO 14230)

SAE J1850PWM

SAE J1850VPW

Which is simply not what the hobby-hacker wants to hear. Fortunately, neither did the people at ELM – so they went on ahead and produced the ELM327 – which frankly is the best thing a car hacker could ever dream of. What this lovely slice of silicon does is flatten out all those differences in protocol and hardware and provides you with a consistent interface for talking to the vehicle across all of them. Instead of having to design your own signal processing and wiring, you can pick up a standard implementation of the ELM327 quite cheaply and immediately begin talking to your vehicle, so let’s do that.

The wonderful types at ELM have provided a datasheet regarding the commands that we’re going to be sending to the car today, available here. I would suggest that once you’re comfortable with the procedure in today’s practical bit then this is well worth reading, even if some of the details may seem a bit abstract at the moment.

The Practical Bit

Things you will need:

  • An ELM327 Bluetooth adapter.
  • Torque Pro
  • Torque Scan
  • A laptop with wireless
  • An Android mobile phone
  • A cup of tea, coffee or weak lemon drink

I’m again going to presume you’ve followed the previous steps and have a Bluetooth ELM327 based device plugged into your OBD port, and that you have connected Torque Pro to it. Now, wobble across to the Play Store and add Ian’s scan tool to the mix: click here.

This tool is an OBD scanner – please don’t run on ahead and hit scan though; today we’re going to be using the Telnet functionality. Because we’re going a little deeper here, here is your obligatory warning:

DO NOT 

  • Run random commands for fun. Or indeed any random commands, the likelihood of them being fun is low.
  • Run scans while the vehicle is moving or can otherwise present a danger to others.
  • Do any of this without reading the learning bit – what’s the point if we’re not learning?

And remember, you are proceeding at your own risk. That said, let’s crack on.

Connect a laptop to the same wireless network as the car, or connect to the phone’s wireless hotspot if you haven’t got a network in range – this is important for using the Telnet feature, and download PuTTYTel; a nice multi-platform TelNet client, available here.

When you open Torque, you should now see a new icon with a spyglass – this is the scan tool. Open it up and get the menu up, select Telnet Server and you will be presented with Ian’s obligatory warning. If you’ve accepted my warning, you should probably accept his – so continuing at your own risk press OK. You’ll now be given a little screen, which will tell you what IP address you need to connect to using PuTTYTel.

On your PuTTY machine, run the program and go to the terminal tab. Tick both “implicit CR in every LF” and “implicit LF in every CR” to tidy up the output. Now click on the TelNet tab, and check the radio button for “passive” under the negotiation mode options. Finally, click on the session tab and click on first “default session” then “save”. Phew, now we’ll never have to do that bit again. Now mash in the IP and the port number into the hostname and port boxes, and click connect (if you know this isn’t going to change, you can save this too). You’ll now have a Telnet window pop up, with some more warning text – I’m holding your hand for now, so we’ll carry on.

A configured PuTTYTel client
A configured PuTTYTel client

Incidentally, if anything I’ve said so far has boggled any part of your brain, please stop for a moment; are you sure you want to be doing this? I only ask because I’m making some assumptions about your knowledge and capabilities, and I don’t want to lose you when we get to the hex math bit. Still OK? Deep breath and let’s carry on.

The first thing we’ll want to do is reset the ELM327 adapter, just so that we can get the thing into a known good condition. All the commands we send to the adapter begin with the magic “AT” phrase, and this lets the ELM device know we are talking to it, rather than the bus it it’s on. The command for resetting the ELM327 is “Z”, so to reset it we just type “AT Z” (or “ATZ” if you have lazy fingers) and press enter. Gosh, we just interacted with some hardware. Hopefully your Telnet window now looks like this:

ELM327
ELM327 says hello

Note the “>” means that the adapter is again in a listening state, get used to not typing until you see that symbol pop up again, otherwise you may get unintended side-effects. Our first command was not an impressive thing, but we’re getting somewhere – at least our hardware is talking to us. The next command we’re going to send is “SP”, which is short for “Set Protocol”. If you’ve not done some research on your vehicle, the easiest thing to do here is type “ATSP 0” (that’s a zero by the way), which tells the ELM that we don’t know the protocol the vehicle uses, and to try and work it out for us.

Finally, we’re going to ask the car a question about itself and find out what protocol was used, then close up for the day. To do the first bit, we enter our first command without the “AT” prefix – “01 00”. In the OBDII standard, this means mode 01 (Current data) Command 00 (Tell me what you can give me), and after a couple of seconds with a “SEARCHING” message, you should get a reply like this:

ELM327 Step 2
A fairly trivial example.. but hey, it works!

Let’s break down that response. First, it helps to understand that the car talks to us in Hex notation, so we’re converting from base 16, the first two characters allow us to confirm this response is meant for us – replies have 40h added to them, so if we have a “41” then we know the reply is to our query, and the next two digits “00” are an echo of our command. The data after this is your car’s answer – we’ll break this down in the next post’s learning bit. Now type “ATDP” (describe protocol) and the adapter will tell us what mechanism it was able to connect by, you can look this value up in the ELM documentation and use it to connect next time by using “ATSP x”, where x is the protocol number.

All that done, we’ve successfully completed our car communication chain and even got a response from our engine management system! We’ll be looking at a bit more detail on that response in the next instalment, and looking at how we transform some of the other responses we can get into usable data.

Until then, remember our watchwords! My advice is offered as is and without acceptance of any liability for any loss or damage incurred as a result of such advice being followed even if I am aware of the possibility of such damage. You are responsible for all your actions.

Hacking your car (for fun and profit)

My car returns 32mpg – according to the official stats. It’s a two litre car that, judging by is performance is already detuned for economy.

And, frankly, that’s horrific.

So I decided to do something about it, and now my car is getting a real world average of 43mpg, so near enough 25% better fuel economy through some modest changes to my driving style and a couple of extremely cheap additions to the car. That, as you might say, isn’t bad. You’ll need a car manufactured after 2006 to get the best out of my guides here, but some advice is of course universal.

I say cheap, you’ll need a smart phone – and if you’re following this guide faithfully it won’t be anything from those “apple” types, fortunately that means I can still put this within a modest budget. The exact device isn’t important, but Bluetooth is, especially if you want to pop panels back after you’ve finished setting up. I would also suggest some kind of mount, preferably close to your natural driving eyeline – in the early stages you’ll be glancing at your phone instead of your dash.

Next, pop into eBay and grab yourself an ELM327 Bluetooth adapter, this should at you back about a fiver. While you wait for this to arrive, you should locate your in-vehicle ODB port – this is a big D-connector hidden somewhere in the car with you, it shouldn’t be too hard to find as there’s legislation regarding how far away from the steering wheel it’s allowed to be. While you’re frantically googling for that, take a moment to visit the play store and grab “Torque Pro” by Ian Hawkins available here – it’s cheap, and it’ll do you proud for your first steps in to increased efficiency.

Plug your ELM327 adapter into your car, fire up Torque and go through setting up a new vehicle profile. Launch the realtime dash and you’ll see a handy little interface for creating your own little dashboard.

Six panels of a custom dashboard
My initial setup

Awesome, now to help me get my mileages up I added an instantaneous MPG gauge, an MPG histogram, current vehicle speed, current trip cost and a couple of others for interest. If you set up the same deal, then immediately you can start getting feedback on your driving profile and how minor changes to your driving style get that magical MPG number up. First thing I noticed was how vague the response to pedal position was in terms of acceleration – as a fly by wire throttle the position actually represent driver demanded load, and as such it seems to allow quite large differences in throttle opening from small changes to the pedal position.

This meant that while I was cruising I was losing about 4-7MPG in typical driving conditions, just because I could ease my foot off the pedal a degree or two and not lose speed.

Once I’d realised this, I added some more gauges; I’d become interested in how the ECU was making fueling decisions based on the available data, so I popped the fuel trims onto a couple of gauges and watched. Immediately I realised something was not right, the trim was batting back and forth by around 50%. What condition could cause this? A few minutes with a spanner proved that my sparkplugs where all well past their service gapping, and one had a cracked liner. A quick dash to the shops, tiny bit of checking with a feeler gauge and I’d snapped up another 3MPG, as well as getting rid of the slight (in retrospect obvious) hunting at idle. Making sure the tyres where fully inflated added a heart 1MPG to the matter.

A dashboard readout
555 miles to empty..

Now I’d gotten really interested in the architecture of the vehicle’s available communication systems, and I realised that I could make some more changes to the car’s behaviour through more involved tweaking. Having found out from some late night google-fu how to reset the learn-ins…

Ah, don’t know about learn-ins? Your vehicle is unique, because it’s made to a budget, not because it’s special. As a result there are lots of little bit of tolerance here and there that make a difference to how the vehicle behaves when compared to an absolute implementation of the engine’s blueprint. Tiny changes in the manufacture of critical components like injectors can result in very real implications for the running life of the engine. So, the engine management is given the capacity to learn how best to use itself to bring it back to it’s best running potential (and to a small degree, to learn how you drive it), by dialing in different fuelling decisions for different conditions.

With the learn-in’s reset, I found the car horrible, jerky and sluggish for the first ten miles… and then gradually it opened up into a soft and friendly ride; even the throttle pedal appeared to have a bit more leeway for that cruising effect.

That really whetted my appetite. At the moment, I’m writing a piece of software more details here to help me explore the rest of my car’s available programmable features – I’ll post more when I’ve got this into a more usable condition and can unleash it upon the world. I’m aiming to get to 50MPG; and when I do I fully intend to find out how I can get my car’s tax bracket reset!

My advice is offered as is and without acceptance of any liability for any loss or damage incurred as a result of such advice being followed even if I am aware of the possibility of such damage. You are responsible for all your actions.