6 ms·
> Firmware images were gleaned from car-tuning forums and from an online portal maintained by Volkswagen for car repair shops. Documentation, in the form of so-
by jancsika 9y ago
> Firmware images were gleaned from car-tuning forums and from an online portal maintained by Volkswagen for car repair shops. Documentation, in the form of so-called “function sheets,” was harder to come by. The function sheets were necessary to give the binary context, but the sheets are copyrighted by Bosch and generally not shared with the public. The research team ended up turning to the auto-performance tuning community again. These hard-core hobbyists and professionals share leaked function sheets so they can make aftermarket modifications to their cars.
This is crazy. And, as we move toward self-driving cars, dangerous.
Can someone point me to a well-regarded source in the industry that makes a cogent and convincing argument for why all the software running in a car (save maybe for the entertainment panel) should not be required to be open source?
To be clear: I'm not asking for speculation, or even an explanation from an expert based on years of experience. I'm asking for a publicly accessible reference based on research data that explains the security benefits of not releasing the source code for life-critical software in the car.
Edit: clarification
- obstinate 9y agoI would be very surprised if such a thing exists. Are there any industries, safety critical or otherwise, where the default is open source? If not, why would anyone think to justify the decision to not open source code, and especially why would anyone think to make such a memo or piece of research public?
- ryukafalz 9y ago>Are there any industries, safety critical or otherwise, where the default is open source? Cryptography.[0] When trustworthiness is paramount, as in crypto (and IMO in safety-critical applications like this), being able to inspect the code helps a lot. [0] https://www.schneier.com/crypto-gram/archives/1999/0915.html#OpenSourceandSecurity https://www.schneier.com/crypto-gram/archives/1999/0915.html...
- Tempest1981 9y agoMore common is submitting their code to a regulatory agency, as in the medical and gaming (slot machine) industries. They can also confirm that the code submitted is what is actually running on the device.
- nickodell 9y agoI would say that this argues for the opposite - making firmware closed source and as hard to reverse engineer as possible. Let's say that the software is open source, and you can buy your own microcontroller and turn it into an ECU. There will be people who make their own modifications to it to improve performance. Some of those modifications make the car fail an emissions test, so they make it so that the car acts like it's at stock settings during those tests.
- semi-extrinsic 9y agoWhat you describe already happens in the extremely-closed-source world of today. For most cars you can buy an ECU remap that can be switched from tuned to standard by the flick of a switch. An ECU is not actually that complicated. It reads a few tens of inputs (temperatures, air mass flow, lambda sensors, crank position, etc.), and controls a few tens of actuators (throttle body, fuel injectors, spark plugs, maybe variable valve timing), with time resolution measured in tens of microseconds. An Arduino doesn't break a sweat - see the Speeduino project.
- deleted 9y ago[deleted]
- deleted 9y ago[deleted]
- unityByFreedom 9y agoCrap. There will be more programmers in the future who will write defeat code for fun while learning, or pursue it as a business. That's obviously not great for the environment. Does anyone else feel our current government is not prepared to handle the changes pervasive software will create in the future?
- semi-extrinsic 9y agoIf you think defeat code/devices are the worst of it, you've obviously not seen the people on YouTube "rolling coal"...
- 21 9y agoFWIW, airplane or medical software is also closed.
- ryukafalz 9y agoRight, and you can see how well that's worked out: https://www.engadget.com/2017/04/21/pacemaker-security-is-terrifying/ https://www.engadget.com/2017/04/21/pacemaker-security-is-te...