Dieselgate, but for trains – some heavyweight hardware hacking
badcyber.com
badcyber.com
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?
If anything, us software developers should be held liable for more of the damages that we cause.
This is why it would only be a contract dispute; they will argue that the contract did not state up front that if they failed to pay the developer that the software wouldn’t work. The MMO certainly has pages and pages of legalese that everyone knows lets the MMO’s developer get away with anything they want. The independent contractor needs explicit language in their contract to specify exactly what will happen if they aren’t paid on time. That should include late fees, but probably also software that refuses to work until someone fills out a credit card payment form.
It doesn't matter whether the act was committed as part of a company's operations or as an individual's private endeavour.
To all software engineers: please refrain from engaging in criminal activities. If you are instructed to do something illegal, it is important to report it to the relevant authorities.
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 feature is to commit a crime. There might even be a legitimate use of the feature, and then someone finds it can be abused to commit a crime.
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.
Hey Czesław, I cannot leave it flexible, because it's a train that can run over 100km/h with 500 passengers inside, so I need to know the details to perform the required safety analysis. All in all, my name will be in the commit log if someone runs... git blame.
GIT_AUTHOR_NAME=Czeslaw GIT_AUTHOR_EMAIL=czeslaw@januszex.com git commit
(obviously, just kidding)
Back in the 90s, when market economy started here, many many businesses' names had the "-ex" suffix, as apparently it sounded western.
And Janusz is a popular first name, which became a meme for a specific type of a businessman, I suspect that because years ago when the meme started, many of those businessman actually had that name (i.e. it was very popular in that generation).
Now, when you open januszex.com, what's there is a meme of "Janusz Alfa" [1] (I think it should be self-explicable), and a related long-nosed monkey meme (I guess they could be thought of as "Janusz Beta" ot sth like that).
EDIT: [1] The real person from the photo is a Polish politician. I couldn't find if he somehow "triggered" the whole meme situation, so I guess it was just a coincidence--someone stumbled upon his photo, used it, and the rest is history.
Art. 254a. Disruption of a network; damage. Anyone who takes, destroys, damages or renders unfit for use an element of a water supply, sewage, heating, electricity, gas or telecommunications network, or a railway, tramway, trolley bus or metro line, thereby causing a disturbance in the operation of all or part of such network or line, is liable to imprisonment for six months to eight years.
I certainly think that this malware meets the criteria set forth in that law: "renders unfit for use an element of ... a railway ... , thereby causing a disturbance in the operation of all or part of such network or line".
Seems pretty cut & dry to me. I hope some people face real jail time for this. As another comment mentioned, it will probably be a "fall guy" (perhaps a middle manager) but that will still deter future managers from authorizing such fraud, even if the orders come from above. Future managers might reject such orders since it's not worth jail time.
Have you seen The Incredibles (pixar film). This scene is exactly what I'm talking about:
What we have in this case is a company doing something that is wrong, not an individual. To sentence somebody with the statute you and the parent are referring to you need to have a case against an individual, not a company. Secondly, except for this specific statute you have to take into consideration the general rules of the penal code (Zasady odpowiedzialności karnej) and in this case you have to assign blame, find out that the intent, the knowledge of what they were doing etc.
In general, in best case this will be a breach of contract, a civil case, there probably won't be jail time. Don't get your hopes up.
Don't get me wrong, what they did is nefarious, but at the same time I don't think there should be Jail time, just huge fines and some scrutiny (maybe NIK, ABW, CBA etc. - other polish three later agencies) on Newag, maybe barring them from some future deals.
Source: I might be a lawyer...
"To all software engineers; please refrain from engaging in criminal activities. If you are instructed to do something illegal, it is important to report it to the relevant authorities."
I honestly hope that company will be fined to the oblivion, and for criminal charges for that, but i doubt it will happen.
> A day of train downtime in the workshop costs over 1000 USD in contractual penalties, and there are several trains stuck, so the tension level in the SPS is rising.
Also LSR, because evidently they were interested in holding a tender before and so likely don't want to be forced by Newag into overpriced maintenance contracts?
This of assumes that the owner of the train company has the skills to do this. In reality they probably would need outside help and that company might fall foul of copyright issues. (when they are distributing the modified code back to the train company, for example)
But the real problem of course is that all of this code is very likely safety critical. Can they modify it? Probably. Is it a good idea? Not really.
Rather, the companies with botched trains should demand from Newag to remove their locks, for free, and on the side sue them.
This is the way.
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.
Which is why any government funding for new trains should come with the requirement for open source firmware.
Well better yet would be to abolish or reform copyright to be more aligned with the interests of society at large but international pressure makes that even less likely.
Seems more like malicious denial of service, with the goal of enriching the malicious actor.
A motivated legal team would likely be able to find Serious Charges that could apply. Especially if these specific trains / locomotives happen to be "Critical Infrastructure" (not guaranteed).
Go check out GCP web UI on Firefox and tell me it's not intentional.
This isn't correct by my understanding - there's actually two separate things here:
- The company made their trains stop functioning after spending 10 days at competing maintenance locations, based on GPS
- In one firmware, they hardcoded to pretend a compressor failure a few days after the next scheduled maintenance for the train
- The 10 days limit was their initial attempt, no GPS involved
- After it turned out the trains were immobilized in the "wrong" location, they added GPS geofencing
- The compressor failure was supposed to happen every day till the end of the year, starting on the scheduled maintenance date. (This might as well be bad coding.)
Again, I could get some details wrong, especially that the articles I read were kinda all over the place (subjectively, IMHO).
That the worst part of all that.
Standardizing the outputs of the sensors would let us swap in and out various components to ensure the system is not cheating the regulators.
But yes, it's basically it.
[1]: https://wheelsports.co/formula-1s-standardised-ecu-explained...
What F1 needs is disruption, more options, like too many options that all of them won't be test-able, less standardization. Even the limited sim time is a problem, because there are certainly optimizations left on the table that can't really be found otherwise. What you wind up with is a A-team and a B-team of mostly the same designs. That's booring, and moreso because if the cars really were 100% standardized, at very least it'd be competitive in terms of driver skill.
It's why these days, I don't watch much F1, I much prefer the more 'indie' racing leagues where, on any given raceday, anyone can win. The days of F1 being that way are long gone, and, it's not likely to change at-all.
At work we're a small team, providing a B2B application to perform a small, but very important task for our customers. We integrate with tons of other systems, at our largest customer we talk to 30 other systems. We're highly specialized and we rely on being good at exchanging data with other systems that are good at what they do.
This allows us to innovate and provide great value for our niche, while the other systems can focus on getting better at what they do, rather than implementing a half-assed solution because it's not their core focus.
[0] How the ECU is configured does, but the ECU itself doesn't
I have a buddy with a WRX that absolutely should not pass smog, has no cats, big turbos, tune, etc, but it has no codes, passes every time without issue because the sensor data is synthetic that governs those things.
There are visual inspections, but, they're not terribly thorough, and they don't disassemble anything.
That's for normal cars mind, for diesel semis/lori's they also have a measure of how much smoke comes out of the stacks at a given load, and how long it lingers in the air, so even if the ECU reads clean, if it's running dirty like that it'll still fail.
Curious to see the court’s decision.
The fact that lawmakers, courts and the public are lost in the tech is a problem, but surely this crime can be fitted into existing criminal code against sabotage… although the methods are “new” the crime itself is classic.
For example, both the NYC taxi medallion system and warlords controlling a city in a failed state would get input as "lawlessness" in your encoding.
But then if I ask what is the quality of life in each instance, I can't get that answer because there aren't bits in your encoding for that.
As a computer scientist, I find this embarrassing. Just compare these modern trains to the old trains built in East Germany [2] during the 80ies that were pulling old West German carriages [3] from the 50ies here until recently. Minimal or no usage of digital electronics. No "boot times". They just worked. And if they didn't, the train driver usually knew where to hit the engine with a hammer to fix it. You cannot expect a train driver to hack into the train firmware and fire up gdb to find out why it doesn't move.
[0] https://www.sueddeutsche.de/wirtschaft/deutsche-bahn-ic-1.47...
[1] https://bahnblogstelle.com/33872/twindexx-swiss-express-soft...
It's probably true of lots of aspects of product design - if it's not driven from the top, it's mediocre.
SW has an input problem and a testability problem. On one hand, the inputs to the SW are not limited (iMessage happily accepts any image file) and testing is limited to some known inputs. Software vulnerability assesment (worst case analysis) is usually performed outside of the development process at very high costs and limited outcome.
You can compare this situation with Boeing. And issues they had with software of 737max.
The quality of SW has nothing to do with the pay. Notice that FAANG SW developers do not deliver safety critical SW.
There are more things to SW development than writing code.
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 wise..
You can not treat modern machines like small embedded hobby devices - but the industry does.
Some outside-programmers make good money coming in and solving these yesterday's problems with proper software architecture and good c development practices. But the industries doesn't learn from this. Making software will forever not be a profession for them.
Not always a blessing and I've actually recently been thinking (e.g. in context of Lua) if object orientation is in most situations not better to avoid.
The clearest example of the difference of reliability is looking at public digital signage (on transit and elsewhere). If it's based on LED segments or something similarly basic (with old-school embedded software development) it will basically always work. New LCD Screens inside trains/busses and outside working with a modern software setup (using an OS, often with a pc architecture, quite often just displaying a website) are broken ~10%-20% of the time. Looking at (for example) busses, a large portion of the time the screen will either be blank, not display anything, old information or just wrong information. Going inside fast food restaurants with large LCDs for the menu, often something is broken, frozen or something else.
It is of course possible to make modern software more reliable. It's just much, much harder than making embedded software or PLC programming reliable. Software can be easily made more complex, but it's hard to make it non-complex or to wrap the complexity so it isn't an issue anymore. The ecosystem isn't set up for non-complexity.
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.
I'm not sure if you remember older software properly. The idea that an entire desktop computer, much less a web browser, could even run for weeks without a reboot would blow the mind of '90s me.
Netscape Navigator was the direct cause of at least 80% of the Mac OS 8/9 crashes I've experienced in my life. It was less common for the browser to entirely take down a Windows system in that era but I sure do remember seeing a lot of those application crash dialogs until the modern era of tabbed browsing made people care more about stability.
Prior to Windows 7 becoming mainstream I never had to check uptime when diagnosing weird behavior on end user computers because they just naturally got rebooted regularly. Now there are a lot of computers that only reboot when they receive updates that require one, and depending on the user might not get those updates very often. I see systems that haven't been rebooted in the better part of a year and some times longer every few weeks. Even more now with Windows 10+ "Fast Start" where "Shut Down" actually means hibernate so users who think they're shutting down every night actually haven't had a fresh boot in months.
The issue is as machines get way more complex this issue gets worse. Also there are generations of PLC devs that still want to stick with ladder logic. Huge fragmentation.
The fact is the unmodernized plc platforms deliver working machines and plants. The projects are built, commissioned, and unlike modern software they are finished and left to operate instead of constantly modified With no benefit to the end user
Don't get me wrong. <PLC programmers> tend to also have electrical skills and some are pretty good at their jobs, and you can learn a lot from them!
But ... they're not programmer programmers. It's a different skill-set with only so much overlap.
controlling physical processes like oil refineries, power generation, or sawmills is different from most computer programs as are the consequences of bugs or errors so it makes sense that it takes different people with different interests and skills.
PLCs replace relay circuits for Industrial Electrical technicians (hence: Ladder). And make no mistake: relay circuits are important, and is something they are very adept at!
However, this doesn't imply that they are automatically able to write or debug regular Python or C code or what have you.
-----
PS. If you let a PLC programmer at any language, they'll find a way to do ladder logic. Illustrative example (combining some features I've seen in textbooks and IRL, formatting included):
if Tank_Level_Reached == True and EF132121 == False and Ready_To_Start == True and Finished == False and Belt == Not_Ready and Stage == 5 and Position_Left_Arm == Up :
move_left = True
move_right = False
if Tank_Level_Reached == True and EF132121 == False and Ready_To_Start == True and Finished == False and Belt == Not_Ready and Stage == 5 and Position_Left_Arm == Down:
move_left = False
move_right = True
if Tank_Level_Reached == True and EF132121 == False and Ready_To_Start == False and Finished == False and Belt == Not_Ready and Stage == 5 and (Position_Left_Arm == Down or Position_Left_Arm == Up):
move_left = False
move_right = False
There are more "engineers" writing software for your car or a train than "engineers" at Microsoft, Google, Apple or Facebook.
I don't think that someone will be happy when driving with 100 km/h on a highway, the car will suddenly decide to restart itself. There are bugs everywhere where profits are put before engineering but calling those people names is not constructive. Especially when they use SW created by "engineers" which crash with no apparent reason when they are doing their work.
Of course I'm half joking, but I wouldn't be surprised if software problems contributed to the delays (which tend to chain, as trains need to wait for each other, etc).
It took more than 1h to start going back, and I wonder how much of it was making sure the track is clear, and how much was "rebooting the train" or whatever else was necessary.
Haha wait until you find out how TVs worked in the 70s and how fast it was to change the channel *sob*
My take is this: the peak is at the point when a given product category existed long enough to be thoroughly developed, but short enough that value engineering didn't kick in yet to ruin it.
(To be fair though, nowadays we have UHD/4K channels, which need way more bandwidth than the SD TV quality from 2000s. I wonder if this could be fixed with a more powerful CPU in those boxes? maybe it could, but might increase power usage?).
Audio effects and synthesizers all have software driven versions that sound effectively identical to analog and are typically cheaper. Yet, analog has been hanging on due to the simplicity and immediacy.
It is way harder for different computerized systems to work together due to the higher complexity and more obfuscation (a traditional logic circuitboard is often easily reverse engineered. Reverse engineering software is a very specialized task). This is also very noticeable in other sectors, where interoperability has become much worse due to moving to proprietary digital protocols.
This is in part due to the difficulty in getting software approved as compared to previous tech (due to software being so intransparent) but also because of truly lacking quality. One of the reasons Bombardier was so deep in trouble was bad software, even leading to a contract of over 40 ordered trains just being cancelled ([2]).
In my opinion building reliable (and understandable) software is way harder than building logic or even mechanical systems. I don't know what the solution is, but it's been a problem for a long time.
[0]: https://www.vrt.be/vrtnws/de/2013/02/12/belgische_bahn_storn... [1]: https://www.augsburger-allgemeine.de/augsburg/Neue-Zuege-auf... [2]: https://de.wikipedia.org/wiki/Bombardier_Talent_3#%C3%96BB
Everyone in this thread seems to be forgetting that those might be useful and not just fancy toys. I prefer trains that have digital signage indicating their location, and connections at the next station. Higher level of automation in trains (e.g. Communications-based train control) also drastically increases efficiencies in speed and scheduling, allowing more trains on the same tracks, and minimises time wasted waiting or accelerating/decelerating needlessly.
The problem is poorly implemented software, not the existence of software.
You know? Shortly after German reunification they appeared in NRW in front of, or behind (pushing them/'Wendetraktion') the Regional-Expresses, S-Bahn, doing the heavy lifting of mass-transportation there, on all or at least most important relations in the Rhine-Ruhr-Area. Not that much later we got DOSTOS there, but brand-new ones.
I remember wondering why that was at the times, and that they couldn't be bad at all, because otherwise they'd break down more often, leading to delays. Which I rarely experienced at the times, as almost daily user.
Die verdammte Scheissbahn war da noch in Ordnung!
However, English has become the (now ironically named) lingua franca of, at least, the more educated parts of the world, and many people who are most comfortable in their native languages are still often translating their best work into English in order to see it more widely read. This is often the case with scientific papers, for example.
Perhaps England's biggest gift to the world was its language.
The original language which was actually called wasn’t really French it was a creole/pidgin language used in the Mediterranean mainly based on Italian and Occitan dialects.
Greeks and others just called all Western European Franks even though they didn’t really interact with people who actually spoke French (only used in the Northern half of modern France back then) that much.
And I only learnt about this whole train "vendor lock-in" from HN. Otherwise I either wouldn't know about it, or I would learn about it weeks or months later.
I've met q3k because we used to work at the same company and briefly on a project together. Not the kind of person I would suspect of participating in a conspiracy of this sort and Newag's statement generally reads like "we didn't think we would get caught".
Additionally, I am fairly certain they are not stupid enough to not have kept detailed, forensic-quality records of their actions and whatever they dumped. Sure it may not stand up in court as evidence but it will be more than enough to show that they didn't pull this out of nowhere
"No hacker can tell, based on the content of the digital record alone, who is the author of the digital record in question"
Boy oh boy. Either they're not singing their firmware (which is a serious indictment in and of itself) or proving that it was them all along will be trivial, but the ones signing off this message are unaware of this.
Overall they got caught with their pants down and handling it badly as evidenced by the fact that they don't even have a scapegoat prepared.
I have no idea how those systems work and what guarantees they provide, but this would be hair-raising...
As with dieselgate, this suggests you basically cannot trust anything containing software. Can't trust it to follow regulations. Can't trust it to do its job.
Can't trust the software. Can't trust the institutions that write the software.
All very "late stage capitalist software development".
Make it so code needs to be reproducibly buildable. Only reproducibly buildable artifacts can be deployed on hardware. Document the whole process.
I wonder if companies purchasing trains could put code disclosure in the purchase contract? I wonder if, in aggregate, train purchasers or car purchasers could fund an independent code storage vault and pay a small premium to fund that code vault organization?
In other words, if purchasers wanted this and valued this, they would demand it in purchase contracts and fund it.
In most OECD countries food needs to be labelled with a full list of ingredients.
Your GP can read scientific papers about the efficacy and risks of a new treatment.
(Yes, many papers are paywalled but that's irrelevant compared to secrecy)
(I think both are equally egregious personally, but I know there's a lot of support here for Apple, so I'm curious how people reconcile these. I don't want to make this a religious war about Apple, but those practices in general regardless of which company is doing it).
Is it the secrecy that makes it different? i.e. if the train company were honest about it then it would be ok?
Or is it the scale that matters? Trains are big and expensive, while phones are small and cheap, so it's ok? (that wouldn't work for John Deere but would for Apple)
Imagine if this happened to an airliner in flight: there'd be criminal charges for sure, not to mention huge damages and lawsuits from the families of the dead if some of the control systems locked up in mid-air.
Trains are not quite as susceptible to disaster arising in the course of operations as airliners, but a Newag Impuls 45WE runs at up to 160km/h in service with up to 218 people on board. (Their speed record is considerably higher.) A sudden breakdown in service is at a minimum going to cause timetable havoc and knock-on delays for other trains and at worse could lead to a mass casualty accident.
(John Deere tractors don't usually carry 200+ passengers and Apple computers don't usually get deployed in safety critical situations. So, different!)
For instance, has anyone really analyzed, what would happened if the trains were running at 160km/h at midnight, on Nov 21? I mean, they might have, I don't know. But that would be pretty funny--having documentation for what's very likely a tort (well, it's Polish counterpart), if not an outright criminal act.
In battery gate, 1-2 year old devices were starting to reboot at low state-of-charge (typically <30% battery). Apple issued a software update that fixed the reboot problem... hmm, how does software fix what smells like a hardware issue? Well, the underlying cause was that aged batteries could not supply enough current and would brownout the CPU (which caused the reboots). The fix was to throttle the CPU a low SoC, which avoided the brownout--so they "fixed" a real problem that I experienced.
My feeling is that Apple owed customers like me some compensation. But, it is clear that the performance throttling was not just an arbitrary "fuck you". Rather, it was a misguided attempt to save the cost of warranty battery replacements in a way they thought customers wouldn't notice.
The current situation couldn't be more different. Here, the manufacturer has added software from the factory to create fake error codes. The hardware is working perfectly fine, but when the train sits in certain locations for too many days, it will pretend to have a hardware failure. During certain months of the year, the train will fake a hardware error. There is no possible explanation for this, except as a "fuck you" to the customer who wants to use 3rd party service.
Sounds like fuck you to me.
IMHO mainly that and clearly those trains are required to be designed in such a way that they could be repaired by a third party (either by law or by contract based on how the situation is described).
Apple provides (nor is required) no such guarantees. Also it has more or less legitimate reasons for its design decision (making it harder to reuse stolen parts).
> equally egregious
I certainly disagree almost completely. With Ape you know what you’re getting and can make an inform choice. Also it’s a completely different type of product. Trains have various regulatory, safety and maintenance requirements which are irrelevant for consumers devices. Screwing with the software controlling trains can literally kill people..
If they want to explicitly claim exclusivity on maintenance or a certain enforced product lifetime, fine, it is a nasty practice but fair enough. But not making the operators aware of these conditions, when they knew months beforehand what would happen when they lost the tender, and while it was seriously affecting the public later on, that is criminal in a way that is not comparable to Apple's practices for instance.
> 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
1. it's not failing, it's disabling
2. it's a safety feature - "SPS can't safely maintain these trains, so we have a safety lock out if they attempt it"
3. there is a ton of stuff that works this way - even Harley Davidson motorcycles require authorized maintenance and the bike's computer won't accept repairs unless a proprietary tool is used
> Newag explains that the train were
> blocked by a “safety system” – but in
> the 20,000 pages of instructions, it
> is in vain to find even a mention
> of it.
This episode puts even John Deere to shame. I'm imagine JD are enjoying themselves right now on this Friday afternoon.
That is until your scheme is uncovered because you left the GPS coordinates of your competitors workshops in your code.
>5.5 mln USD. U$5.5m? Not saying I'm more correct than anyone else, but the former seems outlandishly long.
This would force the government to rely exclusively on that manufacturer to then fix these trains and perform all future maintenance.
Arsehole-ish, but not illegal. All the hidden lockouts on the other hand....
Context and manuals are just so much smoke and fail to obscure the facts.
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.
"Deliberate by manufacturer" 100%.
The scarier part is that had this happened in the United States, DMCA would likely have protected them from prosecution, and the government might be liable for damages.
Welcome to the dark side of Poland - where citizens don't matter.
https://en.wikipedia.org/wiki/Corruption_Perceptions_Index#/...
>The Index only measures public sector corruption, ignoring the private sector. This, for instance, means the well-publicized Libor scandal, Odebrecht case and the VW emissions scandal are not counted as corrupt actions.
But according to their results the "west" has the least perceived corruption.
The programmer who implemented the code? Do you think they thunk these tricks up? They was just following orders.
The manager of the programming team, who set these tricks as things that needed to be implemented? Again, just following orders.
The "Cxx" Title people who directed that there be "some protection" in some way that got implemented as what we see? Did they specify these measures? Did they say "it should break if serviced by a competitor?" Unlikely. Thye wouldn't know how to be that specific, probably.
Some middle manager, maybe a committee meeting, sketched out a "DRM" scheme with the specifics? What do you imagine that meeting looked like? "We've got a directive to secure the systems from outside tampering, what does that mean in terms of how the machine behaves?" Or does that bring us back down to the engineers again?
... the responsible part here isn't a person, its the company as a whole. Just as it took the collective efforts of everyone to make the train, it took their collective efforts to make it wrong.
Corporate Death Penalty; perhaps. make it plain that we will no longer tolerate sill shenanigans like this.
In itself that’s not enough to be considered innocent.
But that is the thing. We do not know who is responsible without an investigation.
We don't need to guess. The local responsible agency should get a warrant and take a copy of their code repo and their internal comms. And then they need to spend the time (call in experts if needed) to figure out what happened and who was involved.
If it is normal code development you can find all the paperwork which documents the change. If they tried to disguise it, (which they might have, or might not) then that is some maffioso stuff and you take the tools police use to break up organised crime groups. You take a low level person who you can incriminate and you flip them. You show them that you have enough to send them to a prison for years and offer them the opportunity to cooperate.
I seem to recall there was a trial in the forties of some relevance to Poland about this sort of thing.
There is Article 254a in the Polish Penal Code. If you obstruct critical elements of infrastructure such as trains, you can face between 6 months to 8 years in prison.
This is a case of fraud, industrial malfeasance and just plain dishonesty. The software component of the story and its security measures are not even at play. Sure they are probably shit (given the date parsing ...) but even FreeRTOS would make an amazing OS *IF USED PROPERLY *.
Absolutely, and thus there's obvious room for improvement.
>This is a case of fraud, industrial malfeasance and just plain dishonesty.
In practice, this amounts to critical infrastructure sabotage, which fits into terrorism.
If the train network experiences issues, the whole country is impacted.