Breaking News
Blog

Car Hacking: Here’s Code, Have at It

NO RATINGS
Page 1 / 2 Next >
View Comments: Threaded | Newest First | Oldest First
Bert22306
User Rank
CEO
Local access does make the difference
Bert22306   8/7/2013 7:23:08 PM
NO RATINGS
Sorry, Junko, we've been over this already. Local connection to the OBD-II port makes all the difference. Unless you encrypt any content that can go into the OBD-II port, making it essentially useless for its intended purpose, it would be pretty hard to prevent "hacking" when the "hacker" is deliberately allowed to get inside.

This OBD-II port is meant for garages to use, e.g. for troubleshooting and emissions testing. They also have access to brakes, steering, and throttle, and every other system in that car, without needing wires to cause damage.

If you do encrypt that OBD-II port, and then you give garages the private key necessary to decrypt, so they can do their work, then we're back where we are now.

Having remote wireless access to the critical functions, such as brakes, throttle, and steering, through an unencrypted interface, is what has to be shown. If that's available, then that security hole needs to be plugged. But quite honestly, this stream of articles about hacking seems to obfuscate the attack vectors, by including a lot of extraneous information.

Show me where a remote wireless device can impair the function of throttle, brakes, or steering. Leave the rest out. Then we can see if there's a problem to be fixed.

Susan Rambo
User Rank
Blogger
Re: Local access does make the difference
Susan Rambo   8/7/2013 8:06:50 PM
NO RATINGS
Only a matter of time, do you think? What happens when cars become just a "thing" -- an end node -- on the Internet of Things, as this newly formed US Consortium is working toward? I bet wireless remote hacking will be possible. Researchers from the CAESS Center for Embedded Automotive Systems  (the same UofW and UCSD group mentioned in article) say "we can call our car's cellular phone number to obtain full control over the car's telematics unit over an arbitrary distance."

Bert22306
User Rank
CEO
Re: Local access does make the difference
Bert22306   8/7/2013 8:47:36 PM
NO RATINGS
In short, the focus has to be on brakes, steering, and to a lesser extent, throttle. Listing a lot of other stuff just adds noise to the discussion.

The question of what will be possible or not in the future isn't the issue. The future will have to be taken care of, in due course. The question at hand now is how vulnerable vehicles are, present tense, to remote hacking into the critical system (steering, brakes, throttle, not the stereo). It goes without saying that as new capabilities are added to cars, for safety, efficiency of operation, or convenience, new attack vectors will emerge that will need to be addressed. We need not assume right now that these eventual vulnerabilities will go unaddressed.

That's the way engineering of new things has always evolved, after all. You design something new, then you do your best to debug the new gadget before putting it on the market. Unless we're to believe that engineers are unable to discover vulnerabilities, and why that would be the case I don't know, then this network connectivity is just another new aspect to debug thoroughly. And yes, things are missed from time to time, and they have to be fixed quickly when this happens.

As to telematics hacking, that's not a major safety concern, unless you show that OnStar (or other) can incapacitate the brakes, steering, or throttle. Can it? It is probably possible to shut the car down remotely (anti-theft), but fortunately cars can stop passively, without incurring a huge risk. On the other hand, whether the hacker can determine your location, or whether your engine warning light is lit, is more of a privacy issue at best. AND, any car owner can incapacitate that OnStar system. Find the access panel, probably in the trunk, and disconnect it.

Susan Rambo
User Rank
Blogger
Re: Local access does make the difference
Susan Rambo   8/7/2013 10:19:30 PM
NO RATINGS
You are probably right. We are all in more danger from badly designed code in ECUs than we are yet from car hacking.

DU00000001
User Rank
CEO
Re: Local access does make the difference
DU00000001   8/8/2013 12:20:46 PM
NO RATINGS
@ Susan

As I really have the insight into automotive developments: it's less about badly designed code - it's more about poorly designed systems. Too much time wasted on inefficient processes and "management hobbies" leaves too little time for good system design. Other constraints add to this.

There are already means available to protect - to some extend obviously not implemented in the 2 vehicles under test - against tampering of messages.

Some thoughts:

What will always be an issue is blocking the CAN (read: communications link) as described. (You might as well simply short CAN+ and CAN- with the same effect.) But a stationary vehicle is considered the safe state by the authorities so this is not really an issue. And every ECU should have fault strategies for communications failure. See about "poorly designed systems".

