Facilitating Non-Intrusive In-Vivo Firmware Testing with Stateless Instrumentation

Facilitating Non-Intrusive In-Vivo Firmware Testing with Stateless Instrumentation

Speakers: Jiameng Shi

Conference: NDSS Symposium

YouTube: https://www.youtube.com/watch?v=6TbcMvuFVJo

Overview

Dynamic testing techniques, ubiquitous in general software development, face formidable challenges when applied to firmware on deeply embedded devices like microcontrollers (MCUs). These devices operate in unique runtime environments characterized by severely restricted resources, making it impractical to directly deploy resource-intensive analysis tools such as sanitizers or advanced debuggers. Firmware developers often resort to rudimentary debugging methods like halt-and-examine, a stark contrast to the sophisticated tooling available for PC-based software. This talk introduces IPEA (in-vivo probe, ex-vivo analysis), a novel framework designed to bridge this gap by intelligently partitioning the workload of firmware testing.

IPEA’s core innovation lies in its ability to decouple the computationally intensive parts of analysis from the resource-constrained MCU. A small, lightweight component, consisting of "needle probes," resides on the MCU chip to collect high-fidelity runtime information directly from the device – the in-vivo aspect. The heavy-lifting analysis, which requires significant processing power and memory, is offloaded to a more capable development PC – the ex-vivo aspect. Communication between these two parts is facilitated by the ubiquitous hardware debug dongle, an integral part of existing firmware development workflows. This design ensures IPEA is non-intrusive, seamlessly integrating without additional hardware, while providing high-fidelity data collection and incurring minimal memory overhead on the target MCU.

The significance of IPEA is underscored by its practical contributions. The framework enables the deployment of advanced analysis techniques, specifically a pointer-based sanitizer (IPEA-San) and a greybox fuzzer (IPEA-Fuzz), as modular plugins. Through comprehensive evaluation, IPEA-San demonstrated significantly reduced memory overhead and superior detection accuracy compared to a memory-optimized AddressSanitizer (ASan) port for MCUs. Critically, the combination of IPEA-Fuzz and IPEA-San led to the discovery of seven zero-day bugs in popular IoT libraries and peripheral driver code, validating the framework's effectiveness in uncovering real-world security vulnerabilities in embedded systems.

Background

▶ Watch: Introduction to firmware testing challenges and IPEA (0:00)

Microcontroller firmware development is a unique ecosystem. Developers typically write source code on a powerful development PC, cross-compile it into a binary firmware image, and then use a hardware debug dongle to download and debug this firmware onto a target MCU prototype board. This debug dongle, often connected via JTAG or SWD, grants ultimate control over the MCU, allowing operations such as suspending/resuming execution, setting breakpoints, and examining memory and register values. These capabilities are crucial for debugging but are often manually driven and lack the automation found in modern dynamic analysis.

MCUs are resource-constrained Systems-on-Chip (SoCs), designed for low power consumption and embedded applications. They operate at lower frequencies (e.g., 500 MHz) and integrate on-chip SRAM and flash memory, typically in the range of hundreds of kilobytes. A critical difference from general-purpose computing is the common absence of a Memory Management Unit (MMU). Firmware on these devices runs in a single, flat address space where kernel code, user tasks, and memory-mapped peripherals are intermingled. This bare-metal environment renders many existing dynamic software testing tools, designed for systems with MMUs and virtual memory, inapplicable without radical redesign. Even if adapted, their resource demands often exceed the MCU's limited capacity.

Firmware, predominantly written in memory-unsafe languages like C and C++, is highly susceptible to memory bugs. These can be broadly categorized as spatial memory bugs (e.g., out-of-bounds (OOB) accesses) or temporal memory bugs (e.g., use-after-free (UAF) or accessing de-allocated objects via dangling pointers). Detecting these bugs is particularly challenging in embedded systems because memory corruptions rarely lead to observable crashes due to the lack of hardware-based memory isolation.

A common and effective strategy to reveal real-world memory bugs is combining a fuzzer with a sanitizer. A fuzzer generates abnormal test cases to trigger violations, while a sanitizer makes memory corruptions more noticeable by instrumenting the code to enforce checks. AddressSanitizer (ASan), a powerful redzone-based sanitizer, instruments software to enforce bounds and validity checks at pointer dereferences, generating immediate alerts. While highly effective in PC environments, ASan’s typical memory overhead (an average of 3.37x) often exceeds the capacity of MCU prototype boards, making its direct application infeasible.

