For years, heavy vehicle cybersecurity training has had a fundamental bottleneck: hands-on learning required physical ECU hardware rigs. These are obviously hard to scale or access remotely. We have led a chain of upstream open-source contributions to make remote fleet cybersecurity lab environments a practical reality for technicians and engineers alike. There have been many upstream changes to ultimately make the vehicle simulator in the fleet cyber challenge (coming soon) a possibility. That work has three parts: make the software reliable over remote links, give learners a realistic heavy-vehicle network to practice on, and make the simulator easy to reach through cloud-hosted tools. Together, those pieces turn hands-on heavy-vehicle cybersecurity training from something tied to a physical bench into something that can scale to more learners and more locations.
Our journey began by fixing foundational transport bugs that crop up in scapy over any slow link – e.g. over virtualized network-transported interfaces. When testing ISO-TP diagnostic requests over serial link CAN (slcan) connections, we discovered that some windows systems (but not all) had very long latencies and caused delays, select-loop hangs, and sniffer thread race conditions under background traffic. By submitting Scapy PR #4938, we eliminated bus filters for slcan, optimized latency in the python-can mux, and ensured select() loops properly handled internal signal pipes. Resolving these timing races on virtualized serial links laid the bedrock for reliable vehicle interaction across higher-latency connections.
Training your skills on heavy vehicle networks pretty much requires a heavy-vehicle firmware target. We had seen the great success of the RAMN for passenger car vehicle networks and knew it could be very useful in this domain too. Through RAMN PR #45, we implemented native SAE J1939 mode into the open-source RAMN ECU firmware. This remapped standard vehicle control signals to J1939 Parameter Group Numbers (PGNs) such as TSC1 (PGN 0), XBR (PGN 1024), and EEC1/EEC2 (PGNs 61444/61443), while retaining the complete UDS, KWP2000, and XCP diagnostic stacks that were already available there. We added J1939 Diagnostic Trouble Codes (DM1 via PGN 65226 using BAM TP) to it too. For virtualized simulations and also for lower-cost physical uses it is beneficial to not need the expansion pods that contain the steering, brakes etc. But a useful starting point for any vehicle network training is to do some signal decoding of mission time signals and it is best that the signals do change for that task; therefore, we introduced ‘Showcase Mode’—a compile-time feature that switches RAMN to a network commanded by a headway controller and randomizes command signals at 1 Hz, bypassing sensor overrides. Showcase Mode automatically generates dynamic, real-time J1939 bus traffic without requiring physical expansion pods.
We think the key to long term vehicle network security testing success is delivering a working understanding of the vehicle network interactions and enabling dynamic, context-specific testing (i.e. via scripts); we don’t think that any one command-line tool will ever provide what can be done by scripting with, e.g. an LLM agent. So we aimed at scapy to provide robust upstream Python library tooling. Collaborating with Nils Weiss (polybassa), we expanded upstream Scapy with native J1939 support. What began as a massive pull request was systematically split into manageable modules over several months, culminating in Scapy PR #5164 (still WIP at this time). This latest will add J1939 Controller Application (CA) scanning capabilities directly over soft sockets, enabling researchers to issue Address Claim requests (PGN 60928 / 0xEE00) and scan active CAs on the vehicle bus. We have been using the forked versions for some time in our Truck Cybersecurity Assessment Tool (TCAT) beta program training with fleets.
In the TCAT beta program training we also show the technician and fleet IT students how to use jupyter notebooks to complete cybersecurity assessments of heavy vehicles using the Automotive Scapy Playground notebooks as a starting point. These Jupyter notebooks can be used for J1939 CA scanning, address claiming, and UDS diagnostic discovery. These notebooks are continuously rebased to rely directly on official Scapy releases as upstream merges complete.
To eliminate hardware dependencies entirely, we virtualized RAMN in cloud infrastructure. As detailed in Antmicro’s Re:node blog post on virtualizing RAMN, we adapted the firmware for headless execution within the Re:node simulation framework. In RAMN PR #73, we shifted ECU A’s serial command transport to LPUART1 and exported it over TCP. We also added a superserver which allows connection to the re:node TCP via python-can slcan socket://, WebSocket, and secure WebSockets. Then, since it was now possible, we added automated integration tests to the project so the actual RAMN firmware can be used in validation testing in CI. A more complicated form of this superserver was then used in our fleet cyber challenge to spawn RAMN vehicle simulators on-demand for the capture-the-flag (CTF) players.
Want hands-on heavy-vehicle cyber experience without the lab?
Discover the Fleet Cyber Challenge and be among the first to take on our virtual RAMN simulators.
