embedded-rtos-security

Skill: Embedded RTOS Security

Supplementary Files:

• payloads.md — Command catalogue for VxWorks WDB RPC/Wind debug agent exploitation (Urgent/11 CVEs CVE-2019-12256/12258/12260, IPstack flaws), QNX Neutrino Qnet/qconn/procfs exploitation, FreeRTOS+TCP CVE-2018-16528 stack attacks, ThreadX/Azure RTOS bug matrix, Zephyr Kconfig/Bluetooth host CVEs, Mbed OS uVisor/Pelion, TI-RTOS/BIOS, MicroC/OS-II/III, NuttX, RIOT, Contiki-NG, plus hardware attack surfaces (JTAG/UART/SWD enumeration via JTAGulator/Shikra/J-Link/Black Magic Probe, OpenOCD target control, voltage/clock glitching via ChipWhisperer/NewAE, side-channel analysis with GreatFET/HydraBus/Bus Pirate) — 11 sections, 60+ code blocks.
• test-cases.md — Structured test cases (lab bring-up, JTAG/UART enumeration, OpenOCD target attach, VxWorks WDB RPC fingerprint/exploit, FreeRTOS+TCP CVE PoC, QNX qconn/procfs enumeration, Zephyr Bluetooth host stack fuzz, ChipWhisperer voltage glitch on secure boot, RTOS binary static analysis with Ghidra/IDA, scheduler priority inversion, Renode system emulation, MPU bypass via heap corruption) — 12 cases across 6 categories.
• guides/embedded-rtos-security-playbook.md — End-to-end RTOS red team playbook covering architecture comparison (monolithic kernel vs microkernel vs real-time executive), the full RTOS attack surface map (debug agent, network stack, IPC, scheduler, MMU/MPU), real CVE deep dives (VxWorks Urgent/11 by JSOF 2019, FreeRTOS+TCP by Zimperium 2018, Zephyr Bluetooth 2019-2023), hardware lab setup (JTAGulator, Shikra, J-Link, ST-Link, Black Magic Probe, OpenOCD, Bus Pirate, GreatFET), glitching rig (ChipWhisperer, NewAE, GlitchIP), emulation (Renode, QEMU system, angr symbolic execution), defensive guidance (MPU/MMU enablement, stack canaries, ASLR-on-MCUs, secure boot), RTOS MITRE ATT&CK for Cloud + ICS mapping, and RTOS secure boot + Trusted Execution Environment (TEE) analysis.
• guides/embedded-rtos-security-deep-dive.md — Hands-on VxWorks WDB RPC exploitation lab: WDB RPC protocol reverse engineering, MODE_ANY unauthenticated escalation, memory read/write primitives via wdbCtxRead/wdbCtxWrite, task spawn RCE via wdbTaskSpawn, four Urgent/11 CVE PoCs (CVE-2019-12256/12258/12260/12264), QEMU lab setup, Wireshark Lua dissector for WDB RPC, network-level detection and defense bypass, three capture-the-flag scenarios with progressive difficulty.
• guides/freertos-tcp-vulnerability-research.md — FreeRTOS+TCP CVE reproduction and fuzzing lab: POSIX simulator build with TAP networking, IP-task architecture and heap_4.c internals, four Zimperium 2018 CVE PoCs (CVE-2018-16525/16528/16529/16603), AFL harness for IP-task packet fuzzing, angr symbolic execution for variant discovery, Diaphora and Ghidra BSim patch diffing methodology, field hardening for devices that cannot upgrade.

Summary

Real-Time Operating System (RTOS) security covers the exploitation of deterministic operating systems used in safety-critical and embedded devices — VxWorks, QNX Neutrino, FreeRTOS (+ FreeRTOS+TCP), ThreadX/Azure RTOS, Zephyr, Arm Mbed OS, TI-RTOS/SYS/BIOS, MicroC/OS-II and III, NuttX, RIOT OS, and Contiki-NG. These operating systems are the runtime for avionics (ARINC-653 partitions on VxWorks 653 and LynxOS-178), automotive ECUs (QNX on multiple IVI platforms, AUTOSAR OS on OSEK derivatives), industrial controllers (VxWorks, MicroC/OS on PLCs, RTU/IED firmware), medical devices (ThreadX on infusion pumps, QNX on MRI consoles), IoT networking gear (FreeRTOS on consumer routers and Zigbee radios, Zephyr on 802.15.4 sensors), and aerospace/military systems (VxWorks, INTEGRITY-178B, Deos). Unlike a general-purpose OS, an RTOS sacrifices isolation for determinism: a single memory corruption, debug-agent exposure, or scheduler flaw often gives the attacker direct code execution in the highest-privilege supervisor/handler mode on the device.

Tools: IDA Pro, Ghidra, Binary Ninja, radare2/r2macho, OpenOCD, J-Link/ST-Link/Black Magic Probe/JTAGulator/Shikra, binwalk/firmwalker/FACT, QEMU system/Renode, angr, ChipWhisperer (NewAE), GreatFET/HydraBus/Bus Pirate, flashrom, strace/ltrace/perf.

Domain: embedded-rtos-security

MITRE ATT&CK: T1548-Abuse Elevation Control Mechanism (MPU bypass, debug agent escalation), T1068-Exploitation for Privilege Escalation (scheduler, kernel), T1055-Proccess Injection (task corruption, heap spray), T1049-System Network Connections (WDB RPC, qconn discovery), T1210-Exploitation of Remote Services (RTOS network stack), T1499-Endpoint Denial of Service (priority inversion, RTO deadlock)

