servers. This also allows many instances of the system to be started -with the number of instances only limited by the availability of general purpose computing resources.The primary challenge to re-hosting firmware is providing valid inputs for the hardware that is not implemented in the emulator. Emulators such as QEMU [6] provide the ability to emulate a variety of CPU architectures, but provide very limited support for the huge variety of peripherals (e.g., timers, UARTs, Ethernet controllers) used in commodity embedded systems. Many different approaches have been proposed to address these challenges. One approach is to implement the hardware at low-level memory mapped register interface as done in QEMU -a laborious task that does not scale well. Another approach is hardware-in-the-loop emulation [18], where accesses to peripherals are forwarded to physical hardware -which reduces its scalability. Machine learning [14] is an approach where interactions with peripherals are recorded on hardware and used to build models of peripherals. These models are then used during emulation. Another approach is to use a fuzzer [12] to provide inputs for the peripherals. Both machine learning and fuzzing peripherals limits control over the devices making them unsuitable for high fidelity emulation.A promising approach is High Level Emulation (HLE) [8], [7], [10], [11] where common abstractions within the firmware are utilized to remove the need to provide low-level support for peripherals. Both Firmadyne [7] and Costin et al. [10], [11] utilize the Linux kernel abstractions to enable re-hosting Linux based firmware. HALucinator [8] uses hardware abstraction layers provided by micro-controller manufacturers, enabling re-hosting of simple bare-metal applications.Our goal is to advance the art of re-hosting to enable answering questions about how low-level logic and vulnerabilities in Real-Time Operating Systems (RTOS) impact the larger systems in which they are a part. While we are not yet able to achieve this final end goal we report our current progress here. To achieve this goal we extend HALucinator to work with a commercial RTOS. For a more general review of re-hosting we refer the reader to [34]. RTOSes aim to make the process of writing firmware for embedded systems easier. These RTOSes provide the basic constructs for a real-time system and give the developer abstract mechanisms to define system behavior. These mechanisms are often organized as layers, which hide the working details of the system from higher layers. In addition, these operating systems define an interface-called a Board Support Package (BSP)-to enable portability across a large variety of hardware. These layers, and in particular the BSP, provide a natural place for HALucinator to decouple firmware from its hardware and enable re-hosting in an emulator.Here we focus on VxWorks, a commercial RTOS Abstract-Emulating firmware is increasingly popular for systems research, particularly vulnerability research. In this paper we describe how we extend HALuc...