Tagged: railroad

isTRAIN: Detecting if a Train is Blocking a Local Crossing By Listening to Railroad Frequencies

Jhestyr takes pride in being punctual, but a local railroad crossing keeps getting in the way. Trains sometimes park across it for hours at a time, and there is no way to know one is sitting there until you have already driven out to it. Every wasted trip to the crossing and back out to an alternative route costs him a significant chunk of time and fuel.

This is why Jhestyr used two RTL-SDR dongles to build isTrain, an open source program that decodes End-of-Train brake pressure and motion telemetry on 457.9375 and 452.9375 MHz, transcribes railroad voice traffic in the 160 to 162 MHz band via Whisper, and fuses both sources into a single live verdict on whether the crossing is blocked.

The program generates a webpage that can be accessed, providing a YES/NO verdict on whether there is a train blocking the crossing. A live public instance of Jhestyr's isTrain webpage is available here https://istrain.jhestyr.net.

AI-Disclaimer: Jhestyr notes that the code was developed with a 60/40 agentic/human split.

The isTrain Web Interface
The isTrain Web Interface

US Trains are Vulnerable to Derailment via RF Attacks to the End of Train Device

A recently published CVE (Common Vulnerabilities and Exposures) states that a software-defined radio can be used to remotely send a brake command signal to the End-Of-Train wirelessly linked control box.

Security researcher Neil Smith reported the vulnerability. Neil explains more in X, explicitly noting that he has been trying to get this published for 12 years and how no one from the American Association of Railroads (AAR) seems to consider this vulnerability a significant issue.

US trains use wireless RF communications devices, called "End-of-Train" (EoT) and "Head-of-Train" (HoT), to enable data communication between the head and end of the train. The two systems interface with the train's braking and control system, allowing the engineer to view information from both sides of the train, and command systems at ends of a long train instantaneously. Such signals can easily be received with an RTL-SDR and the softEOT decoder, or the PyEOT decoder.

The vulnerability stems from the fact that a software-defined radio can easily be used to replicate an EoT RF signal that can command braking. The signal could be transmitted over a long distance with an appropriate amplifier and antenna. Unexpected braking could cause derailment, amongst other problems.

As of right now, the vulnerability is still unpatched, but AAR have noted that they intend to replace the system with the 802.16t standard. However, in the X thread, Neil notes that this replacement won't be in place until 2027 in the best-case scenario.

If you're interested, another security researcher did a talk about railroad telemetry systems back at DEF CON 26, 6 years ago.

An EoT device (aka FRED) on a US Train. Attribution: https://commons.wikimedia.org/wiki/File:FRED_cropped.jpg