Its insane how brazen this is. Code that 'bricks' the train locomotive if its gps coordinates remain with bounds of a competing repair facility for more than ten days! This is way beyond putting information barriers to repair, like undocumented interfaces or even crypto-signed firmware. This is actively malicious destruction of property. I don't know anything about the legal system in Poland, but I can't imagine how…
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.
Dieselgate, but for trains – some heavyweight hardware hacking
171–180 of 309 posts
Re: Dieselgate, but for trains – some heavyweight hardware hacking
#172Re: Dieselgate, but for trains – some heavyweight hardware hacking
#173Its insane how brazen this is. Code that 'bricks' the train locomotive if its gps coordinates remain with bounds of a competing repair facility for more than ten days! This is way beyond putting information barriers to repair, like undocumented interfaces or even crypto-signed firmware. This is actively malicious destruction of property. I don't know anything about the legal system in Poland, but I can't imagine how…
If an individual did this, they'd go to prison.
Re: Dieselgate, but for trains – some heavyweight hardware hacking
#174> it has to be taken apart, the parts sent to the various manufacturers, checked, sent back, the train put back together again and tested
Instead of having one public company mastering the art in its entirety everything is split with contractors. A good example of a successful way to do that (but slowly dying thanks to capitalism) is SNCF operating everything in a massive warehouse https://www.youtube.com/watch?v=SeRH2M2Z-ms
Re: Dieselgate, but for trains – some heavyweight hardware hacking
#175Earlier 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…
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 every loop, and prove by induction that each loop does what it's supposed to do. Basically, annotate your program with Hiare triples. (There are books about how to do this). Then, extensive tests should be run for as much of rhe program as possible.
Nowadays, we have tools for this so that we don't actually have to write a proof by induction for every loop; instead, we have bounded model checkers. In theory, the manual proof writing could be isolated to the parts of the program whose properties a bounded model checker cannot verify.
However, it seems like this whole plan is infeasible unless regulations are written that enforce this onto the industry. It would make them a lot less productive, and therefore less profitable. The only benefit would be that software is more reliable. By necessity, it would have to become simpler, too. For instance, there's absolutely no way that web browsers like Chromium, with 38 million lines of code, will ever be verified, because they're too large and complex.
Re: Dieselgate, but for trains – some heavyweight hardware hacking
#176Re: Dieselgate, but for trains – some heavyweight hardware hacking
#177Earlier quoted context omitted.
Companies are made up of individuals. I'm all for holding everybody who contributed to this malware accountable.
I don't believe the Polish judicial systems has experience in dealing with corporate crime, especially of the tech-related kind. I'm a bit afraid of disappointment here.
I mean - how is "let's mess with something on purpose so that trains won't run" NOT sabotage, since such time as railways exist?
Re: Dieselgate, but for trains – some heavyweight hardware hacking
#178Its insane how brazen this is. Code that 'bricks' the train locomotive if its gps coordinates remain with bounds of a competing repair facility for more than ten days! This is way beyond putting information barriers to repair, like undocumented interfaces or even crypto-signed firmware. This is actively malicious destruction of property. I don't know anything about the legal system in Poland, but I can't imagine how…
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.
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 of change for the better.