46 comments

[ 3.6 ms ] story [ 111 ms ] thread
Interesting, I guess that's one aspect of software systems that doesn't come to my mind right away. With the increase in the amount of microprocessors in each car and as the code behind all that processing becomes more intelligent, I wonder if these complexities will make cases like this more prevalent.
Of course it will. The worst bit is that it won't be just your audio system not working either, but some critical part.

Cruise control malfunctions can be relatively benign or they can be the equivalent of someone stomping on the accelerator.

Car mechanics: the next generation of programmers?
No more so than an "IT Support Technician" who comes to reflash your BIOS and maybe install a few Windows patches.

The real hackers are screwing around with (hopefully their own) ECUs: http://ecuhacking.activeboard.com/

I'm not sure it's so much the quantity of controllers/code, but the quantity and quality of the interfaces between them.

If I were writing something like this, there'd be a very clear demarcation of "safety critical throttle/brakes/steering stuff" | "blinky lights and radio"

I suspect that it starts out that way when the engineers are arguing about the liability issues of going full-throttle at random, but then it becomes standard, everyone gets a bit blasé, and before you know it the assistant vice-chairhorse of marketing is talking about how cool it'd be if your radio gets louder as you speed up.

Even then, I'd be arguing in favour of something like a data diode[1]. I can't think of any non-critical system that should have input to the cruise control[2]

[1] https://secure.wikimedia.org/wikipedia/en/wiki/Unidirectiona...

[2] Of course, if it did, I'd claim it was by definition now a critical system. :)

> If I were writing something like this, there'd be a very clear demarcation of "safety critical throttle/brakes/steering stuff" | "blinky lights and radio"

As an ex-blinky-lights-and-radio tech, I can assure you that they are clearly separated.

Admittedly, my experience is limited to BMWs, but there's enough shared knowledge across the industry about the Right Way to do this stuff that I'd be surprised if Jaguar had made that mistake.

I have heard that there are separate buses for these things, but how does information propagate between them? For example, if my ABS fails, how does it pop up into the service menu on iDrive?
The instrument pack in the dashboard is connected to both buses. It needs real-time data from the drive systems to display speed and so on, so it's used as a hub.
In next five years could we see cars updating their system software over WiFI?
(comment deleted)
ford syncs it's gadgets on assembly lines http://news.cnet.com/8301-1035_3-20014787-94.html and no doubt that somewhere in the future that will be the way to upgrade ECU firmware. taking the design-production cycle into account, such systems should already be in advanced stages of progress to go into production in 5 years, so I doubt that.
BMW already does this (others too I guess, I don't know), although not over WiFi, but over a GPRS connection. You pay a yearly fee for data costs, it also transmits data on car health back to your dealer so that they know when to call you to make an appointment for maintenance.
I recently had a problem with the turbocharger unit in my car. The local techs couldn't figure it out so they just patched in a remote engineer in Germany. I was impressed.
My car wouldn't drive without software telling it what to do. I find it very disturbing that I can't it. I think life-critical software should be open source by law ..
Though nothing would delight me more than to be able to hack my cars open-source firmware, I can't see that happening by a long shot.

Security-by-obscurity is still a - supposedly - valid claim nowadays.

There's nothing that would delight me less than driving on the road with someone who has hacked their cars firmware.

In any case this seems more like competitive advantage through obscurity than security through obscurity, for the same reason that manufacturers don't include blueprints and engine schematics.

"There's nothing that would delight me less than driving on the road with someone who has hacked their cars firmware."

Engine tuners already do this.

Yes. And also developers/testers of other electronic control units in the vehicle. The early phase development is always in simulators and on test tracks, but typically car manufacturers have deals with the governments which allow them to drive on regular roads with systems under development.

Of course, should something happen, there's a number to call to get towed away quickly.

Only a very small part of the firmware, or more specifically, not really the firmware but just some chips that control the ignition timing and gas mixture. None of which puts other drivers at risk; at worst they blow up the engine of their own car (I don't know if that's possible with chip tuning, just saying). Many 'types' of car tuning that cause danger are already prohibited on most places.

But if somebody could rewrite the firmware so that the car stereo controls all of a sudden are the only way to actuate the brakes, that could create very dangerous situations. Which I why I hope that there will remain strong regulations on what firmware people can load onto their cars, at least in as far as they use that car on public roads.

Fairly recently, a box came out for the car I drive that lets you use the steering wheel volume controls to upshift and downshift. The same box has a trick that, under very controlled circumstances, allows you to lock only the front brakes (the car is RWD) until your speed is > 5mph.

You have to be in fake-manual mode, set to 1st gear, with the brakes depressed, and the box enabled. Then you pull back on the cruise control stalk to engage the brakes. There's really no way to accidentally engage the mode, but yeah, that sounds exactly like the sort of thing you're worried about. Using the cruise control stalk to trick the car into thinking it hit a patch of ice, so it selectively engages the brakes.

I should note that a) I don't do burnouts and would never use this option, and b) I believe you can enable/disable it via USB and the programming utility.

