Avatar²: A Multi-Target Orchestration Platform

Device-agnostic Firmware Execution is Possible: A Concolic Execution Approach for Peripheral Emulation

“…We developed the prototype of Laelaps based on QEMU [4] and angr [42], which are concrete execution engine and symbolic execution engine, respectively. To facilitate state transfer between the two execution engines, we integrate Avatar [34,46], a Python framework for seamlessly orchestrating multiple dynamic analysis platforms, including QEMU, real device, angr, PANDA [17], etc. Our tool inherits the state transfer interface of Avatar, enhances Avatar's capability to handle Cortex-M devices, implements a memory synchronization mechanism between QEMU and angr, develops the proposed CPSA on top of angr, and exports to firmware analysts an easy-to-use Python interface.…”

“…They are either ad-hoc, tightly coupled with real devices, or rely on an abstraction layer such as the Linux kernel. Existing work [25,28,34,44,46] forwards peripheral signals to real devices and run the rest of firmware in an emulator. In this way, analysts could execute the firmware and inspect into the inner state of firmware execution.…”

FirmAE: Towards Large-Scale Emulation of IoT Firmware for Dynamic Analysis

“…The unpacked firmware can be analyzed with real devices. Zaddach et al [62] and Marius et al [44] relayed process execution and peripheral access to real devices and partially emulated target code using a JTAG interface. Similarly, Kammerstetter et al [28,29] developed a proxy environment using real devices and forwarded character device access to them.…”

FIRMCORN: Vulnerability-Oriented Fuzzing of IoT Firmware via Optimized Virtual Execution

“…Multi-target orchestration analysis is based on both real devices and emulation technology and strives to solve the accuracy problem that cannot be solved by emulation and the automatic analysis problems that cannot be solved by hardware debugging. Avatar [16] and Avatar 2 [17] are concrete examples of this concept, trying to forward I/O operations to real devices to solve external environment interaction problems. However, the Avatar and Avatar 2 schemes have the problem that switching between emulation environment and real devices affects the running speed in large-scale fuzz testing.…”

“…Zaddach et al [16] proposed the Avatar framework to forward I/O accesses from the emulator to the embedded device. On the basis of this work, Muench et al [17] implemented Avatar2 to enable interoperability between different dynamic binary analysis frameworks, debuggers, emulators, and real physical devices. However, the above scheme has considerable overhead in hardware and emulator switching, thereby limiting its application in fuzz testing.…”