Sanitizers can be broadly classified into redzone-based and pointer-based approaches. Redzone-based sanitizers, like ASan, place "redzones" around memory objects, use shadow memory to track allocation states, and quarantine freed objects for temporal bug detection. While effective, this incurs significant memory overhead. Pointer-based sanitizers, such as CCured, encode pointer capabilities (bounds, validity) as metadata. This metadata is checked before dereferencing the pointer. Modern variants might use disjoint metadata or hardware features. A related concept is memory tagging, which uses a lock-and-key mechanism where memory and its corresponding pointer receive the same tag upon allocation. All accesses must use a pointer with a matching tag, enforcing both spatial and temporal properties. While hardware implementations like Arm MTE are efficient, they are currently exclusive to Arm A-profile processors, not the resource-constrained MCUs typically targeted by firmware development.

Existing approaches to firmware testing face significant hurdles. Emulation-based testing, where firmware is rehosted on a PC (e.g., using Memcheck), promises powerful analysis but struggles with precisely modeling diverse peripherals. This often leads to a lack of fidelity, false crashes, and an inability to accurately reflect real-world hardware interactions. Conversely, on-device testing is severely restricted by the MCU's limited resources. Even if adapted, tools like ASan are often too expensive in terms of memory, and the internal firmware state remains opaque to external analysis, preventing comprehensive understanding of runtime behavior.

Key Findings

▶ Watch: IPEA's key contributions: framework, techniques, discoveries (1:45)

The research presented through IPEA yielded several crucial findings that significantly advance the state of firmware security testing:

• Superior Memory Error Detection: IPEA-San demonstrated exceptional accuracy in detecting memory errors. In qualitative evaluations, it successfully detected peripheral-based buffer overflows and intra-object overflows, capabilities that a memory-optimized port of ASan for MCUs lacked. Quantitatively, on the extensive Juliet Test Suite 59, IPEA-San achieved a perfect record of 0% False Positives and 0% False Negatives. In contrast, the ported ASan initially showed a high 26.95% False Negatives (1,781 FNs), primarily due to its lack of support for the alloca library function. Even after filtering alloca-related tests, ASan still exhibited a 4.83% FN rate (240 FNs), primarily missing non-linear OOB accesses and intra-object overflows. Analysis of 37 CVEs in deeply embedded systems revealed that IPEA-San would be effective in detecting 37.84% of these, including CVE-2021-42553, which ASan cannot find.
• Drastically Reduced SRAM Overhead: IPEA-San significantly mitigated the resource consumption problem on MCUs. It achieved an overall SRAM overhead of approximately 1.14x for real-world applications, a remarkable 62.75% reduction compared to ASan's 3.06x total SRAM overhead. For heap and global data, IPEA-San incurred virtually 0 overhead, with stack overhead reaching a maximum of 2.79x in some cases. This reduction is critical, as ASan failed to compile three real-world applications (U-Disk, MQTT-Echo, HttpServer) due to its demanding SRAM requirements, while IPEA-San successfully compiled all of them. Flash overhead for IPEA-San was comparable to ASan, with a geometric mean of 1.74x, which is less critical given the relative abundance of flash memory in MCUs.
• Manageable Performance Overhead: While IPEA-San introduced a slightly higher runtime overhead compared to the optimized ASan, it remained manageable. It incurred an 86% slowdown for the BEEBS benchmark and a 14% slowdown for real-world applications. This is attributed to the additional code for tracking events and the time spent on SEGGER Real Time Transfer (RTT) transmissions. ASan, by comparison, had a 67% slowdown for BEEBS and 4% for real-world apps, but its higher memory footprint significantly limited its applicability.
• Discovery of Zero-Day Bugs: The combination of IPEA-Fuzz and IPEA-San proved highly effective in identifying novel vulnerabilities. The system successfully discovered seven zero-day bugs in widely used IoT libraries and peripheral driver code. These included:
• Three new global buffer overflows in the JPEGDEC library.
• One new Use-After-Free (UAF) bug (CVE-2023-38749) in the NXP USB driver.
• One new buffer overflow bug in the STM32-WiFi driver.
• One new Denial-of-Service (DoS) bug in the STM32-USB stack.
• One new buffer overflow bug in the SEGGER emUSB-Host.

