Whose router is it? Reverse-engineering a Digi Comtrend GRG-4355u

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:

• 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.

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.

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.
• 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).