- Polonya’daki Newag’ın Impuls 45WE trenleri, bağımsız bakım sonrası normal teşhis sonucu vermesine rağmen hareket etmedi ve bakım şirketi SPS, Dragon Sector’dan araç üstü bilgisayarın tersine mühendisliğini yapmasını istedi
- Araştırmacılar CAN veri yolu analizi, TriCore tabanlı bellek dökümü ve Ghidra iyileştirmeleriyle yazılımdaki kilit bayraklarını ve çalıştırma koşullarını bulup trenleri yeniden hareket ettirdi
- Bazı tren kodlarında, belirli bakım atölyelerinin GPS koordinatlarında 10 günden uzun kalındığında çalıştırmayı engelleyen koşullar, parça değişimi kilitleri, 1 milyon km sonrası arıza koşulu ve tarihe bağlı kompresör arızası raporlama koşulu yer alıyordu
- Analiz edilen toplam tren sayısı 29’du; 5’i hariç tüm trenlerde resmî işletim talimatları dışında “sürprizler” bulundu ve sorun Wrocław, Opole, Krakow, Szczecin, Warsaw gibi birçok bölgeye yayıldı
- Olay davalara ve kolluk kuvveti soruşturmalarına uzandı, ancak tüketici/rekabet koruma kurumu ya da demiryolu taşımacılığı kurumunun somut bir adım attığı doğrulanmadı
Bakımdan sonra duran Newag Impuls trenleri
- Olay, 2022 ilkbaharında, Lower Silesian Railways tarafından işletilen Newag üretimi Impuls 45WE trenlerinden ilkinin 1 milyon km zorunlu bakımını tamamladıktan sonra hareket edememesiyle başladı
- Bakımı bağımsız bakım şirketi Serwis Pojazdów Szynowych(SPS) üstlendi
- Newag da ihaleye katıldı ancak üreticinin teklifi yaklaşık 750 bin dolar daha pahalıydı
- SPS, 11 trenin bakımını yaklaşık 5,5 milyon dolar karşılığında yapma şartıyla ihaleyi kazandı
- SPS, üreticinin sağladığı yaklaşık 20 bin sayfalık bakım kılavuzuna göre trenleri söküp kontrol edip yeniden topladı, ancak araç üstü bilgisayar normal olduğunu göstermesine rağmen tren hareket etmedi
- İnvertör motora gerilim vermiyordu ve bakım teknisyenleri yalnızca kılavuz ile elektriksel/mekanik kontrollerle nedenini bulamadı
Tekrarlanan duruşlar ve büyüyen sözleşme riski
- İkinci tren de aynı bakımdan sonra aynı şekilde durdu ve üretici Newag yardım etmeyi reddetti
- Üçüncü tren, akü sorunu nedeniyle incelemeyi kaçırdı ve yerine dördüncü tren atölyeye girdi
- Normal çalışan dördüncü tren, duran trene bağlanınca çalışan tren de durdu
- Bunun nedeni hâlâ doğrulanmadı
- Szczecin’deki başka bir atölyede de bakım sonrası Impuls trenlerinin çalışmadığı vakalar görüldü
- Lower Silesian Railway’in uzun dizili 6 treninin devre dışı kalması, sefer tarifesinin daralmasına, yedek tren kullanımına ve daha kısa dizilerde yoğunluğa yol açtı
- Newag, trenlerin “güvenlik sistemi” tarafından engellendiğini söyledi, ancak 20 bin sayfalık kılavuzda bu sistemden hiç söz edilmiyordu
- Atölyede duran her tren için günde 1.000 doların üzerinde sözleşmesel ceza doğuyor, bu da SPS üzerindeki baskıyı artırıyordu
Dragon Sector’un tersine mühendisliği
- SPS, “Polish hackers” diye arama yaparak CTF ile tanınan Dragon Sector ekibini buldu ve taraflar sözleşme yaptı
- Projeye Michał “Redford” Kowalczyk, Sergiusz “q3k” Bazański ve Kuba “PanKleszcz” Stępniewicz katıldı
- Redford ve q3k, Toshiba dizüstü bilgisayar hack’iyle tanınan isimlerdi
- Kuba’nın endüstriyel otomasyon deneyimi vardı
- Sahada araştırmacılar, hareket etmeyen bir tren, 2 yedek bilgisayar ve bilgisayar üreticisinin SDK dosyalarını teslim aldı
- İlk analiz, CAN veri yolunu dinleyerek başladı ancak protokol belgeleri olmadığından trafiği yorumlamak zordu
- SDK yalnızca yeni yazılım yüklemeyi destekliyordu; mevcut yazılımın dökümünü alma özelliği yoktu
- Buldukları eski sürüm yazılımı ilk yedek bilgisayara yükleyince o bilgisayar yanıt vermez oldu
- Araştırmacılar çalışmayı elde kalan tek yedek bilgisayarla sürdürdü
- Sonunda hata ayıklama arayüzünü bulup cihaz belleğini bayt düzeyinde indirdiler
- Araç üstü bilgisayar, otomotiv alanında da kullanılan TriCore mimarisi tabanlıydı; iyi bir disassembler olmadığı için Ghidra’yı kısmen geliştirerek kodu analiz ettiler
Son tarihten hemen önce bulunan çalıştırma koşulları
- Yaklaşık bir buçuk ay sonra Lower Silesian Railway daha fazla bekleyemeyeceğine karar verip Newag ile arızalı trenlerin onarımı ve bakım işbirliği konusunda anlaştı
- SPS ile sözleşmenin 1 hafta sonra feshedilmesi bekleniyordu ve araştırmacıların kalan sürede sonuç göstermesi gerekiyordu
- Araştırmacılar çalışan trenler ile arızalı trenlerin bilgisayar bellek imajlarını karşılaştırdı
- Trenlerin işlev setleri ve yazılım sürümleri farklı olduğundan basit karşılaştırma zordu
- Bazı trenlerde ayarlanmış görünen, başka trenlerde ise 0 olan değerler buldular
- Bilgisayar, trenden sökülmüş durumdayken de kısa süre çalıştırılabildiği ve invertörün işletime hazır durumunu gösterebildiği için masaüstü test yapılabiliyordu
- Son tarihe bir günden az kala, treni hareket ettirebilecek bir bayrak yapılandırması buldular; ancak deney sırasında son çalışan araç üstü bilgisayarın kondansatörü yandı
- Hasarlı iki bilgisayarı birleştirme denemelerinin ardından yanan bilgisayarı onardılar ve sabaha karşı 2’de treni çalıştıracak şekilde ayarladılar
- Araştırmacı bu bilgisayarı alıp atölyeye gitti, ancak tren gecikti; sahaya vardığında bağlanan bilgisayarla tren ilk denemede yine çalışmadı
- Ek görüşmelerden sonra eksik bir bayrak daha bulundu ve tren saat 08:42’de başarıyla çalıştırıldı
- Saat 09:30’da Lower Silesian Railway heyeti trenin yeniden hayata döndürülebileceğini gördü ve SPS ile sözleşmeyi feshetmedi
Kodda gizlenmiş kilit koşulları
- Aylar süren analiz ve tersine mühendislik sonucunda, Newag’ın sağladığı çeşitli tren yazılımlarında ani çalışamaz hâle gelmeye yol açan koşullar bulundu
- Koddaki
53.13845,17.99011gibi sayılar GPS koordinatlarıydı ve Bydgoszcz Główny Railway Station yakınındaki PESA sahasını gösteriyordu - Daha sonra Polonya’daki diğer bakım ve onarım yapabilen atölyelerin koordinatları da bulundu
- Kodda, tren belirli bakım atölyesi bölgelerinden birinde en az 10 gün kalırsa çalıştırma yeteneğini devre dışı bırakan bir koşul vardı
- Koordinatlardan biri Newag’ın kendi atölyesine aitti
- Newag atölyesinin koordinatları için farklı mantık koşulları tanımlanmıştı; bunun test amacıyla olduğu tahmin edildi
- Başka trenlerde ek kilit koşulları da bulundu
- Belirli parçalar değiştirildiğinde parça seri numarası kontrolüyle tren bloke ediliyordu
- Sürücü kabininde ve araç üstü bilgisayar ekranında belirli düğme sıraları basılarak kilidin açılmasını sağlayan bir seçenek vardı
- Impuls’un yeniden çalıştırıldığı haberi basına yansıdıktan sonra trenlere bu “fix” seçeneğini kaldıran bir yazılım güncellemesi gönderildi
- Başka trenlerde 1 milyon km sonrasında “arızalanmasını” söyleyen kod da bulundu
Tarih koşuluyla oluşan kompresör arızası bildirimi
- Başka bir tren, 21 Kasım 2022’de bakımda olmadığı hâlde çalışmayı reddetti
- Bilgisayar kompresör arızası bildiriyordu, ancak bakım ekipleri kompresörde bir sorun olmadığını düşünüyordu
- Kod analizi şu koşulu ortaya çıkardı
- gün 21 veya üzeriyse
- ay 11 veya üzeriyse
- yıl 2021 veya üzeriyse
- kompresör arızası bildir
- Bu trenin aslında 2021 Kasım’da bakıma girmesi planlanmıştı, ancak gerçekte daha erken bakıma alındı ve ancak 2022 Ocak’ta hizmete döndü
- 2021 Kasım’da koşul tesadüfen tetiklenmedi; planlanan arıza koşulu ancak 21 Kasım 2022 tarihinde gerçekleşti
Donanımda bulunan GSM bağlantı cihazı
- Yalnızca yazılımda değil, donanımda da sıra dışı bir cihaz bulundu
- Bir tren setinde araştırmacılar “UDP<->CAN converter” etiketli bir cihaz buldu
- Bu, trenle uzaktan iletişim kurmayı sağlayan bir cihaz gibi görünüyordu
- Cihaz çıkarıldığında çalışmayı durduran herhangi bir işlev bulunmadı
- Araç üstü bilgisayar kilit durum bilgilerini bu cihaza gönderiyordu ve cihazın kendisi bir GSM modeme bağlıydı
Sorunun birçok bölgeye yayılması ve analiz ölçeği
- SPS’nin Newag’ın “arızalı” trenlerini onardığı haberi başka şirketlere de yayıldı ve benzer sorunların yaygın olduğu ortaya çıktı
- Wrocław’da 13 Impuls analiz edildi
- Başka bölgelerde de sorunlu trenler doğrulandı
- Kolej Mazowieckie 1 tren
- Opole 2 tren
- Krakow 4 tren
- Zielona Góra 1 tren
- Szczecin 4 tren
- Warsaw 1 tren
- Araştırmacıların geliştirdiği araçlar, araç üstü bilgisayardaki yazılım kilidini kaldırdı ve her tren onarılabildi
- Toplam 29 trenin yazılımı analiz edildi; bunların 5’i hariç hepsinde resmî işletim talimatlarının dışında unsurlar bulundu
Sonraki adımlar ve kamuya açıklanan kapsam
- Bu konuda davalar sürüyor
- Polonya’daki Office of Consumer and Competition Protection ya da Railway Transport Office’in somut adım atıp atmadığı bilinmiyor
- Araştırmacılar bulgularını CERT Polska’ya bildirdi
- CERT Polska da bunu “ilgili makamlara” iletti
- Olayı kolluk kuvvetleri ele alıyor
- Bu metin, 5 Aralık 2023’teki Oh My H@ck konferansında Jakub Stępniewicz, Sergiusz Bazański ve Michał Kowalczyk tarafından yapılan sunumun kısa bir özetidir
- Asıl metin, tam teknik analizin önemli bölümlerini dışarıda bıraktığını ve araştırmacıların ayrı bir teknik belge hazırlayıp yayımlamasının beklendiğini belirtiyor
1 yorum
Hacker News yorumları
Konuyla ilgili yeni bir yazı da var: Polish trains lock up when serviced in third-party workshops - https://news.ycombinator.com/item?id=38530885 - Aralık 2023, 347 yorum
Bu kadar arsız olunabilmesi akıl alır gibi değil. GPS koordinatları rakip bir bakım şirketinin bölgesinde 10 günden fazla kalırsa lokomotifi tuğlaya çeviren kod ha.
Belgelendirilmemiş arayüzler ya da kriptografik imzalı firmware ile tamiri zorlaştırmanın çok ötesinde; bence kötü niyetli mal tahribine daha yakın. Polonya hukuk sistemini bilmiyorum ama bunun nasıl yanlarına kalabileceğini hayal edemiyorum
Trenler zaten var ve çalışmak zorunda, ama bakım-onarım şirketi telif hakkı nedeniyle yazılımı yasal olarak değiştiremiyor. Tam bir çıkmaz. O şirketin çok ağır para cezaları almasını ve hatta cezai yaptırımla karşılaşmasını umuyorum, ama gerçekten öyle olup olmayacağından şüpheliyim
İstekli bir hukuk ekibi uygulanabilecek ciddi suçlamalar bulabilir gibi geliyor. Özellikle de söz konusu tren ya da lokomotif kritik altyapı kapsamına giriyorsa; gerçi bu garanti değil
Gizli bir el sıkışma koyup prosedür belgelerini kötü hazırlayarak rakibi beceriksiz göstermek ile, rakip servise girdi diye kendi ürününü kasıtlı olarak bozmak bambaşka şeyler
Başlık biraz yanıltıcı. Bu olayda “gate” kısmı, Dieselgate’teki gibi yapay koşullarda sertifikasyondan geçmek için çevreciymiş gibi aldatmak değil; sahte arıza simüle etmek.
Şirket, konum bilgisine dayanarak başka bir şirketin treni tamir ettiğine karar verirse, kompresör gibi normal çalışan parçalarda arıza varmış gibi raporlayıp trenin çalışmasını durduran bir algoritmayı hardcode etmiş
Elbette iki olay tamamen aynı olamaz, ama bu benzetmenin neden yapıldığı açık görünüyor
Biri, GPS’e göre rakip bakım lokasyonunda 10 gün kaldıktan sonra trenin çalışamaz hâle getirilmesi. Diğeri ise belirli bir firmware’de, bir sonraki planlı bakımdan birkaç gün sonra kompresör arızası olmuş gibi gösterecek şekilde hardcode edilmesi
“Polonya’da bu konuda nazik bir ilgi beyanından fazlasını gösteren bir kurum bulmak zor. Tüketici ve Rekabeti Koruma Kurumu’nun ya da Demiryolu Taşımacılığı Dairesi’nin herhangi bir adım atıp atmadığını da bilmiyorum” kısmı en kötüsü
Tüketiciyi koruma kurumlarının yetkileri bu kurumlar kadar güçlü değil
İlgili makalenin önceki yazısındaki tartışma da dikkate değer: https://news.ycombinator.com/item?id=38530885
Emisyon testi manipülasyonu, üçüncü taraf tamiri engelleme gibi tuhaf motor kontrol sorunlarının çözümü bu sistemlerin arayüzlerinin standartlaştırılması olabilir.
Sensör çıktıları standartlaştırılırsa, çeşitli bileşenleri değiştirip sistemin düzenleyicileri kandırıp kandırmadığını kontrol etmek mümkün olur
[1]: https://wheelsports.co/formula-1s-standardised-ecu-explained...
WRX’i olan bir arkadaşım var; katalizörü yok, büyük turbosu ve tune’u var, yani normalde emisyon testinden kesinlikle geçmemesi gereken bir araba. Ama sensör verisi sentezlenip ilgili bölümleri kontrol ettiği için hata kodu da yok ve her seferinde sorunsuz geçiyor
Firmware denen kara deliği ortadan kaldırıp denetimi mümkün kılmak iyi olurdu
Tam standartlaştırma şart değil; açıklık bile yeter. Yine de temel olarak doğru yön bu
Üretici servisi yerine daha ucuz üçüncü taraf servislerin kullanılmasını engellemek için yazılımla kasıtlı sabotaj yapılmış gibi görünüyor.
Mahkemenin kararını merak ediyorum
Kanun koyucuların, mahkemelerin ve kamuoyunun teknik meseleler karşısında yolunu kaybetmesi bir sorun, ama bu suç mevcut sabotajla ilgili ceza hukuku hükümlerine rahatça oturtulabilir. Yöntem “yeni” ama suçun kendisi klasik
Tren ürün yazılımının kalitesinin genel olarak pek iyi olmadığı izlenimi var; umarım bu skandal daha sıkı incelemelerin yapılmasına yol açar.
Üç yıl önce Deutsche Bahn, yeni teslim edilen Bombardier trenlerindeki “tuhaf” yazılım sorunlarından açıkça şikâyet etmişti. Örneğin makinist gidiş yönünü değiştirdiğinde tren yazılımı çöküyor, yeniden başlatılması 1 saat sürüyordu [0]. İsviçre’de de 2018’de benzer bir sorun yaşanmıştı [1].
Bir bilgisayar bilimci olarak bu utanç verici. Yakın zamana kadar buralarda 1950’lerden kalma Batı Almanya yolcu vagonlarını [3] çeken 1980’lerden kalma eski Doğu Almanya trenleriyle [2] karşılaştırmak yeterli. Dijital elektronik ya neredeyse hiç yoktu ya da hiç yoktu; açılış süresi de yoktu. Sadece çalışıyordu. Çalışmadığında da makinist genellikle motorun neresine çekiçle vurursa düzeleceğini bilirdi. Bir makinistten trenin ürün yazılımını hack’leyip neden hareket etmediğini bulmak için gdb açmasını bekleyemezsiniz.
[0] https://www.sueddeutsche.de/wirtschaft/deutsche-bahn-ic-1.47...
[1] https://bahnblogstelle.com/33872/twindexx-swiss-express-soft...
[2] https://de.wikipedia.org/wiki/DR-Baureihe_243
[3] https://de.wikipedia.org/wiki/N-Wagen
İçinde yazılım olan fiziksel ürünler üreten şirketler, yazılım çalışanlarına eskisinin 2-3 katını vermeye hazır bir pazarda değiller. Geriye, bu işi ilginç bulmayı toplam ücret farkının karşılığı sayanlar ve daha fazla ödeyen işlere giremeyenler kalıyor. Kullandığımız çoğu emniyet açısından kritik sistemi bu insanlar geliştiriyor. X ile SpaceX’teki geliştirici ücretlerini karşılaştırırsanız piyasanın nasıl işlediğini görürsünüz. İlginçlik de toplam ödemenin bir parçası, ama bunun bir sonucu olarak iyi geliştirici olmayan bazı insanlar bu alanda yeni süreçler ve araçlar tasarlama yönüne de kayabiliyor. Modası çoktan geçmiş full-stack furyasına tutunup bunu tren ürün yazılımına uygulamaya kalkabilirler. Jira’da Git’ten 10 kat fazla metin olması, scrum-şelale geliştirme yapılması ve emniyet açısından kritik gömülü sistemlere REST API ya da servis odaklı mimari konması şaşırtıcı olmaz.
Beckhoff’un Tc3’ü gibi birkaç istisna dışında henüz nesne yönelimliliğe bile ulaşılmış değil; tüm alan geçmişin mavi ekran madeninde sıkışıp kalmış durumda. Karmaşıklık ince standart dokümanlarıyla yönetiliyor, sürüm kontrolü bile yok; buna karşılık makineler sensörler ve aktüatörler açısından giderek daha karmaşık hale geliyor. Modern makineleri küçük hobi tipi gömülü cihazlar gibi ele alamazsınız, ama sektör tam da bunu yapıyor. Dışarıdan programcılar gelip düzgün yazılım mimarisi ve C geliştirme pratikleriyle dünün sorunlarını çözerek iyi para kazanabiliyor. Ama sektör bundan öğrenmiyor. Onlar için yazılım üretimi asla gerçek bir meslek olmayacak.
Birçok modern tren temel sürüş yazılımı sorunları [0] ve yazılım onayı gecikmeleri [1] yaşıyor. Ama bence en kötü gerileme uyumluluğun kaybı. Modern elektrikli tren setleri fiilen yalnızca aynı partideki tren setleriyle birlikte çalışıyor. Aynı modelde bile iki şirket ayrı sipariş verdiyse çoğu zaman birbirleriyle uyumlu olmuyorlar; şirketi farklı olan ya da sipariş tarihleri arasında 10 yıldan fazla bulunan elektrikli tren setlerini birlikte kullanmayı ise neredeyse unutmak gerekiyor. Buna karşılık dijitalleşme öncesinde farklı nesil tramvayları birlikte kullanmak ve kablolamayı uyarlamak yaygındı. Eski yolcu vagonları sorunsuz birlikte çalışıyor, ama IC2 ile Railjet’i ya da RailJet ile ICE-L’yi birlikte kullanmak kolay değil. Çoğu zaman yalnızca belirli lokomotifler ile belirli vagonlar birlikte çalışabiliyordu.
Bilgisayarlı sistemlerde karmaşıklık ve opaklık yüksek olduğu için bunları birlikte çalışır hale getirmek çok daha zor. Geleneksel mantık devre kartları genellikle kolayca tersine mühendislik yapılabilir; yazılım tersine mühendisliği ise son derece uzmanlık isteyen bir iş. Tescilli dijital protokollere geçişle birlikte birlikte çalışabilirliğin büyük ölçüde kötüleştiği başka alanlarda da bu olgu belirgin.
Bunun bir nedeni yazılımın opak olması nedeniyle önceki teknolojilere kıyasla onay almasının daha zorlaşması; ama gerçek kalite eksikliği de büyük bir etken. Bombardier’nin büyük sıkıntıya düşmesinin nedenlerinden biri de kötü yazılımdı; 40’tan fazla trenlik bir siparişin iptal edilmesine kadar gitmişti ([2]).
Güvenilir ve anlaşılabilir yazılım yapmanın, mantık devreleri ya da mekanik sistemler yapmaktan çok daha zor olduğunu düşünüyorum. Çözümü bilmiyorum, ama bu çok eskiden beri süren bir sorun.
[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
Yalnızca İngilizce içerik tüketiyorum. Diğer ülkelerin içerikleriyle ancak büyük medya üzerinden sızıp geldiğinde karşılaşıyorum
Çevrilebilecek ne kadar çok iyi içerik olduğunu merak ettiriyor
Ancak İngilizce, en azından dünyanın daha eğitimli kesimlerinde artık ironik biçimde ortak dil haline geldi ve ana dili kendilerine daha rahat gelen insanlar bile en iyi çalışmalarının daha geniş okunması için çoğu zaman İngilizceye çeviriyor. Bilimsel makaleler bunun tipik örneği. Belki de Britanya’nın dünyaya verdiği en büyük hediye İngilizcedir
Buna rağmen trenlerdeki bu tedarikçiye bağımlılık meselesinin tamamını HN’de ilk kez öğrendim. Aksi halde ya hiç haberim olmayacaktı ya da ancak haftalar, aylar sonra öğrenecektim