Was GL-iNet firmware compromised by the chinese national security law?


after breaches into my systems it was soon clear it is one of my network devices. Since I expected this (somewhat) all network hardware based and manufactured in China Mainland will sooner or later be compromised, it seems like GL-iNet is now. I can proof that to a significant extend, via logs and screen recordings, dns requests by the OS the CCP uses (chinauos.com) their parent which is owned by the (broadly speaking) PLA uniontech.com which has even though I used DNS-OVER-TLS plus a VPN just routed all my requests to and then with "0ms" ping directly to their systems. That worked for them
both with Cloudflare & Nextdns.

Be careful and @Openwrt team pls stop endorsing them, sadly not even HK is free anymore, it seems like the party is over. No cloud features of GL-inet were used/activated and SSH/Dropbear was disabled via Luci, didn't help. Its also suspicious that they only download the .ipk data from their servers, not from the official openwrt repos. Or that somewhere in the memory they must safe the UUID, since all devices I have from them let me reconnect to their cloud without login even after reflashing it with DD-WRT (in one case) in all others when I reflash from original OpenWrt back to GL-iNet Factory. That was always the case though.

Neither I or the VPN connection are remotely close to south-east Asia. Be careful folks.


I really hope I and the logs are somehow wrong but it seems increasingly unlikely.

I might add that I do not intend any harm on them, I do believe though that its out of their hands.

You don't provide much version info on the actual system that you are running...

Are you running and talking about the proper OpenWrt, or GL-iNet's proprietary OS (that is based on an older version of OpenWrt)?

This part seems to indicate that you are running their OS, not the actual OpenWrt.


That is correct, using their (edited) OpenWrt 19.07

I would recommend strongly to reflash the device to original openwrt for anyone.

I trusted them for years and they did a lot of good, its sad that they probably don't do this voluntarily, but I think they can't get around this law.

That information would best be added to the first post, if you can still edit it. Maybe also also add it to the post title, along with the word "suspected".


generally for a fork... i'd consider this good etiquette... and not an indicator in itself of untoward activity...


I didn't claim that its in of itself an indicator, I wouldn't have used their mod for years otherwise.My claim is not far fetched at all + I hope still they can relocate the company somehow or are planning to do this. https://medium.com/technicity/chinese-3-5-2-policy-is-a-major-move-towards-tech-independence-48d178157b3f

Maybe you should contact gl.inet directly, provide them with real logs and ask for a statement. The only thing I see so far is a screwed up screenshot - nothing more.

BTW, @alzhao


I provide proper logs gladly to a moderator, it's just that... if you read the law and consider the crackdown in HK plus the fact that they manufacture the hardware in Shenzen or the fact that it would be illegal to not follow the "national" "security" law is not helping the situation.

Sure, it is possible that Chinese routers contain stuff related to local regulators. And sure, those rules may not always be in benefit of the end-users... But from a neutral point, there might be chinese DNS servers as the default fallback options in their OS. (Those might even be quite openly in the /etc/config/dhcp config file, or similar.)

But so far you have not provided much info on the context: how you think you have configured your DNS, what were you doing, what were you expecting to happen, and what you think actually happened... is the localhost, the router itself.
The screenshot mainly shows failing DNS queries if I understand it correctly.
One query to dns.nextdns.io succeeds, right?

Note that is used by some adblockers to direct traffic to the router instead of the blocked ad sites. (e.g. dibdot's adblocker used that technic originally, but then switched to the nxdomain strategy)


Yes thats why it can't be real, like 0ms to a server in Beijing from the "West"
"(should be 3-500ms, depending on the connection)

That is the issue, some stuff is wrong and has "bugs" OpenWrt has not. OpenWrt would cancel the connection bc of different reasons, at least for sure when the TLS fails to connect to the provided server.


If you care you should know that their product was clean of ccp govt bullshit. Changes...

you do realize 90% (guestimate) of all electronics is made in China, right ?

With the same logic applied, your home theatre receiver, or any other device containing electronics, are just as "unsecure" as your GL.iNet device.


Yes, ofc. I am talking about a company I trusted for years until yesterday. None of the chips they use are designed in China, they are manufactured in Taiwan for the most part aka they are good to go.

They were good to go! Now I posted this thread because there have been strange changes on the software-side and on the official forums are strange answers given like "if you don't trust us use stock OpenWrt" whereas before they would always help their customers.

In addition to that in years their devices never connected to govt-linked servers before - now they (for whatever reason) do point to a unique closed source ccp-ubuntulike OS. (http://chinauos.com/)

I did not know such a thing exists, I got it through the logs and its as you imagine.

As said I hope they are basically ASAP out of reach of the national sec law and just continue to do the good work they did to this point. But I doubt it, logs don't lie.

I am the last person who would want that all to be the truth but I can't deny reality. At the very least they were hacked on a major level. As said, I do not wish or necessarily say that this is intentional by the GL-iNet team.

Well, as you said

they gave you the correct way.

But I understand that's not the point.


Even though one can use OpenWrt's "stock" firmware, instead of GL-Net's custom version, there is still GL-iNet code executed before loading OpenWrt firmware. Who knows what is going on there?

You mean uboot?

It loads on most routers, and a lot of other devices too.

But it's open source, you can always check the code, and compile one yourself.

Want to feel 'safe', disconnect from internet, completely.

Calm down and reflash it with stock OpenWrt


My SOP is every device first thing out of the box gets flashed with current OpenWrt. I mean the assumption should be that your device is compromised from the start and that was always true from any mfg, Tp-link, Netgear, D-Link, whoever.

I also update my managed switches first thing out of the box. At one point my firewall was blocking my managed switches IP address from routing to the internet. I should check that again.


I have a bunch of GL.inet mini routers sitting in a drawer and I would lite to "independently validate" the claim, could you post instructions to reproduce what you did?

Also others can do the same so we can figure out if this is indeed a valid claim or if it happens only on your end.

I'm not going to flash DD-WRT, but as I said below there should be no need to.

Its also suspicious that they only download the .ipk data from their servers, not from the official openwrt repos.

No it is not suspicious, they are not official OpenWrt so they don't (and shouldn't) use offical OpenWrt repos.
All downstream projects based on OpenWrt never ever pull stuff from OpenWrt but host their own repos.
OpenMPTCP router, ROOTER, FreiFunk and other mesh network projects in germany, and many more. Nobody uses official repos because they are not official OpenWrt.

All routers have flash space dedicated to store serial numbers and MAC addresses and wifi calibration firmware and such factory data. It is usually in a "factory" or "ART" partitions that OpenWrt or DD-WRT don't edit (as it would break the device wifi in many cases).

Also both OpenWrt and DD-WRT can read some of the data in this partition (usually the mac address, maybe more) so yeah if their cloud see a device that reports itself as same MAC and same serial number they get recognized correctly. That's how that service identifies devices, see the section about "adding manually a device" of their documentation

1 Like

Yeah, security in embedded device firmwares is a sad joke, someone on this forum posted that someone hacked his router and flashed OpenWrt on it. His router was on the list of unpatched remote-exploits so someone could have done this over the internet, no problem.

1 Like

anyone that can read and compile the source code. GL.INet posts all their device uboot (bootloader) source code. https://github.com/search?q=org%3Agl-inet+uboot

And even then, the bootloader exists only for a few moments on boot. When the firmware starts, the linux kernel takes full control and the ram used by the bootloader is reclaimed.

GL.Inet remains much better than average, no other manufacturer give you a "ready to compile" version of their bootloader and firmware.
At most you get some GPL code drops of random stuff for the kernel, and that's it, you know nothing about bootloader or rest of the userspace.