Description

An RTOS is the OS layer between the silicon and a deterministic application: where a general-purpose OS optimizes for fairness, throughput, and isolation, an RTOS optimizes for guaranteed worst-case latency, predictable scheduling, and minimal interrupt jitter. That mandate produces four architectural properties that shape every attack in this domain:

1. Determinism over isolation. The kernel reserves CPU time slices via fixed-priority preemptive scheduling (rate-monotonic in VxWorks, EDF in some MicroC/OS-III deployments, priority inheritance for bound priority inversion in POSIX/QNX). Tasks share the same flat address space more often than not — MicroC/OS-II has no MMU support, FreeRTOS is MMU-optional until V10.3+, and even QNX's microkernel pays a per-message context-switch tax that many IoT deployments trade away by running everything in kernel mode. A single task compromise is, in many RTOS deployments, a full-device compromise.

2. Debug agents as the standard remote attack surface. Every major RTOS ships a debug agent intended for development: VxWorks has WDB (Wind River Debug Agent) exposed over UDP port 17185 speaking the Wind River Debug RPC protocol; QNX has qconn on TCP 8000 used by Momentics and the QNX System Information Viewer; FreeRTOS Plus has TCP-only GDB stubs enabled by default in vendor SDKs; ThreadX has NetX Debug Agent and Azure RTOS adds the ThreadX TraceX server; TI-RTOS ships ROV (Runtime Object Viewer) accessible over UART/Ethernet. These agents were never intended for production, but OEM shipping profiles routinely leave them listening on the WAN interface. The 2019 Urgent/11 vulnerabilities (JSOF, CVE-2019-12256 stack overflow in the WBD RPC parser, CVE-2019-12258 Memory Pool Allocator overflow, CVE-2019-12260 DHCPv4 client overflow) demonstrated that the WDB agent and the WIND IP stack together expose unauthenticated, remote-code-execution attack surface on over 200 million devices — including Schneider Electric Modicon PLCs, OTN systems in healthcare, and multiple aerospace platforms.

3. The network stack is the kernel. On VxWorks the WIND IP stack runs in kernel context. On FreeRTOS the FreeRTOS+TCP stack (FreeRTOS_IP.c, FreeRTOS_Sockets.c, FreeRTOS_DHCP.c) runs in a single "IP-task" with kernel-equivalent privileges. On Zephyr the networking subsystem lives in the kernel's net_core context. A buffer overflow in any of these is a kernel-mode RCE — there is no userland boundary to fall back to. The 2018 Zimperium disclosures (CVE-2018-16528 FreeRTOS_SendPing heap overflow, CVE-2018-16529 FreeRTOS_recvfrom do-not-fragment handling, CVE-2018-16525 IP fragmentation UAF, CVE-2018-16603 TCP SYN queue overflow) demonstrated unauthenticated, single-packet RCE across an estimated 4 billion FreeRTOS+TCP-enabled devices.

4. The hardware is part of the threat model. Real-time devices ship with JTAG/SWD/ETM debug interfaces, UART consoles, and unprotected external flash because they are mandatory for factory programming and field debug. Even when secure boot closes the "flash via JTAG" path, the underlying silicon primitives — ARM's Debug Authentication Mode (DAM), the JTAG-DP DPIDR access port, the Cortex-M TPIU trace port — are themselves a battle frontier. Voltage glitching (ChipWhisperer), clock glitching, and EM fault injection bypass secure boot, attestation, and key extraction on a daily basis in modern labs.

The combination is what makes RTOS security its own discipline: you do not get to choose between software exploitation and hardware exploitation — a real RTOS engagement requires both, because the network stack exploit lands you in kernel mode and the secure-boot bypass is what got you the firmware to begin with. The VxWorks Urgent/11 disclosure, the FreeRTOS+TCP Zimperium report, the multiple Zephyr Bluetooth host CVEs (CVE-2019-17500, CVE-2020-10019, CVE-2021-3329, CVE-2022-3821), and the ongoing stream of ThreadX NetX DUO CVEs (CVE-2021-2924, CVE-2023-34625) all share the same shape: a remote or local attacker exploits the IP/Bluetooth stack or debug agent to gain supervisor privileges on a device that has no separation kernel, no MPU enforcement on the compromised task, and no ASLR to randomize the target address.

Difference from firmware-reverse: Firmware-reverse covers generic firmware image acquisition (binwalk signature scan, sasquatch/jefferson filesystem extraction, FACT and firmwalker scanning) and generic full-system emulation (firmadyne, qemu-system). Embedded-rtos-security assumes the firmware image is already extracted and goes one layer deeper: identifying the RTOS, fingerprinting version via debug agent banner, exploiting RTOS-specific components (WDB RPC protocol, qconn, FreeRTOS IP-task, ThreadX NetX, Zephyr Bluetooth host), and leveraging RTOS-specific hardware attacks (priority inversion, MPU bypass, scheduler abuse). The boundary: binwalk/unblob extraction → firmware-reverse; once you know the image contains VxWorks 6.9 and you're targeting the WDB agent on UDP 17185, you're in embedded-rtos-security.

