Let me start out with this statement: my OSEK skills are decent, but I’m not the foremost expert here.  I will tell you what I know and leave it up to you to belittle me in the comment section.  Thank you.

The OSEK standard is a large section of documents that cover many, many aspects of CAN BUS communication, Network Management is a small section of this entire cadre.  The entire document can be purchased publicly, I just don’t remember how.  The Network Management section (2.5.3; available for free download here) is 130+ pages and is a riveting tale of bits and bytes.  So let me tell you about some of the highlights…

OSEK Network Management (NM) primarily works by passing a ‘token’ around a logical ‘ring’.  This token is simply like passing a one byte message to your neighbor and then your neighbor passes it to his neighbor and so on until it comes back to you and you start the process all over again.  The key here is what does the message token mean?  At first the message token just broadcasts your network management ID.  For example if your CAN BUS Arbitration ID is 0x420 your NM ID would be 0x20 (the lower byte of your Arb. ID). Each node on the bus would have its own NM message.  So if you have five nodes you would have five NM messages all of them within a particular range (this range is specified by the OEM not OSEK).

Once the node has sent out its ID, it starts listening for other NM messages (it knows of other NM messages because these messages will be in a particular range of Arbitration IDs).  Once a certain time has elapsed it will send a token to its neighbor.  This might look like this: 0x420 21 12 00 00 00 00 00 00 00 00.  Where the 0x21 is its neighbor’s ID and 0x12 is the token.  Once the neighbor has received his message, he will in turn send his own NM message with his own token: 0x421 26 32 00 00 00 00 00 00. Where 0x26 is the next node ID in the ring and 0x32 is the token. And then the cycle would continue, where each node passed their token to the next node and so on.

The token is encoded data that indicates the node’s desired state for the network.  For instant if the network should go to sleep, nodes that wish for sleep will turn on an “enable sleep” bit in the token.  If all of the nodes enable this bit, then the final node to elect for sleep will then send the “sleep network” bit and the network will go to sleep.  This sleep is only temporary until another message is sent, this will initial a network wakeup and NM messages will start broadcasting with a token that indicates this message is an Initialization message.

So the key to a NM message is how the token is decoded and this is not specified by the OSEK layer but rather by the OEMs themselves.

With thousands of data parameters flowing continuously along one or more CAN Buses in any particular vehicle, there is no doubt that finding out what these parameters mean can be very benificial, but, in having the data, you can also use it to simulate what is there.

So why would you want to simulate what is ALREADY there? One, because you want to get rid of what is there and add something of your own. Removing the engine and engine controller? No problem just simulate it, the other modules probably wont care. Removing the driver or passenger seat, no problem just simulate it, the other modules probably wont care.

Or two, you want to enhance the functionality of existing controllers. Want the doors to auto-lock at 2mph not 5mph? No problem simulate the lock message, the doors won't mind. Want to have the vehicle chime all the time while the seat belts aren't buckled, no problem simulate the chime.

So how does simulation work? Typically, you will need to look at the message(s) that you want to simulate. What is there Arbitration ID? What is there data length? Is the data static or dynamic? Is it sent periodically, on event, or both? If you send the message and do not remove the original controller that is sending the message are the desired results nullified by the original controller (i.e. if you are sending head lights ON and the original controller is sending head lights OFF, do the headlight turn ON, OFF or flicker?) ?

Once you've answered these questions, then you are ready to begin. So what was the Arbitration ID? Let's say it was 0x555. Ok now what's the data length? 8 bytes with static data, sent periodically at 100ms update rate.

Let's assume this message is a command that moves the driver mirror up when we change the first byte from 0x00 to 0x01. So the message on the Bus looks something like this: 0x555 00 00 00 00 00 00 00 00. But if we send our simulated message of 0x555 01 00 00 00 00 00 00 00 the mirror will move up just a smidge and if we send it at 100ms it will continue to move up until we stop sending or we change the first data byte from 0x01 back to 0x00. However we may notice that the upward movement of the mirror is not as smooth as when I press the up button of the mirror control switch. This is because you are simulating a message that is already present on the CAN Bus. This means that the receiving controller is receiving your message 0x01 and the original controller's message 0x00 and interpreting an Up command when your message arrives and a Stop command when the original controller's message arrives. Depending on how well or bad the software for the mirror control module is written, this may cause havoc on the system you plan to implement, and will most definitely be the source of many CAN Bus Error frames (don't worry there not too bad, in general it is almost impossible to cause any issue when simulating an existing CAN Arbitration ID).

