ट्रेनों को तृतीय-पक्ष मरम्मत के बाद खराब होने के लिए डिज़ाइन किया गया था, हैकर्स ने पाया

कथित तोड़फोड़ तंत्र

• फ़र्मवेयर कथित रूप से:
  • ट्रेनों को लगभग 10 दिन निष्क्रिय रहने के बाद अक्षम कर देता था, खासकर जब GPS से पता चलता था कि वे विशिष्ट तृतीय‑पक्ष डिपो में थीं।
  • गैर–निर्माता-स्वीकृत सीरियल नंबर वाले घटकों की जाँच करता था और पाए जाने पर ट्रेनों को ब्रिक कर देता था।
  • एक तारीख-आधारित किल स्विच शामिल था जो एक निर्धारित सेवा तिथि से जुड़ा था, लेकिन एक तारीख बग के कारण गलत तरीके से सक्रिय हो गया।
  • ड्राइवर कंसोल पर एक बिना दस्तावेज़ वाला “अनलॉक” बटन क्रम शामिल था; बाद के अपडेट्स में कथित तौर पर इसे खोजे जाने के बाद हटा दिया गया।
• रिवर्स इंजीनियरों के बारे में कहा गया है कि उन्होंने फैक्टरी सेवा से पहले/बाद फ़र्मवेयर डंप किया और वहाँ “बैकडोर” कोड को अपडेट होते देखा।

ज़िम्मेदारी: दुष्ट डेवलपर बनाम प्रबंधन

• इस बात पर व्यापक संदेह है कि कोई अकेला “दुष्ट dev”:
  • प्रतिस्पर्धियों के GPS निर्देशांक एकत्र करेगा।
  • कई-शर्तों वाली ब्रिक लॉजिक लागू करेगा।
  • निर्माता के सेवा केंद्रों को गुप्त रीसेट प्रक्रियाएँ बताएगा।
• कई लोगों का मानना है कि प्रबंधन व्यक्तिगत इंजीनियरों पर दोष डालेगा, पिछले घोटालों जैसी उपमाएँ देते हुए, लेकिन टिप्पणीकारों का तर्क है कि ऊपरी प्रबंधन शामिल था या उसने लापरवाही बरती।

राइट टू रिपेयर, स्वामित्व, और प्रतिस्पर्धा

• इसे राइट‑टू‑रिपेयर और प्रतिस्पर्धा-विरोधी मुद्दे के रूप में मज़बूती से प्रस्तुत किया गया है:
  • बिक्री के बाद ट्रेनों का स्वामित्व ऑपरेटर का होता है, निर्माता का नहीं।
  • ऑपरेटरों ने वैध रूप से स्वतंत्र, प्रमाणित रखरखाव कंपनियों को अनुबंधित किया था।
  • छिपे हुए लॉकआउट को सुरक्षा नहीं, बल्कि धोखाधड़ी और विक्रेता लॉक‑इन के रूप में देखा जाता है।

सुरक्षा, दायित्व, और विनियमन

• एक तर्क यह है: तृतीय‑पक्ष काम के बाद ट्रेनों को अक्षम करना सुरक्षा और दायित्व चिंताओं के कारण उचित हो सकता है।
• प्रतिवाद:
  • कोई स्पष्ट त्रुटि कोड या दस्तावेज़ीकरण नहीं; ट्रेनें बस “स्टार्ट ही नहीं होती थीं।”
  • खराब मरम्मत के लिए दायित्व आमतौर पर मरम्मत करने वाले पर होता है, OEM पर नहीं।
  • लाइव ट्रैकों पर मनमाने ढंग से ट्रेनों को रोकना, विशेषकर अपूर्ण बुनियादी ढाँचे में, सिस्टम जोखिम बढ़ा सकता है।

फ़ॉरेंसिक्स, टूलिंग, और PLC प्रथाएँ

• PLC प्रोग्रामिंग (IEC 61131‑3, दृश्य उपकरण) और संस्करण नियंत्रण पर चर्चा:
  • कुछ प्रणालियों में उचित VCS नहीं होता, लेकिन कई SVN/Git का उपयोग कर सकती हैं और करती भी हैं।
  • सुरक्षा-महत्वपूर्ण ट्रेन सॉफ़्टवेयर के लिए VCS का अभाव अपने आप में निंदनीय होगा।
  • टिप्पणीकार उम्मीद करते हैं कि यदि आपराधिक मामले आगे बढ़ते हैं, तो डिजिटल फ़ॉरेंसिक्स (रिपो, कमिट लॉग, वर्कस्टेशन विश्लेषण) निर्णायक होंगे।

कानूनी और नैतिक दृष्टिकोण

• कई टिप्पणियाँ इस व्यवहार को “लॉजिक बम” और स्पष्ट रूप से जेल योग्य बताती हैं।
• इस पर बहस कि दोष का कितना हिस्सा व्यक्तिगत डेवलपर्स बनाम प्रबंधकों पर जाता है; व्हिसलब्लोअर सुरक्षा की मज़बूत माँगें।
• पूरी अदालत-कार्यवाही और सार्थक दंड की आशा; कुछ लोगों में जवाबदेही को लेकर निराशावाद भी है।