Responsible disclosure in progress 2026-04-04

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.

IoT Router Firmware RE ARM Cortex-A7 MediaTek MT7626 8 vulnerabilities 2× Critical Responsible disclosure

Target

ProductTP-Link Archer A6 (AC1200 MU-MIMO Wi-Fi Router)
HardwareVersion 4.0, MediaTek MT7626 “Leopard” (ARM Cortex-A7, ARMv7)
Operating SystemTPOS 5 (TP-Link Proprietary RTOS)
Firmware Tested1.13.6 Build 240430 and 1.14.30 Build 250729 (latest)
API ProtocolCustom encrypted: XOR token auth + AES-128-CBC + RSA-512 GDPR transport
RegionEU (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:

RoundTargetVectorsResult
1systool ping/tracert injection12No shell — internal parser
2Parameter format manipulation30Whitelist + atoi() parsing
3Admin instruction injection45Stored injection in 5 fields
4Service trigger (CWMP/NTP/DDNS)15No execution triggered
5ECB config restore attack5Payloads persist through reboot
6HTTP code gap analysis30+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.

SeverityCountCategories
Critical 2Unvalidated flash write, debug service exposure
Medium 4Input validation, DoS, CSRF, information disclosure
Low–Medium 2Default credentials, weak cryptography

Key numbers

MetricValue
Test vectors executed120+
Injection test rounds6
JavaScript files reversed25+
Configuration blocks mapped106
ARM functions disassembled7
TPOS binary (decompressed)4.3 MB (fw 1.13.6) / 4.9 MB (fw 1.14.30)
Vulnerabilities found8 (2 Critical, 4 Medium, 2 Low)
Fixed by firmware update1 / 8
PoC scripts with --proxy7
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.