S12X Patch Diffing with QBinDiff Ben Gardiner National Motor Freight Traffic Association Inc. This is a preprint; final version presented at VehicleSec / Black Hat USA 2026
arXiv:2608.05350v1 [cs.CR] 5 Aug 2026
Abstract
ties including hardcoded secrets protecting traction control configuration, buffer overflows, and memory corruption leading to denial of service (of the vehicle) and remote code execution. Finally, we identified the removal of PID handlers discoverable through simple fuzzing. This suggests the safety recall also functions as a security patch, preventing attackers with wireless, ‘adjacent’ 6, access to J2497 from exploiting these vulnerabilities. This paper focuses exclusively on changes that were ‘fixed’ by this patch; no ‘0day’ vulnerabilities are revealed as all have been patched.
This paper presents a reverse engineering analysis of a firmware update for a commercial vehicle Brake ECU. We analyze the updater executable to extract firmware and perform differential binary analysis of the S12X architecture firmware images. Our research identifies specific changes in the recall that address undocumented vulnerabilities in legacy protocol processing. We demonstrate that the patched functionality contained critical flaws. The findings confirm the safety recall remediation was also a security patch.
1
Contributions. In summary, we make the following contributions:
Introduction
• FW Update Process: We reverse engineered the operations performed by ID9363 from several captures of the UDS 8 traffic (Section 3)
Introduced circa 2001, the J2497 1 (aka ‘PLC4TRUCKS’) powerline databus remains the only industry-standard means to satisfy the trailer ABS warning light requirement of FMVSS 121 2, S5.1.6.2(b). As such, J2497 has been present in all towing application Class 8 vehicles in North America from 2001 to the present.
• EC80 Firmware Partitions: The flash layout/partitioning and fixed addresses of the EC80 are revealed within the constraints of the S12X architecture (Section 4) • S12X Reverse Engineering: We present novel methods for reversing the S12X banked memory architecture. We detail memory map reconstruction, symbolic analysis, and opportunistic function identification, overcoming significant tooling gaps (Sections 5, 6 and 7)
Previous research on J2497 ECU security 3 4 5 6 revealed that J2497 is wirelessly reachable and trailer brake controller ECUs implement diagnostics functions inside J1587 Data Link Escapes beyond FMVSS 121 requirements. However, current threat models assume tractor brake controllers only process necessary LAMP messages on J2497.
• The Security Patch: The functionality removed by the patch is confirmed on all three types of EC80 units acquired and the vulnerabilities present in the removed functionality are itemized (Section 8)
The 2024 Bendix EC80 safety recall 7 revealed safety impacts to tractor ECUs from J2497 reception, suggesting the EC80 processed J2497 traffic beyond necessary LAMP messages. The safety recall was remediated via a firmware update of the EC80 using the ‘ID9363’ updater executable.
• Exploitability of Removed Functionality: We evaluate the exploitability of each of the patched vulnerabilities from a mix of: bench and in-motion vehicle testing (Sections 9 and 10).
We performed binary differential analysis on the S12X firmware (FW) pre- and post-recall in 3 types of the EC80 (one for each OEM affected by the recall). 2 Background Results show extensive processing of J1587 messages received by the tractor brake controller over J2497 in In late 2024, three Class 8 vehicle OEMs in North the removed code. This code contained vulnerabili- America issued a safety recall 9 10 11; these were 1
the three OEMs that integrate the Bendix EC80 brake controller. Bendix identified potential memory corruption causing the ECU to go offline and worked with OEMs to deploy a firmware update for affected trucks – those with Electronic Stability Program (ESP) or Automatic Traction Control (ATC) features – estimated at 450,000 units at the time of this writing 12. The timeline of this recall is summarized below in Figure 1 (see also 13 14 15). See 16 for further details on the recall. The recall was later expanded in October 2025 to cover some units which were sold as aftermarket equipment 17 18 1 .
Bendix EC80 Recall Timeline
Investigation 2023
May 2024
For the J1587 application layer, the first byte is defined by J1708 and is the Message Identification (MID), which identifies the sender or the message type. MIDs 0x0A (LAMP ON), 0x0B (LAMP OFF), and 0x57 (Active Trailer ABS Event) are required by the J2497 standard. For other J1587 messages the bytes following the MID are Parameter Identification (PID), which specify the type of attached data (e.g., VIN, wheel speed, diagnostics) followed by parameters (payload). Some PIDs have a fixed data length (like a 1-byte speed value), while others are variable length. PIDs data enables transmission of vehicle signals, diagnostic commands, and proprietary data.
Initial Recall
Sep 2024
Oct 2024
Oct 2024
1st OEM & Remedies
Oct 2024
Nov 2024
Dec 2024
The Bendix EC80 is a heavy-duty vehicle Electronic Control Unit (ECU) responsible for Anti-lock Braking (ABS), ATC, and ESP functions. It controls pneumatic circuits through external pressure modulation valves connected to PCB-mounted FET drivers. During initialization, absent critical Diagnostic Trouble Codes (DTCs), modulators undergo individual testing, producing a ‘roll call’ of small air chuffs 2 .
The Expansion
Jan 2025
Oct 2025
Table 1 provides an overview of the EC80 units acquired for this study. The complexity of the EC80 firmware varies with the integrated features. The The firmware update was distributed to fleets via a middle target, 2ec80, represents a medium complexWindows executable, ‘ID9363’ 19 20 21. We examine ity unit and was selected as the primary target for the ID9363 update process and the resulting firmware reverse engineering in this paper. All findings have been validated across all the target firmwares. changes in three EC80 ECUs (one per OEM). Figure 1: Bendix Recall Timeline.
The firmware update, or ‘patch’, purportedly prevents J2497 noise from triggering memory corruption. However, due to CVE-2022-26131 6, it is possible to wirelessly inject signals onto J2497. It is also possible to inject from compromised connected devices such as the increasingly common trailer telematics devices. We examine if these memory corruptions could be triggered by malicious actors using wireless (or wired) injection on J2497. J1587 22 serves as (roughly) the application layer for J2497, while J1708 23 defines the original physical and data link layers (i.e. “framing”). The J1708 physical layer is replaced with a Power Line Carrier (PLC) modulated over the 12V auxiliary power line in J2497, but it inherits the J1708 data link and J1587 application layers. A frame can only be a maximum of 21 bytes long and must end with a one-byte checksum (the two’s complement of the sum of the preceding bytes). In software, the frames are received byte-bybyte over a standard UART peripheral via a J1708 to J2497 converter chip (the Intellon SSCP485 24).
Target Name
1ec80
2ec80
3ec80
FW version, before FW version, after Sticker Name Non-sticker Feature Sticker Features
Z228999 Z300822 EC80ESP+ J1708 6S/6M PLC 2nd CAN -
Z266494 Z302578 EC80ESP 6S/6M PLC 2nd CAN CAN Gateway -
Z286098 Z302579 EC80ESP 4S/4M PLC -
20230507 3E2323G
20221019 2F1423G
HW Date Code SW Date Code
Integrated TPMS 20220723 3H0922G
-
Table 1: Information on the three EC80s acquired and tested. While specific part numbers and OEM integrators are omitted, the firmware versions presented are consistent with recall documentation and can be retrieved from the target ECU via a Read Data By Identifier request (0xF194). The order here matches Figure 2 left to right. The EC80 units affected were released in April
1 all
recalls for this same issue known at this time: 24V780000, 24V818000, 24V915000, 25E073000, 25E077000, 25E078000.
2 In a bench environment the same successful power-on re-
sults in a clicking of a failsafe ‘diagonal’ relay.
2
2020 20. Given its role in preventing rollovers and maintaining stability, brake controllers are expected to have a high Automotive Safety Integrity Level (ASIL), likely ASIL C or D, to meet OEM safety targets. While specific ASIL targets for EC80 vehicles are unpublished, Hazard Analysis and Risk Assessment (HARA) of brake controllers 25 identified ASIL D scenarios. While focused on autonomous systems, this analysis notes the architecture applies to nonautonomous vehicles, stating the brake system is critical regardless of autonomy. Furthermore, the literature for a competing product, the mBSP, explicitly states compliance with ISO 26262 26 up to ASIL D 27.
into a 23-bit global address space. The device includes 512 KiB of PFLASH (Program Flash) residing at global addresses 0x780000 - 0x7FFFFF and 32 KiB of DFLASH (Data Flash) located at 0x100000 - 0x107FFF. Additionally, it features a 4 KiB Emulated EEPROM (EEE) buffer RAM mapped to global addresses 0x13F000 - 0x13FFFF, which allows the firmware to treat the DFLASH as random-access nonvolatile memory.
3
ID9363 Update Process
We observed several EC80 firmware updates. The new firmware is readable in cleartext from CAN A Threat and Risk Assessment (TARA) of Class 8 ve- databus captures; however, analyzing the update hicles 28 ranked brake controllers third, after telem- requires the pre-update firmware contents. While atics and gateway devices, for cybersecurity priority. some ECUs offer a UDS ‘upload’ service, we conThe EC80 connects to multiple interfaces, including firmed the EC80 does not. From the traffic we re“Untrustworthy Network Domains” like J2497 29. Be- constructed the seed-key exchange routine in closedcause it is not explicitly intended to transport, trans- form for all DSC,SA sessions (see Appendix A), late, or filter traffic, it is classified as an “unintended confirming no firmware upload service exists in the gateway” device 29 3 . Consequently, it must satisfy observed sessions (DSC=2,SA=5) (DSC=3,SA=1) cybersecurity requirements NGW-S-001 (Security As- (DSC=3,SA=7) (DSC=3,SA=3) 4 . surance), NGW-S-002 through -005 (Won’t TransWe used the BDM interface to dump PFLASH, port, Translate, Filter, etc.) 29. DFLASH, and EEE (emulated in DFLASH) from The EC80 uses two S12X microcontrollers (as can both MCUs to obtain the pre-update firmware. We be seen in the PCBs pictured in Figure 2). Both found that both the XPROG tool 32 and PROGS12Z are specifically the NXP MC9S12XEQ512 30, a 16- 33 worked well. XPROG creates flat binary files of bit microcontroller from the S12X family; however, PFLASH, DFLASH and EEE which correspond to the ‘left’ MCU is in a smaller footprint 80-pin QFP their global address extents. PROGS12Z creates .s19 package compared to the larger ‘right’ MCU in a 144- files 34 which contain the global address extents of PFLASH, DFLASH, and EEE. pin LQFP package. We found that although the S12X used in the EC80 supports read-out protection, it was not enabled. We confirmed that the data transferred over CAN matches the PFLASH contents after update. Only the ‘right’ MCU (larger package) receives code changes; the ‘left’ MCU’s PFLASH remained unFigure 2: The PCBs of the three EC80s acquired changed. It did, however, receive some DFLASH / and tested. A 0.1” header is installed for access to EEE changes during the update process. We focus the BDM programming pins on the right S12X MCU. solely on the ‘right’ MCU’s code changes. The added/removed components are highlighted in A visualization of the byte-by-byte difference of green/red, respectively. PFLASH before and after update of a 2ec80 is presented in Figure 3. Byte differences are marked by The S12X 31 features an XGATE peripheral coproces- pink fill, red outline boxes, and are numerous (this is sor to offload high-speed data transfer and logic pro- clearly not a micropatch 35). The “Drive Block”s 1 cessing from the main CPU12X core. The S12X em- and 2 are labeled. The PPAGE numbers correspondploys a paging architecture using PPAGE, EPAGE, ing to the PFLASH offset are labeled at the bottom and RPAGE registers to map 16-bit logical windows for reference. The same style of visualization will be reused throughout the paper to illustrate successive 3Although the ‘Z’ version which implements a ‘CAN Gateway’ (see Table 1) could be considered a ‘(intentional) gateway device’
4 memory leaks,
other unintended upload functionality in the bootloader or application are out of the scope of this paper
3
analysis steps. In this figure function prolog estimates 5 Limitations of Static Analysis are plotted as green circles (in subsequent figures the functions resulting from firmware analysis will replace The S12X primarily uses a 16-bit memory space with banked windows (PPAGE, DPAGE, RPAGE) to acthese). cess global memory 30, rather than direct global addressing (Figure 5) 5 . Disassemblers must model this Despite extensive byte differences, the high-level mapping to correctly resolve page-dependent refersource code changes may be concise. Small machine ences to the global address space. Fixed mappings, code changes and linking order can cause massive like PPAGE 0xFF at 0xC000-0xFFFF, are straightbyte differences. Byte-level analysis cannot reveal forward. The reset vector is in this address so startspecific code changes or isolate areas of interest, as ing analysis with a disassembler is likewise straightchanges span ‘Drive Blocks’ 1 and 2. Understandforward. In all EC80 firmwares, execution quickly ing the changes requires disassembling and comparencounters a call instruction with a 3-byte target: a ing the pre- and post-update images. 16-bit offset and a PPAGE. At this point the disassembler needs to have the code in the correct location in its memory model.
4
are not many examples of S12X architecture EC80 Bootloaders and Appli- There reversing available. Of course the seminal work of 37 did include S12X reversing of a power assist steering cation module, and it did include uncovering the use of hardcoded passwords there for UDS 8 seed-key exchange (the security access $27 service). But the ‘how’ of creating dumps of PFLASH, DFLASH, RAM and assembling it for a reverse engineering tool (e.g. IDA Pro as used by 37) are not available. The recent analysis by Pulse Security of a motorcycle ECU 38 demonstrates a way to assemble an S12X target binary image for analysis in Ghidra 39 before switching to hunting for numeric tables in Flash. Ghidra does not support the XGATE coprocessor, whereas IDA Pro 40 does; therefore IDA Pro was selected for this analysis. The IDA Pro support team was kind enough to provide a code snippet of how PPAGE is modeled in the IDA
Global PFLASH byte differences (Figure 3) and ID9363 updater traffic analysis (Table A.1) indicate a J1939 36 CAN UDS 8 bootloader in the skipped region. We label this the ‘late’ bootloader as it does not contain the reset vector. Code between the reset vector and this late bootloader is labeled the ‘early’ bootloader. Its code likely resides in some subset of PPAGE 0xFF (aka “Drive Block 2 of 2”) which has a fixed mapping in the S12X memory space.
The bootloaders presumably hand-off to the ‘application’. Its code is very likely in the “Drive Block” 1 of 2 region, although it could have some code in the 5 although specific, slower execution, instructions exist for other “Drive Block” as well to make use of the fixed mapping of PPAGE 0xFF. direct global address access.
Figure 3: Comparison of the PFLASH of 2ec80 before and after ID9363 update. The unchanged extents illustrate that both the interrupt vector table at the end of PFLASH (0x7E8800) and the region 0x7E8800 - 0x7FC000 were skipped by the firmware update. Many other locations where the PFLASH contents are unchanged were found to have value 0x3F ’?’, the Software Interrupt (‘SWI‘) instruction, which we believe is used as a padding value. The number of 0x3F bytes increased, suggesting function deletion by the update. Function prolog estimate locations across the update suggest shifting to lower addresses which (also) suggests function deletion by the update (examined in Section 8). 4
Reset Vector
Fixed PPAGE FF PFLASH Banked Window
Total IDA Linear
PPAGE FF 0xff8000 ...
0xc000
PPAGE FD 0xfd8000
RAM Banked Window 0x8000 Fixed PPAGE FD 0x1000 Fixed EPAGE FF 0xc00 Fixed RPAGEs FE and FF 0x4000 0x2000 EEPROM Banked Window 0x800 Registers 0x0
...
Global PPAGE FF 0x7fc000 PPAGE E1 0xe18000 ...
Global PPAGE FD 0x7f4000
PPAGE E0 0xe08000
...
Figure 5: Local 16-bit memory map of S12X by linkerscope. Green for fixed page areas and blue for paged windows.
Fixed PPAGE FF 0xc000 Fixed PPAGE FD 0x4000
Global PPAGE E1 0x784000 Global PPAGE E0 0x780000
Figure 6: Illustration of the copies of PFLASH placed in the IDA Linear Address space memory map for some success in static analysis.
linear address space model. It corresponds to how all of Ghidra, the HSW12 open source assembler 41, and the original S12X debugger, HiWave 42 treat it: use PPAGE as the most significant byte in a three-byte address (e.g. the gray boxes in Figure 6). The same is done for RPAGE and EPAGE 6 . Because RPAGE and PPAGE windows are discontiguous in the 16-bit local space this does not cause collisions. This addressing scheme is very useful and will be used in the remainder of the paper (i.e. any three byte addresses other than global addresses imply the first byte is the page and the remaining bytes are the offset within it). IDA also expects to be able to address the global memory space in the exact same address values in its linear memory map (the peach boxes in Figure 6); however, this is only used for instructions that do global memory space access.
ure 3. Analysis proceeds past three-byte calls, confirming correct PPAGE installation. While analysis reaches the late bootloader, it fails to reach application code. Starting from the reset vector often yields incomplete coverage due to unresolved data-dependent jump or call targets in many firmwares and the EC80 is no exception.
We focus on J2497 processing changes, so understanding the entire EC80 bootloader is unnecessary. The EC80 receives J2497 data via an Intellon SSCP485 24 chip connected to the S12X SCI2 peripheral. However, the SCI2 interrupt vector of the default table We used IDA Pro Python scripts to map PFLASH to points to a dummy function, and no discovered funcglobal addresses and copy it to high-byte and fixed tions reference SCI2 data registers. PPAGE locations in the 16-bit local space (Figure 6, Appendix C.0.1). We then created an entrypoint for every interrupt vector in 0xFF80 - 0xFFFF, including 6 Limitations of Dynamic Analreset, CAN, Programmable Interrupt Timer (PIT), ysis Serial Communications Interface (SCI), and all other peripherals with an interrupt. IDA Pro analysis results are shown in Figure 4, with function extents Since static analysis failed to reveal SCI2 access, we replacing the prolog estimates used previously in Fig- used the unlocked BDM for dynamic analysis. The debugger software we had access to is HiWave 42. Breakpoints on SCI2 register reads were never triggered. We found that breakpoints cease function-
6 This causes IDA linear space collisions between EPAGE 0x10/0x13 and DFLASH global addresses. No workaround exists; users must be cautious if firmware uses both.
Figure 4: Visualization of what the IDA Pro auto-analysis achieved after creating entrypoints for each of the handlers in the default interrupt vector table. The lack of functions in all but the ’early’ and ’late bootloader’ regions illustrates that auto-analysis is not able to follow the exeution flow into the ’application’ region. 5
Figure 7: Visualization of what the IDA Pro auto-analysis achieved after creating entrypoints for each of the handlers in an interrupt vector table given by IVBR=0xF7. Compared with Figure 4, this figure shows several functions in the ’application’ region; however, they represent a small fraction of the firmware’s total application code, the upper bound of which is given by the byte differences. Similar to the prologs in Figure 3, it also shows correlated, left-shifted function extents which (again) suggest code deletion by the update; however, the low overall coverage limits our confidence. ing after the late bootloader entrypoint (0xFBADB1). The cause is unknown; possibilities include BGND instruction execution or resets triggered by the secondary (‘left’) processor. Attempts to reset both MCUs in tandem failed. Despite evidence of debugaware firmware (e.g. watchdog feeding after STOP), we abandoned further investigation to focus on the firmware patch.
CAN4, Enhanced Capture Timer (ECT), SPI1, and SCI2. We focus solely on SCI2. The SCI2 ISR, sub_C12B, calls functions where IDA Pro analysis fails due to lack of ‘register tracking’ for S12X. For now, we manually resolved data-dependent call instructions (e.g., call [-$2662,y]) that IDA failed to handle. We also manually resolved jump tables, which IDA Pro does not support on S12X.
BDM allows reading S12X address spaces without interrupting execution (mostly 7 ). We used HiWave’s 42 scripting interface (Appendix C.0.10) to create hexdumps and convert them to .s19 files. This allowed us to read ‘live’ RAM and register contents without breakpoints and load them into IDA.
Then IDA Pro analysis revealed the application’s J2497 message reception operation 10 . The details of the receiver architecture are captured in Appendix B; but the dataflow of received packets from the SCI2 peripheral to consumers is simpler: frames are built by appending to a receive buffer at 0x3BF5 and frame reception is signaled with the frame counter / semaphore at 0x3BF4. Figure B.1 illustrates this dataflow. This IDA analysis identified only the ‘publish’ side. No consumers of the frame counter or receive buffer were found. Firmware typically splits interrupt handling into a lightweight top-half and a main-thread bottom-half to minimize interrupt context cycles.
Polling registers revealed that the application uses an IVBR of 0xF7, unlike the initial bootloader’s default 0xFF. The S12X has the capability to switch the location of its interrupt vector table 8 ; although static analysis at the stage shown in Figure 4 missed the IVBR assignment, we had confirmed the application uses an interrupt vector table at 0xF710-0xF7F9.
We updated the IDA Pro database with RAM dumps and entrypoints for the new vectors (Figure 7). Anal7 Binary Diffing ysis still covers much of the late bootloader, as the application frequently calls back into it (e.g., for pro- Interrupt context execution was explored, but the gramming mode). main execution thread remained invisible. Analysis We can now access application interrupt handlers. failed to trace the late bootloader hand-off to the 11 Target 2ec80 supports XGATE 9 , PIT, CAN0, application . Searching for function prolog byte sequences yielded excessive false positives. We ob7 BDM accesses global address space bypassing the MPU. It served function pointer arrays in ‘Drive Blocks’ 1 and is non-intrusive only during free bus cycles, otherwise stealing cycles or stalling the CPU. 8 Except for Power-on, Clock Monitor, and COP Watchdog reset vectors. 9We analyzed XGATE code by mapping PFLASH and RAM in IDA. XGATE handled only ECT interrupts (channels 07) and was irrelevant to J2497 reception, so analysis ceased. Ghidra would suffice here, but we had at this point invested in IDA-based automation.
10 One firmware change is observable now but will be detailed in Section 8. 11 Presumably due to at least a data-dependent call target but possibly due to this and other reasons. The result was good enough to identify the functions that consume the receive buffer 0x3BF5 and Frame Counter 0x3BF4: sub_EEB98 and sub_F096F9; these are functions that check for LAMP messages and then process non-LAMP J1587 messages, respectively.
6
2. Indirect call instructions (e.g., call [-$2662,y]) 0xFD. We adjusted the IDA database segment setup, read a 3-byte address (PPAGE offset + PPAGE as shown in Figure 8. value) from a resolved memory location. The compiler/linker used here always emits a trailing zero byte. Scanning for these patterns, filtering for valid PPAGE values and offsets (0x8000-0xC000), significantly reduced false positives. We further filtered out isolated function pointers, as they typically occur in arrays. See Appendix C.0.4 for the script used. Then analysis discovered the main-thread bottom-half function for J2497 message processing at sub_EEB989 (see Figure B.2). The main thread processing in sub_EEB989, handles J2497 LAMP ON (0x0A), LAMP OFF (0x0B), and Active Trailer ABS Event (0x57) commands, ignoring payloads. It consumes contiguous 0x0A, 0x0B, or 0x57 messages. Messages with other MIDs are passed to sub_F096F9. J1587 messages can contain one or more PID payloads. This function splits J1587 messages into PID payloads and passes the payloads to sub_F2A3E1, which dispatches each to a handler from PFLASH tables starting at the 0xDC3D ‘context structure’ (see Appendix C for details). This data flow processing is illustrated in Figure B.2.
Figure 8: Hiveplot panel comparing IDA Pro analysis achieved before (above) and after (below) a change of the 0x4000 mapping from Flash to RAM. The crossreferences (xrefs) are drawn as edges directed counterclockwise (CCW); each region with executable code is doubled to show intra-region xrefs; the ”Drive blocks” 1 and 2 are shown co-linearly and the skipped region is shown lifted above them; yellow edges are code xrefs, red edges are data reads, blue are data writes and black are interrupt vector references.
To analyze six firmware images (three pairs) with BinDiff 43, we automated IDB creation (see C.0.1), segment setup, interrupt vector definition, and function search. We scripted the identification and marking of PID tables and handlers (Appendix C.0.5). We excluded the late bootloader to focus BinDiff on the These steps achieved function coverage of 80% (1ec80), 60% (2ec80), and 75% (3ec80) of byte differapplication firmware. ences in PPAGEs E0-F9. We then automatically perLack of ‘register tracking’ hindered automatic anal- formed BinDiff on all three target pairs. Bindiff was ysis, requiring manual resolution of indirect call tar- able to support the S12X architecture and give reagets. We implemented rudimentary concolic analy- sonable insight; however, its shortcomings when apsis to parse disassembly and symbolically track ex- plied to this firmware caused spurious matches e.g. it ecution, substituting concrete values from PFLASH, matched the SCI2 handler in a before image with the DFLASH, or RAM when needed and where available. SCI3 handler in an after image. See Appendix C.0.2 for the script used. We also implemented basic jump table detection and creation by We ultimately created a QBinDiff 45 analysis, the reparsing disassembly and creating manual code xrefs sults of which are in Figure 9. The key to successful QBinDiff analysis was to ‘anchor’ (force a match) all (Appendix C.0.3) 12 . the interrupt handlers. This yielded improvements To ensure BinDiff fidelity, we aimed for zero disassem- over the Bindiff results. Less than 1% of discovered bly errors. We found numerous disassembler errors functions were low-confidence matches. Over 98% in PPAGE 0xFD functions. Hiveplots 44 of IDA Pro of functions remained unchanged, while ~110 - ~140 xrefs revealed invalid data writes to PPAGE 0xFD were modified or deleted (Table 2). from functions in other PPAGEs. These writes are invalid as PFLASH requires sector erasure. Runtime Three-way BinDiff analysis showed that matched polling of the MMCCTL1 register confirmed that the functions dropped from 968 (pre-update) to 878 application maps 0x4000 to fixed RAM, not PPAGE (post-update) across all ‘Z’ versions, corroborating function deletion. The patch makes very similar 12 because the actual jump table operation “probably can’t changes in all three cases: of the deleted functions, be scripted” according to IDA Pro support. 87 were common to all three updates. The next 7
New Deleted Modified Unchanged Low Confidence
1ec80
2ec80
3ec80
0 104 11 1109 12
0 127 12 1100 13
0 123 13 1031 14
13
Modified functions primarily remove calls to these deleted functions: 1. In sub_EEB989 (LAMP/ABS check), the call to sub_F096F9 and subsequent PID processing is removed (Figure 10, EBB 0xEEBA20), consequently removing all linked PID processing tables and functions.
Table 2: QBinDiff results summary of all three targets.
2. In sub_C12B (SCI2 ISR), the call to EDGE intersection, 8, analyzes these changes. Fewer functions rupt handling is removed (Figure 11), effectively were deleted in the 1ec80 update because it retained eliminating the ‘RXEDGIF Branch’ (Figure B.3) J1587 Transport Protocol (TP) management funcand related setup/processing. tions which were deleted in the others; presumably, because they are used due to the J1708 interface The bulk of the deletions were due to the removal of all PID processing on J2497 (see Table C.1 for the which 1ec80 has and the other targets do not. full list). The disassembly of all deleted functions (for target 2ec80) is provided in Appendix C.0.10. Term Definition BinDiff Terminology Function Extents (matched, unchanged) Function Extents (matched, changed)
Functions present in both binaries with identical logic and structure.
Matched, Similarity = 1.0
Functions present in both binaries but with some modifications to instructions or structure.
Function Extents (unmatched) < 95% confidence Function Extents
Functions present in one binary but not the other (new or deleted). Functions that might be matched but with low confidence; ignored for high-assurance analysis.
Matched, Similarity < 1.0, Confidence >= 0.95 Unmatched (Primary/Secondary) Matched, Confidence < 0.95
9
of
Removed
We reviewed deleted functions (primarily PID handlers, Section 8) for vulnerabilities using static and dynamic analysis. Dynamic analysis was limited to fuzzing due to breakpoint limitations (Section 6). We identified several vulnerabilities in the deleted code. The PID 0xC2 handler was exploitable for Denial-ofService (DoS) and Remote Code Execution (RCE); both verified, see below. A DoS condition could be triggered by a J2497 message like 89C2XXX, where a large ‘n’ parameter (0xFE) caused a crash. For RCE, the handler processes a length parameter specifying the total size of data following the length parameter. The data is copied to a 0xXXXXXXXX-byte stack buffer without length check. The return address is 0xXXXXXXXX bytes from this buffer, creating a classic buffer overflow 46 (see Listing of sub_F1B623 in appendices) with one intervening byte: the count of a loop executed after the copy. While J2497 frame limits restrict direct attacker-controlled data to 18 bytes, the copy size is fully controllable.
Table 3: Table defining the categories of functions used in Figure 9 and the analysis presented in Sections 8 and 9.
8
Exploitability Functionality
Changes Made in Patch
Manual BinDiff analysis, validated by call tree analysis script (Appendix C.0.6), categorized all the deleted functions in all three firmwares as one of:
1. All J1587 PID processing present in the pre- Furthermore, the adjacent region is attackerupdate image (Appendix C), excluding LAMP controlled, as J2497 frames are contiguous (with an injected frame-length byte) in a 0xXX-byte FIFO and active ABS event processing. buffer: an attacker can control the entire 0xXXXXX 2. SCI2 UART EDGE interrupt handling (Ap- byte copy by first sending a complete 0xXXXX byte pendix B). buffer as a message (results in additional injected 3. Secondary J1587 features, including the diagnos- length byte and added checksum byte) starting with tic code manager (sub_E9858A), J1587 Trans- 89c2XXXXXXXX which fills the buffer at 0x3BF5 (but 13 J1587 TP was not functional even before the update, conport Protocol (TP) connection management (sub_EF905B), and TP timeouts (sub_EC8116). firmed with static analysis and testing.
8
Figure 9: A visualization of the QBinDiff analyses of all three of the firmware updates (when limited to the APPLICATION parts of the PFLASH), overlaid on the byte differences of each. The varying complexity of the firmwares mentioned in the introduction is clearly illustrated here (compare to Table 1); target 3ec80 (top) shows the least complexity while 1ec80 (bottom) shows the most. Links between matched (by QBinDiff) functions are plotted across pre- and post-update. Despite noise from small/null function matches, the links show clear function shifting to lower addresses and numerous unmatched functions in the pre-update images (colored magenta), suggesting multiple function deletions. More conclusively: there are no (known) spurious matches and zero ’new’ functions post-update: further suggesting multiple function deletions in the update.
9
does not get passed to higher application layers because it is longer than 21 bytes) then sending 89c2XXXXXXXX by itself. The second message will get written to the same location as the previous 89c2XXX bytes in the receive buffer and will be passed to higher layers (with the remaining buffer in-tact). The wrinkle here is that any reception of other messages on the J2497 databus will interfere with the layout in the buffer: messages received before will move the start position of the first and/or second messages, reducing available buffer space and messages received in-between will move the start of the second message, removing the adjacency of the attackercontrolled buffer. A typical J2497 databus does contain a stream of LAMP messages and e.g. 0xC2 and other lower priority messages. There is a means to inhibit reception: during the development of the keyhole mitigation 47 the ideal standing sinusoid frequency was discovered to inhibit message reception. An attacker can transmit this sinusoid interference (to empty the buffer) and then transmit their exploit in a blanking of the sinusoid. They can also abuse the Intellon SSCP485 receiver feature where the pre-amble is superfluous to send the two bodyonly messages in a sequence quicker than ‘normal’ Figure 10: BinDiff of the LAMP etc check function J2497 databus transmitters can achieve. before and after update. The modified EBB has a two-line change: remove a call to sub_F096F (Process The RCE was confirmed on the 2ec80 and 3ec80 tarPID payloads) and remove load of an argument to gets in a bench environment. This confirms that althat call. The deleted EBBs were removed because though the S12X has an MPU which could inhibit with the call to PID processing removed there is no execution from data buffer and/or stack areas, it was longer any need to handle LAMP and Active ABS not configured to do so. The following listing shows a simple proof of concept with NOP placeholders. The MIDs at a higher priority. first code block is copied to the stack (as described above); the return address is overwritten with the address of the first code block in the receive FIFO 0x3BF5. Execution flows into the receive buffer original copy of the code block and jumps over the return address and intervening byte there to use an additional area for more code in the buffer. # REDACTED FOR PREPRINT
This PoC uses the receive FIFO buffer at 0x3BF5 as the location for hosting the executable code and only queues one message (the [0:20] slice above). If other bytes are received before the SEI is executed they will be written into the buffer after 0x3BF5+20. The interfering sinusoid mentioned above can be reasonably effective at accomplishing this. A more robust approach could use the stack only (if the SP Figure 11: BinDiff of the SCI2 Handler before and address in the 0xC2 handler were known 14 ) or an after update. The deleted EBBs were responsible for 14 it was not for us. Because there was no dynamic analysis servicing SCI2 EDGE interrupts. possible this PoC was developed iteratively in a crash/no-crash loop
10
approach could send multiple messages and skip over address function pointers in the firmware 16 . the injected length bytes. Long-running payloads will require feeding the watchdog peripheral and there are Deleted SCI2 EDGE interrupt code theoretically presented a write-where primitive. Exploitation involves: many examples of this in the firmware. 1) Triggering an EDGE interrupt and timeout to The PoC leaves 66 bytes of usable payload; this is partially reset the receive buffer (by sub_F1B035), enough to transmit a valid J1939 36 CAN frame. The setting a buffer full flag (see Table B.1) but leavbasic form of this is 85 bytes long using MOVB for ing the write offset (0x3C4B) un-reset. 2) Consumdata move. This can be reduced to 62 bytes by us- ing a subsequent message clears the buffer full flag ing STD 2,X+ instead. And it can be golfed into without resetting the offset, potentially exceeding the a 43 byte payload by abusing the stack for PULX; 0xXXXXXXXX buffer limit. 3) sub_EC803E (append however, using PULX is not practical on the targets data) contained a write-before-check flaw. Data was which use the XGATE coprocessor during their run- written to the receive buffer (0x3BF5) at the current time (such as 2ec80) because the stack is shared. The offset (0x3C4B) before boundary validation. This alpayload can also be reduced to 39 bytes by re-using lowed writes beyond the limit. 4) Positioning the the firmware’s CAN-sending function sub_E9919A. write offset at +0xXX and sending a X-byte frame alThis was confirmed using the HSW12 assembler 41. lowed setting arbitrary upper bound (0x3C49) and Also possible is misconfiguring the CAN transceiver current offset (0x3C4B) values. Subsequent data to a bad bps which will crash that CAN bus segment would be written to the new offset address. and this a much smaller payload. This will silence all ECUs on the bus – until bus recovery fixes the The PID 0xC7 handler contained a hardcoded passproblem, if at all. More is possible. As is always the word check. Receiving the matching password discase with RCE: anything is possible 48. The space ables traction control, as per J1587 specification 22. message ACC7XXXXX satlimitation here is also only a minor problem since an Bench testing confirmed that 17 isfies this password check . attacker can find many RAM areas to write longer payloads ‘in pieces’ as well. Returning to the vulnerabilities in the other deleted code, the PID 0xED 15 handler can also crash the ECU. Sending a rapid sequence of messages with a large length parameter triggered this vulnerability. Bench and closed-track testing confirmed that greater than 10 repeated 89EDXX messages triggered the crash (128x was used to be sure). The PID 0xED handler (sub_F2BA46) causes this by copying the PID payload (length-specified) into a static buffer at 0x5BDC without bounds checking (see Listing for sub_F2BA46s). This buffer has a XXX-byte safe limit before overwriting critical structures at 0x5BF6 and 0x5BF8. These locations are used by sub_F38241 for a conditional memcpy (sub_E642), with the condition seemingly controllable via the PID 0xB4 handler. Like the 0xC2 handler, the attacker controls copy size and can control the adjacent bytes in the receive FIFO buffer.
Component
Vulnerability
Impact
PID 0xC2
Buffer Overflow
PID 0xED
Unbounded Copy
PID 0xC7
Hardcoded Credential OOB Write
DoS (Verified), RCE (Verified) DoS (Verified), RCE (Theoretical) Auth Bypass (Verified) DoS (Theoretical), RCE (Theoretical)
SCI2 EDGE
Table 4: Summary of vulnerabilities in removed functionality.
Exploits of these RCE vulnerabilities (verified and theoretical) will depend on the specific ‘Z’ firmware version memory layout. The ID9363 updater contains 13 ‘Z’ versions (covering a total ~450,000 units 12); however, exploits of the DoS vulnerabilities and hardcoded credential will not. Testing shows they worked in all three tested ‘Z’ versions and likely affect all Theoretically, sequential 0xED and 0xB4 PID payversions. loads (potentially in one J2497 message) could establish a write primitive. The write primitive pointer Reverse engineering is not required to discover all and data are XXX and XX bytes from the 0xED han- these vulnerabilities. A simple fuzzing script discovdler’s buffer start. Successful exploitation requires ered the PID 0xC2 and 0xED crashes. These were careful J2497 receive buffer grooming to overcome the verified on the bench and in-motion (Section 10). See XX-byte control limit. This write primitive makes Appendix C.0.7 for the script used. RCE feasible, given unused RAM regions and fixed15 which is Trailer VIN PID, not the previously allocated PID:
Entry Assist Control #1.
16 It would also be possible to send CAN data with a write primitive and without RCE. 17 REDACTED FOR PREPRINT
11
10 Notes on In-Motion Vehicle We conducted in-motion tests below 5 mph and at ~9 mph — fast enough to trigger ABS pulsing but Tests safe for occupants. At 9 mph, after observing the
Figure 12: Right: a 10uF DC block resulting in ACcoupling of the FL2K SDR (not pictured) connected to a power amplifier (not pictured). Left: Connection of the same to the in-cab on board diagnostic (OBD) port.
ECU crash via CAN, the driver initiated a hard brake to check for ABS pulsing. In all cases, CAN traffic ceased. ECU recovery always required a battery disconnect 19 . The crash consistently caused loss of speedometer, steering assist, and shifting (Figure 13). The results are summarized in Table 5. The scripts used to trigger the 0xED and 0xC2 DoS vulnerabilities can be found in Appendices C.0.9, and C.0.8, respectively. One difference emerged: in the PID 0xED case, the EC80 stopped streaming signal data but still responded to UDS TP requests. This was not observed in the PID 0xC2 case or during PID 0xED bench testing. We repeated these in-motion tests on a second vehicle: owned by a fleet and from a different OEM than the previous. This EC80 was ‘factory installed’ and was not yet updated by ‘ID9363’. During these tests we were able to test also the 0xC7 ‘backdoor’ impacts. In this vehicle the impact of crashing the ABS controller did not include loss of speedometer nor steering assist nor shifting; but other impacts were the same. This was also true for the 0xC7 ‘backdoor’.
Figure 13: Top Left: failure state of instrument cluster after any and all the ECU crashes described in 11 Random Noise Sufficiency Section 10 while still in-motion. Wide: in-cab picture of in-motion vehicle test with black bar redacting. The EDGE SCI2 interrupt vulnerability could obviously have been triggered by noise: constant framOnsite testing used a host-provided tractor that did ing errors and/or parity errors could cause false 0x00 not perfectly match the source vehicle of the vulnera- bytes to fill the receive buffer and edge interrupts firble firmware but whose EC80 part number matched ing coincident with these could cause the partial reset perfectly – because the host did not have any EC80s and eventual overwrite of pointers. It is not as clear that were not already updated by ID9363. We man- for the PID processing handlers’ vulnerabilities. ually flashed the target ECU with the vulnerable firmware via BDM. Then the target ECU was part- As was mentioned in Appendix B, the only receiver calibrated to the tractor using OEM tools, and base- error checking is if the checksum is consistent. These line ABS functionality was confirmed via hard brak- checksums are the two’s complement of the sum of all bits in the message. The checksum is not able to ing before further testing. detect many-bit errors, and e.g. fails to detect ‘symTesting focused on the crashes in the handlers for metric’ errors (pairs of bit flips). It is easy to imagine J1587 PIDs 0xC2 and 0xED, identified during bench the checksum failing to prevent reception of invalid testing. We injected J2497 signals using an FL2K messages in noisy conditions. Software Defined Radio (SDR) transmitter 49 50 and power amplifier. Due to insufficient J2497 filtering There are not any established models of bit errors or at the diagnostic port, we were able to use a simple of spurious data reception of the Intellon SSCP485 in-cab setup: AC-coupled via a 10uF capacitor to the cantact -c 0 -b 500000 --filter=00F00100:00FFFF00 (usdiagnostic port’s VBAT pin 18 (Figure 12). As shown ing python-can 51 and CANtact 52). 19 This is a relevant condition because some tractors are conin 4, this simulates wireless injection 6. 18 this was confirmed by observing Trailer ABS fault dash
light status and 0xF001 PGN with python -m can.viewer -i
figured without a battery disconnect switch, requiring a manual removal of the battery leads or a manual cycling of a fuse to recover the ECU.
12
Vuln. Target Speed UDS Notes
0xED 1ec80
< 5 Yes mph
0xED 3ec80
< 5 No mph > 5 Yes mph > 5 No mph
0xED 1ec80 0xED 3ec80 0xC2 1ec80 0xC2 3ec80 0xC2 1ec80
< mph < mph > mph > mph
5 No 5 No 5 No
ABS silent security patching 57 is occuring also in heavy Dis- vehicle firmware. abled
Seminal work 58 identified “standard” vulnerabilities like buffer overflows that, we show, persist in modern components. We extend J1708 security research 59 to J2497 and apply the wireless write attack 53 to tractor equipment. Complementing J1939 diagnostic research 60, we demonstrate that mission-time (as distinct from diagnostics) data processing defects in J2497 (as opposed to J1939) directly impact tractor safety.
Loss of shift, steering as- – sist, speedo. Multiple cluster faults Mulitple Cluster faults. – Loss of shift, steering assist, Yes speedo Mulitple Cluster faults. Yes Loss of speedo, steering as- – sist Mulitple Cluster faults. –
13 Generalizable Contributions
Loss of shift, steering assist, Yes speedo Mulitple Cluster faults. Yes
Our work provides several contributions that generalize across different architectures and target devices. First, we demonstrate that hiveplots can be effec0xC7 3ec80 > 5 No Multiple Cluster faults Yes tively used to survey the current disassembly of a mph including “Dyno Mode”. binary. This visualization technique is particularly Loss of shifting in Reverse useful for identifying ‘configuration’ issues and spotting segmented areas in bare-metal firmware images. Table 5: In-motion test results (In all cases streaming Second, we found that the use of manual anchoring data stopped). in QBinDiff for each of the interrupt handlers is a critical step in achieving useful and accurate binary 24 that we are aware of. However, from previous diff results in its application to bare metal firmware. research 53 it is known to be possible for a message Finally, our approach of performing live RAM dumpon the bus to have several of its bits flipped and/or ing is generally applicable to any case where a debugger is not fully functional. This technique is critical be truncated on reception in the presence of noise. for discovering dynamically resolved functions, parIt is very typical of trailer brake controllers to stream ticularly when function pointers or their offsets are PID 0xC2 and so it could be imagined that bit flips stored exclusively in RAM. of an existing 0xC2 message could cause a large value of ‘n’ and hence the same DoS crash we observed in Section 10. 14 Conclusions 0xC2 3ec80
5 No
Trailer brake controllers do not typically stream 0xED messages 20 . Nor do they stream 0xC7 messages. It is, however, possible that the 0xC2 (or other streaming messages) get bit flipped to 0xED or 0xC7 and truncated to the right length. This could not be reasonably described as a likely possibility though.
12 Related Work
This work demonstrates binary differential analysis on legacy automotive architectures, using heuristics and symbolic analysis to overcome tooling limitations. Our analysis reveals several vulnerabilities were patched by the ID9363 update. While the vendor emphasized safety compliance regarding random noise, our analysis confirms a broader security impact. Random line noise is unlikely to generate the valid J1587 frames and frame sequences required to trigger these vulnerabilities. Specifically, the patch removes the tractor ECU’s J1587 parsing stack (except LAMP/ABS event handling), eliminating vulnerable handlers for PIDs 0xC2, 0xED, and 0xC7.
Binary analysis of bare-metal firmware often faces unique constraints. While 54 uses emulation, we employ minimum-viable concolic analysis where emulation was unavailable. We address BinDiff’s smallfunction mismatch issues 55 by applying QBinDiff 56 with manual interrupt handler anchoring to enable useful results. Furthermore, our findings confirm that We classify the removed functionality as critically 20 although they can send them on power up and on request flawed, containing unauthenticated memory corrupat power-up of the tractor tion (PIDs 0xC2, 0xED) and hardcoded weak au13
thentication (PID 0xC7). In-motion testing validated the severity: exploiting the PID 0xC2 buffer overflow caused immediate ABS Denial of Service (DoS), physically manifesting as loss of steering assist, speedometer, shifting and ABS pulsing. The PID 0xED handler induced the same DoS via memory corruption and the 0xC7 handler also via abuse of weak authenticated functionality. Bench testing confirmed RCE via the memory corruption in the PID 0xC2 handler. The ID9363 update mitigates risks from attackers with wireless adjacency or other forms of J2497 network access, improving the compliance to requirements NGW-S-001 through -005 29. Bendix’s proactive recall and firmware update represent a commendable and responsible action. This is particularly important as users are believed to prioritize safety recalls over security patches. However, the lack of distinct CVE assignments for these flaws may obscure the patch’s security criticality. What is recommended – by ISO/IEC 29147 61 and CISA 62 – is that vulnerabilities which are patched should be communicated to users so that they can make their own informed risk calculations.
units, we strongly advocate that all tractor J2497receiving equipment, especially brake controllers, adopt the security-conscious approach demonstrated by the EC80 update.
Acknowledgments We would like to thank our colleagues at the National Motor Freight Traffic Association Inc. whose expertise and dedication have been invaluable to the completion of this research. Particularly Anne Zachos for the continuous assistance in analysis and onsite testing.
We would like to thank AIS for access to their Class 8 vehicle multiple times during this research. Thank you to Hannah Silva and Jesse Norton for sharing S12X development materials and EC80 experience. Thank you to Chris York for the trailhead. Thank you to Jonatan Mars for critical support at a critical time. We would also like to thank many industry engineers for their support of this research – the rest of whom would prefer not to be named. Without the support of the engineers at these vehicle OEMs and The features removed align with the security archi- suppliers this work would not be possible. Last but tecture for tractor J2497 reception 21 detailed in all not least, this work would also not be possible withof: out the support of the member fleets of the NMFTA Inc. 1. the ATA TMC position paper on next generation tractor trailer interfaces 63: “Pertaining We used various large language models (Gemini 65 to PLC communications as described in SAE 2, 2.5-pro, 3-pro) for tasks such as: drafting Python J2497: only the MID 10 and 11 lamp messages, code and Mermaid diagrams. We acknowledge MID 125 J2497 identification, and MID 87 active the open-source tools used: Pandoc 66, Matplotlib ABS event shall be permitted on new tractor and 67, Hiveplotlib 68, Zynamics BinDiff 43, Quarkslab trailer equipment…” QBinDiff 45, Quokka 69, Python 3 70, python-can 51, py-hv-networks 71, RP1210 python 72, Osmocom 2. the CISA mitigations in advisory ICSA-25-021- FL2K 50, Linkerscope 73, Mermaid 74, and Graphviz 03 64: “To most effectively mitigate general 75. vulnerabilities of the powerline communication, any [tractors] utilizing J2497 technology should disable all features where possible, except for Open Science - Availability backwards-compatibility with LAMP ON detection only.” The complete code listings of scripts mentioned in the paper are available in the Artifact Appendix of 3. the latest version of SAE J2497 1: “For tractor this paper https://doi.org/10.5281/zenodo.19664811. PLC units, it is recommended that the software With the exception of the QBinDiff analysis which implements only reception of the LAMP ON and will be made available later as ‘howto’ document pull OFF messages … All other reception of messages request to the Quarkslab QBinDiff repository docs. should be performed on other network types.” None of the firmware images used in the analysis will Given the potential for a) malicious J2497 signal inbe made available. The reverse engineering of this jection and b) compromised J2497-capable telematics work focused only on the machine code patched by 21 for tractor J2497 transmission the same sources recom- the firmware update. This work makes no claims on mended that the tractor mitigate attacks on older trailer equip- the presence nor absence of vulnerabilities in the rement; this patch does not appear to add any such mitigations. mainder of the firmware domains; hence, there is in14
sufficient guarantee of safety of sharing the firmwares. trolled environment, utilizing a closed test track for In lieu of the firmware, we provide the following in in-motion vehicle testing. All testing was performed the Artifact Appendix: with the explicit cooperation and support of an OEM, ensuring that safety protocols were rigorously fol1. disassembly listings (with instruction bytes inlowed and that no public roads or operational vehicles cluded) for the deleted and select modified funcwere subjected to unverified or potentially hazardous tions only conditions. 2. PID Handler and Context Tables deleted in the update 3. an .s19 file containing only the above plus the interrupt vectors for the application The ID9363 updater executable will not be made available because it contains copies of all the new firmware images.
References
[1] The ID9363 firmware update CAN logs will not be made available because they contain the entire updated firmware in the clear as well as seed-key exchange pairs which cannot be guaranteed to be insuf- [2] ficient to reconstruct the seed-key routines in closedform. [3]
Ethical Considerations This research prioritizes disclosure and minimizes potential harm. Prior to commencing the technical anal- [4] ysis, in early 2025, the manufacturer of the brake ECU was contacted and informed of our intent to conduct research on their firmware update for the [5] safety recall and requested to collaborate. Again, as the analysis neared completion, the manufacturer was contacted in an attempt to provide them with an overview of our findings. Two of the three OEMs have received the results in this paper. NHTSA and Transport Canada have also been informed of this [6] research and results. Crucially, this paper discusses only functions and vulnerabilities addressed by the manufacturer’s safety recall. Only deleted function code is shared. Limited side-by-side code modifications are shared to limit disclosure of code in the field. The PoC provided can be used to confirm RCE but does not disclose the details of CAN bus or other physical control by the ECU. The updated firmware has been deployed on ~310,000 units 12 at the time of this writing. These vulnerabilities are confirmed absent in updated firmware versions Z300822, Z302578, Z302579 (one for each affected OEM). Thus, disclosing these vulnerabilities introduces no new risks. By focusing on alreadypatched issues, this research aims to contribute to the broader understanding of automotive security without inadvertently exposing users to unmitigated risks.
[7]
[8]
[9]
[10]
Finally, the in-vehicle testing was conducted in a con15
SAE Truck and Bus Control and Communications Network Committee, “J2497 power line carrier communications for commercial vehicles.” Warrendale, PA, 2026. Federal motor vehicle safety standard no. 121, air brake systems. Washington, D.C.: National Highway Traffic Safety Administration. MITRE Corporation, “CVE-2020-14514.” 2020. Accessed: Nov. 2025. [Online]. Available: h t t p s : / / c v e . m i t r e . o r g / c g i bin/cvename.cgi?name=CVE-2020-14514 B. Gardiner, “Disclosure of confirmed remote write to J2497 aka PLC4TRUCKS,” NMFTA, Alexandria, VA, Letter, March, 2022. National Motor Freight Traffic Association, “Actionable mitigations options v9.” 2022. Accessed: Nov. 2025. [Online]. Available: https: //nmfta.org/wp-content/media/2022/11/Ac tionable_Mitigations_Options_v9_DIST.p df MITRE Corporation, “CVE-2022-26131.” 2022. Accessed: Nov. 2025. [Online]. Available: h t t p s : / / c v e . m i t r e . o r g / c g i bin/cvename.cgi?name=CVE-2022-26131 Bendix Commercial Vehicle Systems LLC, “24E086 chronology.” 2024. Accessed: Nov. 2025. [Online]. Available: https://static .nhtsa.gov/odi/rcl/2024/RMISC- 24E0865355.pdf ISO 14229: Road vehicles – unified diagnostic services (UDS). Geneva, Switzerland: International Organization for Standardization, 2020. PACCAR Incorporated, “Safety recall report 24V-915.” 2024. Accessed: Nov. 2025. [Online]. Available: https://static.nhtsa.gov/odi /rcl/2024/RCLRPT-24V915-6438.PDF Navistar, Inc., “Safety recall report 24V-818.” 2024. Accessed: Nov. 2025. [Online]. Available: https://static.nhtsa.gov/odi/rcl/2024/ RCLRPT-24V818-4283.PDF
[11]
[12]
[13]
[14]
[15]
[16]
[17]
[18]
[19]
[20]
Volvo Trucks North America, “Safety recall report 24V-790.” 2024. Accessed: Nov. 2025. [Online]. Available: https://static.nhtsa.gov /odi/rcl/2024/RCLRPT-24V790-3386.PDF National Highway Traffic Safety Administration, “NHTSA recalls by manufacturer.” Accessed: Nov. 2025. [Online]. Available: https: //datahub.transportation.gov/Automobiles /NHTSA- Recalls- by- Manufacturer/mu99t4jn National Highway Traffic Safety Administration, “Technical service bulletin 10194446.” 2024. Accessed: Nov. 2025. [Online]. Available: https://dot.report/bulletins/10194446 National Highway Traffic Safety Administration, “Technical service bulletin 10176745.” 2024. Accessed: Nov. 2025. [Online]. Available: https://dot.report/bulletins/10176745 National Highway Traffic Safety Administration, “Technical service bulletin 10222229.” 2024. Accessed: Nov. 2025. [Online]. Available: https://dot.report/bulletins/10222229 National Motor Freight Traffic Association, “Bendix EC80 recall: Safety and security implications.” 2025. Accessed: Jan. 2026. [Online]. Available: https://nmfta.org/bendixec80-recall-safety-and-security-implications/ Bendix Commercial Vehicle Systems LLC, “Safety recall report 25E-073.” 2025. Accessed: Nov. 2025. [Online]. Available: https: //static.nhtsa.gov/odi/rcl/2025/RCLRPT25E073-3346.pdf Land Line Media, “Defective bendix ECUs have prompted recall of nearly half a million trucks with latest paccar recall.” 2025. Accessed: Nov. 2025. [Online]. Available: https://landline.media/defective- bendixecus-have-prompted-recall-of-nearly-half-amillion-trucks-with-latest-paccar-recall/ Bendix Commercial Vehicle Systems LLC, “Technical bulletin TCH-27-007.” 2024. Accessed: Nov. 2025. [Online]. Available: https://www.bendix.com/media/servicesand-support/product-action-center-pdfs/tch _27_007_en_000.pdf Bendix Commercial Vehicle Systems LLC, “Technical bulletin TCH-27-006.” 2024. Accessed: Nov. 2025. [Online]. Available: https://www.bendix.com/media/servicesand-support/product-action-center-pdfs/tch _27_006_en_000.pdf
[21]
[22]
[23]
[24] [25]
[26]
[27]
[28]
[29]
[30]
[31]
[32]
16
Bendix Commercial Vehicle Systems LLC, “Technical bulletin TCH-27-008.” 2025. Accessed: Nov. 2025. [Online]. Available: https://www.bendix.com/media/servicesand-support/product-action-center-pdfs/tch27-008_en_000.pdf J1587: Electronic data interchange between microcomputer systems in heavy-duty vehicle applications. Warrendale, PA: SAE International, 2013. J1708: Serial data communications between microcomputer systems in heavy-duty vehicle applications. Warrendale, PA: SAE International, 2016. Intellon Corporation, SSC P485 PL transceiver IC data sheet. 1997. S. Behere, X. Zhang, V. Izosimov, and M. Törngren, “A functional brake architecture for autonomous heavy commercial vehicles.” 2016. Available: https://legacy.sae.org/publication s/technical-papers/content/2016-01-0134/ ISO 26262: Road vehicles – functional safety. Geneva, Switzerland: International Organization for Standardization, 2018. ZF Friedrichshafen AG, “mBSP XBS factsheet.” 2024. Accessed: Nov. 2025. [Online]. Available: https://www.zf.com/public/org/ ZF_CVS_mBSP_XBS_Factsheet_EN_296 135.pdf Vehicle Cybersecurity Working Group (VCRWG), National Motor Freight Traffic Association, “NMFTA vehicle cybersecurity requirements.” 2024. Accessed: Nov. 2025. [Online]. Available: https://github.com/nmfta- repo/nmftavehicle_cybersecurity_requirements B. Gardiner, J. Maag, and K. Tindell, “Security requirements for vehicle security gateways,” SAE International, 2024-01-2806, 2024. Accessed: Nov. 2025. [Online]. Available: https://www.sae.org/papers/security-requ irements-vehicle-security-gateways-2024-012806 NXP Semiconductors, “MC9S12XEQ512 data sheet.” Accessed: Nov. 2025. [Online]. Available: https://www.nxp.com/docs/en/datasheet/MC9S12XEP100.pdf NXP Semiconductors, “MC9S12XE family reference manual.” Accessed: Nov. 2025. [Online]. Available: https://www.nxp.com/docs /en/reference-manual/MC9S12XERM.pdf ELDB, “XPROG-box.” Accessed: Nov. 2025. [Online]. Available: https://www.eldb.eu/
[33]
[34]
[35]
[36]
[37]
[38]
[39] [40] [41]
[42] [43] [44]
[45]
[46]
PEmicro, “PROGS12Z flash programmer software.” Accessed: Nov. 2025. [Online]. Available: https://www.pemicro.com/ Motorola, “Motorola s-record description (PDF).” Accessed: Nov. 2025. [Online]. Available: https://deramp.com/downloads/mfe_a rchive/060-Standards%20and%20Specificatio ns/Hex%20Data%20Formats/Motorola%20S %20Record.pdf DARPA, “Assured micropatching (AMP).” Accessed: Nov. 2025. [Online]. Available: https://www.darpa.mil/program/assuredmicropatching J1939: Serial control and communications heavy duty vehicle network. Warrendale, PA: SAE International, 2018. C. Miller and C. Valasek, “Adventures in automotive networks and control units,” IOActive, 2014. Accessed: Nov. 2025. [Online]. Available: https://www.ioactive.com/wpcontent/uploads/pdfs/IOActive_Adventur es_in_Automotive_Networks_and_Contro l_Units.pdf Pulse Security, “Reversing the ducati 696 ECU part 2.” 2022. Accessed: Nov. 2025. [Online]. Available: https://pulsesecurity.co.nz/articles /ducati-696-part2 National Security Agency, Ghidra. (2025). Available: https://ghidra-sre.org/ Hex-Rays, IDA pro. (2026). Available: https: //hex-rays.com/ida-pro/ hotwolf, HSW12. Accessed: Nov. 2025. [Online]. Available: https://github.com/hotwolf /HSW12 NXP Semiconductors, HiWave debugger. 2010. Zynamics, BinDiff. Available: https://www. zynamics.com/bindiff.html M. Krzywinski, I. Birol, S. J. Jones, and M. A. Marra, “Hive plots—rational approach to visualizing networks,” Briefings in bioinformatics, vol. 13, no. 5, pp. 627–644, 2011. R. Cohen, R. David, R. Mori, F. Yger, and F. Rossi, “Improving binary diffing through similarity and matching intricacies,” in Proc. Of the 6th conference on artificial intelligence for defense, 2024. A. One, “Smashing the stack for fun and profit,” Phrack Magazine, vol. 7, no. 49, 1996, Available: http://phrack.org/issues/49/14.ht ml
[47]
[48]
[49]
[50]
[51]
[52] [53]
[54]
[55]
[56]
[57]
[58]
[59]
17
National Motor Freight Traffic Association, “j2497-keyhole.” Accessed: Nov. 2025. [Online]. Available: https://github.com/nmftarepo/j2497-keyhole Masterjun, “Super mario world ”total control” TAS.” 2014. Accessed: Nov. 2025. [Online]. Available: https://tasvideos.org/2513M T. Yapo, “FL2K experiments.” Accessed: Nov. 2025. [Online]. Available: https://hackaday.i o/project/164346-fl2k-sdr Osmocom, “Osmo-FL2k project.” Accessed: Nov. 2025. [Online]. Available: https: //osmocom.org/projects/osmo-fl2k python-can Developers, Python-can. (2024). Available: https://python-can.readthedocs. io/ E. Evenchick, “CANtact.” Accessed: Nov. 2025. [Online]. Available: https://cantact.io/ B. Gardiner, “Mitigating PLC4TRUCKS remote write,” in Proceedings of the 9th escar USA conference, Ypsilanti, MI: escar, 2022. Available: https://escar.info/downloads R. Tsang, D. Joseph, S. Salehi, et al., “FFXE: Dynamic control flow graph recovery for embedded firmware binaries,” in 33rd USENIX security symposium (USENIX security 24), 2024, pp. 5573–5590. A. Marcelli, M. Graziano, X. Ugarte-Pedrero, Y. Fratantonio, D. Balzarotti, and A. Francillon, “How machine learning is solving the binary function similarity problem,” in USENIX security symposium, 2022. E. Mengin and R. David, “QBinDiff : Un outil de diffing binaire flexible et modulaire,” in SSTIC 2020 (symposium sur la sécurité de l’information et des communications), 2020. J. Ruge, J. Classen, F. Gringoli, and M. Hollick, “Frankenstein: Advanced wireless fuzzing to exploit new bluetooth escalation targets,” in USENIX security symposium, 2020. K. Koscher et al., “Experimental analysis of a modern automobile,” in 2010 IEEE symposium on security and privacy, 2010. B. Hass, Y. Burakova, L. Millar, and A. Weimerskirch, “Truck hacking: An experimental analysis of the SAE J1939 standard,” in 10th USENIX workshop on offensive technologies (WOOT 16), Austin, TX: USENIX Association, 2016.
[60]
[61]
[62]
[63]
[64]
[65]
[66] [67]
[68]
[69] [70]
[71]
[72]
R. Chatterjee, C. Green, and J. Daily, “Exploiting diagnostic protocol vulnerabilities on embedded networks in commercial vehicles,” in Symposium on vehicles security and privacy (VehicleSec), 2024. ISO/IEC 29147: Information technology – security techniques – vulnerability disclosure. Geneva, Switzerland: International Organization for Standardization, 2018. Cybersecurity and Infrastructure Security Agency, “Shifting the balance of cybersecurity risk: Principles and approaches for securityby-design and -default,” 2023. Accessed: Nov. 2025. [Online]. Available: https://www.ci sa.gov/resources- tools/resources/shiftingbalance-cybersecurity-risk-principles-andapproaches-security-design-and-default Technology & Maintenance Council, “Position paper 2024-3: Next generation tractor-trailer technical needs,” American Trucking Associations, 2024. Accessed: Nov. 2025. [Online]. Available: https://tmc.trucking.org/sites/def ault/files/TMC_PP-2024_3_NEXTGEN_T RACTOR_TRAILER_TECHNICAL_NEE DS%20.pdf Cybersecurity and Infrastructure Security Agency, “ICS advisory (ICSA-25-021-03) bendix EC-80.” 2025. Accessed: Nov. 2025. [Online]. Available: https://www.cisa.gov/n ews-events/ics-advisories/icsa-25-021-03 Google DeepMind, “Gemini: A family of highly capable multimodal models.” 2023. Accessed: Nov. 2025. [Online]. Available: https: //deepmind.google.com/technologies/gemini/ J. MacFarlane, Pandoc. (2026). Available: ht tps://pandoc.org/ J. D. Hunter, “Matplotlib: A 2D graphics environment,” Computing in science & engineering, vol. 9, no. 3, pp. 90–95, 2007. Hiveplotlib Developers, Hiveplotlib. (2025). Available: https://github.com/hiveplotlib /hiveplotlib Quarkslab, Quokka. (2024). Available: https: //github.com/quarkslab/quokka Python Software Foundation, Python programming language. (2026). Available: https: //www.python.org/ TruckHacking organization (originally by Haystack), Py‑hv‑networks. (first published 2016). Available: https://github.com/Tru ckHacking/py-hv-networks dfieschko, RP1210. (2019). Available: https: //github.com/dfieschko/RP1210
[73] [74] [75] [76]
18
LinkerScope Developers, LinkerScope. K. Sveidqvist, Mermaid. (2026). Available: https://mermaid.js.org/ Graphviz Authors, Graphviz. (2026). Available: https://graphviz.org/ Wireshark Foundation, Wireshark. Available: https://www.wireshark.org/
A
Appendix: ID9363 Update 1. Tester Present Process Further Details
The update process is executed by the ID9363 updater executable, where we captured the J1939 36 traffic sent between it and the target ECU. The update process uses UDS 8 on J1939 36; in all cases we observed the traffic was unicast, default priority, between the vehicle diagnostic adapter at address 0xF9 and the brake controller at 0x0B: resulting in the two extended (29-bit) CAN IDs 0x18DA0BF9 and 0x18DAF90B. The CAN traffic was filtered on those two IDs and processed with Wireshark 76 to reconstruct the ISO-TP multi frame messages used by UDS and then these were analyzed to reconstruct the ID9363 update process, a simplified summary of which is reproduced in Table A.1:
2. Read DIDs (Start)
3. Auth to Programming
4. Fingerprint
5. Download Block 1 of 2
6. Download Block 2 of 2
7. Checksum & Reset
8. Auth to Programming
9. Download Dataset
10. Checksum & Reset
11. Auth to Extended
12. Write Proprietary DID
13. Write Customer PN
14. Auth to Extended
15. Write Proprietary ’Revision’ DID
16. Update Proprietary DID 17. Auth to Extended
18. ’Commit Step’ & Reset
19. Clear DTCs 20. Read DIDs (End)
2x Tester Present requests; many more periodically and all omitted below. Read Data By Identifier requests for: 0xF18A, 0xF192, 0xF18C, 0xF194, 0xFDEA, 0xFDA0, 0xFDE8. Diagnostic Session Control (0x02) followed by Security Access (0x05) seed-key exchange. Write Data By Identifier (0xF184) to record Tool ID (contains ”ID9363”). Always follows auth step; omitted in the following. RoutineControl (Erase), RequestDownload, TransferData. Writes 0x68800 bytes to PFLASH (0x780000 - 0x7E8800). RoutineControl (Erase), RequestDownload, TransferData. Writes 0x3800 bytes to PFLASH (0x7FC000 - 0x7FF7FF). RoutineControl (0xFF01 checkProgrammingDependencies) without any extra parameters, followed by Hard Reset. Re-enter Programming Session (0x02) followed by Security Access (0x05). And fingerprint. RoutineControl (Erase), RequestDownload, TransferData. Writes 0xC00 bytes of dataset/calibration data to EEE buffer at 0x13F400. RoutineControl (0xFF01) with extra parameters, followed by Hard Reset. Enter Extended Session (0x03) followed by Security Access (0x01). And fingerprint. Write Data By Identifier (0xFDA0) with values from Step 2. Write Data By Identifier (0xF191 vehicleManufacturerECUHardwareNumberDataIdentifier). Enter Extended Session (0x03) followed by Security Access (0x07). And fingerprint. Write Data By Identifier (0xFDEA) with revision data (e.g., ’R011’). Read and Write Data By Identifier (0xFDE8). Enter Extended Session (0x03) followed by Security Access (0x03). And fingerprint. Proprietary Requests: 0xFE5C, 0xFE5D, 0xFE6A followed by hard reset. Read Data By Identifier requests (0xF192, 0xF194, 0xFDEA, 0xF18C) to verify update.
Table A.1: ID9363 Update Process Steps.
19
B
Appendix: J2497 Reception byte is consumed by the callers, all error information is discarded. This means that all error detection is deArchitecture of EC80 ferred to the correct checksum calculation described
The reception is driven by events from the SCI2 and previously. PIT hardware peripherals as illustrated in Figure B.3, PIT being used to manage timeouts. SCI2 is a UART that supports several interrupt event types and the receiver state machine makes use of ‘data ready’ (RDRF), IDLE, and edge (RXEDGIF) events. The entire state machine is distributed over several functions which all access address 0x3C52, a set of control bitfields, summarized in Table B.1. Bit Mask
Control Name
Function Address(es)
0x01 0x02 0x04
PENDING IGNORE_RX TIMEOUT
0x08
BUF_DONE
0x10 0x20
BUF_FULL EDGE_TRIG
sub_EBBE13 sub_EBBB47 sub_EBBB47, sub_EBBE13, sub_EC80B5, sub_EBBEDB sub_EBBB47, sub_EBBE13, sub_EC80B5 sub_EBBB47, sub_EC803E sub_EC80D0, sub_EC80F8, sub_EBBEDB
via sub_EC8000 sub_F1AFA7
The state machine maintains a running checksum on every byte received and will mark a complete frame on an IDLE event if the checksum is correct and the frame length is between 3 and 21 (inclusive), matching the J1708 specification’s 23 “Total message length, including MID and checksum, shall not exceed 21 characters.” 22 The state machine injects the length of the received frame minus 1 into the receive buffer 0x3BF5 at the byte preceding the current received frame (e.g., index 0 for the first frame) and increments the frame counter 0x3BF4. Further frames are stacked in this receive buffer for First-In, First Out (FIFO) processing outside the interrupt context up to a maximum size of 0x54 bytes (combined data and injected frame lengths).
sub_C12B
(SCI2 ISR/Handler) via various sub_EBBB47
(Main State Machine) Handles: RX, Idle, Timeout Byte Received Pass Byte (B Reg) sub_EC803E
(SCI2 Data Read and Error Checking)
(Append Rx Buf)
Read Data
Write Byte
Hardware Registers
Table B.1: All control bits of the state tracked at address 0x3C52 and its client functions.
Interrupt Context
SCI2_DRL (Data Register Low)
Increment on Frame Complete
Local Memory - RAM FIFO Receive Buffer Addr: 0x3BF5 (J2497 Frame Data)
Frame Counter Addr: 0x3BF4 (Semaphor)
Figure B.1: Diagram focusing on the dataflow of received J2497 data in the 2ec80 target. See Figure B.3 for the details which are omitted here. The J2497 frame reception is realized by a state machine driven by the events as described above. . As detailed in Section 6, the dataflow is straightforward: frames are appended to a receive buffer at 0x3BF5, and completion is signaled via the frame counter at 0x3BF4 (see Figure B.1).
There are two reads of the SCI2 Data Register Low (DRL), the first (in the ISR) is a necessary hardware ‘handshake’ to satisfy the peripheral’s requirement of two reads to clear its state, the real data read occurs within the state machine in sub_F1AFA7; it reads the data and catalogs all the errors which are detected by any given UART peripheral 23 – but only the data 22 although, according to the spec: >= 21 bytes is permitted when the vehicle is not in motion. 23 This function, like many others encountered, accepts a ‘device index’ argument. While other firmwares use non-zero indices for the J1708 interface, all target firmwares use index 0 for SCI2/J2497. Fortunately, this simplifies structure access and reduces to direct offsets, facilitating data xref analysis.
20
Local Memory
RAM FIFO Receive Buffer Addr: 0x3BF5 (J2497 Frame Data)
Frame Counter Addr: 0x3BF4 (Semaphor)
Read
PFLASH PID Handlers Table Addr: 0xD9DD (via Context 0xDC3D)
Post-Processing Table Addr: 0xD87D (via Context 0xDC3D)
Read (Polling) Main Thread sub_EEB989
Read Base Addr Calculate Offset
Read Table Rows
(check LAMP ON OFF and ABS event)
Indirect Read via PayloadPtr
Fall-through Call
Read Table Rows
sub_F096F9
(PID payload splitting and periodic postprocessing) Call (Pass PayloadPtr: SP+0x17, Len: SP+0x13)
e.g. Call e.g. sub_ECBB3A (send PID 0xC4 DTC Counts)
sub_F2A3E1
(dispatch each PID payload) e.g. Call e.g. sub_F1B623 (PID 0xC2 Handler)
Figure B.2: Diagram focusing on the dataflow of received J2497 messages in the 2ec80 target. This diagram picks up where Figure B.1 left off.
21
Hardware Registers SCI2_ASR1 (Alt Status Register 1)
SCI2_DRL (Data Register Low) Read Status
PIT Hardware Channel 1 Timer
SCI2_SR1 (Status Register 1)
SCI2 Interrupt
Handshake Read Status
Read Status
IVBR=0xF7 Interrupt Context
sub_C12B (SCI2 ISR/Handler)
RXEDGIF Branch Poll ASR1 (AMAP=1) If RXEDGIF=1 & RXEDGIE=1
Read Data
RDRF Branch Poll SR1 If RDRF=1 & RIE=1
IDLE Branch Poll SR1 If IDLE=1 & ILIE=1
via sub_F1B001 &
via sub_F1B01B &
Arg: 0x00 (RX)
Arg: 0x01 (Idle)
sub_EC80EF
sub_EC80D0
sub_C93F
(PIT Ch1 Handler)
Timeout via sub_EC80DE Arg: 0x02 (Timeout)
sub_EBBB47
(Main State Machine) Handles: RX, Idle, Timeout via sub_EC8000 via sub_F1B035 & sub_EC8106
sub_F1AFA7
Frame/Timeout sub_EC81C7
(SCIX Data Read and Error Checking)
(Disable PIT & Call) Byte Received Pass Byte (B Reg) Increment on Frame Complete
sub_F3A2F1
(Check Counter & Call)
sub_EFBC09
sub_EC803E
(Stateful UART data parser)
(Append Rx Buf)
Write
Write Byte Local Memory RAM
Parser State Data Addr: 0x476E (parsing progress) Addr: 0x476F (buffer index) Addr: 0x4770 (status byte)
FIFO Receive Buffer Addr: 0x3BF5 (J2497 Frame Data)
Frame Counter Addr: 0x3BF4 (Semaphor)
Figure B.3: Dataflow diagram visualization of the handling of J2497 UART peripheral events: edge, idle, data and also of PIT peripheral events used for timeouts.
22
C
Appendix: J1587 PID Processing
The PID (number) is the first byte of the PID payload and this is used to match a handler in PID handler tables at 0xD9DD (see Table C.2) along with a secondbyte match (which can be 0xFF for a wildcard). This table is accessed via a pointer in a ‘context structure’ (see Table C.4) and the PID handlers row can set a nested-context structure for any matched PID and second-byte match (e.g. this is how 0xFE data link escapes are handled in the firmware). The function, sub_F096F9, also looks up periodic processing functions after the PIDs are processed. It uses an assumption of the rate it will be called by the parent functions and a per-device count to fire periodic processing calls at rate and phase configured in the table linked from offset 0xB in the context structure. The call rate is 20Hz because sub_EEB98 contains an implementation of the J2497 lamp hysteresis specification in state variables word_FD126F and flag 0x10 of byte_4466; the values taken by word_FD126F only match the specification if the function is called at 20Hz. It also follows from this that the non-LAMP PID processing only consumes one J2497 frame per 50ms. The context structure C.4 holds pointers to the PID handlers and post-processing tables and total sizes (the post-processing entries are zero in the nested context structures). It also holds a limit for the clockcounter in post-processing (also unused in nested contexts) and a default handler when no PID is matched (implemented as a null subroutine in the firmwares). The function pointers in these structures were already picked up by the automated function pointer discovery discussed above. Several pointed at the same address but there were unique and non-trivial handlers. We wrote a script to walk the table and name the functions with the information gleaned from the table context e.g. “pid_FF_any_default_OR_pid_FE_88_de fault_OR_pid_80_any_default_OR_pid_00_any_ default_OR_nullsub_2_OR_pid_default_handler .” See Appendix C.0.5 for the script used. The recursive tables were analyzed in all three before-update firmwares and the PIDs supported were found to be the same. The supported PIDs are in Table C.1. Note that ‘supported’ here means that the target ECU will parse incoming payloads of these PIDs; in all cases on J2497 there is no response emitted (whereas there might be on J1708 interface).
23
J1708 message
PID / PID Request Description
Data Input Size
mm0031 / mm803188
Request for 0x31 49 ABS Control Status
one byte data (broadcast req) / zero bytes data (unicast req) one byte data / zero bytes data one byte data / zero bytes data one byte data / zero bytes data one byte data / zero bytes data
mm003E / mm803E88 mm0054 / mm805488 mm0097 / mm809788 mm009E / mm809E88
mmC303 mmC7
Request for 0x3E 62 Retarder Inhibit Status Request for 0x54 84 Road Speed Request for 0x97 151 TC Control State Request for 0x9E 158 Battery Potential (V), Switched Request for 0xA8 168 Battery Potential (V) Request for 0xC2 194 Transmitter System Diagnostic Code and Occurrence Count Table Request for 0xC4 196 Diagnostic Data/Count Clear Response Request for 0xC7 199 Traction Control Disable State Request for 0xD1 209 ABS Control Status, Trailer Request for 0xD6 214 Vehicle Wheel Speeds Request for 0xE9 233 Unit Number (Power Unit) Request for 0xEA 234 Software Identification Request for 0xED 237 Vehicle Identification Number Request for 0xF3 243 Component Identification 42 Pressure Switch Status 70 Parking Brake Switch Status 84 Road Speed 117 Brake Primary Pressure 118 Brake Secondary Pressure 169 Cargo Ambient Temperature 180 Trailer Weight 194 Transmitter System Diagnostic Code and Occurrence Count Table 195 Diagnostic Data Request / Clear 199 Traction Control Disable State
mmD1
209 ABS Control Status, Trailer
mmED
237 Vehicle Identification Number
mmF5 mmF7 mmFE88C5 / mmFE88C6 mmFF73 mmFF7B
245 Total Vehicle Distance 257 Total Engine Hours 254 Proprietary DLE 115 Trailer Pneumatic Supply Line Pressure 123 Door Status
mm00A8 / mm80A888 mm00C2 / mm80C288 mm00C4 / mm80C488 mm00C7 / mm80C788 mm00D1 / mm80D188 mm00D6 / mm80D688 mm00E9 / mm80E988 mm00EA / mm80EA88 mm00ED / mm80ED88 mm00F3 / mm80F388 mm2A mm46 mm54 mm75 mm76 mmA9 mmB4 mmC2
one byte data / zero bytes data one byte data / zero bytes data one byte data / zero bytes data one byte data / zero bytes data one byte data / zero bytes data one byte data / zero bytes data one byte data / zero bytes data one byte data / zero bytes data one byte data / zero bytes data one byte data / zero bytes data 1 byte data 1 byte data 1 byte data 1 byte data 1 byte data 2 bytes data 2 bytes data variable bytes data. byte count, followed by sets of diagnostic data 3 bytes data variable length data. byte count, state flags, ASCII ’access code’ of 0-15 characters selected by the manufacturer ... variable bytes data, up to 3x5 bytes for 5 trailers byte count, followed by the status bytes variable bytes data. byte count, followed by the VIN ASCII 4 bytes data 4 bytes data permitted lengths of only 0xC5 and 0xC6 one byte data one byte data
Table C.1: J1587 PIDs supported by the before update firmware. ’mm’ refers to any MID value except 0A, 0B, or 57, which are handled earlier in processing.
24
Offset
Size
Description
0x00 0x01
1 1
0x02 0x05 0x06
3 1 2
Primary identifier for the PID. Secondary identifier (0xFF indicates a wildcard/any). 24-bit pointer to the handler function. Unused byte. 16-bit word. If non-zero, it is treated as a pointer to a nested Context Structure (see Table C.4) for recursive matching and processing of the next bytes in the payload.
Table C.2: PID Handler data structure.
Offset
Size
Description
0x00
2
0x02
2
0x04 0x07
3 1
Used to calculate execution rate (Base 20Hz). Rate = 20 / Divisor. Used to calculate execution phase/offset. Phase = Remainder * 50ms. 24-bit pointer to the handler function. Unused byte.
Table C.3: Post Processing data structure.
Offset
Size
Description
0x00
2
0x02
2
0x04
3
0x07 0x08
1 2
0x0A 0x0B
1 1
16-bit pointer to the PID Table array. See Table C.2 16-bit pointer to the Post Processing Table array. See Table C.3 24-bit function pointer invoked if no PID match is found. Unused byte. 16-bit word (likely a limit for a device counter). Number of entries in the PID Table. Number of entries in the Post Processing Table.
Table C.4: Context (and nested context) data structure.
25
Appendix: Code Listings In this section we provide code listings for the scripts mentioned in the paper. These are standalone scripts produced by inlining functions from an idapython ec80-specific analysis library which runs completely automatically to create the before and after images of all 3 of the targets and then performs the qbindiff analysis and produces the plots in this paper. We are not releasing that script because it contains many dependencies on the specifics of the EC80 and hence also ‘leaks’ potentially attacker-beneficial information. C.0.1
IDA Pro Python Script: PFLASH and PPAGE Setup
This script sets up the memory map for the S12X processor in IDA Pro, handling the PFLASH and PPAGE banking. See file ida-pflash-s12x-setup.py in the paper artifacts. C.0.2
IDA Pro Python Script: Concolic Analysis
This script performs a basic concolic analysis to resolve indirect calls. See file ida-concolic-s12x-resolve.py in the paper artifacts. C.0.3
IDA Pro Python Script: Jump Table Detection
This script detects and creates jump tables by parsing the disassembly and creating manual code xrefs. See file ida-jumptables-s12x-resolve.py in the paper artifacts. C.0.4
IDA Pro Python Script: Function Pointer Discovery
This script scans the firmware image for potential function pointers to identify additional functions. See file ida-funcptr-s12x-discovery.py in the paper artifacts. C.0.5
IDA Pro Python Script: PID Handler Naming
This script walks the PID handler tables and names the handler functions based on the PID and context. See file ida-pid-ec80-naming.py in the paper artifacts. C.0.6
IDA Pro Python Script: Call Tree Validation
This script validates the call tree to identify deleted functions. See file ida-deletedfn-report.py in the paper artifacts. C.0.7
Fuzzing Script: J1587 PID Fuzzer
This script was used to fuzz the J1587 PID handlers and discover the vulnerabilities in the 0xC2 and 0xED PID Handlers. See file j1587-pid-fuzzer.py in the paper artifacts. C.0.8
In-motion Test Script: 0xC2 PID Handler
This script was used to trigger the 0xC2 vulnerability during in-motion tests. It emits the test signal on an attached FL2K SDR. It expects the j2497-keyhole 47 project is installed as a package or that the script runs from the same directory as the project. See file j2497-sdr-badones-transmit.py in the paper artifacts. 26
C.0.9
In-motion Test Script: 0xED PID Handler
This script was used to trigger the 0xED vulnerability during in-motion tests. Same script as listing C.0.8; uncomment the desired payload. C.0.10
HiWave Script: Memory Dump
This script uses the HiWave scripting interface to dump memory to a file. NOTE: you must set the hiwave command window’s cache limit to unlimited before running the script/commands below: DMM CACHINGOFF DMM WRITEREADBACKOFF HCS12X_MAP4000 RAM db 0x4000'L..0x7FFF'L db 0x0f8000'G..0x0FBFFF'G
Appendix: Disassemblies REDACTED FOR PREPRINT
27