All discovered bugs were reported to maintainers and subsequently confirmed, highlighting the practical impact of IPEA.

• Indispensability of Real Hardware for Driver Testing: The evaluation unequivocally demonstrated the critical need for testing complex driver code on real hardware. State-of-the-art emulation solutions like Fuzzware 64 struggled significantly with peripheral driver samples (e.g., USB, WiFi), failing to properly initialize them, getting stuck, or generating authentic MMIO responses. This illustrates that emulation often requires extensive manual intervention to remove hard-to-emulate logic, thereby compromising fidelity and coverage. IPEA, by leveraging real hardware, provides high-fidelity testing for such intricate components.

Technical Deep Dive

▶ Watch: Redzone-based vs. Pointer-based sanitizer types explained (3:20)

The core of IPEA's technical approach is a strategic decoupling of the analysis workload between the resource-constrained MCU and the powerful development PC. This addresses the fundamental dilemma where MCUs lack resources for analysis, and PCs lack direct access to the MCU's internal state. The enabling technique for this decoupling is stateless instrumentation.

On the MCU, IPEA deploys lightweight "needle probes" that collect high-fidelity execution information in-vivo. Crucially, these probes are stateless: they simply stream out important events without storing or processing any metadata related to the analysis. All resource-hungry tasks, including the actual analysis and the reconstruction of runtime metadata, are offloaded to the development PC, constituting the ex-vivo aspect. This stateless instrumentation offers two key advantages: it requires only one-way communication from the MCU to the PC, avoiding interactions that could block normal execution, and it drastically reduces memory overhead on the MCU, as no metadata needs to be stored on-chip.

IPEA's design adheres to three critical goals:

• G1: No chip-specific features: The framework avoids reliance on unique hardware features, ensuring broad applicability across different MCUs.
• G2: Real devices, high-fidelity: Firmware runs on actual hardware, not emulators, to guarantee accurate and high-fidelity information collection.
• G3: Minimal memory overhead: The tool is designed to be usable on existing prototype boards without exceeding their limited memory capacity.

These goals are achieved through static instrumentation via LLVM compiler techniques and the aforementioned stateless approach.

IPEA System Overview and Communication

IPEA functions as a flexible firmware testing framework, supporting various analysis plugins. Developers load specific analysis modules, such as IPEA-San or IPEA-Fuzz, onto the PC. The target firmware is compiled using an analysis-specific LLVM pass that inserts the necessary stateless instrumentation. The IPEA core on the development PC, in conjunction with the debug dongle, manages communication with the prototype board via three distinct channels:

1. Upstream execution information channel: Carries collected data from the MCU to the PC.
2. Control command channel: Used for coordinating firmware execution (e.g., suspend/resume).
3. Testcase channel: Transfers test cases from the PC to the board.

The IPEA core on the PC orchestrates the testing environment for each test case. Its responsibilities include programming the instrumented firmware to the MCU's flash, initiating execution, monitoring firmware status, recovering non-responsive hardware, downloading test cases, and receiving runtime data. For efficient and chip-agnostic data exchange (channels 1, 3), IPEA leverages SEGGER Real Time Transfer (RTT). RTT is a market-leading solution, backed by J-Link, which reserves a control block in the MCU's memory for high-speed data transfer without halting the CPU. The IPEA core routes received data packets to the appropriate analysis plugins using a compact tag-value encoding scheme, where each runtime event has a unique header (identification tag) followed by its value.

IPEA-San: Stateless Pointer-Based Sanitization

IPEA-San is a pointer-based sanitizer, chosen over redzone-based alternatives due to several key advantages for resource-constrained environments. Redzone overheads (for redzones themselves and object quarantines) must reside on the firmware, making offloading difficult. Redzone-based solutions can also suffer from false negatives for non-linear OOB accesses or when quarantine memory is exhausted, and they cannot support intra-object bounds checking. Pointer-based solutions, by maintaining distinct metadata per pointer, overcome these limitations and are easily extensible for tracking other information like type safety.

IPEA-San essentially emulates an enhanced Arm MTE hardware feature, with the MCU and PC plugin jointly completing the sanitization. The MCU collects minimal information about four event types: object creation/deallocation, pointer propagation, and pointer dereferences. The PC plugin then reconstructs the full metadata and performs the actual sanitization checks.

