DIVER: Deep Visibility and Anomaly Detection for VxWorks
🔍 Why VxWorks Controllers Need Deeper Security Visibility #
VxWorks-based embedded controllers are widely used in cyber-physical systems (CPS), industrial automation, power infrastructure, telecommunications, and other environments where deterministic execution and reliability are essential.
However, the same characteristics that make embedded RTOS platforms effective for real-time control can make them difficult to monitor from a cybersecurity perspective.
Traditional host-based security tools designed for Windows or Linux often depend on capabilities such as:
- System-call tracing
- Process enumeration
- Registry or configuration monitoring
- Extensive filesystem logging
- Persistent security agents
- Interactive administrative shells
These assumptions do not map cleanly to many VxWorks deployments.
VxWorks systems may use monolithic architectures, limited process isolation, constrained memory and storage, and restricted shell access. Many controllers also operate with specialized hardware and tightly integrated applications rather than the general-purpose software stacks found on PCs and servers.
This creates a significant visibility gap.
An attacker who compromises a controller may be able to modify tasks, replace modules, alter timers, manipulate memory, or change configuration data while leaving the human-machine interface (HMI) apparently normal.
The DIVER framework addresses this problem by moving security observation closer to the underlying VxWorks runtime.
🧩 DIVER’s Hybrid Monitoring Architecture #
DIVER, short for Defensive Implant for Visibility into Embedded Run-times, uses a two-part architecture:
- A lightweight measurer implant running directly within the VxWorks environment
- A more capable remote listener responsible for collection, analysis, baselining, and visualization
This division is important because embedded controllers have limited resources.
Instead of performing expensive analytics on the controller itself, DIVER collects low-level runtime measurements and sends them to an external system for analysis.
The On-Device Measurer #
The measurer is a compact module that can be loaded into the VxWorks kernel using available vendor or operating-system mechanisms.
It provides a TCP-based communication interface and exposes measurement and control functionality through parameterized commands and scripting capabilities.
The measurements can include:
- Running tasks and their states
- Task priorities
- Program counters
- Stack pointers
- Task activity statistics
- Loaded kernel modules
- Application modules
- Memory hashes
- Timer hierarchies
- Timer callbacks
- System diagnostics
- I/O configurations
- Memory regions
- Filesystem information
The implant can therefore observe aspects of system behavior that may not be visible through an HMI or conventional application-level monitoring.
The Remote Listener #
The remote listener handles the computationally heavier functions.
It can:
- Connect to one or more embedded devices
- Request measurements interactively
- Stream measurements continuously
- Establish known-good baselines
- Detect configuration changes
- Identify unexpected tasks and modules
- Compare memory hashes
- Analyze timer-tree changes
- Track task behavior over time
- Visualize results through command-line and browser interfaces
This architecture keeps the embedded footprint small while allowing sophisticated security analytics to run on a more capable monitoring system.
🛡️ Runtime Integrity Monitoring #
One of DIVER’s most valuable capabilities is the ability to detect changes that traditional application-level monitoring could miss.
A controller may continue reporting apparently normal process information while its underlying runtime has been modified.
DIVER can establish baselines for trusted system configurations and compare subsequent measurements against those baselines.
Potential indicators include:
- Unexpected kernel modules
- Unauthorized runtime tasks
- Modified application modules
- Memory-hash mismatches
- Changed timer configurations
- New timer callbacks
- Altered task priorities
- Suspended or deleted critical tasks
- Changes in task-state distributions
- Unexpected program-counter behavior
This creates a form of runtime integrity monitoring that operates beneath the normal application interface.
📈 Detecting Behavioral Anomalies #
Configuration integrity is only one part of the problem.
A malicious modification may leave filenames, task names, or other obvious identifiers unchanged. Behavioral monitoring can provide another layer of detection.
DIVER can record task-level activity over time and establish statistical patterns for known-good operation.
For example, a legitimate controller task may normally alternate among:
- READY
- PENDING
- DELAYED
- EXECUTING
in a relatively stable pattern.
A sudden change in those distributions can indicate that something has altered the task’s execution behavior.
Similarly, changes in program-counter variability may reveal that a task is executing a substantially different code path than expected.
Time-series analysis therefore provides a behavioral perspective in addition to static integrity checking.
🧠 Detecting Malicious Runtime Changes #
The framework can identify several classes of suspicious activity.
Unauthorized Modules and Tasks #
An attacker could insert a kernel module or runtime task into a controller.
If the new component does not appear in the established baseline, DIVER can flag it for investigation.
A similar technique can identify unauthorized RTP applications or other executable components.
Memory Integrity Violations #
Simply checking a module’s name is insufficient.
An attacker could replace a legitimate component with malicious code while retaining the original filename or module identity.
Memory hashing provides a stronger integrity check by comparing executable memory regions against trusted measurements.
A same-named module with a different memory hash can therefore become a strong indicator of compromise.
Timer Manipulation #
Timers can be particularly important in real-time controllers.
Unauthorized timer callbacks could be used to execute malicious functionality periodically without obviously modifying the main control task.
Monitoring the timer hierarchy and registered callbacks provides another layer of runtime visibility.
Critical Task Manipulation #
Attackers may attempt to interfere with legitimate controller tasks rather than introduce obviously malicious processes.
Potential indicators include:
- Task suspension
- Task deletion
- Priority changes
- Unexpected code modifications
- Significant behavioral changes
Monitoring these properties can help identify attacks that attempt to disrupt or subtly alter control behavior.
🔐 Lightweight Secure Communications #
Remote monitoring introduces its own security requirements.
If measurements travel over an ordinary network connection without protection, an attacker could potentially observe or manipulate the monitoring channel.
DIVER can therefore incorporate lightweight authenticated encryption based on Ascon, a lightweight cryptographic standard designed for constrained environments.
The objective is to protect communications while avoiding the resource demands associated with heavyweight security mechanisms.
For resource-constrained controllers, this balance is particularly important: security instrumentation must not consume enough CPU, memory, or network bandwidth to interfere with the control application.
🏗️ Cross-Architecture Deployment #
An important aspect of DIVER is its use across different VxWorks platforms.
The framework was demonstrated on:
Motorola ACE3600 RTU #
- 32-bit PowerPC processor
- VxWorks 5.5
- Real-world SCADA/industrial control hardware
Raspberry Pi 4 #
- 64-bit ARM Cortex-A72
- VxWorks 7
- Representative of newer embedded and IoT-oriented platforms
The same overall framework can support both architectures while accommodating processor-specific requirements such as symbol resolution and deployment.
Reported footprint measurements demonstrate that the monitoring component can remain relatively small.
| Configuration | ACE3600 | Raspberry Pi 4 |
|---|---|---|
| Base implant | ~10.6 KB | ~7.3 KB |
| Encryption overhead | ~8–9 KB | ~8–9 KB |
| Lightweight scripting | ~47 KB total | ~55 KB total |
| Full scripting engine | Larger, optional | Larger, optional |
These numbers illustrate the advantage of moving analysis away from the controller.
⚡ Measuring Real-Time Performance Impact #
Any kernel-level security instrumentation must answer an important question:
Does monitoring interfere with the real-time workload?
DIVER was evaluated using a closed-loop inverted-pendulum control application running as a dedicated VxWorks task.
The control loop received sensor data at 100 Hz, calculated control commands, and returned the resulting torque values.
Measured latency changes were small:
- Motorola ACE3600: approximately 3.46 ms → 3.48 ms
- Raspberry Pi 4: approximately 0.40 ms → 0.44 ms
The control system remained stable during the evaluation.
These results suggest that carefully designed instrumentation can provide substantial additional visibility without imposing a large timing penalty.
Actual production impact will naturally depend on the controller, workload, measurement frequency, network configuration, and specific instrumentation enabled.
📡 Why Moving Analysis Off the Controller Matters #
Performing anomaly detection directly on a constrained RTOS device would consume resources needed by the control application.
DIVER instead follows a simple principle:
Measure locally, analyze remotely.
The controller performs lightweight collection tasks while an external listener handles:
- Statistical analysis
- Baseline management
- Visualization
- Historical comparison
- Detection logic
- Forensic investigation
This approach allows security functionality to scale without requiring every embedded controller to carry the computational burden of a modern security analytics platform.
🔄 DIVER as a Foundation for Moving-Target Defense #
DIVER’s programmability also creates opportunities beyond passive monitoring.
Because the measurement system can be reconfigured, defenders can change:
- What is being measured
- How frequently it is measured
- Which runtime structures are inspected
- Which integrity checks are performed
This can support moving-target defense strategies in which the observation pattern changes over time.
An attacker who attempts to hide from a fixed monitoring configuration may therefore face a less predictable measurement environment.
The technique does not replace conventional security controls, but it can make persistent compromise more difficult to conceal.
⚠️ Limitations and Deployment Considerations #
DIVER should not be treated as a complete intrusion-prevention system.
Its primary purpose is to provide a trustworthy observation channel into an otherwise difficult-to-monitor embedded runtime.
Several assumptions and limitations remain important.
Initial Deployment Must Be Trusted #
The defender must have a trusted mechanism for initially installing the measurement component.
This may require:
- Physical access
- Vendor deployment tools
- Existing management infrastructure
- A trusted maintenance process
If the system is already compromised before installation, establishing trustworthy baselines becomes more difficult.
Monitoring Does Not Automatically Prevent Attacks #
Detection and prevention are different functions.
DIVER can identify suspicious changes and provide information for downstream analysis, but additional controls are required to block, isolate, or remediate an attack.
Broader Validation Is Still Needed #
Embedded controllers vary considerably in hardware, VxWorks versions, workloads, and timing requirements.
Additional testing across different industrial devices and real-world control applications would help establish broader deployment characteristics.
🏭 Implications for Industrial and Critical Infrastructure Security #
The DIVER approach is particularly relevant to systems where conventional endpoint security agents are difficult or impossible to deploy.
Examples include:
- Power-grid controllers
- SCADA equipment
- Remote terminal units
- Industrial automation systems
- Embedded transportation controllers
- Legacy VxWorks devices
- Resource-constrained IoT controllers
These environments often have long operational lifetimes, specialized hardware, and strict availability requirements.
Replacing a controller simply to gain modern security telemetry may be impractical.
Runtime instrumentation provides another option: add carefully designed visibility without fundamentally changing the control architecture.
🔭 The Future of RTOS Runtime Security #
As embedded controllers become increasingly connected, security monitoring needs to evolve beyond traditional endpoint models.
Future approaches could combine runtime instrumentation with:
- Formal verification
- Binary integrity analysis
- Behavioral machine learning
- Hardware-assisted monitoring
- Secure boot measurements
- Remote attestation
- Network-based anomaly detection
- Safety-aware intrusion response
The most effective architectures will likely combine multiple layers rather than relying on any single monitoring mechanism.
🏁 Final Thoughts #
VxWorks controllers provide the deterministic behavior required by many critical cyber-physical systems, but their embedded architecture can make conventional security monitoring difficult.
DIVER demonstrates a practical alternative.
By placing a lightweight measurement component directly inside the VxWorks runtime and moving intensive analysis to a remote listener, the framework can expose:
- Task behavior
- Module integrity
- Memory changes
- Timer structures
- Runtime configuration
- Filesystem state
- Statistical execution patterns
The reported performance measurements show that deep instrumentation does not necessarily have to compromise real-time behavior when it is carefully designed.
For industrial and critical-infrastructure operators, the central lesson is straightforward: visibility is itself a security capability. When traditional host-based monitoring cannot see deeply enough into an embedded RTOS, lightweight runtime instrumentation can provide the missing layer of observability needed to detect subtle compromise and configuration drift.
DIVER therefore offers a useful blueprint for building security monitoring around constrained VxWorks controllers without abandoning the deterministic characteristics that make these systems valuable in the first place.