So, in this instants, if we want to make the control as smooth as the original switch, we must stop the existing controller from sending the message. There are a couple of ways to do this, the first is obvious, disconnect or power-down the original controller. Remove a fuse, disconnect the CAN Bus or power from the controller. Now of course this will most definitely have other symptoms, but if your application can tolerate this, then its the easiest and simplest solution.

Next to physically disconnecting the module is using diagnostic messaging to ask the module the stop sending. Often called Disable Normal Communications. If supported, this service will make the module stop sending its data. The problem is that the message format and rules are typically quite different from vehicle manufacture to manufacture, so unless you know what this message is, it is difficult to make this work. Plus this method suffers similar draw-backs as the power-down method mentioned above.

Last, you can gateway the message. Gatewaying the message is done by disconnecting the sending OR receiving module (typically easier when it is the receiver). Once disconnected, you can gateway all of the message to the receiving module EXECPT the one that you want to simulate. This allows you to have complete control over the data in that message while maintaining the messages and data from other modules. As you can imagine this solution requires the most work because you must have a device that is fast, support at least two identical CAN Bus channels, and is quickly programmable. But if you can get these three things together, you will can simulate nearly any message with nearly zero issues.

Well this has been some simulating conversation...

Every CAN message has an Identifier.  This is referred to as the Arbitration ID or ArbID.  It serves two functions.  First, it is to help identify the payload or data of the frame. Second, because no two modules are allowed to send a frame with the same ID, it serves as an arbitration method on which frame gets priority on the bus when two or more messages are sent at the SAME TIME (in other words if a low priority ArbID frame is half-way through sending, a higher priority ArbID will not stop that frame from sending).

So if the ArbID is the identifier of the message, what are Extended IDs?  The concept is simple, take the ArbID and add data bytes from the frame as the ID as well.  For instance, say you have to messages you want to send: Engine Speed and Engine Coolant Temp.  A lot of the time you will see them sent in the same message with the same ID and always in their same respective location in that message.  However what if you wanted all of your parameters to occupy byte 5 of every frame, and instead you change out the ID to denote the parameter, but because of application rules you are only allowed to broadcast on a single ID?  In this case you would use Extended IDs.

For example your only ID you are allowed to send is ID 0x444 (again this is because of rules imposed by a network design committee not by CAN Bus itself).  And you have more data than one frame can possibly hold or you want all of your parameters to be in the 5th byte?  In this case you may set byte 1 as your Extended ID and for each parameter you would assign a new ID.  So Engine Speed would be 0x0C and Coolant Temp would be 0x05 and Engine Parameter X = 0x06, Y=0x07, etc.

Your Engine Speed Frame would look like this: 0x444 0C 03 00 FF 22 00 00 00 00; where 0x22 Is the engine speed. And for Engine Coolant Temp it may look like this 0x444 05 04 00 FF 10 00 00 00 00; where 0x10 is the Engine Coolant value.  So you can see that if you have certain limitations on network IDs, Extended IDs can give you more versatility.

Extended IDs can also be seen in Diagnostics messages as well.  For instance Toyota vehicles often use Extended IDs for Diagnostic Requests and Responses. A typical Enhanced Diagnostic Request on Toyota vehicles starts with 0x750 and the first data byte is the Destination Controller Address.  Compare this with an OEM that does not use Extended IDs, but rather assigns each ECU Destination address its own Arbitration ID (Ford, GM, Chysler, etc.)  The more controllers you have the fewer available Arbitration IDs would be available because they would be taken by Diagnostic Identifiers.

Now you know what some applications are for extended IDs and know that you know, it should be easier for you to identify them when reverse engineering data on the CAN Bus.

This year's Defcon will host yours truely.  I will be giving a workshop on CAN BUS Hacking.  So if you have some time come out and join us at Defcon August 4~7 @ the Rio Hotel in Las Vegas, NV.

Please check out www.defcon.org for more information about what days the workshops will be held.

Here is a preliminary example of what will be:

