Persistence Techniques on Embedded Devices
Getting onto a device is one thing; staying there across reboots and firmware updates is another. Persistence is how an attacker keeps access after the initial compromise, and on embedded systems it has its own shapes because the storage, the boot process, and the update mechanism differ from a PC. Understanding persistence matters for both attacking and defending a device.
Why Persistence Is the Real Goal
An attacker who has to re-exploit a device on every reboot has a fragile foothold. Persistence converts a one-time compromise into lasting control, surviving power cycles and, in the worst case, firmware updates meant to remove it. For anyone defending a fleet, persistence is what turns an incident into an ongoing breach.
On embedded devices persistence is often easier than on a hardened PC, because the same lack of integrity checking that let the attacker in lets them modify the system that boots. The flip side is that understanding where persistence hides tells a defender exactly what to protect and what to inspect when a device is suspected of compromise.
The Writable Filesystem Question
The first thing that shapes persistence is whether the root filesystem is writable. Many embedded devices use a read-only SquashFS root with a small writable overlay for configuration. An attacker has to land their persistence in the writable area, or find a way to modify the read-only image, which the storage layout decides.
mount | grep -E 'squashfs|jffs2|ubifs|overlay'
/dev/mtdblock2 on / type squashfs (ro) /dev/mtdblock5 on /overlay type jffs2 (rw)
A read-only root with a writable JFFS2 overlay tells the attacker exactly where they can persist: the overlay, and the configuration and scripts that live there. It also tells a defender that anything outside the overlay should match the signed image, which is the basis for detecting tampering.
Startup Scripts and Services
The most common persistence is the oldest: add or modify a startup script so the attacker’s code runs at every boot. The device’s init system, whether a classic rcS, a set of init.d scripts, or a systemd unit on larger devices, is the target, and the writable overlay is usually where a persistent entry lands.
# an attacker's persistence appended to a writable startup script
cat /overlay/etc/init.d/rcS.local#!/bin/sh # legitimate config restore... /tmp/.sysmon & # <-- attacker's implant, launched every boot
A backdoor launched from a startup script runs with whatever privilege the init system has, usually root, on every boot. It is simple, reliable, and exactly what a defender should look for: an unexpected entry in a startup script, or a script that does not match the signed firmware, is a classic sign of compromise.
Cron and Scheduled Persistence
Where cron is available, a scheduled job gives persistence that also recovers itself: a job that re-installs the implant if it is removed, or that periodically phones home. Because cron entries are easy to overlook, they are a favored hiding place, especially on devices where an init-script change might be noticed.
crontab -l; cat /overlay/etc/crontabs/* 2>/dev/null
*/10 * * * * /tmp/.sysmon || cp /overlay/.backup/.sysmon /tmp/.sysmon
A cron job that re-deploys the implant if it is missing makes simple removal ineffective, because the implant comes back ten minutes later. This self-healing pattern is why incident response on a compromised device has to find and remove every persistence mechanism, not just the running process.
Modified Legitimate Binaries
Subtler persistence replaces or patches a legitimate binary so the malicious behavior rides along with normal operation. A trojanized BusyBox, a patched service daemon, or a wrapped login program runs the attacker’s code whenever the normal function is used, with nothing obviously out of place in the process list.
Detecting this requires comparing the on-device binaries against the known-good signed image, because a modified binary looks normal by name and location. A hash mismatch on a system binary is a strong tamper signal, which is why a defender benefits enormously from having the original firmware to compare against, the same image an attacker used to plan the compromise.
Persisting in Configuration
Not all persistence is a binary. Configuration that the device acts on can carry it: a malicious DNS server, an added SSH key, a startup command embedded in a settings field, or a U-Boot environment variable that alters the boot. These hide in data rather than code, which makes them easy to miss.
cat /overlay/etc/dropbear/authorized_keys 2>/dev/null fw_printenv 2>/dev/null | grep -iE 'bootcmd|preboot'
ssh-rsa AAAAB3...attacker-key... # added key grants remote root preboot=run malicious_script # bootloader env hijack
An added SSH key grants the attacker remote access that survives reboots and looks like a legitimate key, and a hijacked bootloader environment runs attacker code before the OS even starts. Configuration-based persistence is among the hardest to spot precisely because it does not change any binary.
Bootloader and Below
The deepest persistence sits in the boot chain, where it survives even a firmware reflash of the application. A modified bootloader, or persistence in a region the update process does not overwrite, can re-infect the device after an update that the owner believes cleaned it. This is the embedded equivalent of a bootkit.
Defending against this is exactly what secure boot and verified boot are for: if each stage verifies the next, a modified bootloader or kernel will not run. A device without that verification can be persisted at a level no software update reaches, which is why boot-chain integrity is the foundation that makes the higher-level detections meaningful.
Surviving a Firmware Update
The strongest persistence survives the update meant to remove it. If updates do not wipe the writable overlay, persistence there carries across. If the update does not verify and replace the whole image, a modified component can remain. And persistence below the application, in the bootloader or a protected region, can outlast a normal update entirely.
This is the worst case for a defender, because the standard remediation, push a clean firmware update, fails. It is also why update design matters for security: an update that fully replaces and verifies the image, and that resets the writable areas where persistence hides, is what guarantees a compromised device can actually be cleaned.
Detecting Persistence
Detection comes down to comparing the device against its known-good state. Hash the binaries against the signed image, inspect the startup scripts and cron jobs for unexpected entries, check authorized-keys and configuration for additions, and verify the bootloader and boot environment. Anything that differs from the signed baseline is suspect.
# compare on-device files against the known-good firmware image
for f in $(find /overlay -type f); do
sha256sum "$f"
done > device_hashes.txt
diff device_hashes.txt golden_overlay_hashes.txtA diff against a golden baseline surfaces exactly what changed, which is the core of detecting persistence. The prerequisite is having that baseline, the signed image and the expected configuration, which is why a device designed with integrity verification in mind is also a device you can actually investigate when something goes wrong.
Designing Against Persistence
The defenses are the familiar ones, aimed at the levels persistence uses. Verified boot stops modified boot components and binaries from running. A read-only, signed root filesystem limits where persistence can land. An update process that fully replaces and verifies the image, and resets writable areas, removes the survive-the-update case. Together they leave an attacker very little ground.
For a product team, the takeaway is that preventing persistence is mostly about integrity: the device should run only what it can verify, and should be able to return to a known-good state on demand. A device built that way denies an attacker the lasting foothold that turns a momentary compromise into a permanent one, which is the difference between an incident and a breach.
Where This Fits
Assessing how an attacker would persist on a device, and whether the design can detect and remove that persistence, is part of a thorough product security assessment. If you want to know whether a compromise of your device could be made permanent, and survive your updates, that is the kind of work we do at Berkner Tech.