Car Hacking | Report reveals security flaw in immobilizers

Over 100 models at risk from wireless attacks; study was hidden for two years

A security flaw in Volkswagen, Volvo and Fiat cars could allow hackers to remotely start and steal vehicles without having a key, a report has revealed.

The report, titled ‘Dismantling Megamos Crypto: Wirelessly Lock-picking a Vehicle Immobilizer’, was recently released after a Volkswagen court injunction blocking its publication was lifted after two years.

Cars are only supposed to start if the key is present in the car. But the report says anti-theft systems on some models can be hacked – allowing the car to be simply driven away.

Report authors Roel Verdult, Flavio Garcia and Baris Ege wrote: “We were able to recover the key and start the engine with a transponder-emulating device. Executing this attack from beginning to end takes only 30 minutes.”

The hackers were able to eavesdrop on the signals sent between the cars’ immobilizers and their keys.

Cars from Porsche, Ferrari, Audi, Bentley, Lamborghini and Alfa Romeo are among those that use the same transponders that the experts hacked.

Car hacking: could it happen to you?

The researchers are calling for their findings to be taken into account by car companies that use radio-frequency identification (RFID) technology, so necessary security measures can be put in place. But unlike a recent security flaw discovered on the Tesla Model S, the latest security risk cannot be fixed by a simple software upgrade.

The researchers who uncovered the flaw believe their findings should be made public and used as an incentive for car manufacturers to increase their cyber-security efforts.

The manufacturers, on the other hand, prefer to keep the discussion under wraps.

Volkswagen Group of America, along with 12 other car manufacturers, is lobbying for car technology to fall under the protection of the Digital Millennium Copyright Act in the US. If successful in its efforts, research of this nature would become illegal.

In a statement, Volkswagen said: “In this connection, Volkswagen does not make available information that might enable unauthorized individuals to gain access to its vehicles.

“In all aspects of vehicle security, be this mechanical or electronic, Volkswagen goes to great lengths to ensure the security and integrity of its products against external malicious attack.”

 

You can download the full report here

 

 

Credit: Simon Davis

Hack a Car | Part Two

a complete guide to hacking your vehicle bus on the cheap & easy – part 2 (interpreting the data)

OBD hackin part deux
in part 1 of this series, i covered the basics for how to interface with a vehicle bus using an inexpensive USB or Bluetooth ELM327-based scan tool. in part 2 below, i’ll go over how to actually use that hardware interface to collect and analyze data with the intention of discovering how to interact with the vehicle in some specific way.for my own first project, i wanted to know how to intercept the steering wheel radio remote-control button press events. i replaced my factory radio with a Motorola Xoom 10″ Android tablet in order to have a bigger and better GPS (and OBDII app, and better entertainment options, etc). however, touching the screen precisely while driving can be difficult (especially when bouncing around off-road). hence why i wanted the factory steering wheel buttons to still control volume, track, play/pause, etc. i’ll use this goal as an example to walk through navigating the bus data.
http://www.youtube-nocookie.com/embed/T3BidW0OYek?rel=0

 

what you’ll need

 

task 1: get a baseline

the first task is to gather some baseline data – i.e. what msgs are flying around the bus when your are NOT doing whatever particular interaction you are looking to find the msg for. i tested and found that with the vehicle not running, i could still use the steering wheel buttons to control the radio. that made things a little simpler since i would be able to gather all my sample data with the engine off and the key in “run” (there are way less msgs on the bus when the vehicle is not running).

  • issue the following commands (one at a time): ATL1, ATH1, ATS1, ATAL
  • be sure your serial terminal app is set to log to a text file.
  • issue ATMA to have the scan tool start reporting all of the bus msgs it sees.
  • just press enter after a minute to stop the stream of data.

 

task 2: log data from the event/interaction in question

the next task is to log the bus msgs when the action you are looking for occurs. this could be when something like when the radio changes tracks, when you press the sunroof close button, etc. i wanted to know the msg for each steering wheel button. i did a data collection run for each of the 6 buttons separately. for each run, i would press the same button 5 times, trying to space the presses evenly about 1 second apart. i wanted to create some sort of pattern that would hopefully stand out in the data stream.

  • repeat the steps from the previous task, while causing the event in question (or allowing it to happen if you have no control over it).

 