Difference from iot-pentest: IoT-pentest covers the application-layer IoT protocols (MQTT, CoAP, AMQP, LwM2M, AWS IoT Device SDK, OCF) and the cloud back-end. Embedded-rtos-security covers the RTOS that sits underneath those protocols — the FreeRTOS TCP/IP stack that carries the MQTT traffic, the ThreadX NetX DUO stack that carries the LwM2M traffic, the Zephyr networking subsystem that carries CoAP. IoT-pentest is "what the device says over MQTT"; embedded-rtos-security is "the IP stack underneath the MQTT client that has its own 4 CVEs."

Difference from hardware-security: Hardware-security covers generic chip-level debug interfaces (JTAG/UART/SWD enumeration), glitching (voltage, clock, EM), and side-channel (power analysis via ChipWhisperer, Riscure Inspector). Embedded-rtos-security applies those techniques to RTOS-specific targets — JTAG access to dump FreeRTOS task control blocks, glitch attacks to bypass the QNX kernel boot signature, power analysis to recover ThreadX NetX crypto keys. The overlap is the lab gear; the difference is the target.

Difference from binary-reverse: Binary-reverse covers general disassembly and decompilation methodology across architectures (ARM, MIPS, x86, RISC-V). Embedded-rtos-security applies binary analysis to RTOS-specific artifacts — VxWorks VxWorks symbol table (vxworks.sym), QNX qnx_bootstrap ELF segments, FreeRTOS linker map for task stack layout, ThreadX _tx_block_pool heap structures, Zephyr Kconfig build artifacts. The same Ghidra session produces different findings depending on whether the analyst knows they're looking at a microkernel vs a flat-address-space RTOS.

Difference from scada-ics-security: SCADA covers industrial control protocols (Modbus, DNP3, S7comm, OPC UA, IEC 61850, GOOSE). Many SCADA devices run on VxWorks or MicroC/OS, but the SCADA layer is the application; embedded-rtos-security is the OS underneath. The overlap is Schneider Modicon PLCs running VxWorks (Urgent/11); embedded-rtos-security owns the WDB agent exploit, scada-ics-security owns the Modbus function code exploitation.

Use Cases

• VxWorks WDB debug agent exploitation: Identify a device running VxWorks (banner UDP 17185, TCP 17185, broadcast fingerprint), map the WIND IP stack version, exploit the Urgent/11 chain (CVE-2019-12256 stack overflow in wdbDbgArchLib.c, CVE-2019-12258 memory pool allocator overflow, CVE-2019-12260 DHCP client dhcpClientOptionGet overflow) for unauthenticated remote code execution on a Schneider Modicon PLC or an ABB RTU.
• FreeRTOS+TCP stack exploitation: Identify a device running FreeRTOS+TCP (often via DHCP option 60 strings, banner signatures in TCP/IP response timing, or filesystem strings indicating FreeRTOS), exploit the Zimperium chain (CVE-2018-16528 SendPing heap overflow, CVE-2018-16603 TCP SYN flood exhaustion, CVE-2018-16525 IP fragment reassembly UAF) for kernel-mode RCE in the IP-task.
• QNX Neutrino microkernel exploitation: Identify QNX Neutrino (procnto-smp-instr on boot, qconn on 8000, the Qnet protocol on TCP/UDP 4000), exploit qconn weak authentication, abuse procfs (/proc/<pid>/as for arbitrary process memory access given CAP_SYS_ADMIN-equivalent credentials), or compromise a QNX Momentics IDE-launched binary via the Slinger/jqconn trusted channel.
• ThreadX / Azure RTOS exploitation: Identify ThreadX (filesystem strings, banner), exploit NetX DUO CVEs (CVE-2021-2924 HTTP server overflow, CVE-2023-34625 IPv6 ND prefix corruption), abuse the ThreadX block-pool allocator for heap-style attacks, or compromise Azure RTOS's HTTPS/REST server features added by the OpenAMP migration.
• Zephyr RTOS exploitation: Identify Zephyr (Kconfig build artifacts in the firmware filesystem, Bluetooth HCI vendor strings), exploit Bluetooth host-stack CVEs (CVE-2019-17500 L2CAP heap overflow, CVE-2020-10019 GATT handler UAF, CVE-2022-3821 HCI ACL buffer overflow), or attack the Zephyr networking subsystem (CoAP server, LwM2M client).
• Mbed OS exploitation: Identify Mbed OS (Pelion Device Management strings, uVisor traces), exploit uVisor enclave bypass, attack the Pelion Cloud client (HTTPS over mbedTLS with the FSF certificate chain), or compromise mbed-cli build artifacts.
• TI-RTOS / SYS/BIOS exploitation: Identify TI-RTOS (BIOS task scheduler signatures, XDC tools artifacts, the C6000/C2000 boot signature), exploit the NDK TCP/IP stack, abuse ROV (Runtime Object Viewer) debug exposure over UART/Ethernet.
• MicroC/OS-II / III exploitation: Identify MicroC/OS (heap signature, OSTaskCreate runtime strings), exploit the absence of MMU/MPU enforcement (the OS does not enforce task isolation), abuse the lack of address randomization for trivial ROP on a task stack.
• NuttX / RIOT / Contiki-NG exploitation: Identify these smaller RTOSes (often on 6LoWPAN / 802.15.4 sensors), exploit their TCP/IP stacks (NuttX BSD-derivative, RIOT GNRC, Contiki uIP), attack the 6LoWPAN mesh layer.
• Hardware-assisted exploitation: Enumerate JTAG/SWD/ETM via JTAGulator or Shikra, attach via OpenOCD + J-Link/ST-Link/Black Magic Probe, dump FreeRTOS task control blocks, patch the secure boot fuse via voltage glitching with ChipWhisperer, or perform power-analysis key extraction on an mbedTLS AES implementation.
• RTOS firmware static analysis: Use Ghidra/IDA Pro with RTOS-specific loader scripts (VxWorks symbol recovery, FreeRTOS linker map import, ThreadX heap layout reconstruction) to identify memory corruption primitives, locate the WDB agent or qconn binary, and build the exploit chain.
• RTOS emulation and symbolic execution: Use Renode (which has first-class VexRiscv / LiteX support and is the canonical multi-RTOS emulator) or qemu-system to boot the RTOS in an emulated environment for repeatable dynamic analysis, then use angr to symbolically explore the WDB agent RPC parser or the FreeRTOS DHCP option handler for input-to-crash paths.

