Hacker News Reader

Comment by kileywm | Hacker News Reader

The core automaker message I got out of this is:

Automakers want to lock out consumers and unapproved mechanics from tinkering with vehicle software on the grounds that (1) they could purposefully or accidentally make the vehicle non-compliant with safety/emission standards, and (2) they could use the vehicle's computers to infringe copyright (presumably ripping streaming audio?), and (3) closed source = more difficult for malicious hacking of vehicles.

There are already laws in place to deter all of the outcomes of these actions. To deter the action that might lead to unlawful action... sigh.

View on HN

I bet it's primarily the fear of being sued.

If your cousin's friend changes the code for the ABS to "work better on gravel roads" and then you wreck, who's going to get sued? Not your cousin's friend - he's living in a van down by the river. The automaker is, because they're the ones with the money.

This was my immediate reaction as well. I'm quite sure that their primary motivation (service fees aside) is avoiding the litigation minefield created by permitting people to hack their cars and potentially make them unsafe.

Which you can do already without electronics.

The whole justice system is broken if we have to take the stupidity of ridiculous cases in account to tame down technological progress.

> Which you can do already without electronics.

As is stated elsewhere, it's easier to determine that a physical part failed, and that it was not automaker-issued than to do the same with (e.g.) modified firmware. It's not like people are above attempting to hide the fact that they modified the firmware in order to win a lawsuit.

But aren't they innocent until proven otherwise?

Not in civil trials, no. Well, they aren't "innocent", they are either liable or not, depending on the preponderance of evidence.

I don't really understand that. How can you sue your car maker for some software fault, if you don't know it was one?

You can sue anyone for anything. A judge can throw it out before an actual trial if there isn't enough evidence to even go to trial though.

So in the end you would have to come up with clear evidence for the failure.

But how is this different than if I put in aftermarket braking pads and then I wreck? What if my cousin's friend installed them wrong?

Is the litigation risk any different with software rather than hardware?

it is much easier to look at an after market part and determine if it was cause of the failure because it is a physical object. Software and the state and sequence of events are much harder to look at and conclusively say "yes, this was the culprit".

It's hard for me to pick a side here. I want that freedom, but the auto makers have a compelling reason for wanting to stop it (getting sued, warranty issues, etc). I'm 60/40 on the automaker's side.

There's also a major safety argument that just isn't in play with things like cell phones or toasters. The stakes are lower.

If you really want to play with engine management, there's always megasquirt.info and wb02.com, which are more hackable anyway.

On my car, and many others, the stock Bosch Motronic ECU is flashable through the OBDII port. You use community developed software and community information to build a ROM image, do the checksums, and flash it right on.

Thats not true for all Motronic ECUs. The OEM has to decide which kind of tuning protection they want to have activated.

Some OEMs opt for the low settings where tuning gets detected and logged while still allowing you to run new or modified code while others only allow the flashing of signed code.

Also, as far as i know from motronic mods, they mostly only change calibration data and not the code itself, but i may be wrong.

A variety of systems which can be flashed with modified or entirely third-party firmware but usually shouldn't be have tamper flags that make detecting the modification easy, even if the system is restored to its factory configuration afterward. This could be a good solution for car makers, especially if laws were updated to limit their liability in such cases.

To be specific: car makers should not be liable for unsafe modifications made by third parties, even if they intentionally made the car easy to modify and did foresee that some people would make unsafe modifications. To subject the car maker to liability in the case of a modified car, the plaintiff should have to show by a preponderance of evidence that the modification did not cause the crash.

> the plaintiff should have to show by a preponderance of evidence that the modification did not cause the crash.

I can see this going the opposite way too. E.g. the automaker says that they are not liable because the customer modified the audio system, even though it was the ABS that failed.

Sure, but they'd have a very uphill battle convincing a jury of that. This isn't "breaking seal voids warranty". This is "you, and you alone are responsible for the results of modifications you make".

