Code injection attacks on harvard-architecture devices

Harvard architecture CPU design is common in the embedded world. Examples of Harvard-based architecture devices are the Mica family of wireless sensors. Mica motes have limited memory and can process only very small packets. Stack-based buffer overflow techniques that inject code into the stack and then execute it are therefore not applicable. It has been a common belief that code injection is impossible on Harvard architectures. This paper presents a remote code injection attack for Mica sensors. We show how to exploit program vulnerabilities to permanently inject any piece of code into the program memory of an Atmel AVR-based sensor. To our knowledge, this is the first result that presents a code injection technique for such devices. Previous work only succeeded in injecting data or performing transient attacks. Injecting permanent code is more powerful since the attacker can gain full control of the target sensor. We also show that this attack can be used to inject a worm that can propagate through the wireless sensor network and possibly create a sensor botnet. Our attack combines different techniques such as return oriented programming and fake stack injection. We present implementation details and suggest some counter-measures.

💡 Research Summary

The paper presents the first remote code‑injection attack that permanently writes malicious code into the program memory of Harvard‑architecture wireless sensor nodes, specifically Atmel AVR‑based Mica motes. While Harvard architectures separate program and data memories, making classic stack‑based buffer overflows ineffective for code injection, the authors exploit the AVR’s special instructions—SPM (Store Program Memory) and ELPM (Extended Load Program Memory)—to bridge this gap.

The attack proceeds in four stages. First, a carefully crafted payload is embedded in a tiny network packet (≤28 bytes) that triggers a buffer overflow in a vulnerable function. By overwriting the return address, the attacker redirects execution to a Return‑Oriented Programming (ROP) chain composed of existing code “gadgets” that include SPM calls. This ROP chain writes a small amount of data into a flash sector, establishing a foothold in program memory.

Second, the attacker constructs a “fake stack” in SRAM, loading the full malicious payload (the code to be permanently installed) into this region. Third, a second ROP chain is invoked to repeatedly call SPM, copying the fake‑stack contents into a previously unused flash page. The authors address flash alignment, page boundaries, and the limited write‑cycle budget by padding the payload and minimizing the number of SPM invocations.

Finally, the newly written code is made executable by corrupting another control‑flow element—either a return address in the bootloader or a function pointer used during system initialization—so that after a reboot the node automatically jumps to the injected code. The result is a permanently compromised sensor that can execute arbitrary logic without further external triggers.

To demonstrate practicality, the researchers implemented the attack on Mica2 and MicaZ platforms. After successful injection, the malicious code acts as a worm: it scans for neighboring nodes, crafts the same overflow payload, and transmits it over the wireless link. In simulated network topologies, the worm spreads to the entire network after only a few packet exchanges per node, effectively turning the sensor field into a botnet capable of coordinated actions, data exfiltration, or denial‑of‑service attacks.

The paper also surveys counter‑measures. At the hardware level, restricting SPM execution to privileged code or disabling it entirely mitigates the core primitive. Compiler‑based defenses such as stack canaries, address space layout randomization (ASLR), and strict bounds checking reduce the likelihood of a successful overflow. Network‑level protections include packet size limits, authentication of control messages, and rate‑limiting of flash‑write requests. Runtime monitoring of flash‑write counts can detect abnormal activity and trigger a safe‑mode reboot or firmware rollback.

In conclusion, the authors argue that Harvard architecture does not guarantee immunity from code‑injection attacks; low‑level instruction misuse can bypass the logical separation of memories. Their work expands the threat model for embedded devices, showing that permanent code injection and worm propagation are feasible even on highly constrained platforms. The findings underscore the need for multi‑layered security designs that consider both architectural features and the specific instruction set capabilities of microcontrollers.