Happy driving ;)

>> rewrite the firmware so that the car stereo controls all of a sudden are the only way to actuate the brakes

Aside from some minor pulsing of the ABS module, it's a purely mechanical/hydraulic system. You push the pedal in, the master cylinder creates pressure in the line, and the brake caliper pistons get pushed out onto your brake rotors.

On the other hand, as seen in the Pruis nonsense last year, an increasing number of cars do use a electronic throttle which can lead to some interesting failure conditions.

The 'firmware' your discussing in your hypothetical situation is hacking the CANbus system - not the ECU firmware. One could, in todays systems, remap any CANbus device (even as odd as a headlight switch) to manipulate another CANbus device (such as the electronic throttle). Doing such nepharious things are possible today, but would take days worth of hacking and proprietary diagnostic hardware.

ECU controls, on the other hand, have been reverse engineered in nearly all cars being actively tracked/raced today. Bosch (BMW/Porsche), GM PCMs, Honda/Acura, Mistubishi, etc can be modified to control timing/fuel...add additional I/O and features (such as traction control, launch control, antilag, etc ...even when not equipped by the OEM).

Of my vehicles still running an OEM ECU, all have been running 'hacked' firmware without incident for nearly a decade. Even my ABS controller has been upgraded for better threshold braking performance.

If you're intersted in such things, please check out EFIuniversity [0], Ostrich, and persuse Motec's manuals for an idea of what's possible.

[0] www.efi101.com

[1] http://www.moates.net/documentation.php?documentation_id=24

[2] www.motec.com%2Ffiledownload.php%2FM4_M48_M8_Manual_A5.pdf

Even with open source, I'd be doubtful (and concerned) were that an option. There's no reason you can't have open source code (available for public scrutiny/liability purposes), but require that on-road, cars require a particular signed variant. Sort of the anti-GPL3.

Some sort of public bugtracker/remote update mechanism (again, given suitably authenticated binaries) would also be nice.

Actually, it occurs to me from watching far too much Top-Gear, that a fair number of high-end cars have a "Sport" button that does all sorts of things to your ECU, brakes/suspension/steering controls, and (afaik) is strictly speaking only legal for off-public-road/private racetrack usage. Having something similar (and with a log of entry/exit times into each mode for use in crash investigation)[1] might make it possible to experiment.

Still strikes me as pretty scary though.

[1] And a flashing bright yellow tail-light. To make sure everyone else knows it as well :)

The Nissan GT-R (in Japan at least) knows from the GPS where you are and only lets you engage sports mode at registered race tracks.
> (afaik) is strictly speaking only legal for off-public-road/private racetrack usage

No, it isn't…

The brakes are a bit spongy ... `nice -10 brakesd`
I wouldn't want any 18-year old ricer who thinks that that one update he downloaded from the internet will give him an extra 5 hp but in reality makes the brakes lock up under certain circumstances to be able to upload his own firmware with nothing more than a usb cable.

Having 'read-only' access to source code - maybe, although I'm not sure it would actually make a difference. But anyone being able to upload anything to something that controls 1500 kg of steel at lethal speeds in the vicinity of others, and that the vast majority of people are simply incapable of of understanding, no thanks. This is one situation where I'd rather give up my 'freedom' (for certain contrived definitions thereof) for a modicum of 'safety' (queue the 'deserves neither' quotes).

Of course, but all of that is within regulated limits. Only tested and approved components can be imported, and if you do a grey import of an unlicensed part and the police catch you with it, they impound the car (some regions have different regimes/exact measures I guess, that's not my point). So modifications are already controlled, it's not that everybody can just machine their own parts and put it on the road, without having it tested/centrally regulated.

While if anybody could just modify the firmware in their car, there would be no way to check if that version is safe. The only option would be to allow only (a) certain, manufacturer-approved version(s), which is the exact point I was making. And by making it difficult to upload custom firmware, we (as in, regular citizens who have no interest whatsoever in changing the software in our cars, but who are put in jeopardy by morons who think they are capable of making something better but really can't) can protect ourselves (to a certain degree) against the hackery of said morons.

Your position does not match reality, at least in the USA. There is an enormous amount of untested modification of engine ECU firmware going on in the real world over here, and I'm only peripherally involved in that "scene". (My interests are 60s Mustangs, but that means I see a little bit of the import enthusiast world as well.)
Yes, engine ECU modifications aren't controlled, but other parts, that have direct safety or environmental implications, are (for example exhaust pipes and the way that a chassis can be repaired). And modifications to the firmware of other controllers than the engine ECU can have safety implications. Also yes there is much less regulation in the US, I was mostly talking about the EU market (I think for example that the chassis reparation I mentioned isn't regulated in the US?)
Most vehicle repair codes (inspection requirements, etc) are state's rights, though with the advent of OBD-2, many emissions inspections programs have fallen into line. "Plug in the scanner; if it reports 'ready' and no MIL codes, it passes." I won't even bother to enumerate the number of ways that can be gamed. There is a federal emissions certification program, but again, that's only enforced via state inspections, which are a source of income for the independent garages (meaning that there's incentive to interpret the rules loosely to protect the revenue stream). If you need a car to pass, you can find a station that will pass you based on a recent color photograph and a small amount of cash.