A "flipping" dashboard display may be annoying but isn't really a safety issue. (Safety assessments as per IEC 62508&ISO 26262 are quite another issue.)

For state-of-the-art security, each and every message considered safety-critical should be safeguarded. IMHO checking for too many messages per time interval (often forgotten) as well as message counters, additional CRCs, "secrets" (that is information not transmitted via the communications link) shared only between sender and receiver of critical data are some of the means.

 

Caleb Kraft
User Rank
Blogger
Re: Local access does make the difference
Caleb Kraft   8/8/2013 8:16:45 AM
NO RATINGS
I agree with this. I've seen these people "hacking" cars in the news a lot recently, but they are given time inside the car to attach a computer. To me, this isn't as big of news as it sounds. Sure it is interesting that they are able to mess with things, but it is like saying my computer is at risk of hacking as long as I give someone full and unhindered physical access to every component. 

ssavage920
User Rank
Rookie
Re: Local access does make the difference
ssavage920   8/8/2013 6:49:14 PM
NO RATINGS
When we first did our research in 2010, we got the same reaction "hey, you had physical access, that's not a real threat... if you have physical access you can do anything".  We then published a second paper in 2011 in which we demonstrated remote control (e.g., turning on/off the brakes on demand) at arbitrary distance with no prior physical access (i.e., unaltered vehicle).  In spite of this work (see autosec.org) there is still substantial confusion around a number of points:
1) that there is an "air gap" between critical and non-critical systems in vehicles.
This is generally not true and thus, if you can subvert a bridging ECU (which we demonstrated) you can in fact go from a radio compromise to taking over the brakes.


2) that wireless vulnerabilities don't exist.  We demonstrated multiple remote wireless compromises in a very popular vehicle platform.

While I agree that the risk of an individual being a victim of car hacking is very low, I think its a mistake to minimize the reality -- which is that these systems have not traditionally been well harrdened against security threats and they suffer from an expanding attack surface.  This is something that is getting attention precisely because it deserves it.

Bert22306
User Rank
CEO
Re: Local access does make the difference
Bert22306   8/8/2013 7:09:10 PM
NO RATINGS
"... you can in fact go from a radio compromise to taking over the brakes."



In the interest of clarity, even if you don't want to divulge exactly how this was done, can you explain "taking over the brakes"? Does this mean that with a wireless interface, from  a remote location, at attacker can send a message to the car that incapacitates the brakes? So that even with a heavy application from the driver, the brakes will not function?

Same would apply to steering. Is there a wireless remote path that locks the steering column, while the car is being driven?

These are the vulnerabilities that matter most, I think. If they exist, they need to be fixed. As to air gaps between ECUs and the rest, people will get lost in those arguments and lose sight of the bigger picture.