But just like with some computers where you void your warranty by cracking it open and performing upgrades by yourself, all the car manufacturer has to do is sell their cars with the same requirement. You start messing around with the internals and a flag is set in the car that they just have to check for to determine if they're really at fault for what you're claiming or not.

>it is much easier to look at an after market part and determine if it was cause of the failure because it is a physical object. Software and the state and sequence of events are much harder to look at and conclusively say "yes, this was the culprit".

I don't buy your argument.

For example, to plug in a laptop and do a checksum of the binaries would take seconds. To disassemble an engine to find a spec'd up cam would take hours.

For example, to plug in a laptop and do a checksum of the binaries would take seconds.

This would only test that the software was a known set of instructions, it wouldn't help debug the flow of the code and the run-time state:

Software and the state and sequence of events are much harder to look at and conclusively say "yes, this was the culprit".

Disassembling an engine would seem to be on the same order of complexity as disassembling and reverse engineering firmware without source code (perhaps more so).

I agree, but how is it any different than when your cousin's friend does your brake job for you, and then the brakes fail?

To answer my own question: because there are fewer court cases about home mods of automotive software, then there are about home mods of automotive mechanical systems. I think it's the lack of precedent that scares corporate lawyers when it comes to this stuff.

If it was really a fear of being sued, wouldn't they push for laws that explicitly eliminate liability when such modifications are made, rather than making modifications illegal in the first place?

It would be the reasonable thing to do. The problem I see is when the "altered" car crashes into a stock one onthe road. The un-altered car's owner might sue on the grounds that there no proper controls on the modified car's systems to safeguard from such errors.

There is technology readily available in high end cars that will make them automatically brake if they detect they are going to hit something. If someone rear-ends me in a new car, it is unreasonable for me to sue the manufacturer because they didn't include this technology. Is this situation really any different?

I somehow can't imagine the automaker being in any danger of losing the suit, the firmware modification would probably be revealed in court.

I don't know if a reflash event would be recorded in the car's event data recorders. If not, the owner could flash the ECU back to the factory code, and the evidence goes away. For this to work, the cops arriving at the scene of the accident would have to immediately download the contents of the ECU and enter it into evidence.

How is this different from if you used a after market break pad, couldn't you do the same thing and just swap it out for a official one...

Plus vehicle damage. What happens when Johnny Hacker changes his fuel maps, causes massive detonation slagging the engine, flashes the fuel maps back to stock and comes in for service?

Maybe that should still be in Johnny's right to do, and it's up to the service center to detect what happened, but I can see why the automakers would really rather he couldn't do that.

I worked as a service writer for a couple years. I _never_ saw a warranty claim refused based on owner abuse. Not once. There were times it should have happened, but I could _not_ code a work order as "owner abuse". That was a call for the service manager to make and afaik, it never ever occurred. Refusing to cover a repair pisses off the customer and you never see him/her again. If you just fix whatever the idiot broke under warranty, you get paid and keep the customer.

wrong call in my books, but don't be surprised if it happens everyplace.

Why would it be a wrong call?

Honesty.

Some guy comes in with half a cornfield stuck to the undercarriage of their vehicle, who should pay for the suspension work? I deeply feel we should each be responsible for our own stupidity. If it is submitted as warranty, it becomes a cost to the manufacturer and I feel that is inherently dishonest. Additionally, increased costs _do_ get passed onto customers.

I get _why_ it happens, but it shouldn't.

More than likely you'll be absolutely shocked at the code that your car depends on to function (read the Toyota unintended acceleration court documents).

Opening that interface or code turns that black box of deniability into potential evidence of shitty practices leading to failure in what should be safe, correct and easily tested modules.

Think global variables, 4k line functions, goto/jumps, completely ignoring industry standard practices like MISRA, etc.

It's horrifying.

Think global variables, 4k line functions, goto/jumps, completely ignoring industry standard practices like MISRA, etc.

A note about embedded programming on a microcontroller: global variables and goto can be used effectively and safely. Their presence or absence does not alone indicate code quality. Even a 4kloc function might be reasonable if the compiler couldn't be relied upon to inline functions into a time critical global update loop.

