TP-Link Archer A6 v4.0 — LLM-Assisted Router Penetration Testing
A 48-hour LLM-assisted security assessment of the TP-Link Archer A6 v4.0, a popular AC1200 consumer WiFi router based on the MediaTek MT7626 “Leopard” SoC (ARM Cortex-A7). The research combined manual penetration testing with AI-assisted protocol reverse engineering, firmware binary analysis, and exploit development. 8 security vulnerabilities were discovered, including 2 rated Critical. The latest available firmware (1.14.30 Build 250729) was verified to contain all findings unfixed.
Target
| Product | TP-Link Archer A6 (AC1200 MU-MIMO Wi-Fi Router) |
| Hardware | Version 4.0, MediaTek MT7626 “Leopard” (ARM Cortex-A7, ARMv7) |
| Operating System | TPOS 5 (TP-Link Proprietary RTOS) |
| Firmware Tested | 1.13.6 Build 240430 and 1.14.30 Build 250729 (latest) |
| API Protocol | Custom encrypted: XOR token auth + AES-128-CBC + RSA-512 GDPR transport |
| Region | EU (SpecialId 0x5545) |
Methodology
The assessment used an LLM-assisted workflow at every stage:
- Claude (Anthropic) as primary AI assistant for code generation, protocol analysis, and ARM binary reverse engineering
- Local Ollama models (Qwen 2.5 14B, DeepSeek Coder v2) on GPU server for firmware RE assistance and multi-model consensus validation
- Capstone disassembly engine for ARM Cortex-A7 binary analysis
- Custom Python tooling built during the session: authenticated API client (XOR+AES+RSA), 6 injection test suites, SSH key simulator, automated verification suite
Phase 1: Protocol Reverse Engineering (Hours 0–2)
Dumped and analyzed 25+ JavaScript files from the router’s web interface. Reversed the three-layer encrypted authentication protocol: XOR token generation with pre-encrypted password, AES-128-CBC transport with random session key, and RSA-512 key exchange (GDPR compliance layer). Built a fully functional Python API client from scratch, achieving authenticated access to all 106 configuration data blocks. The LLM processed minified JavaScript, identified crypto operations across multiple files, and generated working Python implementations — what might take a day of manual RE was accomplished in under 2 hours.
Phase 2: Systematic Injection Testing (Hours 2–8)
Executed 120+ test vectors across 6 rounds of testing:
| Round | Target | Vectors | Result |
|---|---|---|---|
| 1 | systool ping/tracert injection | 12 | No shell — internal parser |
| 2 | Parameter format manipulation | 30 | Whitelist + atoi() parsing |
| 3 | Admin instruction injection | 45 | Stored injection in 5 fields |
| 4 | Service trigger (CWMP/NTP/DDNS) | 15 | No execution triggered |
| 5 | ECB config restore attack | 5 | Payloads persist through reboot |
| 6 | HTTP code gap analysis | 30+ | OEM crash + syslog leak found |
The router’s systool instruction handler proved well-hardened against command
injection — using an internal key:value parser that never invokes /bin/sh,
system(), or popen(). The instruction whitelist accepts only 5 commands:
systool ping, systool tracert, systool sntpc,
main lm -add/-del, and advanced ISP -websave.
Phase 3: Firmware Reverse Engineering (Hours 8–14)
Downloaded the firmware from tp-link.com. The 1.6MB TPOS image was initially
misidentified as AES-128 encrypted; multi-model LLM consensus correctly identified it
as LZMA-compressed with a non-standard properties byte (0x6E). Decompressed to a
4.3MB ARM binary. Disassembled
7 critical functions using Capstone:
- Bootloader image validation — reversed the firmware integrity check and image loading sequence
- HTTP request dispatch — mapped all handler routing logic including undocumented code paths
- Flash storage handlers — identified critical input validation gaps in privileged write operations
- Authentication subsystems — traced key management and credential processing across multiple protocol layers
- Network service modules — determined root cause of unexpected service behavior through configuration analysis
- Debug interfaces — discovered development/test functionality present in production firmware builds
Phase 4: Discovery, SSH Access & Verification (Hours 14–20)
The combined application testing and firmware RE revealed 8 vulnerabilities. A debug SSH
service (TPOS 5 IPSSH Test) was found running on port 22, accepting password
authentication with the web admin password. While shell/exec channels are disabled, TCP port
forwarding works — enabling network pivoting into internal loopback services (IPC on
port 23, DNS on port 53). An automated verification suite was built and run against the
latest firmware — 1 out of 8 findings was fixed
(unauthenticated syslog disclosure now returns HTTP 403).
Findings summary
8 vulnerabilities discovered, including 2 Critical. Specific details are withheld pending responsible disclosure.
| Severity | Count | Categories |
|---|---|---|
| Critical | 2 | Unvalidated flash write, debug service exposure |
| Medium | 4 | Input validation, DoS, CSRF, information disclosure |
| Low–Medium | 2 | Default credentials, weak cryptography |
Key numbers
| Metric | Value |
|---|---|
| Test vectors executed | 120+ |
| Injection test rounds | 6 |
| JavaScript files reversed | 25+ |
| Configuration blocks mapped | 106 |
| ARM functions disassembled | 7 |
| TPOS binary (decompressed) | 4.3 MB (fw 1.13.6) / 4.9 MB (fw 1.14.30) |
| Vulnerabilities found | 8 (2 Critical, 4 Medium, 2 Low) |
| Fixed by firmware update | 1 / 8 |
| PoC scripts with --proxy | 7 |
| Research duration | ~48 hours |
What worked with LLM assistance
- Protocol reverse engineering — dramatically accelerated. Minified JavaScript to working Python client in under 2 hours.
- Test vector generation — 120+ diverse payloads covering injection, encoding bypass, format string, overflow, and ECB attacks.
- ARM binary analysis — effective without Ghidra/IDA. Traced call chains, identified function boundaries, interpreted literal pools.
- Multi-model consensus — querying multiple LLMs independently avoided tunnel vision. Correctly identified LZMA compression when the primary model concluded AES encryption.
- Safe exploit development — SSH key format simulator validated 7/9 OpenSSH formats against the disassembled handler before any live testing.
Honest assessment
The router’s systool instruction handler is genuinely well-hardened —
120+ injection payloads confirmed it never passes user input through a shell. The httpd uses
a strict instruction whitelist with internal key:value parsing. This level of hardening is
commendable for a consumer device.
However, the critical findings (unvalidated flash write handler, debug SSH service in
production) represent a different class of vulnerability — not coding errors in
user-facing features, but development/debug interfaces left enabled in production
firmware. The HTTP_WRITEOEM handler crashes on any non-“list”
input because it was never designed for adversarial use. The SSH service banner literally
says “Test”.
The firmware upgrade from 1.13.6 to 1.14.30 fixed only 1 of 8 findings (unauthenticated syslog disclosure now returns HTTP 403). Binary comparison of both TPOS images confirmed all vulnerable code paths are present at shifted offsets (+9.1% binary size increase). This suggests these issues are not on the vendor’s radar.
Disclosure status
A detailed vulnerability report has been prepared and encrypted with TP-Link’s
PGP public key (0xB75C8303). The report will be submitted to TP-Link PSIRT
([email protected]) with a 90-day disclosure window. Specific vulnerability
details will be published after the disclosure period or upon vendor remediation, whichever
comes first.
This research was conducted on personally owned equipment in an isolated laboratory. All stored injection payloads were cleaned up and the router restored to its original configuration after testing.