Core Tools

Disassembly and Static Analysis

Hardware Attack

Firmware Extraction and Analysis

Emulation and Dynamic Analysis

Fault Injection and Side-Channel

Flash and Trace

Methodology

RTOS Attack Chain

Fingerprinting            Debug Agent Exploit          Kernel/Task Compromise        Persistence
(Banner/Behavior)   (WDB RPC, qconn, GDB stub)   (RCE in IP-task, MPU bypass)   (Patch image / OTA)
       |                       |                              |                              |
       v                       v                              v                              v
  UDP 17185 banner       WDB_MODE_ANY exploit            Heap overflow in IP-task      Modify vxWorks image
  qconn TCP 8000         Urgent/11 chain                 Task TCB overwrite            Patch secure boot
  DHCP option 60         FreeRTOS DHCPv4 RCE             Scheduler priority inversion  Hook OTA update flow
  Bluetooth HCI banner   Zephyr GATT UAF                 MPU region re-configure       Survive factory reset

Phase Details:

1. Fingerprinting: Identify the RTOS via network banner (VxWorks WDB banner on UDP 17185, qconn banner on TCP 8000), DHCP option 60 vendor class identifier, filesystem strings in extracted firmware, Bluetooth HCI vendor/version response, or symbol recovery via binwalk + VxWorks loader. Determine version (VxWorks 5.5/6.x/7, FreeRTOS 8/9/10/11, ThreadX 5.x/6.x). Cross-reference against published CVE catalog (Urgent/11, Zimperium 2018, Azure RTOS advisories 2023).

2. Debug Agent Exploit: If WDB is exposed (default VxWorks < 6.9.4 ships with WDB_MODE_ANY allowing unauthenticated read/write/execute), use the WDB RPC protocol directly to call tgtPing, read arbitrary memory via wdbCtxRead, write memory via wdbCtxWrite, or spawn a task with wdbTaskSpawn. QNX qconn supports the QConnect protocol with optional authentication that OEMs routinely disable; exploitation includes posix_spawn of a root shell. FreeRTOS GDB stubs (when enabled) accept monitor commands for memory access without authentication.

3. Kernel/Task Compromise: When no debug agent is exposed, attack the IP stack directly. Urgent/11 stack overflow in wdbDbgArchLib.c (CVE-2019-12256) is triggered by a malformed WDB RPC packet even with WDB disabled in some builds. FreeRTOS+TCP SendPing heap overflow (CVE-2018-16528) is triggered by an ICMP echo with a malicious payload length. Zephyr L2CAP heap overflow (CVE-2019-17500) is triggered by an L2CAP signal packet with oversized information payload. After RCE, escalate privileges within the flat RTOS address space: all FreeRTOS tasks share the same address space (no MMU by default), so userland is already kernel-mode. On QNX microkernel, abuse procfs after obtaining any process credentials to read arbitrary process memory via /proc/<pid>/as.

4. Persistence: Modify the firmware image on the external SPI flash (after gaining write access via flashrom-on-target or a vendor-supplied update mechanism). Patch the WDB agent to require authentication. Hook the OTA update mechanism to deliver attacker-controlled firmware. On VxWorks, hook usrAppInit to spawn an attacker task at boot. On Zephyr, abuse the MCUboot serialized update flow.

Debug Agent vs Network Stack Workflow

DEBUG AGENT PATH                                  NETWORK STACK PATH
(preferred — fewer prerequisites)                 (when debug agent is closed)

1. nmap UDP 17185 / TCP 8000 / TCP 3333           1. Identify IP/Bluetooth stack (vendor strings)
2. WDB RPC tgtPing                                2. Craft single-packet PoC (ICMP, L2CAP, IPv6 ND)
3. wdbCtxRead target_nv_params                    3. Trigger heap overflow → ROP → task spawn
4. wdbTaskSpawn revshell_task                     4. Pivot to other network services
5. Dump full RAM via WDB                          5. Leverage for lateral movement in plant

Practical Steps

For detailed commands and payloads see payloads.md, and for the complete test checklist see test-cases.md. Below is a summary of core operations for each phase.

1. VxWorks WDB Fingerprint

# UDP 17185 is the default WDB port
nmap -sU -p 17185 --script=vxworks-wdb <target-ip>
# Confirm with the WDB banner echo
python3 payloads/wdb_probe.py --target <target-ip> --port 17185

2. FreeRTOS+TCP Stack Detection

# DHCP option 60 vendor class often contains "FreeRTOS"
dhcpig -i eth0 --target <target-ip>
# Network stack fingerprint via timing
nmap -sV -p 80,23 --version-intensity=5 <target-ip>

3. OpenOCD + J-Link Hardware Attach