* Introduction
* What is Vehicle Network Communications (Demo)
* Compare Vehicle Comms vs. Ethernet
* Compare Vehicle Comms vs. TCP/IP
* Types of Vehicle Network Physical Layers
* J1850 PWM/VPW
* LIN/ISO 9141
* CAN Bus
* SWCAN
* LSFT CAN
* DW CAN
* Devices Used to Connect to CAN BUS
* Arduino (Demo)
* neoVI/ValueCAN (Demo)
* Generic ELM Tool
* DW CAN Bus Physical Network (Wires and Resistive Properties)
* CAN BUS Data Frame
* IPC or other Controller (Demo)
* Understanding the data on the Bus: Diagnostic Message vs. Normal Messages
* Reverse Engineering Normal Messages (Demo)
* Diagnostic Protocols
* OBDII
* ISO 14239
* ISO 14229
* GMLAN
* Commanding the Vehicle Controllers using CAN BUS
* Understanding Security Systems
* Controller Security Access (Possible Demo)
* Immobilizers (Possible Demo)
* Q&A
* The autoAPIa Project

UPDATE:

Workshops schedule has been released go to https://www.defcon.org/html/defcon-19/dc-19-workshops.html#Leale for more information about the workshops.  The cost is $200 (Cash only) and it will take place starting at 10:00 AM on Friday, August 5th.  I am not sure yet if it is first-come-first-serve or not.  I will update when I find out.

UPDATE 2:

Thank everyone for coming out to the DefCon workshop, had many more people that I thought could make it.  It was a wonderful success.  As promissed here are the links for the workshop's powerpoint:  http://www.canbushack.com/defcon19/workshop.pptx

In diagnostic messaging, services are the functions.  Think of each command as a sentence.  The service is the verb. In standard OBDII services are often referred to as Modes.  You can also think of them as functions to be performed by the controller(s) that you are commanding.
With diagnostic messages, there is always a command and almost always a response from the controller(s) you are commanding.
When looking at raw CAN Bus data the service is often the second, third, or in very few cases the fourth data byte of the message.  In nearly all cases, OEMs will implement ISO 15765-2 (Click Here to read about this protocol).  So the service will be the first byte after the Transport Protocol information.

Here is an example of and OBDII message to get Engine Speed using the CAN Bus ($01 is the Service):
$7DF 02 01 0D 00 00 00 00 00

Will hopefully return the following:
$7E8 04 41 0D 01 FE 00 00 00

Here is a simple list of some common Services that you might find:

OBDII Services (a.k.a. Modes):
$01 - Request Current Powertrain Diagnostic Data
$02 - Request Powertrain Freeze Frame Data
$03 - Request Emission-Related Diagnostic Trouble Codes
$04 - Clear/Reset Emission-Related Diagnostic Information
$05 - Request Oxygen Sensor Monitoring Test Results
$06 - Request On-Board Monitoring Test Results for Specific Monitored Systems
$07 - Request Emission-Related Diagnostic Trouble Codes Detected During Current or Last Completed Driving Cycle
$08 - Request Control of On-Board System, Test or Component
$09 - Request Vehicle Information
$0A - Request Emission-Related Diagnostic Trouble Codes with Permanent Status

Services $10 and higher are non-OBDII services also known as Enhanced Diagnostics.  This is because, unlike OBDII Diagnostics, these services are not government mandated thus each OEM will use their own specification.  For Example GM vehicles use the GMLAN diagnostic protocol.  Ford used ISO-14230 but now use ISO-14229 (UDS).  Each OEM is can decidedly use their own enhanced diagnostic protocol.

GMLAN Enhanced Services:
$10 - Initiate Diagnostics
$12 - Read Failure Record
$1A - Read Diagnostic ID (DID)
$20 - Return To Normal
$22 - Read Data By Parameter ID (PID)
$23 - Read Memory Address
$27 - Security Access
$28 - Disable Normal Communications
$2C - Define Dynamic Data Packet ID (DPID)
$2D - Define PID by Memory Address
$34 - Request Download
$36 - Transfer Data
$3B - Write DID
$3E - Tester Present
$A2 - Report Programming State
$A5 - Enter Programming Mode
$A9 - Check Codes
$AA - Read DPID
$AE - Device Control

Here is an example of a CAN Bus message to get the Engine Speed using Enhanced Diagnostics (where $22 is the service):
$7E0 03 22 00 0D 00 00 00 00

And this will hopefully return:
$7E8 04 62 00 0D 01 7E 00 00

ISO - 14229:
$10 - Diagnostic Session Control
$11 - ECU Reset
$14 - Clear Diagnostic Information
$19 - Read Diagnostic Trouble Codes (DTC)
$22 - Read Data by ID
$23 - Read Memory by Address
$24 - Read Scaling Data by ID
$27 - Security Access
$28 - Communications Control
$2A - Read Data by Periodic ID
$2C - Dynamically Define Data ID
$2E - Write Data by ID
$2F - Input/Output Control
$31 - Routine Control
$34 - Request Download
$35 - Request Upload
$36 - Transfer Data
$37 - Request Transfer Exit
$3D - Write Memory by Address
$3E - Tester Present
$83 - Access Timing Parameter
$84 - Secured Data Transmission
$85 - Control DTC Setting
$86 - Response on Event
$87 - Link Control

