Netgear’s firmware poses a significant national security risk by secretly rerouting DNS requests through China Telecom, a state-controlled entity. This action compromises user privacy and national security by embedding unseen vulnerabilities in consumer networking devices. In an era of global digital interconnectedness, safeguarding the integrity of these devices is critical. Despite recent efforts to repair their reputation, these measures do not compensate for what can be seen as their extraordinary incompetence, or potentially something more sinister
Keep in mind: you’re not supposed to be seeing any of this. I was only able to access this using the NSA’s Ghidra reverse engineering tool (a software framework for analyzing and understanding code). For decades, even from the most charitable perspective, Netgear hard‑coded IP addresses to send domain name service requests directly to Chinese state‑owned internet companies—specifically China Telecom, which has been targeted by U.S. government sanctions/restrictions.
Netgear has used the same Chinese software in its routers for years, yet it only now cries foul about its competitor, TP‑Link, with whom it effectively dominates the wireless router market in the United States.
Several critical questions arise: Why would Netgear embed a concealed DNS backdoor in its routers? Why did a company founded by Chinese national Patrick Lo employ proprietary firmware developed by Kcodes, a Chinese company based in Taiwan, to facilitate such a backdoor? More significantly, why was this backdoor configured to route traffic through an IP address integral to the Chinese state-owned internet backbone? Compounding these concerns, the firmware is designed to override all manual user changes to the router, rendering user attempts to block these ports ineffective.
Patrick Lo has been celebrated as some kind of American immigrant-entrepreneur ideal; meanwhile, he was a key figure—at a pivotal time—in helping produce hardware that quietly enabled the repression of his fellow countrymen behind the Great Firewall for personal profit. Great guy. Who knows what he was doing with the America data…
A few years ago, while scanning open ports on my network, I noticed an obscure port, 20005, that remained constantly open. No matter which user settings I changed, it remained accessible. I later discovered not only that this port was permanently exposed, but also that its encryption key was hardcoded and trivial to bypass. Once bypassed, you could access their proprietary opcodes, which operate under secretive rules and timing protocols that add complexity. If you’re curious to explore your own network, try running a simple port scan using tools like nmap to identify any unexpected open ports. This can be an eye-opening step in understanding potential vulnerabilities in your setup.
Rather than dwell on these opcodes (though I did experiment with them at the time), I shifted my focus to mastering encryption—a journey that became a lifelong training ground. Recently, however, I found time and renewed interest to reverse‑engineer my router’s firmware.
Not only did I build a tool to identify both public and secret opcodes within Netgear’s NetUSB feature, but I also developed another tool to test and measure poorly constructed stack memory and heap boundaries, which are still present today and can be exploited. This vulnerability potentially affects millions of devices in circulation, given that Netgear and TP-Link together dominate a significant portion of the U.S. consumer router market. According to public reports, Netgear and TP-Link collectively account for over 60% of the U.S. consumer router market. This represents a considerable exposure, translating to potentially over 50 million devices that could be at risk from these security flaws. The scope of routers still using this compromised stack highlights the urgent need for extensive security measures.
Netgear’s NetUSB feature is not an in-house implementation. It is based on a proprietary kernel-level networking and USB-sharing stack developed by KCodes, a third-party vendor headquartered in Taiwan, in accordance with its “One China” principle.
NetUSB operates with kernel-level access, enabling it to control critical aspects of device memory that are inaccessible from user space. This level of access is analogous to possessing a master key for the entire system. While device owners may expect to control these settings, the firmware’s unrestricted authority often supersedes user intent. NetUSB can modify and enforce settings, such as maintaining open ports like 20005 and the less-documented 20006 for IPv6, regardless of user intervention. This architecture explains why user attempts to adjust certain settings have no lasting effect.
In the disassembly, it’s not behaving like a normal userland daemon at all — it ships its own kernel‑space socket shim (ks_socket, ks_bind, ks_listen, ks_connect, etc.) that just thunks straight into the Linux kernel socket entry points (kernel_bind, kernel_listen, kernel_connect, kernel_setsockopt, kernel_sock_shutdown). In other words, it’s not “asking nicely” through user space; it’s operating at the layer that actually creates and owns the sockets.
If it wasn’t bad enough that NetUSB provides a persistent back door you can’t override the settings for—on a service that’s been antiquated (no longer even usable) for over half a decade—they let it sit there unaddressed anyway. And it’s not dead code, either: those ks_* wrappers are referenced all over the place (NetUSB data‑path calls like KTCP_put/KTCP_get, plus the connector/announce threads), and there are separate init paths for IPv6 (init_ipv6_*, tcpV6Main, netusb_udp6_main) sitting right next to the IPv4 ones. So the “20005/20006” behavior isn’t some rumor — it matches an architecture that clearly expects both stacks to be alive.
At this stage, I observed numerous calls to specific IP addresses and the presence of hardcoded features that enable opening ports for peer-to-peer communication. The firmware also sends regular heartbeats every 5 seconds to indicate an active connection, all through a designated ‘debugging’ interface.
You can literally see the scaffolding for this in the call graph: routines like udpAnnounce and tcpConnector are wired into the same kernel‑socket layer (hitting ks_setsockopt, ks_sendto, ks_close, etc.), which is exactly what you’d expect from a design that maintains a persistent “I’m alive” signal and a ready‑to‑connect channel. On the send side, it’s not doing some high‑level library call — it builds a struct msghdr + iovec and pushes it through sock_sendmsg(), which is about as “close to the metal” as it gets in Linux networking.
Keep in mind, these “debugging” services are separate from the NetUSB features, although they sit in the same sub‑application — meaning their memory and plumbing are closely related, and it becomes far easier to call into adjacent code paths even if they aren’t “officially” part of the same feature.
That separation is basically organizational, not defensive: you’ve got a whole parallel “debug” surface living in the same blob (run_telnetDBGDServer, run_acktelnetDBGDServer, close_DebugD, even a dedicated sender path like kc_dbgD_send that ultimately routes into the same ks_send implementation). And it’s using the same primitives (ks_accept/ks_recv/ks_send) as everything else. Once it’s in memory, it’s all in the same neighborhood.
The firmware facilitates the creation of sockets, the exchange of status notifications with any IP address, and the establishment of connections. The next focus is the specific IP address involved in this process.
Consumer routers typically allow users to set their own DNS servers, honoring these preferences to enable a personalized networking environment. However, as I dig further into this Chinese Kcode kernel system, which Netgear licenses and grants practically root-level memory and power access, a very specific DNS IP address shows up: 8.8.8.8, the standard Google DNS resolver.
Although I do not endorse Google, my primary concern is that this DNS address is not visible in the main user-accessible sections of the system. Instead, it is embedded within the proprietary Kcode firmware. The system does not simply make standard DNS requests; rather, it is hardcoded to use Google’s DNS, which is notably inaccessible from within China.
Ruijie Networks (Translation)
Why does a Chinese networking guide reference 8.8.8.8 even though Google is blocked?
In the context of that Chinese documentation, 8.8.8.8 is not being presented as a usable DNS resolver. It’s being used as a canonical placeholder—a globally recognizable DNS address that endpoints are likely to generate traffic toward, regardless of whether that traffic is ever intended to succeed.
That distinction matters because the feature being described is DNS forward proxying, not DNS resolution. In this model, 8.8.8.8 functions as a trigger, not a destination.
In Chinese enterprise and ISP environments, it’s commonly assumed that endpoints will be configured with “public DNS” values (often 8.8.8.8, 114.114.114.114, etc.), but that those packets will never actually reach those resolvers. Instead, the router intercepts the DNS request before it leaves the network, rewrites the destination IP, and forwards it to a resolver chosen by policy (China Telecom, China Unicom, and so on). Whether Google DNS itself is reachable is irrelevant—the packet is never meant to get there. The effective logic is simple: if the user sends DNS to 8.8.8.8, silently rewrite it to our resolver.
This is not “normal libc DNS,” either. The firmware blob includes its own resolver logic (ks_gethostbyname) and performs networking directly via ks_sendto and ks_recvfrom, crafting and transmitting raw DNS packets. That design is precisely how DNS behavior is hidden from user settings and from the places administrators normally look.
In ks_gethostbyname, the resolver IP is explicitly hard-coded as a constant (0x08080808 → 8.8.8.8) and executed through a direct sendto() → recvfrom() cycle. If no response is received, the code does not consult system DNS, respect DHCP, or defer to any user-configured setting. Instead, it overwrites the destination with a second hard-coded constant (0x060761CA, bytes ca 61 07 06 → 202.97.7.6) and retransmits the same DNS request.
That is not a reliability fallback. It’s a resolver selection list baked directly into the firmware.
The firmware module performs its own DNS lookups by crafting raw DNS packets, sending them first to 8.8.8.8, and—on failure—silently falling back to 202.97.7.6, completely bypassing the DNS configuration you believe you control.
This is where it becomes far more suspicious: unlike the Google address, the fallback is not a generic “alternate DNS.” It is intentionally hard-quoted into the firmware as the only other option.
So this is not “whatever DNS the router learned from DHCP” or “whatever the user typed in.” It is a resolver decision tree embedded in code the user cannot see, audit, or override—allowing the firmware to redirect DNS traffic to a completely different resolver without consent or visibility.
What 202.97.7.6 actually is
202.97.7.6 is widely recognized as a public recursive DNS resolver associated with China Telecom, one of China’s largest state‑owned telecommunications providers and a core operator of China’s national internet backbone. This is not an edge cache or a consumer router—it’s the kind of upstream infrastructure that sits in a position to observe, log, and influence resolution at scale.
Functionally, that means any device sending DNS queries to 202.97.7.6 is:
Handing domain‑resolution visibility to China Telecom, routing name‑resolution traffic through infrastructure subject to PRC law and policy, and creating a dependency on a resolver environment where centralized monitoring and control are not hypothetical — they’re part of the reality.
From a networking standpoint, the address is significant because it is:
Globally reachable, not limited to China, commonly seen as a hard‑coded resolver in legacy/OEM firmware built for that ecosystem, and part of the same backbone environment where state‑level monitoring and traffic shaping are structurally feasible.
When 202.97.7.6 appears as a hard‑coded DNS endpoint—or as a silent fallback—in consumer router firmware sold abroad, it’s not just “another DNS server.” It’s a direct dependency on foreign, state‑controlled core internet infrastructure for one of the most sensitive and revealing layers of network traffic: DNS.
Why does China Telecom matter in this context?
China Telecom is not just a foreign ISP; it is a state-owned enterprise that has been repeatedly flagged by the U.S. government for national-security concerns. In recent years, China Telecom has faced U.S. sanctions and regulatory actions after U.S. agencies concluded that its operations and network access posed an unacceptable risk of data exposure, surveillance, and influence by the Chinese government.
Those actions were based on findings that China Telecom is subject to PRC national intelligence and cybersecurity laws, which legally compel cooperation with state intelligence services. As a result, any data transiting China Telecom infrastructure—including DNS metadata—is considered potentially accessible to the Chinese state. This is why U.S. regulators ultimately moved to revoke China Telecom’s authority to operate telecommunications services in the United States.
That context matters here: when consumer router firmware silently hardcodes a fallback DNS resolver operated by China Telecom, it creates a direct dependency on infrastructure that the U.S. government itself has deemed incompatible with U.S. national security interests. This is not a hypothetical risk, nor a matter of political opinion—it is the explicit basis on which those sanctions and restrictions were imposed.
It is important to consider several implications of DNS hijacking, even under the most favorable circumstances.
In this case, the presence of hard‑coded resolver addresses—rather than exclusive reliance on user‑configured DNS—indicates that name resolution decisions are being made at a level the user cannot override. That distinction matters: it means DNS behavior is governed by firmware logic, not by network policy or user intent. When the resolver logic is implemented inside a proprietary kernel‑adjacent module that already owns its own sockets (ks_*) and its own resolver (ks_gethostbyname), it’s structurally designed to bypass exactly the knobs you’re “supposed” to be able to use as an owner/admin.
Short‑term implications (immediate, practical harm)
At a basic level, DNS enables activity mapping and profiling. Queries expose which services a user or household interacts with—banks, employers, healthcare portals, cloud providers, messaging platforms, and IoT endpoints. Even when HTTPS is used correctly, DNS metadata alone is often sufficient to construct detailed behavioral profiles.
Control over DNS infrastructure also enables selective interference or “nudging.” A resolver operator can degrade, delay, or intermittently fail lookups for specific domains, creating subtle pressure toward alternative services or causing outages that are difficult to diagnose or attribute.
DNS visibility further enables targeting and exploitation. Resolver logs make it easier to identify device types, vendors, and exposed services in use across a population, improving the effectiveness of phishing campaigns, credential harvesting, and device‑specific attacks.
Finally, when large numbers of consumer devices silently funnel DNS traffic to the same external resolver, it becomes possible to correlate activity across devices and locations, even as IP addresses change. Over time, this enables persistent tracking at the household or organizational level.
Long‑term implications (strategic and systemic)
At scale, aggregated DNS data from consumer routers and IoT devices provides population‑level intelligence: a durable map of what platforms, services, and institutions people and businesses rely on. That data has obvious value for economic intelligence, influence operations, and strategic targeting.
There is also a serious supply‑chain governance issue. When firmware silently overrides user DNS settings or enforces unreachable resolver endpoints, network operators lose the ability to apply local policy—whether for security monitoring, compliance, filtering, or incident response. Control shifts away from the network’s owner to the vendor and, by extension, to any third party the vendor depends on.
Over time, this normalizes covert control mechanisms in consumer infrastructure. Once hidden resolvers and non‑overrideable behaviors are accepted, it becomes easier to justify more aggressive measures later—such as forced resolvers, domain blocking, mandatory logging, or traffic shaping—regardless of which state or corporate actor is in control.
Even in the absence of proven malicious intent, the result is an erosion of trust. DNS sits upstream of nearly all internet activity; when users discover routing decisions are being made outside their knowledge or control, the reputational and regulatory consequences for vendors are inevitable.
Why DNS is uniquely sensitive
DNS is not just “where do I go?”—it is often the first, most consistent, and most observable step in nearly every connection. If name resolution is routed to a party the user did not choose—whether by design, misconfiguration, or coercion—the privacy, integrity, and autonomy of the entire networking stack are weakened from the outset.
Despite the significant time and effort required for this research, I developed a tool to identify and assess various memory exploits in the NetUSB kernel, enabling simultaneous reverse engineering of both public and undocumented opcodes.
Full disclosure: I have not fully explored every possible exploit due to time constraints. However, it would not be difficult for an attacker to use NetUSB opcodes to manipulate addresses, enabling the redirection of connections, signals, and data transfers to the China Telecom IP rather than any intended ‘debug’ destination.
TP‑Link and Netgear together account for most of the U.S. consumer router market. One of the routers, the Netgear R7000, was among the most popular in the country for years; all of them have this back door built in. Worse, when you start uncovering the secret kernel/Telnet‑adjacent commands in NetUSB, they get flagged as proprietary TP codes because these companies are clearly pulling from the same ecosystem.
The hypocrisy in Netgear’s China‑influence narrative
Netgear’s recent attempts to single out TP‑Link for alleged Chinese influence ring hollow when viewed against its own history. For years, Netgear shipped routers running proprietary third‑party firmware that embedded hard‑coded networking behaviors users could not override, including DNS and connectivity logic operating below user control. Those design choices—opaque, persistent, and enforced at the firmware level—mirror the high risks Netgear now warns consumers about.
This is what makes the posture hypocritical: Netgear is not a neutral outsider suddenly alarmed by foreign influence in consumer networking equipment. It is a company that benefited for years from the same cost‑driven outsourcing, shared codebases, and opaque firmware practices common across the router market. Calling out a competitor only after regulatory and reputational pressure mounts does not erase that legacy—it highlights it.
In that light, Netgear’s criticism of TP-Link reads less like principled concern and more like strategic deflection. If hidden control paths, non-overrideable firmware behavior, and foreign dependencies are unacceptable risks, then accountability has to apply equally, including to Netgear itself. To ensure consumer safety and maintain trust in the future, it is crucial for regulators to enforce stringent firmware transparency standards. Vendors should immediately review and update any existing products with hidden control paths, and users are encouraged to demand full disclosure of firmware origins and updates from manufacturers. By taking these steps, we can collectively work towards a secure and reliable networking environment. By empowering ourselves and demanding accountability, we can push for a safer, more transparent tech landscape.
Do I have more faith in TP‑Link than Netgear? No. If you don’t see the nation‑state back door potential in this entire supply chain, you are an idiot.
On a final, purely amusing statistical anomaly I encountered during my research… There’s basically a 0% chance of two people sharing the exact opposite IPv4 address.
We are now familiar with China Telecom’s use of 202.97.7.6
Check out who / what / where is using 6.7.97.202. It could be pure coincidence, but if I had to make a wild shot in the dark, it has some beneficial relationship to endianness, capitalizing on how different systems interpret instructions and various orders. Endianness refers to the order of bytes and how computer architectures process numerical data. For example, a little-endian system stores the least significant byte first, while a big-endian system stores the most significant byte first. This anomaly could affect IP handling in firmware, possibly influencing how data is read from or written to memory. Such implications might affect exploitability, as inconsistencies in IP interpretation could lead to unexpected behavior or vulnerabilities. But at a minimum, it’s kind of amusing…
The IP address anomaly 6.7.97.202 is the byte-reversed form of 202.97.7.6 (little-endian vs. big-endian representation). While statistically improbable as a coincidence, it suggests possible testing artifacts or endianness-related logic in firmware. Worth flagging for deeper analysis.
