Critical infrastructure networks are saturated with embedded devices whose vendors no longer provide security updates. PLCs, RTUs, network switches, and specialised controllers operating at the firmware level are frequently two to four product generations behind current releases. In many cases, the original manufacturer has been acquired, dissolved, or simply discontinued the product line without providing migration pathways. These end-of-life devices remain operational because replacing them would require extensive re-engineering of control loops, recertification of safety systems, and capital expenditure that budget cycles cannot accommodate. The result is a growing population of unpatched, vulnerable firmware executing within the most sensitive operational environments.
Reverse-Engineering Proprietary Firmware
When vendor support is unavailable, the only path to vulnerability remediation is direct firmware analysis. This process begins with acquiring a firmware image, typically through JTAG/SPI extraction or by intercepting update mechanisms still present in the firmware itself. Static analysis tools such as Ghidra and Radare2 are used to disassemble the binary, identify the bootloader architecture, and map the filesystem layout. The objective is to locate vulnerable library functions, hardcoded credentials, and insecure protocol implementations that cannot be addressed at the network layer alone. This is painstaking work that requires deep familiarity with embedded architectures, compiler toolchains, and the specific quirks of real-time operating systems like VxWorks, QNX, and proprietary RTOS variants.
Kernel-Level Patch Development
Once vulnerable code paths are identified, patches must be developed at the binary level. This involves identifying the precise memory offsets of the vulnerable functions, crafting replacement machine code that fits within the original code segment's constraints, and recalculating checksums and signature blocks that the bootloader validates during the boot sequence. In environments where secure boot is enforced, this requires either obtaining the signing key (impossible in most cases) or developing a custom bootloader that bypasses the chain of trust. Hardware validation across board revisions is critical: firmware compiled for one hardware revision may reference different memory-mapped I/O addresses or peripheral registers, causing silent failures or dangerous undefined behaviour if deployed on incompatible hardware.
Deployment Without Downtime
The deployment of custom-patched firmware in operational technology environments demands zero-downtime execution. This typically requires a dual-bank flash architecture where the patched image is written to the inactive bank while the device continues operating from the active bank. A controlled switchover is then executed during a minimal interruption window, with immediate rollback capability if health checks fail. Kryvasis has developed proprietary deployment tooling that orchestrates these firmware updates across fleets of heterogeneous devices, maintaining operational continuity while achieving comprehensive patch coverage.
The vendor abandonment problem will not resolve itself. As the installed base of end-of-life embedded devices continues to grow, organisations that cannot develop internal capability for firmware-level security will be forced to accept residual risk that regulators and threat actors alike will not tolerate.