Now that you have a list of Services, hopefully this will make reading the raw can data a bit more manageable. Soon I will post more information about specific services themselves.  If any are more interesting to you, please post in the comments below.

Because diagnostics is really just a simple way to interact with an ECU, there are a few very common diagnostic services that you’ll find in nearly every permutation of diagnostics.

Tester Present:
Definitely the most common service you’ll find, tester present (typically 0x3E) is used to let the controller(s) know that there is a.. wait for it.. Tester present.  I know it was a bit obvious, but the idea is that some services keep the controller in an augmented state or a diagnostic state.  When this happens there needs to be some way of maintaining that state while the tool that initiated the state is still connected to the diagnostic connector.

So Tester Present is designed to be a heart beet of the diagnostic tool and in the event that the device stops working or is disconnected from the network, the ECU whose state has been altered will stop seeing the tester present message and thus transition out of its altered state.

So if you want to maintain a diagnostic state you should send the tester present message.  A typical timeout for Tester Present is 3 Seconds.  So as long as you send the message between 1 and 2.5 seconds, you will be able to maintain the diagnostic state of a controller.

Read Data by PID:
Reading data from a controller is pretty much the reason for diagnostics in the first place.  So there is no surprise that there are at least two ways to accomplish this task on nearly every new vehicle on the market today.  Services 0x01 and 0x22 are used for this purpose.

Service 0x01 is the OBDII Read data by PID (Parameter ID) where the PID is a one byte number representing the data you want to read.  Service 0x22 is the Enhanced diagnostic method for reading data.  Service 0x22 is typically a two byte PID that represent the parameter you want to read.  In some cases this two byte parameter may also be used in conjunction with another Enhanced diagnostic service to write the data as well (however exactly how this is done varies).

Security Access:
Controllers contain data that manufactures do not want just anyone having access to.  This is typically to stop strange people such as yourself writing data to the controller to modify how it performs.  So in nearly every controller there is a method to “unlock” the data.  To perform this, it is done with service 0x27, the security access service.

In order to “unlock” the controller you must first ask it for a Seed.  This seed will be used in conjunction with a proprietary algorithm to generate a Key.  Then the key will be sent back to the controller.  If the calculation that the controller did is the same as the key that you sent, then the controller will send a positive response indicating that the controller is now unlocked.

There may be several levels of Security Access.  This is due because they may want certain features available to one group of people such as locksmiths who may need to add a new key to the vehicle while still keeping the other levels secure.  So a typically Security Access transaction will have sub-functions that will essentially be the level that you wish to access, these sub-functions operation in Odd/Even Pairs.  So sub-function 0x01 will be the seed request and 0x02 will be the key response.  Then it’s 0x03/0x04, 0x05/0x06, … 0x21/0x22, etc.

That’s pretty much all that is very similar across all of the diagnostic protocols.  Once you’ve learned these three services, you find that they very similar.

Some services are boring.. like really, really, really, boring.. but others can make the car move gauges or make the car’s warning lights light up.  Here is a bit more about these types of services.

Stop Normal Communications (GMLAN and Others):
This service is fun because you can make the Normal Communications (the ECU to ECU communications that occurs normally on the network) stop.  Why would such a service exist, mostly to clear the bus for large amounts of data such as when a controller is going to be reflashed over the CAN Bus.  On GMLAN this service is 0x28.  It does not require any sub-function so an example of this might be: 0x7E0 01 28 00 00 00 00 00 00. This will command the engine controller to stop sending normal communications.  Of course you don’t ever want to do this while the car is being driven, but it’s pretty fun to see what happens when you do it!

You will see the Engine Controllers Normal messages virtually disappear.  I say virtually because not all messages will go away, some that are mission critical will stay, but a lot of them will not.

This service can also be useful if you want to simulate the messages the ECU would send without removing the power to the controller or cutting the CAN Bus itself.

This service requires that you continually send a Tester Present (0x3E) message periodically (2 seconds is good) in order to maintain this.  If you want to return the communications send a Return to Normal message (0x20): 0x7E0 01 20 00 00 00 00 00 00.  This will restore communications.  Or simply stop sending the Tester Present message and it will automatically restore communications after 3 seconds. Oh what fun you’ll have.