Also, for any such hacks to work, do you first assume that something has been reprogrammed through a physical port inside the car? Or do can the brakes and steering column be incapacitated with the car programmed from the factory (assuming I'm understanding the risk here)?

ssavage920
User Rank
Rookie
Re: Local access does make the difference
ssavage920   8/8/2013 7:23:27 PM
NO RATINGS
In the interest of clarity, even if you don't want to divulge exactly how this was done, an you explain "taking over the brakes"? Does this mean that with a wireless interface, from  a remote location, at attacker can send a message to the car that incapacitates the brakes? So that even with a heavy application from the driver, the brakes will not function?

Yes.  We demonsated precisely this.


Same would apply to steering. Is there a wireless remote path that locks the steering column, while the car is being driven?

The car we used did not have computer intermediated steering (and most designs on the market today use a slip-clutch that a typical person could likely overcome). However, we were able to induce a skid in a particular direction by selectively braking individual wheels (and, as above, do this wirelessly)


Also, for any such hacks to work, do you first assume that something has been reprogrammed through a physical port inside the car? Or do can the brakes and steering column be incapacitated with the car programmed from the factory (assuming I'm understanding the risk here)?

In our 2011 paper, we made no assumption that there was _any_ direct physical access to the vehicle (prior or otherwise).  The car was factory standard.  We demonstrated remote compromise via cellular and via bluetooth.  We demonstrated indirect physical takeover via the CD player and via the shop tools (which we demonstrated a wireless compromise for so that someone visiting the dealership could easily compromise all the tools and thus all car subsequently brought in for service).  We also demonstrated remote triggering via cellular, bluetooth, tire pressure sensors and RDS (FM subcarrier) as well as time, location, speed, etc.





We worked closely with OEMs and vendors to fix or mitigate each of the conrete vulnerabilites we found, however based on our experience, the nature of automotive ecosystem is such that it is highly likely that there are quite a few such vulnerabiilities still latent.

 

 

 

Bert22306
User Rank
CEO
Re: Local access does make the difference
Bert22306   8/8/2013 7:29:40 PM
NO RATINGS
"So that even with a heavy application from the driver, the brakes will not function?"

"Yes.  We demonsated precisely this."



So, is this through the ABS? And if so, is there any reason for the ABS control loop to be open to external inputs? Or if there is a reason that I'm not getting, is there any reason for the ABS to ever be permitted to release the brakes for more than a fraction of a second at a time?

ssavage920
User Rank
Rookie
Re: Local access does make the difference
ssavage920   8/8/2013 7:37:00 PM
NO RATINGS
Well, there are two ways you can influence the brake controller to effect braking.  First, most ECUs support a diagnostic interface for mechanics.  This allows them to put ECUs into unsafe states (e.g., bleed pressure from the system) while they are working on/daignosing problems with the car.  This diagnostic interface can be abused to directly override braking behavior.  The second avenue is simply by reflashing the brake ECU.   Both approaches work.  The second requires understanding the brake controller quite a bit better however.

Bert22306
User Rank
CEO
Re: Local access does make the difference
Bert22306   8/8/2013 7:48:37 PM
NO RATINGS
 "This diagnostic interface can be abused to directly override braking behavior."

Sorry, I see that as bad design in a particular model. Diagnosing brakes can also be done with someone applying the brakes, and then sensors connected to OBD-II indicating if the system is working as needed. I don't see any reason why that control loop needs to be opened to remote access. Or if this is allowed during troubleshooting, why it can't be physically switched to a "running mode" when the problem has been resolved.

"The second avenue is simply by reflashing the brake ECU."

And that can also be done remotely via wireless interface? Or does that require access to the OBD-II port?

These are the topics I'd concentrate on in the discussion, leaving aside remote control of the stereo volume control and the rest.

ssavage920
User Rank
Rookie
Re: Local access does make the difference
ssavage920   8/8/2013 8:05:34 PM
NO RATINGS
Sorry, I see that as bad design in a particular model.
 
Perhaps.  I can't comment on that specifically.  In the past things I've thought were bad design decisions (e.g., why can't we separate mission critical components from other stuff like door locks and infotainment) and spent time with the manufacturers I've come to realize that there are complex constraints and couplings that are non-intiutive but neccessary.  However, in some sense its irrrelevant.... the point I was making is that these problems exist in real cars... and popular cars.  I know that the problems we found were present in millions of cars on the road in the US.  Charlie and Chris found similar things on their vehicles.  Security highsight is 20-20, but the issues are real and present.
 
 
Or if this is allowed during troubleshooting, why it can't be physically switched to a "running mode" when the problem has been resolved.
Some of this does happen.  However, typically in some cases (e.g., the car we looked at) there was an authentication protocl that once broken could override this limitation.   Obviously, reflashby bypasses any such limitation.


And that can also be done remotely via wireless interface? Or does that require access to the OBD-II port?

Remotely.  Remember any module on the CAN bus can transmt (they all typically use the same tranceiver chips).  The radio can reflash any component on the same bus with it for instance.  Thus, once you compromise one component it can reflash the others.  In case cases you may need to be able tto bypass a bridge ECU to get across CAN busses, but we did not find this to be difficult.
 

 

Bert22306
User Rank
CEO
Re: Local access does make the difference
Bert22306   8/8/2013 8:35:47 PM
NO RATINGS
"Some of this does happen.  However, typically in some cases (e.g., the car we looked at) there was an authentication protocl that once broken could override this limitation.   Obviously, reflashby bypasses any such limitation."



Actually, I was thinking of something much more positive, like a shorting plug that needs to be removed for brake troubleshooting and diagnosis, and then replaced under normal conditions. Because again, it's not like the ABS control loop needs to be remotely accessible under normal driving conditions. Same with the steering column. Under normal driving conditions, you can still design a monitoring function that doesn't affect the control of the system.

The redundant hydraulic brake arrangement was specifically retained for safety, else brakes would be fully electrically controlled by now. Seems kind of surprising that a manufacturer would retain the hydraulic system, and then defeat its supposed safety role by allowing electric (never mind wireless remote) override?

Not sure this is 20/20 hindsight, somehow.

ssavage920
User Rank
Rookie
Re: Local access does make the difference
ssavage920   8/8/2013 8:43:42 PM
NO RATINGS
Actually, I was thinking of something much more positive, like a shorting plug that needs to be removed for brake troubleshooting and diagnosis, and then replaced under normal conditions.

There is huge resistance to such solutions because of the added labor/parts cost and need to qualify additional failure modes.

 

Because again, it's not like the ABS control loop needs to be remotely accessible under normal driving conditions. Same with the steering column. Under normal driving conditions, you can still design a monitoring function that doesn't affect the control of the system.


Its worth remember that its not the ABS 'control loop" here.  That is isolated.  But the brake controller is a CAN bus peer (and indeed, it will be producing sensor output for other units and there may be some interaction with other units that deal with stability control).  In principal one could implement a predicate that used some secure measurement (e.g., signed signal from a unit with a physical switch) to establish that the car was in "mechanic mode" but I'm not aware of _any_ manufacturer who does that.

 

The redundant hydraulic brake arrangement was specifically retained for safety, else brakes would be fully electrically controlled by now. Seems kind of surprising that a manufacturer would retain the hydraulic system, and then defeat its supposed safety role by allowing electric (never mind wireless remote) override?


By definition, the brake control msut be ablee to ignore user input.  Otherwise, ABS couldn't work (nor stability control, etc)

 

- Stefan

 

junko.yoshida
User Rank
Blogger
Re: Local access does make the difference
junko.yoshida   8/9/2013 11:09:49 AM
NO RATINGS
@ssavage920, thank you so much chiming in on this thread. This is awesome! Nothing like hearing directly from one of the authors of the paper:

http://www.autosec.org/pubs/cars-usenixsec2011.pdf

Bert22306
User Rank
CEO
Re: Local access does make the difference
Bert22306   8/8/2013 7:24:05 PM
NO RATINGS
Also, I would think, if there's any path that incapacitates the brakes, it would probably be through the ABS. Sort of, make the car think that the wheels are locked all the time. But for ABS to have an external connection that would permit such control seems totally unnecessary to me. Even if OBD-II is used to troubleshoot ABS, I can't see why the actual control loop needs to be anything but local and hardwired.

I guess all I'm saying is, I don't think these designs are impossible to get right.

Susan Rambo
User Rank
Blogger
Re: Local access does make the difference
Susan Rambo   8/8/2013 9:09:56 PM
NO RATINGS
Hi Bert. Thanks for your thoughtful contributions to the discussion.

Everyone, we're having a chat on car hacking tomorrow with EE Times editors. Please join us if you can. More details here: "EE Times Week in Review Online Chat: Is Car Hacking a Concern?"

And here: This week's chat will take place on Friday, August 9, 2013, commencing at 10:00 a.m. Pacific Time/1:00 p.m. Eastern Time. To kick things off, we'll start by considering two columns that have sparked a lot of interest over the past few days: How Hackers Can Take Control Over Your Car and Car Hacking: Here's Code, Have at It.

All you have to do is click here at the appropriate time to join the fun and make your opinions known. If you aren't already a member of EE Times, now would be a perfect time to register.



daleste
User Rank
CEO
Re: Local access does make the difference
daleste   8/8/2013 10:41:45 PM
NO RATINGS
I wish I could attend the discussion but since it is during work hours, I will not be able to.  Hope it is a good discussion.

mafugere
User Rank
Rookie
Re: Local access does make the difference
mafugere   8/8/2013 11:46:53 AM
NO RATINGS
I am in agreement.    All this article illustrates is that local, physical access to a standardized physical communications port that is, by design, intended for easy access to numerous diagnostic and test functions of a vehicle is possible by people with communications and some embedded programming skills.   And, what is the primary defense against malicious attack - control of physical access, of course!

Why else do companies put locks on the doors of their servers farms, or lock up their backups?   Attempting to make the leap from this example, to postulating that the same or worse could be done through a wireless communication interface designed for different purposes, like OnStar, for example, is at best HIGHLY speculative and unlikely.   If one allows a malicious person such unlimited physical access to diagnostic/test functions as this, they also could just as easily implement real physical sabotage with even less difficulty.   Until someone actually demonstrate the ability to take over control of a vehicle's primary control systems of engine control, brakes, lighting, or steering through a remote wireless interface such as bluetooth, cellular modem interfaces or satellite links, count me in with the gang who feel this is just more hype to induce fear in the uninformed.   The article basically shows us that with a CAN bus adapter and some code anyone can plug into an OBD-II port and snoop around.   Guess what, many have been doing this for years now!

junko.yoshida
User Rank
Blogger
Re: Local access does make the difference
junko.yoshida   8/8/2013 2:19:10 PM
NO RATINGS
@mafugere, You may change your mind if you read the original tech paper authored by a team of scholars at Univ. of Washington and UC-San Diego.

You can read it in full here: http://www.autosec.org/pubs/cars-usenixsec2011.pdf

In that paper, in conclusion, the authors wrote:

Our experimental analyses focus on a representative,moderately priced sedan. We iteratively refined an automotive threat model framework and implemented complete, end-to-end attacks along key points of this framework.

For example, we can compromise the car's radio and upload custom firmware via a doctored CD, we can compromise the technicians' PassThru devices and thereby compromise any car subsequently connected to the PassThru device, and we can call our car's cellular phone number to obtain full control over the car's telematics unit over an arbitrary distance.

Being able to compromise a car's ECU is, however, only half the story: The remaining concern is what an attacker is able to do with those capabilities. In fact, we show that a car's externally facing I/O interfaces can be used post-compromise to remotely trigger or control arbitrary vehicular functions at a distance and to exfiltrate data such as vehicle location and cabin audio.

Frank Eory
User Rank
CEO
Re: Local access does make the difference
Frank Eory   8/8/2013 2:20:06 PM
NO RATINGS
I agree with Bert, prolonged physical access to the OBD-II connector might qualify as "hacking," but is this really a big secrity concern? If your car is broken into or stolen and later recovered, it should be assumed that it's software-controlled systems may have been compromised and should be thoroughly re-validated. But remotely accessing those systems? How hard is it to simply prevent such access, by design?

Gary44026
User Rank
Rookie
Car Hacking
Gary44026   8/8/2013 8:26:18 AM
NO RATINGS
As *not* an automotive engineer, but as an embedded firmware controls type of guy, I would agree with Bert's last paragraph - a "Show me the money" type of thing.  If steering, brakes or throttle aren't affected, or can't be controlled, then I, too, see no real threat.  However, show me that happening and would definitely sit up and take notice!

Just my $0.02 worth.

junko.yoshida
User Rank
Blogger
It's about the future
junko.yoshida   8/8/2013 9:40:08 AM
NO RATINGS
If you regard the latest reseach by Charlie Miller, a security engineer at Twitter, and Chris Valasek, director of security intelligence at IOActive, as some kind of a tool to judge whether your current car is safe or not, of course, this whole thing reads like just a scare story "without any proof."

I find that unfortunate and disturbing, because that would be, in my opinkion, entirely missing the point. 

The research about the future. This is about how the next-generation connected cars -- which will have more exposure to the external world than ever -- should be protected from potentially malicious attacks.

As the two researchers noted in their paper:

The hope is that by releasing this information, everyone can have an open and informed discussion about this topic. With this information, individual researchers and consumers can propose ways to make ECUs safer in the presence of a hostile CAN network as ways to detect and stop CAN bus attacks. This will lead to safer and resilient vehicles in the future.

Duane Benson
User Rank
Blogger
Re: It's about the future
Duane Benson   8/8/2013 11:23:43 AM
I would say that part of the issue is in the theoretical possibility as much as with any demonstrated vulnerability. I had always thought that these semi-automated cars would fail safe or could easily be over-ridden by the driver. This video does demonstrate that failure isn't always in a safe mode and manual override isn't necessary possible.

Attack vectors and system exposure are both important parts of the "car hacking" equation. For today, the safety critical systems aren't wireless. My understanding is that critical systems are on a different bus than non-critical, like entertainment and navigation. Please correct me if I'm wrong on that. Regardless, that these particular systems can be manipulated without authorization means that they will be vulnerable at some point.

I also don't think we should dismiss the potential for harm in accessing non-critical systems. Messing with GPS or remote ignition could strand someone or get them lost. That may be more on the level of mischief than danger, but there are of people that like to engage in mischief. People have made fake 911 calls leading to a SWAT team showing up at houses to very surprised residents. Onstar like systems could be used to do the similar things - send rescue crews out to spoofed crash reports.

wmwmurray01
User Rank
Rookie
Re: --W
wmwmurray01   8/8/2013 11:45:10 AM
NO RATINGS
My Car was "borrowed" overnight while I was sleeping, and the ABS re-flashed with defective code -- resulting in a collision during an ICE storm.

krisi
User Rank
CEO
it will happen
krisi   8/8/2013 1:16:46 PM
NO RATINGS
We might complain, be concerned etc but this techology will happen...subway in Vancouver where I live operates without a driver, planes fly on auto pilot, Google has its driver-less cars...so these things can work...fully networked car will too eventually, in fact my bet is you will have to pay a premium to have the networking fundtion turned off (the same way as you have to pay your smart meter disconnected)

Tom Murphy
User Rank
Blogger
Re: it will happen
Tom Murphy   8/8/2013 1:34:06 PM
NO RATINGS
Krisi, I suppose you're right in saying driverless cars "will happen," but the question is "When?"  Earlier in this chain, I noted I first heard a confident prediction that they'll appear by 2000 (that was at the NY World's Fair in 1964).  I've heard about them ever since, and the technology -- as noted in several recent articles on EE Times -- suggest they are ever-closer.  But the enormity of the task of making them work on a practical basis seems like an awfully big mountain to climb, even in the US. Most cities and towns here now struggle to fill potholes, online maps are notorious for delivering you to streets that don't exist, and navigation systems don't always know about changes in roadways or new construction.  In sum, I'm not holding my breath for this.  I heard about this a half-century ago, and I wouldn't be surprised if they're still a half-century away.

krisi
User Rank
CEO
Re: it will happen
krisi   8/8/2013 1:40:53 PM
NO RATINGS
I agree Tom, it will take long time...I predict some driveless highway system will appear in 20 years or less...and yes it might take 50 years for all cars to be driverless (it won't be completely driveless, you will might still sit behind the wheel but you will be on autopilot as planes are) Kris

mafugere
User Rank
Rookie
its all about access
mafugere   8/8/2013 4:10:52 PM
NO RATINGS
I think that we can all mostly agree that technological advances can be deployed in rather slipshod fashion, particularly when they are associated with something that is viewed as "trendy" and tied to consumer convenience or luxury.    In so far as the article(s) underscore the need for the control and safety features of vehicles (ANY vehicle) need to have reasonable levels of access restrictions (physical and/or protocol related) I think we also agree. I would like to see the consumer vehicular industry review  and adopt an appropriate level of security standards for all vehicular and safety systems much as the mass transit industry has done.   As long as developers of cars and other vehicles which are becoming increasingly "smartened" through the application of advancing electronics technology keep the basic precepts of controls and safety systems in mind, I think all will continue to be well.   Ancillary or auxiliary functions that MUST always be kept separate in a properly designed systen were described to be compromised shouldn't be allowed to be so easily overcome, but, I would posit that such things represent more of a nuisance, at worst.    These non-critical functions such as entertainment system or cellular/satellite modems for navigation assistance are not going to pose the kinds of safety related threats that tend to come to mind when one is describing "hacking" a vehicle.   In such examples, we may as well be simply describing "hacking" a ipod, cellular phone, or off the shelf GPS.   These things have all been - and will likely continue to be- "hacked".   But, I would assume that this could be happen to such a device, whether it is being carried in my jacket pocket or carried in a plastic dashboard inside my car.    While I would be irritated if someone changed my XM radio preferences to Kenny Chesney, that is hardly in the same scope of threat as reprogramming the ABS or engine management systems.


Yes, the day may come when self driving cars with networked communications are here, flying above the ground.  We do NOT want to be in a position of having to constantly upgrade our  Mercedes Edition Norton AntiVirus 720 to keep from having our ABS  reprogrammed to stop in the middle of the autobahn.   But I think that is a long ways off, and we have plenty of time to plan ahead.

In the meantime, a much more likely vector for damaging vehicular hacking would be through those "safe driver" monitoring modules which various insurance companies are pressing upon their customers and in some fleet vehicles.    THAT is certainly a point/opportunity for real malicious harm to be introduced and I have no idea how carefully THOSE things are screened and verified/certified.   Maybe that would be a good follow up article..

Susan Rambo
User Rank
Blogger
Re: its all about access
Susan Rambo   8/8/2013 9:07:07 PM
NO RATINGS
Thanks for your thoughtful response. We're having a chat on car hacking tomorrow with EE Times editors. Please join us if you can. More details here: "EE Times Week in Review Online Chat: Is Car Hacking a Concern?"

Charles.Desassure
User Rank
Manager
Wave of the Future...
Charles.Desassure   8/8/2013 7:04:03 PM
NO RATINGS
Well, if you work long enough, know about information security techniques, have the right information security tools, and have been provided inside information.  A good hacker can hack into anything really.   Computerized modules within cars in what make this possible.  This is the wave of the future.    Therefore, automotive companies now need to be more concern about information security too.

wmwmurray01
User Rank
Rookie
Just to show it can be done
wmwmurray01   8/9/2013 7:27:02 AM
NO RATINGS
- To duplicate how my vehicle was hacked in the accident, I have in about 18hrs taken a Avnet Development Board, and Code I found on the Internet -- I now have a battery powered JTAG programmer that will program the MCU found in my ABS.   For the Physical Access, I Just get the VIN off of the windshield when it is in a parking lot(public access), and go to the dealer with an ID made on an ID printer bought at a surplus electronics store in DFW.  Then I take the key obtained, open the door, pop the hood, open the cover for the ABS computer, and Voila -- I can

1) Back up the working ABS code onto a SPI flash board

2) Copy this to a file on a PC

3)Look at it with a dis-assembler

4) Edit it

5) Load it onto a new flash board

