Trens foram projetados para quebrar após reparos de terceiros, descobrem hackers
Hackers analisando trens poloneses Newag teriam encontrado código oculto que desativava deliberadamente os veículos depois que passavam tempo em oficinas independentes, ficavam inativos por vários dias ou tinham peças não aprovadas instaladas, com uma sequência secreta no console para reativá-los. Comentadores comparam o caso ao “Dieselgate”, argumentando que ele exemplifica aprisionamento anticompetitivo ao fornecedor e um ataque ao direito ao reparo, ao mesmo tempo em que levanta questões sobre segurança, responsabilidade legal e se executivos tentarão culpar “desenvolvedores desonestos”. Muitos esperam que as descobertas influenciem futuras compras ferroviárias, regulação e exigências contratuais por acesso ao código-fonte e maior segurança e auditabilidade em infraestrutura crítica.
Mecanismos Alegados de Sabotagem
- O firmware supostamente:
- Desativava os trens depois que passavam ~10 dias inativos, especialmente quando o GPS mostrava que estavam em determinados depósitos de terceiros.
- Verificava componentes com números de série não aprovados pelo fabricante e inutilizava os trens se fossem detectados.
- Continha um interruptor de desligamento baseado em data, ligado a uma data de manutenção agendada, que falhou devido a um bug de data.
- Incluía uma sequência não documentada de botão “unlock” no console do maquinista; atualizações posteriores alegadamente removeram isso depois de descoberta.
- Engenheiros reversos são descritos como tendo extraído o firmware antes e depois da manutenção de fábrica e visto o código de “backdoor” atualizado ali.
Responsabilidade: Desenvolvedor Desonesto vs. Gestão
- Ceticismo generalizado de que um único “dev desonesto” teria:
- Reunido coordenadas GPS da concorrência.
- Implementado lógica de inutilização com múltiplas condições.
- Comunicado procedimentos secretos de reset aos centros de serviço do fabricante.
- Muitos esperam que a gestão culpe engenheiros individuais, citando analogias com escândalos passados, mas os comentadores argumentam que a alta administração deve ter estado envolvida ou sido negligente.
Direito ao Reparar, Propriedade e Concorrência
- Forte enquadramento disso como um problema de direito ao reparo e anticoncorrencial:
- Os trens pertencem à operadora, não ao fabricante, após a venda.
- As operadoras haviam contratado legitimamente empresas independentes e certificadas de manutenção.
- Bloqueios ocultos são vistos como fraude e aprisionamento ao fornecedor, não como segurança.
Segurança, Responsabilidade e Regulação
- Uma linha de argumento: desativar trens após trabalho de terceiros poderia ser justificado por preocupações de segurança e responsabilidade.
- Contra-argumentos:
- Não há códigos de erro claros nem documentação; os trens simplesmente “não ligavam”.
- A responsabilidade por reparo defeituoso normalmente recai sobre o reparador, não sobre o OEM.
- Parar trens arbitrariamente em vias ativas pode aumentar o risco do sistema, especialmente com infraestrutura imperfeita.
Perícia, Ferramentas e Práticas de PLC
- Discussão sobre programação de PLC (IEC 61131-3, ferramentas visuais) e controle de versão:
- Alguns sistemas não têm VCS adequado, mas muitos podem e usam SVN/Git.
- A ausência de VCS para software ferroviário crítico à segurança, por si só, seria condenável.
- Os comentadores esperam que a perícia digital (repositórios, logs de commit, análise de estações de trabalho) seja central se processos criminais avançarem.
Visões Legais e Éticas
- Vários comentários descrevem esse comportamento como uma “logic bomb” e claramente passível de prisão.
- Debate sobre quanta culpa recai sobre desenvolvedores individuais versus gestores; pedidos por fortes proteções a denunciantes.
- Esperança de processos judiciais completos e penas significativas; algum pessimismo quanto à responsabilização.