Unlikely. More likely this is another attempt in the long history of car makers trying to gain full control over the entire supply chain. They want to have your car serviced only at approved auto shops that they control or own, using only original parts that they produce/sell.

It's totally about this.

> they could purposefully or accidentally make the vehicle non-compliant with safety/emission standards,

As much as I wanted to know about the mysterious "software upgrade" that the dealer claimed was available for my car (that was covered under warranty) - I understand why they keep consumers in the dark.

Do you really want some random guy messing with the base code of his car and accidentally get into a deadlock situation causing the brakes to not engage? Or for the vehicle's accelerator to keep increasing without being pressed?

Something else to keep in mind - people already have figured out how to remotely control a vehicle using bluetooth. [1]

I couldn't tell you what the solution is - whether it be build-your-own-car or forcing auto makers to release their source code - each will still have problems.

[1] - http://arstechnica.com/security/2015/02/senator-car-hacks-th...

This line really struck me:

"They say you shouldn’t be allowed to modify the code in your car because you might defraud a used car purchaser by changing the mileage."

All you would need to do is checksum to know if the consumer had manipulated the code. Let car owners see the code running on their cars but void liability if the software has been altered.

Odometer mileage is data, not code. If I can fake in a new mileage reading and correctly spoof the checksum (without triggering any anti-tamper safeguards), I've committed fraud with no way to trace it back to me.

Most of the cars I see anymore have some sort of web connectivity, what if you just send a packet every time you start it? If the mileage suddenly goes from 9000 to 3000 you know you have a problem.

There are countless ways you could bypass that and now we're talking about a type of DRM...and DRMs never work.

Plus, the idea of a car needing a net connection to operate is a non-starter (excuse the pun).