6) Re flash the ABS

7) Close up shop

Think your car is physically safe in a garage?   Hardly -- One can easily short the power out on most Protection None home alarms with a pocket knife and gain access to ones house.

Keys a problem?  Not with a locksmiths tools in hand

 

Hope you all had a good nights sleep!

 

 

 

 

 

fmotta
User Rank
Freelancer
With the advent of convenience devices remote access to ODB-II is easy
fmotta   8/9/2013 9:14:53 AM
NO RATINGS
There are a number of ODB-II devies that allow you to proxy the port to bluetooth and wifi so that one need not even have physical access to use the port.  The challenge is to ensure that the access is managed, safe, limited, or otherwise controlled.  Safety items of brakes and steering are of first priority.  But, at some time privacy-related issues are important.

Loser99
User Rank
Freelancer
This is idiotic Hype
Loser99   8/9/2013 6:24:16 PM
NO RATINGS
Heres the essence of what they are doing:

Find the owner of the car let him get into it and start it and drive with you in the car.  Then "Hack" it by dropping a brick on the accelerator pedal.   Car is hacked.

Wow!  earth shaking that I can hack something by physically modifiying it.

 

DrQuine
User Rank
CEO
Attached device need not be obvious ... and an opportunity to learn
DrQuine   8/10/2013 10:42:25 PM
NO RATINGS
Much is being made of the fact that an attached device was used in the cited technical paper.  Actually the device could easily have been hidden within the vehicle and be missed by the regular driver. Nobody (yet) checks for unexpected connections to the diagnostic computer port and the wires leading up to it. It is good this dialogue is beginning as automotive networks become ubiquitous. I hope that the insights gained will protect against the extremely unlikely hackers. More importantly, perhaps they will protect against the much more probable systemic failures that have not been anticipated but will inevitably unfold through time.

