Dupe: https://news.ycombinator.com/item?id=38558120
No, it isn't. Six points with no comments don't count as already discussed.
But why wasn't the new submission merged with the existing one? The urls are identical.
Dieselgate, but for trains – some heavyweight hardware hacking
221–230 of 309 posts
Re: Dieselgate, but for trains – some heavyweight hardware hacking
#222My impression is that the quality of train firmware is generally not very good, and I hope that this scandal will lead to greater scrutiny. 3 years ago, Deutsche Bahn publicly complained of "grotesque" software problems with newly delivered Bombardier trains. For example, when train drivers changed the direction of travel, the train software would crash. It then took 1 hour to boot the train up again [0]. Switzerland…
I think the compensation given to software developers by companies that view software as their product has drawn many of the skilled software developers away from jobs that would have once grabbed them because of the fun factor. Companies that make things that contain software are not in markets prepared to pay 2 and 3 times what they were for software. What you are left with is people who are willing to accept that…
Speaking from experience in vehicle firmware, the controller component belongs to a separate profession.
Re: Dieselgate, but for trains – some heavyweight hardware hacking
#223Earlier quoted context omitted.
It will be stuck in legal hell due to conflicts of interests. Trains already exist, and they need to work - but maintenance/repair companies cannot legally modify software of them due to copyrights. It's a catch22 situation. I honestly hope that company will be fined to the oblivion, and for criminal charges for that, but i doubt it will happen.
This is the kind of thing that will destroy a nation's manufacturing industry overnight. Who in their right mind would buy kind of equipment from a Polish company knowing that this kind of nonsense is both widespread and that their legal system has no solution? Hoestly, "Dieselgate" is not a fitting corollary for this travesty. This is considerably more sinister. Hopefully whatever happens from here will be an agent…
Newag is actually trying to expand into Italy and a few years back they sold (and already delivered) 11 of their Impuls 2 trains (newer variant of the ones described in the article) to Ferrovie del Sud Est. I'm really wondering whether they got the same extortion software as the ones in Poland or did they maybe spare a new client on a new market.
Re: Dieselgate, but for trains – some heavyweight hardware hacking
#224Earlier quoted context omitted.
Because this software is not made by software engineers, it's made by plc programmers, electric circuit designers and whoever did drift into the field. Except for beckhoff to tc3 they haven't made it to object orientation yet, so the field is stuck as a whole in the blue screen mines of yore. Managing complexity with thin standard docs, no version control while the machines grow ever more complex sensor and actuator…
I'm not sure if you've ever used modern software. It's sometimes amazing just how unreliable it is. Web browsers crash every few weeks, windows is known for regularly needing a reboot, evince regularly crashes on me, you can't call 911 with some of cell phones, ... . This reminds me of https://danluu.com/everything-is-broken/ . The clearest example of the difference of reliability is looking at public digital signage…
Yep, I don't eat fast food nearly as much as I used to but whenever I go in to a place with self-service ordering "kiosks" one or more of the kiosks is often out of service or frozen up, sometimes with a Windows error screen, or just stuck in a reboot loop, or it randomly resets in the middle of entering an order.
Re: Dieselgate, but for trains – some heavyweight hardware hacking
#225Earlier quoted context omitted.
It's not about "not wanting to help". It's about placing logic bombs of "if vehicle is at this gps coordinates of a competitor, engage self-destruct". Hackers actually did extract such coordinates from train firmware.
unless we have the entirety of the context for this code and the 20,000 pages of service manuals, i do not accept at face value that it's this simple
Considering that the situation this was named after had _very_ specific timing, state and sensor values coded in a defeat device, I'd say that having the mapped the gps coordinates of your competitors im the firmware of your product is pretty damning.
Nevermind the poorly executed "if day => 21, month => 11, year => 2021", which was conveniently setting a failure which wasn't actually present.
It'a probably not that simple, but it's not that complicated either. If you make something engineered to fail without there being a failure present, that's clear malice.
Imagine buying a car, you own it until the warranty runs out and the the manufacturer's workshop moves (say there was a fire/flood/sinkhole/industrial disaster, and they had to) and the car would refuse to move since it's not being serviced at the official location anymore.
Re: Dieselgate, but for trains – some heavyweight hardware hacking
#226Earlier quoted context omitted.
It's an example of fraudulent / malicious behavior found by decompiling industrial logic controllers, with incontrovertible evidence of illegality. Obviously no two situations are ever going to be the exact same, but I think it's clear why the analogy was made.
Yes, but “Dieselgate” is not appropriate here because that term has “cheating” loaded onto it, which represents a different struggle for companies than vendor lock-in. What this company is doing is related to DRM and arguably closer to what John Deere does with its products.
The example here includes faking a compressor failure, which is a bit beyond ‘vendor lock-in’.
Re: Dieselgate, but for trains – some heavyweight hardware hacking
#227Earlier quoted context omitted.
Sometimes low-tech is just better. Here in Finland we got Sr1 electric trains from the Soviet Union in the 70's, and after some renovations the model is likely to stay in use at least until 2030.
Simply of old designs is often a blessing as long as the drawing and documentation is readable and good. It can be hard to get replacement electronics for 1970s designs so sometimes you have to design new components but the functionality was relatively simple back then so it’s possible to build a 1:1 replacement
They've actually been modernized with newer power electronics and some of the soviet oversights have been addressed. They're still very reliable, and now somewhat more efficient.
Re: Dieselgate, but for trains – some heavyweight hardware hacking
#228Earlier quoted context omitted.
> Dear software engineers, please do not commit a crime Yes, developers shouldn't knowingly write code to commit crime, but developers don't tend to receive instructions that directly. Unsurprisingly, the company doesn't mention to every employee that they are knowingly breaking the law. Instead, developers receive a request to build a feature, and it typically won't be at all obvious that the intended use of that fe…
Sometimes it may not be obvious but the feature still might seem super suspicious. For example, suppose that the malware discussed in this article was broken down into two sub-features assigned to different people: geofencing detection, and bricking the train. The person writing the "bricking the train" part should have realized that there is practically no legitimate reason for that code to be written, and if they a…
> The person writing the "bricking the train" part should have realized that there is practically no legitimate reason for that code to be written
Hey Janusz, can you build a safety feature that prevents the train from operating under certain conditions. We don’t know all the conditions yet, so leave it flexible.
Re: Dieselgate, but for trains – some heavyweight hardware hacking
#229Earlier quoted context omitted.
I'm not sure if you've ever used modern software. It's sometimes amazing just how unreliable it is. Web browsers crash every few weeks, windows is known for regularly needing a reboot, evince regularly crashes on me, you can't call 911 with some of cell phones, ... . This reminds me of https://danluu.com/everything-is-broken/ . The clearest example of the difference of reliability is looking at public digital signage…
I think to make software more reliable, you'd have to go back to the "waterfall" method of development. If we went back to Dijkstra's notion of correctness by construction, then a specification for the program would be made, and then a programmer would prove their part of the code correct to the specification. They would write the precondition and postcondition of every effectful statement, document the invariant of…
Such regulations exist for avionics and aerospace. They were written in blood.
Re: Dieselgate, but for trains – some heavyweight hardware hacking
#230Earlier quoted context omitted.
F1 does this. All teams are required to run the same, approved, ECU[1]. They can change certain mapping tables and such but it's a sealed unit and they can't replace the firmware. [1]: https://wheelsports.co/formula-1s-standardised-ecu-explained...
This is quite interesting because you can imagine that lobbyists would argue that standardization would “stymie innovation.” If F1 does it why can’t you?
F1 is an ecosystem in which the competitors agree to a set of rules as a prerequisite of participating. Among the guiding principles of the rules are "limit spending on aspects that don't meaningfully affect the competition" and "when possible, make it easy to enforce the other rules". Using a single, common ECU (which is both complicated to manufacture and doesn't directly influence performance [0]) saves all the teams (bar McLaren) from having to go down a rabbit hole of doing semiconductor design and manufacturing and makes it easy for the governing body to enforce rules about how the ECU is configured.
[0] How the ECU is configured does, but the ECU itself doesn't