# Identify the SWD interface
openocd -f interface/jlink.cfg -f target/stm32f4x.cfg -c init -c targets
# Dump full flash via GDB
arm-none-eabi-gdb -ex 'target extended-remote :3333' \
  -ex 'monitor reset halt' \
  -ex 'dump binary memory flash.bin 0x08000000 0x08100000'

4. ChipWhisperer Glitch Attack

import chipwhisperer as cw
scope = cw.scope()
target = cw.target(scope)
scope.glitch.width = 5.5
scope.glitch.offset = -7.2
scope.glitch.repeat = 3
scope.glitch.trigger_src = 'manual'
# Fire glitch at target's secure boot validation routine
scope.glitch.manual_trigger()

5. Renode RTOS Emulation

# Zephyr .resc script
:mmio_init
include @zephyr/memmap.repl
:set loglevel 3
emulation TimeLimit 30
showAnalyzer uart0
sysbus LoadELF @zephyr.elf
cpu SetRegister PC 0x08000000

Protocol Deep Dive

WDB RPC Protocol Internals

The Wind River Debug Agent (WDB) is a Sun RPC (ONC RPC, RFC 5531) service registered under RPC program number 0x55555555. The protocol uses XDR (External Data Representation, RFC 1832) for payload encoding. The default UDP transport is port 17185. WDB historically accepts AUTH_NONE (flavor 0) credentials on VxWorks 5.x through 6.9.3, leaving the agent open to unauthenticated memory read/write and task spawn. The 40-byte RPC call header is followed by procedure-specific XDR-encoded parameters; the reply is a 24-byte RPC header plus procedure-specific return data. See guides/embedded-rtos-security-deep-dive.md for the full byte-level protocol specification.

FreeRTOS+TCP IP-Task Packet Path

FreeRTOS+TCP processes all network traffic in a single IP-task created by FreeRTOS_IPInit(). Packets enter via the network driver's receive ISR, traverse ethernetif_input(), are placed in the network event queue xNetworkEventQueue, and are processed sequentially by the IP-task's main loop. The packet dispatch is: prvHandleEthernetPacket() -> eConsiderFrameForProcessing() (Ethertype filter) -> prvProcessIPPacket() -> per-protocol handler (prvProcessICMPPacket, prvProcessTCPPacket, prvProcessUDPPacket, or IP fragment reassembly). Because the IP-task runs in supervisor mode with no MPU isolation, every protocol handler bug is a kernel-mode bug. See guides/freertos-tcp-vulnerability-research.md for the full receive-path walkthrough.

QNX Neutrino Qnet Protocol

QNX Neutrino's Qnet protocol extends native message passing (MsgSend/MsgReceive) across network nodes. Qnet runs on TCP/UDP port 4000 and uses the same synchronous message-passing semantics as local IPC. The protocol's security model assumes all nodes on the Qnet network are trusted — there is no per-node authentication. An attacker on the same Qnet network can send arbitrary MsgSend calls to any process on any peer node, including the kernel's procnto process manager.

Zephyr Bluetooth Host Stack Architecture

Zephyr's Bluetooth host stack is a from-scratch implementation (not BlueZ). The host stack runs in the bt_host thread and processes HCI events from the controller (which may be a separate chip connected via UART/SPI/USB). The L2CAP layer (subsys/bluetooth/host/l2cap.c) handles connection-oriented and connectionless channels. The GATT layer (subsys/bluetooth/host/gatt.c) handles attribute protocol exchanges. Both have been the source of multiple CVEs since 2019 (CVE-2019-17500 L2CAP heap overflow, CVE-2020-10019 GATT UAF, CVE-2022-3821 HCI ACL buffer overflow). The pattern is consistent: payload size not validated before copying into a fixed-size buffer.

ThreadX NetX DUO Stack Architecture

ThreadX NetX DUO is a dual-stack (IPv4/IPv6) TCP/IP implementation that runs as a set of ThreadX threads. The IP receive thread (nx_ip_thread_entry) processes packets from the driver's receive queue. Each protocol has its own handler: _nx_icmp_packet_receive, _nx_tcp_packet_receive, _nx_udp_packet_receive, _nx_arp_packet_deferred_receive. The IP thread runs at a high priority (NX_IP_THREAD_PRIORITY). Heap-allocated packet buffers come from the NetX DUO packet pool (nx_packet_pool) which uses ThreadX's tx_block_pool allocator — a singly-linked free list with predictable layout. See payloads.md §6 for ThreadX block pool exploitation patterns.

RTOS Attack Matrix

The RTOS Attack Matrix maps common attack techniques to the RTOS families and components they target. This matrix guides engagement planning by identifying which techniques apply to the specific RTOS family under test.

Attack Chain Scenarios

Scenario 1: VxWorks PLC Full Compromise Chain — nmap discovers UDP 17185 WDB agent -> WDB tgtPing confirms VxWorks 6.9.3 -> wdbCtxRead dumps kernel memory -> wdbTaskSpawn delivers reverse shell -> pivot to Modbus application (scada-ics-security domain).

Scenario 2: FreeRTOS Smart-Device Fleet Compromise Chain — DHCP option 60 strings reveal FreeRTOS -> oversized ICMP triggers CVE-2018-16528 heap overflow -> heap feng shui positions TCB adjacent to overflow target -> TCB function pointer overwrite -> kernel-mode RCE -> MQTT client is the persistence vector into the IoT cloud (iot-pentest domain).