_hm
User Rank
CEO
Re: Attached device need not be obvious ... and an opportunity to learn
_hm   8/11/2013 9:03:14 AM
NO RATINGS
I was wondering how some guy broke my 2011 model car and pilfered devices. I wanted to google how they did it. But this explains it all. But it is surprising, some teenage kid can do this. He broke quite few cars.

junko.yoshida
User Rank
Blogger
Re: Attached device need not be obvious ... and an opportunity to learn
junko.yoshida   8/12/2013 11:05:05 AM
NO RATINGS
Much is being made of the fact that an attached device was used in the cited technical paper.  Actually the device could easily have been hidden within the vehicle and be missed by the regular driver.

DrQuine, thanks for making that point.

Moreoever, many automotive electronics designers are interested in finding out any weak links or security holes inside an automotive system -- once "the extremely unlikely hackers" come in.  

Bert22306
User Rank
CEO
Re: Attached device need not be obvious ... and an opportunity to learn
Bert22306   8/12/2013 4:28:40 PM
NO RATINGS
But once again, should I list the type of mischief that a mechanic could create, even in ancient cars that aren't full of ECUs? How many people check for these things?

Either intentionally, or just cluelessly. I already mentioned, for example, improperly bleeding the brake lines, after doing brake work. Does your average owner get under the car and re-bleed the brake lines, before driving the car? I doubt it. Or, pouring contaminated brake fluid into the reservoir (or pouring fluid into a reservoir that was left open and gathered dirt), after doing brake work. Does the average owner check for that? Countless examples like that.

