I just take a look at the firmware. Can you provide the content of ubi0:ubi_Config (/var/config)?

ubi cannot be disabled because it is used to mount the config partition.

tr142 (kernel module + tr142_app) is loaded via the following path:
insdrv.sh -> rtk_tr142.sh

However I am not sure if it can be easily disabled because it is referenced in the following binary: axel, boa, monitord, omci_app, smuxctl, startup.
You can try nuking it in insdrv.sh and see if the device still boots.

ccom_linkkit is linked inside /bin/startup. Theoretically building a new statically linked ccom_linkkit should work.

Depending if they actually check for error code, you might get away with replacing ccom_linkkit with inert binary like id:


Also looks like iot-auth-global.aliyuncs.com is actually dead. Depending on which server you hit, you get a 302 to different location. I did not have the hardware to test this, but it seems hardcoded to lookup using the following DNS server: 223.5.5.5, 223.6.6.6, 8.8.8.8.

Completely untested, all based on static analysis and non expert understanding.

This post has been edited by kwss: Jul 24 2024, 09:15 AM

I reverse engineer ccom_linkkit.
It is basically built on top of AliOS Things, which can be found here:
https://github.com/alibaba/AliOS-Things

The vulnerabilities seems to be many of the components are old and never updated.
After looking at some of the CVE, potentially exploitable in the real world are:
CVE-2024-2466
CVE-2024-23775
CVE-2024-6197

I am limiting my CVE search to within these 2 years based on the state of AliOS Things repo.
No doubt there are other known CVE but I feel they are a bit "hard" to exploit.
If I am the attacker I would just focus on the above CVEs.

I only check for curl, cjson and mbedtls. I did not go look at the other long list of components.
This is really some intense time consuming work.

As for boa, I let this article do the talking:
https://www.theregister.com/2022/11/23/micr...boa_web_server/

This post has been edited by kwss: Jul 27 2024, 07:38 AM

This whole speed drop thing is still a mystery.
It might be malware, might be something else, might be a lot of things.

I don't think I will spend that kind of time to finally prove what caused it. Or maybe I get lucky.

I don't even know where to look right now.

You should make a fuss out of it to MCMC. I hope the pressure will stop TM from giving ONR to people.

Just wondering. Did you torrent or transfer lots of data after you turn on VPN?
If you turn on VPN and do nothing, does the speed still drop?

I'm not aware of such thing in D-Link but currently I suspect the 2.5G switch chip is overheating.
In the white D-Link, this external switch chip doesn't exist. All the functionality is provided by the SoC.

Do you happen to put the device in a confined space?

You have experiment and can trigger the speed drop as many times as you want just by connecting to VPN?

What VPN protocol did you use?

Just to be clear. You establish the VPN from your computer and not via the ONR right?
Do you use UDP or TCP for your OpenVPN?

As far as I know, middlebox don't have any special rules for OpenVPN, unlike IKE, GRE or some other protocol.

With bridge mode most of the control logic are turned off. Either something is happening at the OMCI or my earlier suspicion, the external switch chip.

But none of these know you are using OpenVPN.

Just to rule out the switch chip:
Can you try iperf between the 2.5G port and the other 1G port?
Just blast them with bi-directional data

Do you happen to use a USB-C dock?
What about other device? Can they reconnect?
What about already connected devices? Do they continue to work?
What if you manually disconnect your phone while you are home? Can it reconnect?
Can you pinpoint it to a single device that cause this issue?

Can you try changing the 5GHz Wi-Fi to non-DFS channel?

Did you have this problem since the day you get the D-Link or only these few days?
Do you have non-Apple device? Do they work?

Security is a continuous, persistent and long term practice.
The product owner / developer must not only keep up with CVE but also practice secure software development.

The trouble with home router in general is they don't practice this since their goal is just pump out as many new model as possible.

For this D-Link model, their use of boa after it has long EOL shows they never bother in the first place. It's not possible to fix it without massive overhaul.

Personal opinion: Politician cannot fix this. It's not a one time thing.

TM also have a practice of giving lowest cost stuff and treat them as one off procurement instead of going for long term support.

The only home router with long term support I know is Asus. No other brand offer anything remotely close to their long firmware cycle.

Want security? Go for Enterprise product.

Yes you see product like Cisco has a lot of security vulnerabilities. That's because they actively get reported and fixed.

FYI, boa was discontinued in year 2005, almost 20 years ago. That's a heck of a long time in the security world. It's like running Windows ME in year 2024.

This post has been edited by kwss: Oct 27 2024, 04:03 PM

Anime4000
Did the Zyxel has the same GPON SoC as the D-Link?
Is the Zyxel an off the shelf ONR or is it specifically customized for ISP?

The problem with a lot of OpenWRT porting is the board cannot use vanilla kernel due to binary blob.
The specific roadblock I can see in D-Link ONR is all the proprietary initialization sequence are in startup binary. Maybe you can swap those with your own one from PON stick.

But since you have the Realtek SDK, does it comes with the toolchain for the GPON SoC?

Do both Zyxel and D-Link has the same mtdblock layout?
If yes then it should be just re-use the "dtb" and "kimage" from D-Link.
Replace all the kernel module in Zyxel "rootfs" with D-Link and it should just boot?

Maybe copy over those OEM config from D-Link too, as it contains the hardcoded mesh key, VoIP config, etc?