Scenario 3: Zephyr BLE Sensor Compromise Chain — BLE advertisement sniffing -> connect with malformed L2CAP packet -> CVE-2019-17500 heap overflow in l2cap_chan_recv -> ROP gadget chain (no ASLR on bare-metal Cortex-M) -> sensor data exfiltration via CoAP -> lateral movement to peer 6LoWPAN mesh nodes.

Safety Considerations

RTOS Safety Philosophy

RTOS targets frequently govern physical processes: avionics flight surfaces, automotive brake controllers, medical infusion pumps, industrial robotics, power-grid protection relays. A compromised RTOS device can cause catastrophic physical harm, environmental damage, or loss of life. Safety considerations must govern every phase of an RTOS security assessment.

Pre-Assessment Safety Requirements

1. Written authorization explicitly identifying in-scope systems and excluding safety-instrumented systems (SIS).
2. Identify safety-critical functions the device performs (braking, dosing, switching, protection) before any active testing.
3. Establish a stop-testing signal the operator can use if process anomalies appear.
4. Document emergency shutdown procedures for the specific device class.
5. Verify isolated lab environment for any active exploitation (WDB probe, IP-stack PoC, glitch attempt). Never test against production safety-critical devices.
6. Review the device's safety case (DO-178C for avionics, IEC 62304 for medical, IEC 61508 for industrial, ISO 26262 for automotive).

Safety Impact Classification

Operational Constraints

• Real-time deadlines: RTOS devices often have sub-millisecond deadline requirements. Injected traffic must not introduce latency beyond the device's tolerance.
• Watchdog timers: Aggressive scanning can trigger watchdog resets. Use conservative scan timing.
• Persistence across reboots: Some safety-critical devices cannot be safely rebooted in the field. Verify lab equivalence before testing.
• Physical process coupling: A change to one RTOS task may trigger automated responses in physical processes. Understand interdependencies before testing.

RTOS Network Architecture

Reference Architecture: Embedded Device Network Zones

Cloud Tier (AWS IoT, Azure IoT Hub, Pelion)
    |
    [ Cloud Gateway / Protocol Translator (MQTT, HTTPS) ]
    |
[ Edge Router / IoT Gateway (often Linux or high-end RTOS) ]
    |
    [ Field Network - typically one of: ]
    |
    +-- Ethernet-based fieldbus (Modbus TCP, EtherNet/IP, PROFINET)
    |       |
    |       [ RTOS Devices (PLCs, RTUs, IEDs) ]
    |
    +-- Serial fieldbus (Modbus RTU, DNP3, PROFIBUS)
    |       |
    |       [ RTOS Devices (RTUs, IEDs) ]
    |
    +-- Wireless mesh (6LoWPAN, Thread, BLE Mesh)
    |       |
    |       [ RTOS Sensors (Zephyr, ThreadX, Contiki) ]
    |
    +-- Field Devices (sensors, actuators, I/O modules)

Network Zone Testing Methodology

For each zone boundary, test these security controls:

Cloud-to-Edge Boundary: Device enrollment certificate hygiene, OTA image signing key scope, cloud-side IAM for the device's role.

Edge-to-Field Boundary: Protocol-aware firewall rules, Modbus function code allowlist, EtherNet/IP CIP command filtering.

Field Network: VLAN segmentation, multicast traffic containment (GOOSE for IEC 61850), rogue device detection.

Wireless Mesh: Encryption (802.15.4 MAC layer, Thread/6LoWPAN network layer), key rotation, replay protection.

Common Architecture Weaknesses

1. Flat field networks: All RTOS devices on a single subnet with no segmentation.
2. Shared engineering VLANs: Engineering workstations with both IT and OT access create implicit trust bridges.
3. Vendor remote access: Vendor maintenance VPNs that bypass the OT/IT DMZ directly to field devices.
4. Unencrypted OTA: TFTP, HTTP, or MQTT-based OTA without TLS or signature verification.
5. Default credentials on debug interfaces: Telnet on TCP 23, SSH on TCP 22, qconn on TCP 8000 with factory-default passwords.

Detection Strategies

Effective RTOS device detection requires both network-side and host-side instrumentation. The unique fingerprints of RTOS protocols enable targeted detection rules.

Network-Side Detection

Example Suricata rule for WDB:

alert udp $EXTERNAL_NET any -> $HOME_NET 17185 (
    msg:"VxWorks WDB RPC probe - potential Urgent/11 exploitation";
    content:"|55 55 55 55|"; depth:16; offset:12;
    detection_filter:track by_src, count 5, seconds 60;
    classtype:attempted-admin;
    sid:2019001; rev:1;
)

Host-Side Detection

• MPU fault counter: Incremented on any MemManage fault. A rising count indicates exploitation attempts.
• Stack overflow canary: configCHECK_FOR_STACK_OVERFLOW=2 triggers a handler on canary corruption.
• Heap integrity check: A periodic vPortGetHeapStats() call detecting unexplained heap fragmentation.
• Watchdog reset counter: Incremented on each watchdog-triggered reboot. Frequent resets indicate instability possibly caused by exploitation.
• Debug agent disable verification: A boot-time assertion that wdbConfig(WDB_MODE_PASSWORD) or INCLUDE_WDB=FALSE was honored.

Hardening Measures

Compile-Time Hardening

Configuration Hardening