In terms of chassis repair or mods, it's pretty much a free-for-all. Lifted trucks are regulated in some states, but most other modifications are owner and mechanic discretion. I'm completely changing the geometry of my '66 convertible's front suspension, converting to disk brakes all around and changing to a dual-circuit master cylinder. The number of other people who will be required to check my work prior to it being to legal to drive on the public highways: zero. (And IMO, that's as it should be, but I have a pretty strong libertarian streak.) It will have to pass the state safety inspection, but unless I have a light out, there's no realistic chance that the car will fail the safety inspection and they sure won't notice that the suspension and brakes have been completely re-engineered.

Just last month I bought a shift kit for my Dodge Magnum. You tap into the two communication buses and into the transmission control module. I bought it to firm up a sluggish automatic transmission, but the guy recently added a firmware update that lets you do a 'line lock' -- effectively, it tricks the car's computer into thinking it's lost traction, locking -only- the front brakes... until your speed is > 5mph. He added it for 'perfect burnouts' - something I have zero interest in doing, but it's pretty wild that he's got programmable firmware that has that much control over the safety-robot bits in my car.
They should put some sort of manual override switch.
It's frightening how cars' software is bloating up. I would've thought that a product that very easily kills people if things go wrong would have been under more scrutiny.
This is nothing. I work for an aircraft maintenance software company. Last week I fixed a bug where the system would silently delete a maintenance task if you clicked the X button on a confirmation dialog instead of "no". This had not been fixed for three years.
The difference is that a pilot knows far more about an aircraft than the average driver knows about their vehicle.
That's probably true, but the potential for a severe, un-recoverable issue is about as high. An aircraft is composed of hundreds of individually tracked components with associated information about how old the component is, how much it has flown, etc. Most of these parts have a mandatory expiration date at which point it is swapped out or sent for repair. A failure in the system which tracks all this data (which is what I work on) isn't quite as directly dangerous as, say, a bug in the on-board navigational software. But you can still end up flying around with an engine way past its intended expiration date far too easily.
Agreed. I know a fair bit about what keeps my single-engine piston aircraft in the sky, and many of the possible faults are routinely checked/confirmed OK during pre-flight inspection and/or run-up.

Still, I don't want to inadvertantly miss a 500-hr magneto IRAN, a wing spar or bolt NDT inspection interval, run my dry vacuum pump twice as long as I planned, or several other possible faults that aren't easily testable by other than maintenance technicians.

Wow, I thought programs for critical systems went through stringent testing. Was this bug not fixed earlier because they figured that the probability of it being responsible for a fatal error was low ?
The actual on-board software of an aircraft is definitely given a lot of attention as far as testing is concerned, but unfortunately more indirect systems, such as maintenance tracking software, is treated pretty much the same as any other piece of software; which puts it down to the company that made it to judge how much testing they perform.

In my company, the management puts a higher priority on putting all available hands on rolling out new functionality than fixing bugs, in order to try and win new contracts from potential customers. Or at least that's their excuse, in my opinion there is no such thing as a low priority bug, no matter what industry you're in.

Stupid question time. Why couldn't the driver put the car into neutral and coast to a safe halt to restart the system?

(Obviously though it's an issue that needs fixing!)

Strangely enough, it's impossible to go from either of the drive modes (D & S(Jaguar's "Sport" mode)) to neutral, and vice versa, without almost fully engaging the brakes. Just tapping the brakes is insufficient.

A friend and I attempted to do a "neutral bomb" in my XF but as it's impossible to transition without hitting the brakes, the attempt was a total failure.

Much of the shifting is done in software also; for example on my car I can't go from 'drive' to 'reverse' if I'm driving too fast, and I'm not sure if moving the shift stick into neutral has any mechanical effects or if that too is just a signal to the controller who then (electronically) drives the gear box. Which makes sense I guess from the point of preventing damage, but it does cause the software to become a single point of failure.
The brakes should be strong enough to stop the car even if you can't get the car out of gear. It takes longer to stop of course, and you might need to replace your brakes afterwards but it should stop.
Automotive producers in general have pretty high standard of the source code creation and maintenance. However - the set of guidelines that govern the code - MISRA (Motor Industry Software Reliability Association), while better than nothing, are pretty poor. Most of MISRA rules look like they were designed to be easily checked by automated tools - not to check for real defects. That situation may have been acceptable 15 years ago, but modern static and dynamic analysis tools are capable of much more than that.