So, what safeguards do we have against these threats? Any at all? Or does no one know that the above examples can both cause sudden and unexpected brake failure?

Bert22306
User Rank
CEO
Re: Attached device need not be obvious ... and an opportunity to learn
Bert22306   8/12/2013 7:13:22 PM
NO RATINGS
Just as an aside, my bet is that if the automakers are overly concerned about people hacking into their electronics, it's not mostly for the reasons assumed in these various car hacking threads. My bet is, the automakers are trying to defend aginst onwners of these vehicles "adjusting" their cars, e.g. to extract better performance. The few scary examples, like remotely incapacitating brakes, are most likely the exception to this, not the rule.

An obvious example is the speed limiter. Cars are often speed-limited on purpose, so the manufacturer can legally install lower grade tires as standard equipment. If the car goes too fast, a tire fails, and the owner sues, the manufacturer doesn't want to be dragged into court by the hacker-owner who was the actual culprit.

Ditto for any modifications that might cause premature failure or wear of any other component. That's my bet.

Sheetal.Pandey
User Rank
Manager
Re: Attached device need not be obvious ... and an opportunity to learn
Sheetal.Pandey   8/13/2013 2:05:58 AM
NO RATINGS
I will wonder what a hacker would get after breaking into ECUs of automobiles. In my opinion looking at the primary purpose of a car that's transport, the manufacturer would never let electronics take the upper hand in security and safety of the vehicle. People if using smartphone inside car may not always keep its network freely accessible.