• Disable debug agents in production (see Defense Perspective above).
• Disable unused protocols (Bluetooth, CoAP, LwM2M, Telnet, FTP).
• Enforce TLS on all remote services (mbedTLS, wolfSSL).
• Pin OTA signing certificates to specific CA fingerprints, not the system trust store.
• Enable secure boot with fused hardware root of trust.
• Disable hardware debug post-manufacturing (DHCSR DAM fuse on ARM Cortex-M).

Operational Hardening

• Network segmentation: Place RTOS devices on isolated VLANs behind protocol-aware firewalls.
• Inventory management: Track every deployed device's version, patch level, and EOL date.
• Patch management: Establish a 90-day patch SLA for high-severity RTOS CVEs; accept that some devices will exceed it.
• Anomaly monitoring: Deploy network IDS (Suricata, Zeek) and host-side telemetry (MPU faults, watchdog resets).
• Incident response: Pre-stage forensic acquisition tools (OpenOCD, flashrom) and train operators on the IR runbook.

Defense Perspective

Detection Methods

RTOS Runtime Indicators

• Task anomalies: Unexpected task creation; priority inversion signatures.
• Memory protection faults: MPU faults indicating buffer overflow attempt.
• Network stack anomalies: Unexpected connections from RTOS device (typical: outbound only to known controller).

Hardware-Level Detection

• JTAG/SWD access: JTAG activity on production device (debug interface should be disabled).
• Side-channel signatures: Power analysis indicating cryptographic operations.

SIEM Detection Rules

• Splunk SPL (IoT): index=iot sourcetype=rtos_event | where event_type="task_create" | stats count by device_id
• Custom IoT platform: Azure IoT Hub / AWS IoT Core with anomaly detection.

Defense Evasion Techniques

Exploit Stealth

• Single-shot exploits: One exploit attempt per boot; below detection threshold.
• Use legitimate services: Inject into existing RTOS task rather than creating new task.
• Memory-only payloads: No filesystem writes; survives reboot via persistence mechanism.

Hardware Exploitation Stealth

• JTAG fuse blowing: Disable JTAG after exploit to prevent forensic analysis.
• Flash protection: Set flash protection bits; prevent readout.
• Side-channel minimization: Distribute crypto operations over time; reduces correlation.

Hacker Laws

Common Pitfalls

1. Treating an RTOS like a general-purpose OS. RTOS task stacks are tiny (often 256-1024 bytes); a stack overflow that would corrupt a Linux thread's adjacent guard page will corrupt the next task's TCB on FreeRTOS. RTOS schedulers do not have time-slice fairness — a high-priority task will starve everything below it forever. RTOS memory allocators (ThreadX block pool, MicroC/OS OSMemPut) are simple first-fit and have no free() semantics to exploit but have predictable layouts for overflow.

2. Assuming WDB is disabled in production. The VxWorks WDB agent has been found in production devices as late as 2024 — including devices that shipped after the 2019 Urgent/11 disclosure. The reason is always the same: the field service organization needs remote diagnostics, and WDB_MODE_ANY (no authentication) is the path of least resistance. Always scan UDP 17185 even if the OEM claims it's disabled.

3. Confusing configUSE_MPU_WRAPPERS=1 with MPU enforcement. Setting configUSE_MPU_WRAPPERS=1 in FreeRTOSConfig.h enables the MPU-aware API (xTaskCreateRestricted), but does NOT enforce MPU on existing tasks created with xTaskCreate. Every task must be created with xTaskCreateRestricted and a populated TaskParameters_t.xRegions[] for MPU to apply. Many OEMs enable the wrapper, leave xTaskCreate calls unchanged, and ship "MPU-protected" FreeRTOS that is in fact flat-address-space.

4. Ignoring RTOS-specific heap layouts. ThreadX's byte pool allocator (tx_byte_pool) places metadata inline with the allocation in a way that makes classic heap exploitation unreliable. But ThreadX's block pool (tx_block_pool) is a pure singly-linked free list with predictable layout — tx_block_release is a textbook unlink exploit. Know which allocator your target uses.

5. Treating Zephyr like Linux. Zephyr is POSIX-ish but its networking stack is custom, its Bluetooth host stack is a from-scratch implementation, and its scheduler is preemptive fixed-priority with cooperative time slicing only on k_yield. Tools like strace, ltrace, valgrind, and even GDB Python scripts written for Linux will not work out of the box. Use Zephyr's native shell, kernel shell, and the west build tool.

6. Trusting secure boot without verifying the chain. A device may have a fused secure-boot ROM that verifies the first-stage bootloader, but a buggy first-stage bootloader may load a second-stage image from an unverified offset. The TI-RTOS SYS/BIOS boot path, the VxWorks bootrom -> usrAppInit path, and the Zephyr MCUboot path all have multi-stage verification logic that must be reviewed end-to-end. Verify the chain, not the fuse.

7. Glitching without reconnaissance. Voltage glitching on a Cortex-M secure boot requires knowing the exact cycle window where the signature verification branch occurs. Reconnaissance with ChipWhisperer's power-trace capture (10k+ traces aligned by the boot clock edge) is mandatory before any glitch attempt. Glitching blind is a way to brick a $200 dev board and learn nothing.

8. Forgetting that QNX Neutrino has a real microkernel. Unlike VxWorks or FreeRTOS, QNX Neutrino enforces process isolation — a process compromise does not directly give kernel access. The escalation path is via procfs (/proc/<pid>/as), the qconn trusted channel, or kernel-driver IPC messages. Treating QNX like a flat RTOS wastes time; the methodology is closer to Linux kernel exploitation.

Cross-Skill Integration