Input/Output Control (ISO 14229 – UDS):
This is pretty much the coolest services ever made.  I/O Control is exactly as it sounds, you can command Outputs on the Module to do your bidding.  Of course software control will limit your bidding to a safe and secure bidding, but it’s still cool.

I/O Control (Service 0x2F) requires 3 parameters: a DID (Data ID), Control Record, and Control Mask.  The DID is a two byte ID for the output (or input) you want to modify.  Control Record is what you want the output to do (On/Off, Up/Down, etc.). Control Mask is a bitwise mask of one or more parameters that will be modified.  An Example of a I/O Control is something like this: 0x7E0 06 2F 11 22 07 01 00 00 00.  Where 0x1122 is the DID, 0x07 is the Control Record, and 0x0100 is the mask.  This is not a real function, but you could potentially iterate through all possibilities and wait for the controller to give you a positive response.  It would take a while, but it’d be interesting to see what happened…. Right!?

It’s likely that you will get a negative response from the controller 0x7E8 03 7F 2F 13 00 00 00 00, where 0x13 is the Negative Response Code (NRC).

Here are a few possible NRCs you may receive:

•    0x13 – Incorrect Message Length or Invalid Format.
•    0x22 – Condition Not Correct.
•    0x31 – Request Out of Range.
•    0x33 – Security Access Denied.
•    0x80-0xFF – OEM Specific.

Good luck……. .. have fun ..

I will be doing a quick 1 hour presentation at this year’s HOPE (Hackers On Planet Earth) conference at the Hotel Pennsylvania in New York, NY July 13-15 (http://www.hopenumbernine.net).  The title will be “Exploited from Detroit.”  I plan to talk about how to get started in Reverse Engineering vehicle network data and give some particle examples of this data.  Because its only one hour, it will be short and to the point.  I will be fielding questions and if anyone wants to volunteer a vehicle we may even be able to find time to connect to a car and have a real world demonstration.

More details to come as they are released.

Update:

Just got the time and Date for “Exploited from Detroit” "How to Communicate with Your Car’s Network"
Day/Time: Friday, July 13, 2012 - 2200
Location: Sassaman (18th floor)

If you're in Amsterdam March 14th stop by Black Hat Europe and check out my 5+ hour Workshop:

• Vehicle Networks: Vehicle Networks History (10 Minutes)
• Vehicle Networks: CAN Bus-History (10 Minutes)
• Vehicle Networks: CAN Bus-Physical Layer (30 Minutes)
• Activity: Create our Own CAN Bus (15 Minutes)
• Activity: Transmit Messages on CAN Bus (15 Minutes)
• Vehicle Networks: CAN Bus Frame (10 Minutes)
• Activity: Receive Messages on CAN Bus (30 Minutes)
• Activity: Reverse Engineer Controller Traffic (30 Minutes)
• Activity: DoS CAN Bus (15 Minutes)
• Diagnostics: Building a ISO 15765-2 Frame (30 Minutes)
• Activity: Fuzzing CAN Bus (30 Minutes)
• Security: Understanding Security Access (30 Minutes)

Or if you are in San Jose April 23rd, stop by Design West and check out my one hour talk on Vehilce Network Denial of Service.

Been a long time coming but finally someone else is out there making some news on Car hacking front.

http://video.foxbusiness.com/v/2566303720001/hackers-can-take-control-of-your-car/

http://www.npr.org/blogs/alltechconsidered/2013/07/31/206728147/what-were-watching-as-worlds-big-hackers-meet-this-week

Congrats to Chris Valasek and Charlie Miller for really trying to open the door to this world.

With all of this information in the news, you can learn yourself.  Just email me by clicking on the contact link above.  Shoot me a request.  We'll see if we can get some of us together.  We have some curriculum ready to go.

Hope to hear from you soon.

So vehicle manufacturers don’t like you… why?  Because they know you want to modify your car in ways they never intended.  They know you want to break your car and make them fix it under a warrantee claim.  They know you want to Hack your car and make it do fun things.  So they put in place a service that will deter you from accessing privileged functions on your vehicle.

What are these functions? Things like reflashing a controller.  Not just anyone should be able to do this.  Resetting the Odometer.  Accessing control commands that would potentially stop a vehicle from functioning properly.

How do they stop you? Security Access a.k.a. Mode 0x27.  This is the service that validates an application is authorized to do one or more of the privileged functions.
So how does it work?  Well it varies a bit from OEM to OEM, but they all typically work the same.  First you must be in a diagnostic mode (not all OEMs require this, but many do).  So you have to use Service 0x10 – Start Diagnostics.

Start Diagnostics will typically take a Subfunction.  This Subfuction tells the ECU which Level of Diagnostics it needs to go into.  Some OEMs have two or three levels of Diagnostics: OBDII/Standard Diagnostics, Reflashing, and Enhanced Diagnostics.  These subfunctions vary widely depending on the OEM so you’ll have to poke around to find out which your vehicle supports.  Some good ones to try are 0x01, 0x02, 0x03, 0x80, 0x81, 0x82, 0x90).  I’ve found these to be common.  So an example is this: 0x7E0 02 10 82 00 00 00 00 00. If done correctly you will get back this: 0x7E8 02 50 82 00 00 00 00 00.  If not you will likely get this 0x7E8 03 7F 10 12 00 00 00 00 00 meaning that the Subfunction is not supported, so you’ll need to try another.  You might just want to increment through the entire range of 256 possible subfunction levels.  Once you’ve found one that works, you can move on.