Not to operate (I'd never purpose such a travesty) but it could work sort of like carfax. Go to buy a used car, Oh it's never been synced with the cloud in its 3 years of existence? I find that rather suspect. Knock off a couple grand.

If you pay me $50/year I'll have my server spoof the packet report from your car to the manufacturer's server. It will transmit twice a day at 8:45am and 5:15pm to show the car being driven 5 miles to work and back. Hell, I'll even throw in a lunch outside the office once in a while.

Your turn.

Looking forward to your attempt to sidestep crypto. I'll wait while we exhaust the entropy of the universe in a futile attempt to "spoof" a vehicle checking in.

If I have the car in my driveway, I don't see it being a universe-ending project. We've extracted keys out of way smaller devices.

There's a point here though. Someone somewhere can extract the key out of a single car, but if you have a per-car key and you need to decap a chip and put it under an electron microscope to get the key then it quickly becomes infeasible.

There is no perfect system for anything but you can probably take it to the point where an attacker won't profit from his efforts, and I see that as a reasonable goal post for a threat model here.

I implement a RSA key for each car, signed before it leaves the factory. Each key is housed in memory that is heavily epoxied and very difficult to remove (in a place that you would have to remove the majority of the engine to reach). The cars ignition system requests validation from the on board key on every start (in fact it gets the actual <start car> command from the chip itself). If the key is not present, the car does not start and instead tells you to return it to the dealership.

Now you say, I can remove the key and then reverse engineer it. What if I put n keys? How many do I realistically have to add to make it so time and labor intensive for you to remove my little inexpensive keys that you just give up? Probably not that many. Oh and did I mention that all of them are in an array? Better be sure you didn't miss one or it will zero itself out giving you no hope of recovery. (The warranty specifically mentions this as something that will void it)

After all that, if you still want to attempt to modify it. Fine. I'll add 1% to the purchase price of the car and reimburse anyone who bought lemons from your little (illegal) scheme.

Around here, we have yearly inspections for cars. (UK would call them MOT tests). The inspector records the mileage every time and it is stored in the motor vehicle register. When buying a used car, you can check on its history (the owner may make the history private so that it's not given to buyers, but then you know that the history is not available and the car might be a lemon).

Requires no Web connectivity of my year 2000 Nissan Micra.

That is a fair point which I had not considered.

You could flash bad firmware that doesn't report mileage correctly, then flash it back before you sell the car.

That can be at least somewhat deterred by registering the car with the manufacturer to get an unlock code, similar to what HTC does nowadays if you want to root one of its phones. Thus, there's a record of you having installed custom firmware (with the relevant warranty-voiding and such). While it won't specifically detect whether or not mileage reporting has been tampered with, it does signal to a buyer that the software is or was non-stock, and therefore all bets are off, caveat emptor, etc.

Alternately, the odometer could (and I'd argue should) be implemented in hardware, possibly as an ASIC (or maybe FPGA) plus dedicated EEPROM to store the counter, wired directly to the relevant sensors. Perhaps some data interface with the main computer, but it should be read-only. That would solve this issue right quick.

Plus, changing the mileage is already quite common (at least in Europe).

This is actually easier than you think currently. Most muscle cars (like mustangs/camaros) allow you to change your rear end gearing. Different size rear end gear ratios are different factory options. There are programmers that allow you to tell your computer what gear ratio you running so your speedometer is correct. There are also changes that can be made for bigger/smaller diameter tires. You could change the computer's gear ratio setting and tire size setting. Your speedometer would be way off but you'd also be accumulating fewer miles. It's not directly modifying the mileage of the car, but over time the numbers of miles on the car would be far lower than what they really were. Then once you sell or trade-in the car, just set the settings back to the original ones.

No worse than the situation was for almost a century of mechanical odometers...

We need to separate the technical vs. legal issues here.

"Cars should have no anti-tamper mechanisms" != "Owners should be legally able to modify their car."

Even changing the mileage is not a crime, the crime occurs if you sell it and commit fraud by lying to the buyer.

While I agree wholeheartedly with your point, I think some insurance companies, in some countries, may also require an honest readout of the mileage.

Once again, not illegal to make the change, but probably fraud if you were to lie to your insurer about it.

"There are already laws in place to deter all of the outcomes of these actions."

When have laws ever stopped bad actors?

There are laws against breaking and entering, burglary and so on. Does that mean you don't lock your house or install an alarm system?

It does mean you don't use technical or legal measures to prevent people from having locksmiths fix or replace their door locks. You also don't outlaw locksmith tools, hammers and saws etc. (DMCA)

"to prevent people from having locksmiths fix or replace their door locks"

In some places (quick check here, California as one example) locksmiths are required to be licensed:

http://www.bsis.ca.gov/forms_pubs/locksmith_fact.shtml

Also noting that there is a physical limitation to the harm that can be done if locksmith tools are sold. Both geographic and how the tool (which in not digital and has friction in distribution) is able to spread.

Someone using locksmith tools will most certainly operate in one area. They can't work from the comfort of their bedroom and in most cases can't cover their tracks as easily as digital crime can be covered (and done from anywhere in the world).

I guess we're just lucky that anyone who can get licensed (mechanics are also licensed, though not criminal-background-checked I guess) can work on any lock in the regulatory region, because door locks don't have sophisticated software yet.

"Sorry, that's a Yale and I only have my Schlage tools with me"

That actually sounds like something an accomplished lock picker would say!

Laws stop bad actors all the time. Certainly not all burglaries are stopped, but I imagine there would be more of them if there were no consequences.

We should punish the actual bad behavior, not things that enable bad behavior. Otherwise, we'd outlaw kitchen knives and driving cars because, hey, you never know what someone could use them for.

I lock my house. I don't lock yours.

When have laws ever stopped bad actors?

In San Francisco I saw someone start to cross an empty street at an intersection, who then saw a police car cross the street two blocks away. The pedestrian stepped back onto the pavement and waited for the lights to change.

This was one of the most trivial crimes possible - jaywalking on an empty street - and it was stopped by a law.

Reply on news.ycombinator.com