IPEA-San Instrumentation Details:

1. Object Creation:

• Heap Objects: After a malloc call, send_to_PC(OP_NEW, base, limit, id) is inserted. id can be the address for in-memory pointers or a compile-time static ID for temporary pointers (local variables/registers). For reentrant code, a call stack is tracked on the PC using send_to_PC(OP_CALLEE, func_id, current_SP) at function prologues.
• Stack Objects: alloca IR instructions are instrumented with OP_NEW events, identified by a compile-time static ID.
• Global Objects: Identified by pointer references to global objects. send_to_PC(OP_PROP, p_id, obj_id) is inserted. Their fixed location and size are pre-shared with the PC.
• Memory-Mapped Peripheral Objects: Detected by assignments of constant non-memory addresses to data structure pointers with volatile qualifiers. These are treated as global objects.
• Intra-object Overflow Detection: For sub-object derivations (e.g., q = &(p->a)), send_to_PC(OP_SUB, q_id, p_id, p, offset, size) is inserted. This assigns a new "overlay tag" for the sub-object, enabling precise bounds checks within a larger allocated block.
• Metadata Maintenance (Object Creation on PC): The PC sanitizer plugin assigns a monotonic tag to each new object. This tag is stored in a shadow memory region, where one byte on the MCU conceptually maps to four bytes on the PC, supporting 32-bit tags. Pointer IDs are mapped to tags using LocalID_Tag (per execution thread) and GlobalID_Tag (shared) hash tables. For OP_SUB events, the plugin checks for a matching parent tag, then assigns a new overlay tag to the sub-object's shadow memory and the derived pointer.

1. Pointer Propagation:

• Intra-procedural Flows: For assignments and arithmetic operations, send_to_PC(OP_PROP, id_dst, id_src) sends out IDs for the source and destination pointers.
• Inter-procedural Flows (Function Calls/Returns): At call sites, send_to_PC(OP_PROP_CALLER, id1, ...) encodes pointer arguments. In callee prologues, send_to_PC(OP_PROP_CALLEE, id1, ...) encodes receiving pointers. For return values, send_to_PC(OP_PROP_RET, id) is inserted at the function epilogue, and send_to_PC(OP_PROP_RET_GET, id) after the call site to receive the returned pointer's tag.
• Metadata Maintenance (Propagation on PC): The PC plugin retrieves the source tag from the ID_Tag tables and assigns it to the destination pointer, creating a new table entry if necessary.

1. Pointer Dereference: These are the "sinks" of pointer propagation. send_to_PC(OP_CHK, start, size, id) is inserted before every pointer dereference (loads, stores, memcpy, memmove).

• Metadata Maintenance (Dereference on PC): On receiving an OP_CHK event, the PC plugin retrieves the pointer's tag, checks for a correct tag overlay in the shadow memory corresponding to the accessed address range, and triggers an alert if a memory error is detected. Dereferences themselves do not change metadata.

1. Object Deallocation:

• At function epilogues, send_to_PC(OP_RET, func_id) informs the PC of function returns.
• Before free calls, send_to_PC(OP_FREE, id) indicates the freed object.
• Metadata Maintenance (Deallocation on PC): OP_RET informs the plugin to reclaim LocalID_Tag entries and mark shadow memory for local objects as invalid (e.g., 0xFFFFFFFF). OP_FREE verifies a valid entry, marks the corresponding shadow memory invalid, and reclaims the entry. This mechanism effectively detects invalid frees, double frees, and subsequent dangling pointer dereferences.

Advanced Features and Optimizations:

• Interrupt Support: IPEA-San is interrupt-aware. Separate LocalID_Tag tables are maintained for user tasks and interrupt handlers. send_to_PC(OP_IRQ, irq_num) is inserted at the handler entry to track context switches, with OP_RET reporting interrupt returns.
• Library Support: For standard libc functions (e.g., strcpy, sprintf), wrappers are provided to determine string lengths (using strlen) and insert OP_CHK for source/destination buffers. For third-party libraries, developers may need to write custom wrappers based on function semantics, identifying pointer dereferences and allocations, and inserting OP_CHK or OP_NEW events. An example given is pxGetNetworkBufferWithDescriptor() in the FreeRTOS TCP/IP stack, which requires extracting size and return value for OP_NEW.
• Optimizations:
• Event Consolidation: Many events can be merged to reduce encoding overhead (e.g., OP_PROP_CALLEE with OP_CALLEE).
• Unnecessary Propagation: Intra-procedural pointer propagation can be optimized out using backward slicing if the pointer is local and not dereferenced or used globally.
• Unnecessary Initialization: Stack object creation events (OP_NEW) can be omitted, as their locations can be recovered on the PC using DWARF debug information and the current stack pointer (from OP_CALLEE).

