--- title: "Whose router is it? Reverse-engineering a Digi Comtrend GRG-4355u" url: "https://quantarmy.com/en/reverse-engineering-the-digi-comtrend-grg-4355u-router/" description: "Taking control of a Comtrend GRG-4355u fiber router (Digi) without opening the case: a chain of four management-plane weaknesses, firmware pulled over the network, and how we turned it into a neutral, hardened router. With a threat model and a responsible-research note." lang: "en" --- # Whose router is it? Reverse-engineering a Digi Comtrend GRG-4355u The router your ISP hands you is a small OpenWrt you don't fully control: a low-privilege account that can rewrite its own permissions, a root hash in DES, and a TR-069 agent your operator uses to reconfigure the box remotely. This is the reverse engineering, what we found, and how we took back control — no secrets, no recipes. Nov 4, 2026 · 16 min read · [Leer en español](https://quantarmy.com/ingenieria-inversa-router-digi-comtrend-grg-4355u/) - [sec](https://quantarmy.com/tag/sec/) The router your operator hands you isn't entirely yours. You pay for it in the monthly bill, it lives in your home and carries your traffic, but its firmware is the ISP's call, there are accounts you can't see, and through a remote-management channel the operator can reconfigure, update or re-provision it whenever it likes. For a security reader that's a threat-model question: **who really controls this device, and what can an attacker with the sticker credentials do?** This article answers that for a concrete case: the **Comtrend GRG-4355u** that **Digi** ships for fiber. We reverse-engineered it —without opening the case, no UART, no JTAG, over the local network only—, found a chain of weaknesses leading from a guest account to root, and then turned it into a neutral, hardened router that no longer answers to the operator. All on our own equipment and line. **Responsible-research note.** Everything below is on an owned device, on an owned line, on the LAN, with reversible changes and documented rollback. We publish no credential, no hash, no serial number, and no step-by-step recipe: this is an analysis of **vulnerability classes and their significance**, not a weapon against an ISP's fleet. One detail worth telling: the AI guardrail we worked with refused to perform the interactive root login itself, so a human ran those steps. Security is also done that way. ## The ecosystem: a vendor OpenWrt with shared owners Before touching anything, the inventory. The GRG-4355u is made by **Comtrend** (even though Digi distributes it), runs an **Airoha EN7581** SoC (four ARM Cortex-A53 cores), and inside runs a **vendor OpenWrt** with the **LuCI** interface, kernel **5.4.55**, under the firmware label **DIG-1.3.22**. The units we've seen report hardware 1.1 or 1.2. The interesting part isn't the hardware photo but the map of who's in charge of it: Who controls what: three LAN management planes and one remote ISP one - **Accounts:** there's an `admin`, a low-privilege `user` —whose credentials usually come on the sticker— and a `root`. The catch: logging in over SSH with the normal accounts doesn't give a Linux shell but a **restricted vendor CLI** (`/sbin/cli`). - **The web plane:** LuCI talks over HTTPS to `rpcd`/`ubus`, OpenWrt's call bus. That's where configuration decides what each login may read and write. - **A hidden control layer:** besides the standard firewall (UCI), the vendor installs `cxt_acl_lan`, its own access control **outside** UCI. That is, there are rules deciding which ports are open that you **can't see** in the normal firewall config. - **The ISP, above everything:** a **TR-069 / CWMP** agent connects to the operator's management server (ACS) over a separate management VLAN. That channel can push config, firmware and credentials. The homeowner can't turn it off from the interface. That last piece is the article's thesis: the device's strongest trust link isn't local, it's the operator's. ## Reverse engineering: from guest to root, over the network The goal wasn't to open the case. The challenge was to start from what anyone has —the low-privilege sticker credentials and LAN access— and see how far it goes. It goes all the way to root, by chaining four management-plane weaknesses. The chain, at the vulnerability-class level: no commands, just the mechanism **V1 · The authorization plane breaks itself.** The first weakness is the most elegant and the gravest. In `rpcd`, each login has a permission list. The low-privilege account belongs, by factory configuration, to a group that lets it **write the very configuration that defines its permissions**. Put another way: *a restricted account can edit the rules that restrict it* and promote itself to wildcard permissions. No memory exploit needed; it's an authorization-model failure. It's also the part the project itself prepared for publication, because it's the lesson: the privilege boundary was drawn wrong. **V2 · Exfiltrate the firmware over the network.** With broad permissions, the next step is to get the firmware, of which there's no public copy. No UART needed: an authenticated download endpoint of the web stack itself serves whole files **including raw block devices**, which lets you dump entire flash partitions over HTTPS. It's a class of flaw —file/block reads beyond what's intended— that turns an authenticated session into firmware and NVRAM exfiltration. (The exact request stays out: that's the weaponizable part.) **The offline analysis, and the prize: DES crypt in 2026.** With the `rootfs` in hand (a compressed `squashfs`), you extract `/etc/shadow`. And there's the finding a security reader spots instantly: the factory `root` password hash uses **traditional DES crypt** —the 1970s scheme, 56-bit, only 8 significant characters—, obsolete for decades. It cracks offline without effort. A current-generation router in 2026 storing its root hash in DES is a first-order hygiene failure. **V · The wall wasn't the password.** An instructive detail: having the root password wasn't enough, because the SSH port timed out. Not because of crypto or the password, but because that hidden vendor layer (`cxt_acl_lan`) had the SSH service **disabled by policy**, outside the visible firewall. The owner enables it from the vendor's access control and port 22 opens. Lesson: there's security-relevant state the interface doesn't show you. **V3 · Clean persistence.** Oddly, changing root's password from the interface fails ("unauthorized user"), but file writing is available with the elevated permissions. So persistence was done the standard OpenWrt way: **an SSH public key in root's `authorized_keys`**. Key-based login, without touching `/etc/shadow`, and with the `admin`/`user` accounts intact. Reversible by deleting a file. **V4 · The CLI shortcut.** And in case that wasn't enough, the vendor CLI stores its privileged-mode ("enable") password as a **double base64** in config, readable by the low-privilege account. That isn't encryption, it's obfuscation: it decodes trivially. A vendor secret stored with reversible encoding is, in practice, a cleartext secret. ### What this means In classes: **broken authorization** (V1), **firmware exfiltration** by block reads (V2), **weak hash and default password** (DES crypt), **hidden control layer** (`cxt_acl_lan`) and **obfuscated, not encrypted, vendor secret** (V4). None requires physical access. Anyone with the sticker credentials and the LAN can, in principle, pull the whole firmware, the NVRAM, and get persistent root. And since the operator manages the device over TR-069, the remote-management plane is as critical as the local one. ## What we did next: a neutral, hardened router Finding root is the fun half. The useful half is taking back control of the device and leaving it fast, robust and under your command, without breaking fiber. Everything that follows is reversible and designed to survive a reboot. The hardened router, and why own firmware doesn't go on the GRG **Autonomy: TR-069 out.** First, remove the TR-069/CWMP agent (`easycwmp` and the related packages) and disable its daemons. With that, **the operator stops managing, updating and re-provisioning the device automatically**. It's the change that returns the most control: the router now boots from its saved configuration, with no ACS deciding for you. **Reversible debloat.** A home router ships with a pile of services you don't use and that are attack surface: VoIP, DLNA/Samba/FTP, multicast proxy, UPnP, DDNS, SNMP, assorted telemetry. The optimization script turns off around **22 services**, saving state so it can be reverted. Key: it's done with an allowlist of what's **never** touched —the PON stack (the fiber), the firewall, `dropbear`, `rpcd`, `uhttpd`, DNS/DHCP, NTP— so nothing essential breaks. **The optimization we deliberately *didn't* do.** Here's the interesting engineering call: **no SQM, no BBR/buffer tuning**. It sounds counterintuitive, but the EN7581 does NAT in hardware (HW NAT/PPE); adding software queues or rewriting buffers **would pull traffic off the hardware path and make it slower**. The AQM is already done by the chip's own queues. The only network tuning was raising `conntrack_max` (from 16,384 to 65,536) and lowering the console log level. Technical honesty: the CPU governor change was noted but on the EN7581 turns out to be a *no-op* (it stays `userspace`), so it doesn't count as an improvement. **Robustness and persistence.** The changes live in the *overlay* (UBIFS), so they **survive a reboot**. A factory reset does wipe them —by the device's design—, which is why the project has an automated re-entry that puts the router back into its known state without manual work. Every change has its rollback procedure. **The neutral router.** The end goal was to put *your* router behind it and use the GRG only as an ONT. You can, by bridging the Internet VLAN (20) to the 10 Gb port (LAN5): the GRG acts as a dumb ONT and your router routes. In our setup, a second box also ended up as a dumb access point for Wi-Fi. ## And own firmware? The honest verdict The natural question for anyone who gets this far: *why not flash real OpenWrt and forget the vendor firmware?* The answer, after evaluating it, is that **today it isn't viable on the GRG** if you want to keep fiber. The reason is the SoC. The EN7581 is both the router and the **ONT** (the optical part), and the whole fiber stack —the PON MAC kernel modules, Airoha's network daemon, the OMCI stack— is **closed binary** and tied to kernel 5.4.55. Upstream OpenWrt has basic EN7581 support (Ethernet, Wi-Fi, routing) but **does no PON**: flashing it means losing fiber. Reusing the vendor blobs on a modern OpenWrt doesn't work either: the 5.4.55 modules won't load on 6.x kernels and nobody has ported the EN7581 PON stack. The realistic alternatives, then, don't go through the GRG: - **An "8311" SFP ONT stick** (the ONT in a transceiver) in your own router's SFP cage, programmed with the line's identity. Your router is the router; the operator only controls the stick over OMCI. - **Bridge mode**, which is what we left set up: the GRG as a bridged ONT with your router behind it. Saying "you can't, and here's what you can" is part of the craft. An honest result is worth more than a promise that bricks the fiber. ## Threat model and what we take away - **The management plane rules everything else.** It doesn't matter how strong the Wi-Fi password is if a local account can rewrite its own permissions and the operator can push config over TR-069. A router's security is decided by who controls its management, local and remote. - **Defaults at fleet scale are the real risk.** A trivial password and a root hash in DES crypt, if common across the fleet, expose every unit to the same local compromise. DES in 2026 is a hygiene failure that's hard to justify. - **Obfuscation isn't encryption.** A double base64 "protecting" a vendor secret is a cleartext secret with an extra step. The same goes for any "encoding" an attacker undoes in their head. - **There are control planes you can't see.** A vendor firewall outside UCI, or a TR-069 you can't turn off from the interface, mean you don't have full visibility of your own device's security state. Taking it back —removing TR-069, mapping `cxt_acl`— is part of hardening. - **Research your own, and with a brake.** Own equipment, own line, LAN, reversible changes, and no publishing what arms a third party. A guardrail stopping your root login so a human runs it isn't an obstacle: it's the responsibility model working. The living-room router turned out to be a complete security target: broken authorization, firmware exfiltrable over the network, 1970s cryptography and an operator with a control channel the owner can't see. Turning it into a neutral, fast device under your command was the reward; the trust map —and who's really in charge— is what we take away. ## Resources - **OpenWrt** — the system the vendor firmware is built on and the reference alternative: [openwrt.org](https://openwrt.org/). - **The 8311 project** — firmware for SFP ONT sticks, the realistic path to your "own router" on fiber: look for the 8311 community. - On **TR-069 / CWMP** and remote CPE management: the Broadband Forum standard (TR-069). // Versión en español · [¿De quién es tu router? Ingeniería inversa de un Comtrend GRG-4355u de Digi](https://quantarmy.com/ingenieria-inversa-router-digi-comtrend-grg-4355u/) ## More in sec Nov 4, 2026 · 20 min ### [Turning an e-reader into your own system: reverse-engineering the Kobo Libra 2](https://quantarmy.com/en/reverse-engineering-kobo-libra-2-plato/) A 512 MB e-reader with an i.MX6SLL SoC, no secure boot, and a user partition you can mount over USB. We reverse-engineered its boot, wrote an init that verifies the system by sha256 on every boot, and turned Plato into the whole OS. This is the process, the results, and what broke along the way. [sec](https://quantarmy.com/tag/sec/)