Hacker News Reader

Comment by viggity | Hacker News Reader

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.

View on HN

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".

>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).

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.

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.

Reply on news.ycombinator.com