task 3: analyze the data

now you’re ready to analyze the data you collected in order to find just the bus msgs you care about. i used Excel, but you could go with any spreadsheet or database tool that you’re familiar with. the complete MS Excel spreadsheet for all the examples below can be downloaded here: 2003WJ-PCIBus-SWButtonData.xls

  • paste the data from each of your baseline/test runs into separate sheets of the spreadsheet. all the bus msgs should be in the first column. add a column header called “msg“.

sheetz

  • on the sheet with the baseline data, add a second column with the header “count“. just fill this column with a “1” for every row.

2-col

  • still on the baseline data sheet, create a pivot table that sums the count for each msg. this is just an easy way to give you a list of distinct msgs.

turn-n-pivot

  • now go to the sheet with your first sample data run. again use “msg” for the first column header and create a second column filled with 1’s called “count“.
  • for the third column add the header “not in baseline“. for the value of every row, specify a function that places the msg from the first column into this column ONLY if that msg is not in the baseline list. the function might look something like this (my baseline data pivot table is in the sheet named “baseline”, on column “D”):

=IF(ISNA(MATCH(A2,baseline!D:D,0)), A2, "")

you should end up with something like this, where the third column is a bunch of blank cells with only a few having msgs in them:

3-col

  • now create another pivot table similar to the previous. however, for this sample run sheet, use the “not in baseline” and “count” columns. this give you a list of distinct bus msgs that occurred during your test that were NOT duplicates of msgs from the baseline run. it also tells you how many times the msg occurred. you’ve basically removed the background noise from your data sample. if you’re after something really simple, this might be nearly the end of your journey. for my project, i needed to compare several of the buttons to really understand what was going on.

pivot once more

  • in the previous img, notice i had several distinct bus msgs that were not in my baseline. i had pressed the “up” button on the right side of the steering wheel 5 times for this test run, yet none of the distinct “not-in-baseline” msgs happened exactly 5 times! so i went ahead and repeated these steps for the other 2 buttons on the right side. below are the pivot tables i generated from each of the test runs.

dare to compare

  • now for some basic deductive reasoning and a little intuition. above i’ve highlighted in red all of the msgs that occurred at least 5 times – i knew that i definitely pressed the buttons distinctly and hard enough that they should have registered for each press, but perhaps they were sending multiple msgs if i held them down just a bit too long? next i crossed out any msgs duplicated between test runs (the 3 different buttons can’t be producing the exact same msg).

kris-kross

  • this left me with one unique msg to look at in 2 of the runs, and 2 unique msgs in the other run. however with this little data left, it was easy to spot a pattern – all 3 runs had a msg that was sent to bus ID 11. i guessed that 11 must be the radio’s ID, and the 3 distinct msgs sent  it must be my 3 buttons on the right side of the steering wheel.

 