Demo / Proof of Concept

▶ Watch: Challenges with existing firmware testing methods (4:00)

The practical validation of IPEA’s capabilities came through the implementation of IPEA-Fuzz and its integration with IPEA-San, leading to the discovery of real-world vulnerabilities.

IPEA-Fuzz is a greybox fuzzer, conceptually based on AFL (American Fuzzy Lop), leveraging edge coverage as feedback. Similar to IPEA-San, it employs stateless instrumentation, collecting only basic block transitions on the MCU. The remaining fuzzing logic, including test case generation and coverage analysis, runs on the powerful development PC. For instrumentation, send_to_PC(OP_BB, rand) is inserted at the beginning of each basic block, where rand is a compile-time random number. The PC plugin then emulates AFL's shared_mem bitmap using these received random numbers to track edge coverage. To handle interrupts without skewing coverage, the PC plugin creates a new context on OP_IRQ, saving the previous prev_location and using 0 as the new prev_location. Upon interrupt return, the saved prev_location is restored, allowing coverage calculation to resume from the original context.

A prototype of the entire IPEA framework, including IPEA-San and IPEA-Fuzz, was implemented for Arm Cortex-M series MCUs. It supports any development board compatible with the SEGGER J-Link debug probe, a widely used industry standard. The system was extensively tested and evaluated on seven different development boards, including popular models like NXP FRDM-K64F, FRDM-K66F, LPCXpresso55S69, STM32-NueloF411R, STM32H7B3I-DK, Raspberry Pi Pico, and nRF52-DK. The firmware instrumentation module was built upon LLVM 13.0.0, and a Python script based on pyelftools was used to extract static information from the compiled firmware. The IPEA core was developed using the SEGGER SDK, while the IPEA-San plugin was written in C++ and the IPEA-Fuzz plugin largely inherited from AFL. The development PC used Ubuntu OS with an Intel Core i7-8750H CPU and 16 GB RAM. The project contributed 4,555 lines of C/C++ code and 1,659 lines of Python code, all of which are open-sourced on GitHub and Zenodo.

The fuzzing evaluation targeted a range of real-world software, including popular IoT libraries (JPEG decoder, PNG decoder, XML parser) and critical peripheral driver code (UART, USB, WiFi, microSD). Two fuzzing modes were employed:

• Normal mode: Resets the board for each test case, essential for peripheral drivers to ensure a clean hardware state.
• Persistent mode: Reuses a single long-lived execution, beneficial for IoT libraries where setup overhead is low. For a toy example, persistent mode achieved 276.43 executions/second, significantly faster than normal mode's 12.95 executions/second. While reset time (approx. 70ms) and execution time dominate, reset overhead is amortized for slower drivers.

The fuzzing campaigns, running for up to 24 hours (or longer for particularly slow targets), yielded significant results:

• The toy firmware, designed to test specific error types, successfully revealed 8 bugs.
• The Expat XML parser, a well-known library, had 5 out of 6 known bugs reproduced (missing only a format string vulnerability).
• In the JPEGDEC library, 3 new global buffer overflow bugs were discovered.
• For PNGdec, 1 known CVE was reproduced.
• The NXP USB driver, a critical component, yielded a reproduction of 2 µAFL CVEs and the discovery of 1 new Use-After-Free (UAF) bug, assigned CVE-2023-38749.
• The STM32-WiFi driver was found to have 1 new buffer overflow bug.
• The STM32-USB stack revealed 1 new Denial-of-Service (DoS) bug.
• Finally, the SEGGER emUSB-Host library contained 1 new buffer overflow bug.

In total, IPEA-Fuzz combined with IPEA-San successfully uncovered seven zero-day bugs in real MCU products. All these vulnerabilities were reported to the respective maintainers and subsequently confirmed, demonstrating the tangible impact of the IPEA framework in enhancing the security posture of embedded systems.