• firmware-reverse — Provides the extracted firmware image (binwalk + sasquatch + jefferson) that embedded-rtos-security then dissects for RTOS-specific components (WDB agent binary, FreeRTOSConfig.h, ThreadX tx_api.h). Embedded-rtos-security assumes firmware-reverse has run.
• hardware-security — Provides JTAG/UART/SWD enumeration (JTAGulator, Shikra), flashrom dumps, and the physical lab setup that embedded-rtos-security uses to access RTOS task state via OpenOCD. Embedded-rtos-security owns the RTOS-specific exploitation of those hardware primitives.
• binary-reverse — Provides Ghidra/IDA Pro methodology that embedded-rtos-security specializes for RTOS loaders (VxWorks symbol table recovery, FreeRTOS linker map import, ThreadX heap layout reconstruction).
• exploit-development — Takes RTOS vulnerabilities (Urgent/11, FreeRTOS+TCP, Zephyr Bluetooth) and develops reliable exploit code with ROP chains, heap feng shui, and shellcode targeting the specific RTOS task model.
• iot-pentest — Covers the application-layer IoT protocols (MQTT, CoAP, LwM2M) that ride on top of the RTOS networking stack. Embedded-rtos-security owns the FreeRTOS+TCP stack that carries the MQTT broker; iot-pentest owns the MQTT broker itself.
• scada-ics-security — Owns the SCADA application protocols (Modbus, DNP3, S7comm) that run on top of VxWorks or MicroC/OS in industrial controllers. Embedded-rtos-security owns the VxWorks WDB agent underneath; scada-ics-security owns the Modbus function code surface.
• automotive-vehicle-security — Owns the CAN bus, UDS, and OBD-II layer. The overlap is QNX Neutrino running on the IVI — automotive owns the IVI-as-vehicle-component; embedded-rtos-security owns the QNX microkernel underneath.
• sdr-rf-attack — Provides the RF layer for Bluetooth (Zephyr BLE), Zigbee (THREAD/ThreadX), and sub-GHz IoT protocols. Embedded-rtos-security owns the Bluetooth host stack on Zephyr; sdr-rf-attack owns the PHY/MAC layer.
• bluetooth-rfid-nfc — Provides BLE/NFC exploitation methodology that embedded-rtos-security applies to Zephyr's Bluetooth host stack and ThreadX's BLE profile stack.

Learning Resources

Supplementary files for this skill:

• payloads.md — Complete command collection (11 sections, 60+ code blocks covering all major RTOS families and hardware attack surfaces)
• test-cases.md — Structured test cases (12 case templates, TC-RT-001 through TC-RT-012, with prerequisites, expected results, and severity ratings)

Extended learning materials (guides/):

• guides/embedded-rtos-security-playbook.md — End-to-end red team playbook: RTOS architecture comparison, attack surface map, real CVE deep dives (Urgent/11, FreeRTOS+TCP, Zephyr Bluetooth), hardware lab setup, glitching rig, emulation, defensive guidance, RTOS MITRE ATT&CK mapping, secure boot and TEE analysis.
• guides/embedded-rtos-security-deep-dive.md — VxWorks WDB RPC exploitation lab: protocol reverse engineering, MODE_ANY escalation, memory read/write primitives, task spawn RCE, Urgent/11 PoCs, QEMU lab setup, Wireshark dissector, CTF scenarios.
• guides/freertos-tcp-vulnerability-research.md — FreeRTOS+TCP CVE reproduction lab: POSIX simulator setup, IP-task architecture, heap_4.c internals, Zimperium 2018 CVE PoCs, AFL fuzzing harness, angr symbolic execution, patch diffing methodology.

Reference repositories:

• FreeRTOS/FreeRTOS — FreeRTOS kernel and FreeRTOS+TCP source
• eclipse-threadx/threadx — ThreadX/Azure RTOS (now Eclipse Foundation)
• zephyrproject-rtos/zephyr — Zephyr RTOS source
• RIOT-OS/RIOT — RIOT OS source
• apache/nuttx — Apache NuttX
• contiki-ng/contiki-ng — Contiki-NG
• renode/renode — Antmicro Renode emulator
• chipwhisperer/chipwhisperer — NewAE ChipWhisperer
• openocd-org/openocd — OpenOCD source

External resources:

• JSOF Urgent/11 disclosure (2019) — The 11 VxWorks CVEs (CVE-2019-12256 et al.)
• Zimperium FreeRTOS+TCP analysis (2018) — CVE-2018-16525/16528/16529/16603
• Wind River VxWorks security advisories — Vendor PSIRT
• BlackBerry QNX security advisories — Vendor PSIRT
• Zephyr Project security advisories — Vendor PSIRT
• ARM Cortex-M security guidelines (AN-1221, ARMv8-M Security Extension)
• OWASP Embedded Systems Security Testing Guide
• Attacking Network Protocols (James Forshaw) — relevant for WDB RPC and qconn analysis

Related skills:

• skills/firmware-reverse/SKILL.md — Generic firmware extraction and analysis
• skills/hardware-security/SKILL.md — JTAG/UART/SWD/glitching methodology
• skills/binary-reverse/SKILL.md — Generic disassembly and decompilation
• skills/exploit-development/SKILL.md — Exploit development methodology
• skills/iot-pentest/SKILL.md — Application-layer IoT protocols
• skills/scada-ics-security/SKILL.md — Industrial control protocols
• skills/automotive-vehicle-security/SKILL.md — Vehicle attack surface (QNX IVI overlap)