task 4: test your hypothesis

  • you might next want to do a confirmation test, monitoring only the ID that you believe is sending the msg (ATMT#), or only the ID that the msg is destined for (ATMR#).

based on the deductions above, i thought i had the right 3 bus msgs. but why didn’t they occur exactly the number of times i pressed the buttons? i decided to perform another test, but only monitor ID 11 (the radio). hopefully my sample data would be small enough to look at directly and spot a pattern. again i tested each button separately, this time issuing the command ATMR11 to only see msgs destined for the radio. i pressed each button 5 times again, about a second apart. this time i was extremely deliberate and consistent in how i pressed each button. check out the results:

we have a GO

i think what is happening is a side-effect of mechanical switches known as contact bounce or chatter. i later saw that holding down a switch sends regular timed repeats of the msg, whereas a quick press can send from 1 to 3 msgs in rapid succession. this reinforces my suspicion of bounce.

  • another way to test your conclusions is to send the msg into the bus and physically verify the vehicle responds as expected. this would work for actions like locking/unlocking the doors, etc. i tried to replicate the “up” button on the right side of the steering wheel. if i was sending the right msg, then i would hear the radio increase volume (and see the display indicate the new level). the “up” button msg that i had monitored was 3D 11 04 00 C3, so i used the the command ATSH 3D 11 04 and then issued 00 C3. sure enough, it worked!

for all of the examples so far i’ve been working with the a SAE J1850 type bus. the msg structure and sample commands should work with most other protocols except CAN-Bus. you may have already inferred part of the msg structure:

3 byte header + up to 7 data bytes + checksum

the ELM327 reports the msgs in hex, so they look like this  (where PP = priority, RR = receiver ID, TT = transmitter ID, DD = data, CC = checksum):

PP RR TT DD DD DD DD DD DD DD CC

the msg structure for CAN is just a bit different, and the ELM327 has an entire set of commands specifically for working that protocol. check out the datasheet for complete info on msg structures and all the possible commands.

 

additional resources

  • walkthrough of a much more complex data gathering/analysis exercise (CAN-Bus, Mini Cooper)

http://bobodyne.com/web-docs/robots/MINI/CAN/MINI_CAN.pdf

  • Chrysler/Jeep/Dodge

http://www.canhack.org/

  • Audi/VW

http://secuduino.blogspot.com/2011/04/grupo-volkswagen-can-confort.html

http://www2.dasilvas.info/home/steering-wheel-buttons

  • BMW

http://web.archive.org/web/20041204074622/www.openbmw.org/bus/

http://www.reslers.de/IBUS/index.html

http://www.loopybunny.co.uk/CarPC/k_can.html

 

conclusions

you’ve likely surmised that vehicle bus hacking can prove non-trivial. it could be much more complex than my little example. i’ve read that some manufactures encode longer data across multiple standard msgs using custom schemes. deciphering something like that might be impractical. deciphering constantly changing data from a running vehicle is also challenging.

there are professional data collection and analysis tools/software, but you could also write your own. creating a simple application that time-stamps each msg in the log file would be a good start to help find patterns. adding the capability to graph msg frequency would be useful as well.

i came away from this project frustrated that the majority of data moving about in our vehicles is proprietary. it’s just another example of how society is moving away from a fix-it culture. if this type of information remains confidential, there is no hope of an individual or small repair shop fixing certain types of vehicle problems. we’re not far from a future where cars are as throw-away as iPads. one day i’ll have a Jeep that has to go to the Fiat/Chrysler Genius Bar. there i’ll find out that repairing whatever minor issue it has is too costly because everything is glued together, and that i’m better off buying the new model.

 

Credit: theksmith

Hack a Car | Part One

A complete guide to hacking your vehicle bus on the cheap & easy hardware interface

haxored?
modern vehicles have internal networks that provide access to nearly every major component and accessory – everything from the transmission to the cd-changer.why hack it? because you can! maybe you want to install your own car-puter that will replace the radio and climate controls. or maybe you’d like to make your key fob roll up windows or remote-start. i’m sure you can think of something.

so that’s different

net-ardu-micro-propeller-thingy

it seems people often approach this concept with an Arduino/NetDuino/PIC/etc, plus a shield or some custom circuitry, and a bit of custom code. depending on your end goal, a microcontroller could be the best approach. however, this article is about getting started quickly and cheaply by leveraging a standard ELM327-based OBD-II scan tool (~$25) and your laptop, tablet, phone, Raspberry Pi, etc.

note: we’re not talking about “pulling codes” or clearing the check engine light, that’s everyday stuff. we want to control and get info from accessories attached to the more interesting buses.

all aboard the short bus (background)

in 1996 a federal law took effect requiring most new consumer vehicles in the US to have standards-based On Board Diagnostics, called OBD-II. the OBD regulations were put in place by the EPA for monitoring emissions related components, but the systems have evolved to be much more capable.

don't be a tool

the good thing about OBD-II was it defined a limited set of network types that a car maker could implement for the emissions related diagnostics. this meant that tools to interface with those networks could also become standardized and inexpensive. called scan-tools, they come in full-featured versions with built-in software/display/buttons, and dumb versions that must be connected to a PC/Mac/tablet/phone to be useful.

what follows is information on how to use one of these inexpensive scan-tools (the dumb USB, Bluetooth, or serial-port kind) to interface with a vehicle in ways it wasn’t exactly intended.

a couple ones that i’ve personally had success with:

step by step

the challenge: OBD-II standards only apply to the emissions related portions of a vehicle bus. other systems often operate on an entirely different bus which may or may not use the same protocol as the OBD-II diagnostic bus. even worse, the non-emissions-related bus data is proprietary manufacturer info that can vary for each make/model/year.

the good news is that for simplicity and cost-savings, most manufactures only implement a single network type during certain year ranges. since they have to use one of the standard OBD-II protocols for the diagnostic bus, they might as well use the same protocol (or a slight variation) on the other buses. this is why we are sometimes able to use a scan-tool to interface with a non-OBD bus.

from a high level, we need to:

  1. determine what protocol(s) our car uses
  2. make the physical connection
  3. test the interface
  4. start hacking

now onto those details…

step 1: which protocol?

vehicles usually have at least 2 buses, the main diagnostic bus and an interior or comfort bus. the diagnostic bus often has access to all the drivetrain components as well as the OBD-II emissions stuff. the simplest vehicles to hack are the ones where all the buses use the exact same protocol and all relay messages to each other. some vehicles may have the secondary buses connected to the diagnostic bus through a gateway that may only relay information when queried with the correct command. other vehicles use the same overal protocol on all buses, but different speeds.

buy a Factory Service Manual for your vehicle if at all possible. it will almost always tell you what you need to know to at least get connected and is full of great info. you can get FSM’s used on eBay if your vehicle is a few years old or get the PDF version if you can find it. online tech libraries like AllDataDIY may have complete service manual info too. public libraries sometimes have subscriptions to those services. don’t forget to just Google for your make/model and “OBDII protocol”, “OBD bus”, etc.

we are ultimately looking for the exact protocol that our target bus uses and any information about the messages that components on that bus send/receive. if we don’t have this info, we can still try connecting to the diagnostic bus and hope it relays from our target bus.

the OBD-II spec allows for the following protocols: SAE J1850 PWM, SAE J1850 VPW, ISO 9141-2, ISO 14230-4 KWP, ISO 15765-4 CAN, SAE J1939 CAN. if our target bus uses one of those, or if the target bus relays to the diagnostic bus, then we can continue with our hack of using a scan tool to interface with it.

example: i was able to find online that my 2003 Jeep Grand Cherokee (WJ) actually supported 2 different protocols for the OBD-II system (due to a factory mistake). the FSM cleared up which one was the native protocol for the “Chrysler PCI Bus” (SAE J1850 VPW). it also confirmed that the radio and steering wheel mounted remote-control buttons communicated via that PCI Bus. using those buttons to control something else was my personal end-goal.

step 2: physical connection

the OBD-II spec requires a standard diagnostic port to be located within 3 feet of the driver and be accessible without tools. usually it’s under the dash, right above your feet, and looks like this:

government mandated access port

this is often the simplest place to access a bus. these ports will have certain standard pins populated depending on which OBD-II protocol the vehicle uses. there are also pins left undefined by the spec. car makers often bring out access to other buses on these optional pins so that their own proprietary scan tools can interface with the entire vehicle. consult that Factory Service manual you bought for your connector pinout or wiring diagram. here’s the standard vehicle-agnostic pinout info:

count the pins!

important note: at this point you should move on to step 3 and try the main diagnostic bus first. if that doesn’t get you the info you want, then come back here for how to tap into the correct bus directly.

if your vehicle’s diagnostic port does have pins with access to the target bus, then you can take apart your scan tool and swap wires from the standard pins to the target bus pins. otherwise you may need to actually splice into a wire harness somewhere in the vehicle. you can get an OBD-II extension cable from Amazon/eBay for cheap and hack off the vehicle end to give you raw wires to play with. tip: the radio wiring harness is often a great place to get at the interior/comfort bus.

example: my FSM told me that pin 3 of the diagnostic port went to the radio-related bus. since my Grand Cherokee uses the single wire J1850-VPW protocol, i only had to swap one wire inside my scan tool from pin 2 to pin 3 to get a direct connection to the bus i was interested in. i later found out that all the buses in my particular vehicle relay between each other and so i didn’t really even need to do that.

step 3: basic first tests

if you’re still reading then you’ve probably had all the background info you can stand and are dying to get to some actual hacking. bear with me as there’s one more bundle of knowledge required – how to actually use an ELM327-based scan-tool to read and write bus data.

these scan tools use the ELM327 IC from Elm Electronics (or more likely a clone). we can interact with the IC using AT commands similar to modems from back-in-the-day.

to get started exploring, you need a serial port terminal application (even for USB and Bluetooth devices, they create virtual serial ports). HyperTerminal for the PC has a free trial, goSerial for the Mac is free, and there’s Slick USB 2 Serial Terminal for Android 3.1+ in free and paid versions.

connect your scan tool to your vehicle and computer or Android device (iOS devices might work also, i haven’t had a chance to check into it). turn your vehicle on (the key in “run”, no need to actually start it). pull up your serial terminal program and connect to the scan-tool. check the manual for connection settings. nearly every one that i tested used the following:

  • Speed/Baud: 115200
  • Data Bits: 8
  • Parity: none
  • Stop Bits: 1
  • Hardware Flow Control Input: none
  • Hardware Flow Control Output: none

once connected, type the command ATI and press enter. you should get back ELM327 v1.4b (the version might be different). if nothing comes back, try ATZ instead and wait a couple seconds for the device to reset. if you don’t get anything back or you get random looking characters, you probably have the baud rate set wrong in your serial software. i did try one odd scan tool that used a rate of 9600 when not connected to the vehicle and 38400 when connected.

once you have verified that your connection to the scan tool is working, then we want to verify the scan tool’s connection to the vehicle is working. issue the command ATSP0 to tell the tool to use automatic protocol selection (you should get back OK). then issue ATMA and you’ll get back a stream of data (sets of hex numbers to be exact). just press enter again to stop the stream. if you don’t get any data back, then double check the scan-tool’s connection to the vehicle and that the vehicle is on.

if you know for sure which protocol your vehicle is using, you can try setting the tool for that instead of automatic. issue ATSP# but replace the “#” with one of the following designators:

  • 0 – Automatic
  • 1 – SAE J1850 PWM (41.6 kbaud)
  • 2 – SAE J1850 VPW (10.4 kbaud)
  • 3 – ISO 9141-2 (5 baud init, 10.4 kbaud)
  • 4 – ISO 14230-4 KWP (5 baud init, 10.4 kbaud)
  • 5 – ISO 14230-4 KWP (fast init, 10.4 kbaud)
  • 6 – ISO 15765-4 CAN (11 bit ID, 500 kbaud)
  • 7 – ISO 15765-4 CAN (29 bit ID, 500 kbaud)
  • 8 – ISO 15765-4 CAN (11 bit ID, 250 kbaud)
  • 9 – ISO 15765-4 CAN (29 bit ID, 250 kbaud)
  • A – SAE J1939 CAN (29 bit ID, 250 kbaud)

i always issue the following commands to get the scan tool into a baseline state (enter them one at a time, you should get back OK for each one): ATL1, ATH1, ATS1, ATAL. that will ensure that you see human readable data, which will enable us to analyze what’s going on. most scan tools will remember these settings between uses.

super cereal

for more information on interacting with the ELM327 IC (and to lookup what those commands did):

step 4: start hacking

that last datasheet, combined with the info in this post, should be all you need to start hacking!

my next post (part 2) will give more detail about how to get what you want out-of or in-to the bus. i’ll be covering:

  • the bus message structure
  • a real-world example of how to find what messages you care about
  • how to send msgs into the bus to control components
Credit: theksmith