But yes its great that the hackers researched the option. Precautions are always better than cure.

 

Wobbly
User Rank
CEO
Re: Attached device need not be obvious ... and an opportunity to learn
Wobbly   8/14/2013 6:33:26 PM
NO RATINGS
Car tuners regularly modify the tuning maps in modern ECUs.

Ramu_Embedded
User Rank
Rookie
Security Fails in Vehicel System
Ramu_Embedded   8/12/2013 1:49:48 AM
NO RATINGS
Currently all securuty sytem with CAN Based, i.e Only  Data Once you hack the encryption  information then it is easy to hack the device.

in compuers the security is very high because no memory and processoring time, in case vehicel might run not more than 500Mhz. so incorporing huge algorthems to unsecur is verydifficult. even incorporate anybody can see on CAN. to avoid this hackins, 1st need to improve the Security system. like dynamic security system. data trasferon can also encryption data shoud be use.something like this.... i am not expert in security system.

 

 

 

 

Loser99
User Rank
Freelancer
I think most people would rather 'hack' an ATM instead
Loser99   8/12/2013 4:19:10 PM
NO RATINGS
Who cares about hacking a car? Hacking an ATM is where the money is.

So whats the purpose? To somehow make the car crash or make it easy to steal, or to change the inflation readout of the tires ?  Maybe to change the station on the radio?  The next article should be people concerned with hacking their thermostats or their clock radio's at home.  Millions of people could be late to work if hackers were succesful at changing others home alarm clocks.

Flash Poll
Radio
LATEST ARCHIVED BROADCAST
EE Times editor Junko Yoshida grills two executives --Rick Walker, senior product marketing manager for IoT and home automation for CSR, and Jim Reich, CTO and co-founder at Palatehome.
Like Us on Facebook

Datasheets.com Parts Search

185 million searchable parts
(please enter a part number or hit search to begin)
EE Times on Twitter
EE Times Twitter Feed
Top Comments of the Week