A critical aspect highlighted by the fuzzing efforts was the indispensability of real hardware for testing low-level driver code. Such code frequently interacts with complex peripherals, making accurate emulation extremely difficult. When four peripheral driver samples were tested with Fuzzware 64, a state-of-the-art emulation solution, it consistently failed to properly initialize USB/WiFi drivers, either getting stuck or failing to generate authentic MMIO responses. This underscores that existing emulation solutions often necessitate manual removal of hard-to-emulate logic, compromising the fidelity of the testing process. IPEA, by directly involving real hardware, enables streamlined firmware testing with high fidelity, a crucial advantage for complex embedded systems.

Defensive Implications

▶ Watch: IPEA's technical approach: stateless instrumentation benefits (4:20)

The findings from the IPEA framework have profound implications for firmware developers, security researchers, and device manufacturers. The traditional reliance on rudimentary debugging tools for deeply embedded systems is no longer tenable, given the sophistication of modern attacks and the critical role firmware plays in IoT and other connected devices.

Firstly, firmware developers should actively integrate advanced dynamic analysis techniques like IPEA into their development and quality assurance pipelines. The framework offers a practical path to leverage sanitizers and fuzzers, which are standard in general software development but have been historically difficult to apply to MCUs. By adopting IPEA, developers can catch critical memory safety bugs much earlier in the development cycle, reducing the cost and risk associated with post-deployment patches.

Secondly, the talk emphatically highlights the limitations of traditional on-device sanitizers like ASan for MCUs. While ASan is powerful, its inherent memory overhead makes it impractical for many resource-constrained devices, and its design can miss specific classes of bugs, such as intra-object overflows and certain non-linear OOB accesses, which IPEA-San successfully detects. Defenders should prioritize pointer-based, decoupled sanitization approaches for their superior detection capabilities and significantly reduced memory footprint, enabling comprehensive testing on actual hardware.

Thirdly, the indispensability of real hardware for testing peripheral-intensive code is a crucial takeaway. The demonstrated failures of state-of-the-art emulation solutions underscore that abstracting away complex hardware interactions through emulation can lead to significant blind spots in testing. For any firmware that interacts closely with physical peripherals (USB, WiFi, sensors, etc.), testing on the actual target hardware is non-negotiable for achieving high-fidelity results and uncovering real-world vulnerabilities. This implies investing in robust hardware-in-the-loop testing setups.

Finally, the discovery of seven zero-day bugs in popular IoT libraries and vendor-supplied peripheral drivers serves as a stark reminder of the pervasive memory safety issues in the embedded software supply chain. Device manufacturers and integrators must demand higher assurance from their third-party software components and actively employ tools like IPEA to vet these crucial elements. The findings suggest a systemic problem that requires a shift towards more rigorous, automated testing methodologies across the entire embedded ecosystem, moving beyond basic functional testing to embrace deep security analysis.

Key Takeaways

• IPEA solves the firmware testing dilemma by intelligently decoupling resource-intensive analysis from the MCU to a development PC, using a debug dongle for communication.
• Stateless instrumentation on the MCU allows for lightweight, in-vivo data collection without incurring significant memory overhead, making advanced dynamic analysis feasible on deeply embedded devices.
• IPEA-San is a superior sanitizer for MCUs, outperforming memory-optimized ASan by detecting critical bug classes (e.g., intra-object and non-linear OOB) that ASan misses, while drastically reducing SRAM overhead by 62.75%.
• IPEA-Fuzz, combined with IPEA-San, is highly effective at discovering zero-day vulnerabilities, evidenced by the discovery of seven new bugs in popular IoT libraries and peripheral drivers.
• Testing on real hardware is crucial for achieving high-fidelity results, especially for firmware that interacts with complex peripherals, as emulation solutions often struggle to accurately model such interactions.
• The entire IPEA framework, including its sanitizer and fuzzer plugins, along with benchmarks and firmware samples, has been open-sourced, encouraging broader adoption and further research in embedded security.

About the Speaker(s)

Jiameng Shi delivered this insightful talk at the NDSS Symposium, presenting groundbreaking research on facilitating advanced security testing for deeply embedded firmware. The technical depth and practical impact of the IPEA framework highlight Jiameng Shi's expertise in embedded systems security and dynamic program analysis.