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)



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:


  • 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 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.

Leave a Reply

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