So Security Access is a Seed/Key authentication method.  First you request a Seed from the ECU then you calculate the appropriate Key response then send it back to the ECU.  Of course you likely don’t have the appropriate algorithm to successfully calculate the Key.  So you may need to brute force it.  (I’ve spoke about this in an early post, but I’m going to reiterate it here with some more general examples).

Brute forcing the key will take a while. How long? Well that depends on how wide the Key is (is it 2 bytes wide, 3 bytes, etc.).  How do you know how wide it is?  You have to make an educated guess.  You do this by seeing how wide the Seed is.  You know this by requesting the Seed from the controller (I’ll go into how to do this in a bit).  So if the Seed is 2 bytes, likely the Key is too.  If the Seed is 4 bytes or larger, the odds that you’ll be able to brute force it in any reasonable time is unlikely as manufactures add some simple steps to slow down the brute forcing method.

So how do you request a Seed? Send this 0x7E0 02 27 01 00 00 00 00 00 (do this within 3 seconds of the Start Diagnostics command).  You should get back a Seed in the response: 0x7E8 04 67 01 XX XX 00 00 00 or 0x7E8 05 67 01 XX XX XX 00 00.  Remember that the 0x04 indicates that the Seed will be two bytes wide (two bytes for the control information and two bytes for the seed) and 0x05 means the Seed will be three bytes wide. Also, you don’t have to send 0x01 as the subfunciton, but all Seed request have odd numbers (except 0xFF) as the subfunction.  This is how you differentiate from a Seed Request from a Key (Key requests are even numbers and must be x+1 where the Seed request subfunction is x).
Now you have a Seed, that’s nice.  But you have no way of calculating the Key so why even bother asking for one?  Why not just send the Key?  Because you can’t, you must ask for a Seed before you can send a Key.  The system requires it.

Now you need to send the Key.. but wait not yet.  Because there is one thing you need to determine first.  Is the Seed static or dynamic?  You want to know this because this will let you know if you are going to increment your key or not.  If the Seed is static, then you’ll need to change the Key when you are brute forcing the system.  If the Seed is dynamic, then you’ll want to keep the Key Static. So send another Seed Request.  Did the Seed change?  If so it’s a dynamic Seed.  If not it’s static.
Now we need to send a Key.  To do this we send 0x7E0 04 27 02 XX XX 00 00 00, where XX XX is the Key (remember 0x02 subfunction is x+1 of the Seed request). Likely we will get a negative response because the odds of us guessing the exact Key for the Seed we received is 1/(2^key width).  So if key width = 65536 then we have a 1/65536 chance of getting it right.  Now if we increment through all possible Keys then our odds of getting the response approach 100% quickly (see the birthday problem).  But if the Seed is dynamic we don’t want to increment the Key.  So this is a much different problem.

However those pesky engineers at the auto manufactures thought of this brute force method and took some steps to slow us down. How? By making it so that we after 3 or 4 attempts we get locked out. How do we know that we’ve reached this condition? They let us know by sending this: 0x7E8 03 7F 27 36 00 00 00 00.  Which means “Exceeded Number of Attempts.” This means we have to someone reset the controller so we can try again.  This can be achieved by either cycling the power.  You can do this by finding the fuse for the controller and simply pulling it.  Now this could be cumbersome so you may want to automate it using your favorite open source embedded controller.  Or we may be able to reset it using the ECU Reset Service a.k.a. Mode 11.

