Trains were designed to break down after third-party repairs, hackers find

Original Article ↗ Hacker News Discussion ↗

Hackers analyzing Polish Newag trains allegedly found hidden code that deliberately disabled vehicles after they spent time at independent repair shops, remained idle for several days, or had non‑approved parts installed, with a secret console sequence to re‑enable them. Commenters compare the case to “Dieselgate,” arguing it exemplifies anti‑competitive vendor lock‑in and an attack on the right to repair, while also raising questions about safety, legal liability, and whether executives will try to blame “rogue developers.” Many expect the findings to influence future rail procurement, regulation, and contractual demands for source access and stronger security and auditability in critical infrastructure.

Alleged Sabotage Mechanisms

  • Firmware reportedly:
    • Disabled trains after they spent ~10 days idle, especially when GPS showed they were at specific third‑party depots.
    • Checked for components with non–manufacturer-approved serial numbers and bricked trains if detected.
    • Contained a date-based kill switch tied to a scheduled service date, which misfired due to a date bug.
    • Included an undocumented “unlock” button sequence on the driver console; later updates allegedly removed this once discovered.
  • Reverse engineers are described as having dumped firmware before/after factory service and seen the “backdoor” code updated there.

Responsibility: Rogue Developer vs Management

  • Widespread skepticism that a lone “rogue dev” would:
    • Gather competitor GPS coordinates.
    • Implement multi-condition brick logic.
    • Communicate secret reset procedures to the manufacturer’s service centers.
  • Many expect management to blame individual engineers, citing analogies to past scandals, but commenters argue upper management must have been involved or negligent.

Right to Repair, Ownership, and Competition

  • Strong framing of this as a right‑to‑repair and anti‑competitive issue:
    • Trains belong to the operator, not the manufacturer, after sale.
    • Operators had legitimately contracted independent, certified maintenance companies.
    • Hidden lockouts are seen as fraud and vendor lock‑in, not safety.

Safety, Liability, and Regulation

  • One line of argument: disabling trains after third‑party work could be justified by safety and liability concerns.
  • Counterpoints:
    • No clear error codes or documentation; trains simply “would not start.”
    • Liability for faulty repair typically rests with the repairer, not the OEM.
    • Stopping trains arbitrarily on live tracks can increase system risk, especially with imperfect infrastructure.

Forensics, Tooling, and PLC Practices

  • Discussion of PLC programming (IEC 61131‑3, visual tools) and version control:
    • Some systems lack proper VCS, but many can and do use SVN/Git.
    • Absence of VCS for safety‑critical train software would itself be damning.
    • Commenters expect digital forensics (repos, commit logs, workstation analysis) to be pivotal if criminal cases proceed.

Legal and Ethical Views

  • Multiple comments describe this behavior as a “logic bomb” and clearly jailable.
  • Debate over how much blame falls on individual developers vs. managers; calls for strong whistleblower protections.
  • Hope for thorough court proceedings and meaningful penalties; some pessimism about accountability.