ECU Reset is the funnest service ever… because it allows you to tell a controller to cycle its power.  (Don’t try it while you are actually driving bad things may happen……).  The problem with ECU Reset is there are so many different permutations of it, it’s hard to describe universally.  So you’ll have to do some experimenting on how your vehicle has it implemented.  But here is an example of how it may work: 0x7E0 02 11 01 00 00 00 00 00.  Because you did a reset, you may not get a response from the controller at all if you did it correctly.  However if it didn’t like the request, it will give you a negative response 0x7E8 03 7F 11 XX 00 00 00 00, where XX is the negative response code.  You’ll have to parse the code know how to handle the exception.  If the NRC is 0x12 just keep trying all subfunctions until one of them works.

Once you’ve reset the controller, send another Seed request.  If you still get “Exceeded Number of Attempts” as a response.  Then the reset didn’t work. Keep trying more subfunction of the reset command until you’ve exhausted them all.  If still no luck, you’ll have to do a hard reset of the power to the ECU (pulling the fuse).  Now try to send another Seed request.  Likely if you do this quickly (within 10 or so seconds of the ECU powering up), you’ll get another negative response, 0x7E8 03 7F 27 37 00 00 00 00, “Required Time Delay Not Expired.” Meaning that you have to wait a few seconds longer.  Keep trying until this error goes away.  This is just another way that the manufacturer has made it difficult for you to brute force the system.  Because of this delay, the brute force will take much longer.  But if you’re motivated you’ll eventually get there.

How will you know you’ve got it?  You’ll see this: 0x7E8 02 67 02 00 00 00 00 00.  Then you can be sure.  And if you missed that message you can always send another Seed request.  If you get Seed of Zero that means that the ECU security is bypassed.

Don’t let the window close.  If you want to keep the ECU “unlocked” then you’ll need to maintain this state.  To do this simply keep sending a Seed request or better, send a Tester Present message: 0x7E0 02 3E XX 00 00 00 00 00, where XX is the subfunction (you’ll have to test this first to see what works) or 0x7E0 01 3E 00 00 00 00 00 00.
Good Luck and as always feel free to contact me if you have any questions.

Good news training is coming to a Las Vegas near you!

TITLE: Vehicle CAN Bus Communications and Diagnsotics Reverse Engineering

WHEN: August 2-3 or August 4-5, 2014 (Two Sessions of the same course each two days long)

WHERE: Mandalay Bay, Las Vegas, NV

WHY: BlackHat 2014

WHO: You, Me and 14 other CanBusHackers

HOW: Sign Up Now while there is still the introductory price at <http://www.blackhat.com/us-14/training/vehicle-can-bus-communications-and-diagnostics-reverse-engineering.html>

PRIZES: That's right, Prizes.  I'll do anything to get you in the door.

Now we have a large garage.

New address:

1848 Star Batt Rd.
Rochester Hills, MI
48309

I just recently got my hands on a great introductory book into Car Hacking!  It’s called Car Hackers 2014 by Craig Smith.  I’ve worked with Craig in the past and was pleased to see his book.  It’s a great place to start if you want to get more information about the fundamentals of a lot of car hacking things.

Here is the Outline:

Introduction
Understanding Attack Surfaces
Infotainment Systems
Vehicle Communication Systems
Engine Control Unit
CAN Bus Reversing Methodology
Breaking the Vehicle
CAN Bus Tools
Weaponizing CAN Findings
Attacking TPMS
Ethernet Attacks
Attacking Keyfobs and Immobilizers
Attacking ECUs and other Embedded Systems
What does your hacker garage need?
Creative Commons

Go to http://opengarages.org/handbook/

Search Amazon for “Car Hackers 2014” ISBN: 978-0-9904901-0-4

Watch out for this guy!  He can control your windshield wipers!  And other things....

https://gma.yahoo.com/video/hackers-may-able-control-cars-140640951.html

Good news training is coming to a Las Vegas near you!

TITLE: Vehicle CAN Bus Communications and Diagnsotics Reverse Engineering

WHEN: August 2-3 or August 4-5, 2014 (Two Sessions of the same course each two days long)

WHERE: Mandalay Bay, Las Vegas, NV

WHY: BlackHat 2014

WHO: You, Me and 14 other CanBusHackers

HOW: Sign Up Now while there is still the introductory price at <http://www.blackhat.com/us-14/training/vehicle-can-bus-communications-and-diagnostics-reverse-engineering.html>

PRIZES: That's right, Prizes.  I'll do anything to get you in the door.

How to play with Device Control.

Once you found out the Diagnostic ID for any particular controller, you can now start sending new an exciting request to it to see what it can do. Device Control (or I/O Control) is usually to most dynamic. The premise of this service is just as it sounds, to control the hardware. This service is typically used for mechanics to test the controllers output features such as actuating door locks, turning on/off lights, etc. This is a very interesting service in that it allows you to actuate features discretely in the vehicle. So instead of turning on all Left Turn Indicators (like when you do when you push down on the turn indicator switch) you can turn on only the Left Front Indicator Lamp. Now string that together with some music and other lights and you can have a cool Car Disco Party Mode.

So how does it work? When that depend on what kind of Diagnostics your car uses. There are three common types of Diagnostics: Keyword 2000 (ISO 14230), Universal Diagnostic Services (UDS ISO 14229) and GM LAN (GMW3110). I’ll talk about them individually below. For my examples I’ll use the Engine Control Modules standard Diagnostic ID, but you can sub out your modules ID. The effects will likely be different but the concepts remain the same. Also keep in mind that its often the case the you will have to initiate a Start Diagnostics Command (0x10). I will give these in the example but the Subfunction may be different (0x03 being the most common, but also try 0xC0 or 0x90 as well)

Keyword:

0x7E0 02 10 03 00 00 00 00 00 – Start Diagnostics (0x03 is the Mode this may be different on some OEMS)

0x7E8 02 50 03 00 00 00 00 00 – Positive Response to Start Diagnostics

0x7E0 04 30 01 07 01 00 00 00 – IO Control of IO 0x01; Short Term Adjustment (0x07); Turn ON (0x01)

0x7E8 02 70 01 00 00 00 00 00 – Positive Response. (Be careful because it gives you a positive response but does NOTHING; no control is executed. This is rare.)

0x7E0 03 30 01 00 00 00 00 00 – Return Control of IO 0x01 back to ECM.

0x7E8 02 70 01 00 00 00 00 00 – Positive Response.

UDS:

0x7E0 02 10 03 00 00 00 00 00 – Start Diagnostics (0x03 is the Mode this may be different on some OEMS)

0x7E8 02 50 03 00 00 00 00 00 – Positive Response to Start Diagnostics

0x7E0 06 2F 12 34 03 80 00 00 – IO Control of IO 0x1234; Short Term Adjustment (0x03); Turn ON (0x80, this could vary widely depending on the IO being controlled)

0x7E8 03 6F 12 34 00 00 00 00 – Positive Response.

0x7E0 04 2F 12 34 00 00 00 00 – Return Control to ECM.

0x7E8 03 6F 12 34 00 00 00 00 – Positive Response.

GM LAN:

(Start Diagnostics not needed)

0x7E0 07 AE 01 08 00 08 00 64 – IO Control of IO 0x01; Turn on 0x0800 (Bit Map of IOs, IO Bitmap duplicated in next two bytes to prevent accidental triggering) to 100% (0x64).

0x7E8 02 EE 01 00 00 00 00 00 – Positive Response

Common Negative Responses:

0x7E8 03 7F XX 80 00 00 00 00 – Incorrect Diagnostic Session. You need to change the Subfunction in Start Diagnostics.

0x7E8 03 7F XX 22 00 00 00 00 – Condition Not Correct. Likely the Key Needs to be in the RUN Possition.

0x7E8 03 7F XX 31 00 00 00 00 – Incorrect Format. Something’s wrong with your request message.

http://www.carhackingvillage.com

We are excited to officially announce the Car Hacking Village at Def Con 23.  I will be running this allong with many other people.  Please go to CarHackingVillage.com for more information.  I hope to see you there.

We're doing it again!!!11!!!!111!!

Come visit us at Black Hat for some 2 day Hands-On Training.

Course 1: July 30th-July 31st
Course 2: August 1st-August 2nd

Go Here to signup: https://www.blackhat.com/us-16/training/car-hacking-hands-on.html

Overview

Who Should Take this Course

Student Requirements

What Students Should Bring

What Students Will Be Provided With

Trainers

Robert Leale has been a regular trainer of automotive electronic security for over 4 years. He also consult with the automotive industry on securing electronic systems. As the founder of CanBusHack, he has been at the forefront of vehicle data reverse engineering for over six years.