Obtaining root access to the ONT Sercomm RV6688 by contact closure
Once, the author wanted something new to replace the good one, and he decided to connect to GPON from one well-known operator. And the author was put into the apartment a magic box through which one could make phone calls, surf the Internet and watch TV, and a real optical cable was brought into it. And this box is called optical network terminal (ONT) Sercomm RV6688, it was made by order of this very operator and is painted with the corresponding logo.
The box works. But the author did not sit, and again he wanted something more, and he decided to make out (sya) how all this magic inside the box is obtained and whether it can be finely controlled. But what magic can be without surprises.
What could be found on the topic on the Internet. In addition to the admin account that is known from the user manual admin with admin rights “below the baseboard”, we managed to unearth a “secret” (not listed here) account with extended support rights on technical forums, which gives more degrees of freedom, but does not allow you to look deep into ONT operating system. Also mentioned were “holes” in the web interface through which it was possible to increase the rights of users, but which were quickly eliminated in new firmware and therefore lost their relevance.
Experience with such equipment suggested that the ONT somewhere should have a port for servicing. Usually this is an RS-232 serial port, which (rarely) is output to the outside in a D-sub connector with 12V levels or is present on the board in the form of a pin block with TTL levels of + 5V or + 3.3V, i.e. pure UART without an additional voltage level conversion chip. Often, the Linux console is displayed on this port, which is called the tty * device in Linux (after all, no one doubts that it is inside ONT Linux? :)) and the console bootloader Redboot, U-boot, Barebox, etc. Access to this console is provided would have a wide field of action. But I did not find the external connector.
In general, I stuck to these assumptions when I started to unscrew the ONT. For aesthetes, a few words about the sticker-seal of protection. The plastic case of the RV6688 can be “tricky” slightly opened without breaking the seal. If you slightly “strain” the fastening of the sealed screw on the bend, you can even remove the board, which was done.
ONT Board:
A quick inspection of the board after a glance at the optical module for a few seconds revealed a likely candidate for the same service port. And the signatures of RX, TX, GND only strengthened this opinion. A multimeter test showed that this is a UART with levels of 3.5V.
Service Port:
At that moment I didn’t have the USB <-> UART (TTL) adapter on hand, but I had an Arduino Mega 2560 board, which acted as a signal converter. Just in case, I poured an empty sketch into it that does not use UART mega (translates the inputs into a high impedance state).
Arduino Mega 2560 as a USB <-> UART converter:
Next, build a simple cable, connect to a PC, launch your favorite Tera Term terminal program. And finally, the satisfaction of displaying the expected lines of the boot log with an invitation to interrupt the boot process for 1 second and enter the U-Boot loader environment. At the end of the boot, a Linux login prompt appears. But none of the known ONT login / password pairs came up, so the next step in the study was to enter the U-Boot bootloader environment, which would make it possible to control the Linux boot process, including possibly allowing you to bypass the login prompt!
Start loading output:
And now we would have to relax and, while drinking coffee, slowly looking through the U-Boot environment variables, but ONT developers presented an interesting surprise.
It turned out that the combination Ctrl + C does not work, and entering the U-Boot environment at this stage is not possible! I tried many other and even random key combinations, changed the settings of the terminal program, and the communication speed. To no avail. I suspected that sending data from a PC (RX to ONT) did not work, but at the end of the boot procedure, when the login Linux prompt appeared, keyboard input already worked. In general, working at the keyboard could not give anything. (I think there is still some kind of key combination, but ...)
I finished my cold coffee and thought about the situation. Eureka was not long in coming. At boot time, the processor reads the flash memory diligently in accordance with the steps in this download. Loads the bootloader and its parameters until it is prompted to interrupt the download and then reads the kernel of the system, etc. after one second of waiting. The idea was simple: at the moment when the countdown ticks on the screen, block the ability to read data from flash. The boot procedure will be interrupted (read error), and the transition to the U-boot console will be performed to correct the boot parameters (at least as I thought :)). Of the possible implementation options, the following was chosen as the least labor-intensive and, in my opinion, moderately safe. I decided to short the legs 43, 44 flash chips after starting the bootloader and thus block the correct reading of data at the time after a one-second delay. Which was implemented using a thin screwdriver. It turned out from the third attempt, when I more confidently began to “poke” with a screwdriver.
Flash legs:
Here is the attempt to boot with shorted lines of flash data from the moment of the reverse report:
As you can see, at the end, the U-boot command prompt appeared. Let's see what's inside (printenv):
Now you can tweak the variables. We will increase the wait pause to 3 seconds and replace the Init process with the shell / bin / sh (Why do we need login? No, we do not need login). Those. Let's make a simplified single-user download.
We will save the changes (saveenv) and run run bootcmd or just distort the power of the ONT.
Now we wait until the ONT is fully loaded without any manipulation with a screwdriver.
The last lines of the download log:
Hooray, we are at rootfs.
In conclusion, a recommendation on how to increase permissions for users connecting via SSH.
Those who worked with this ONT on SSH have seen that they are not launching a very traditional Linux shell. In ONT, it is called the CLI. I found the configuration file / var / cli_pw, which contains information about CLI users (primarily SSH users) and has a syntax similar to / etc / passwd
It does not make sense to add a user record directly to this file, as every reboot / var / cli_pw is overwritten from a configuration stored elsewhere. Therefore, I used the autorun script / etc / rcS to add my user to / var / cli_pw. Each reboot this command is executed. Add something like this to / etc / rcS:
Vi editor to help.
Accordingly, user alex will have full administrator rights when connecting via SSH to ONT.
Now you can return the U-Boot variables to their original values and enjoy root access.
The box works. But the author did not sit, and again he wanted something more, and he decided to make out (sya) how all this magic inside the box is obtained and whether it can be finely controlled. But what magic can be without surprises.
A starting point
What could be found on the topic on the Internet. In addition to the admin account that is known from the user manual admin with admin rights “below the baseboard”, we managed to unearth a “secret” (not listed here) account with extended support rights on technical forums, which gives more degrees of freedom, but does not allow you to look deep into ONT operating system. Also mentioned were “holes” in the web interface through which it was possible to increase the rights of users, but which were quickly eliminated in new firmware and therefore lost their relevance.
Own way
Experience with such equipment suggested that the ONT somewhere should have a port for servicing. Usually this is an RS-232 serial port, which (rarely) is output to the outside in a D-sub connector with 12V levels or is present on the board in the form of a pin block with TTL levels of + 5V or + 3.3V, i.e. pure UART without an additional voltage level conversion chip. Often, the Linux console is displayed on this port, which is called the tty * device in Linux (after all, no one doubts that it is inside ONT Linux? :)) and the console bootloader Redboot, U-boot, Barebox, etc. Access to this console is provided would have a wide field of action. But I did not find the external connector.
In general, I stuck to these assumptions when I started to unscrew the ONT. For aesthetes, a few words about the sticker-seal of protection. The plastic case of the RV6688 can be “tricky” slightly opened without breaking the seal. If you slightly “strain” the fastening of the sealed screw on the bend, you can even remove the board, which was done.
ONT Board:
A quick inspection of the board after a glance at the optical module for a few seconds revealed a likely candidate for the same service port. And the signatures of RX, TX, GND only strengthened this opinion. A multimeter test showed that this is a UART with levels of 3.5V.
Service Port:
At that moment I didn’t have the USB <-> UART (TTL) adapter on hand, but I had an Arduino Mega 2560 board, which acted as a signal converter. Just in case, I poured an empty sketch into it that does not use UART mega (translates the inputs into a high impedance state).
Arduino Mega 2560 as a USB <-> UART converter:
Next, build a simple cable, connect to a PC, launch your favorite Tera Term terminal program. And finally, the satisfaction of displaying the expected lines of the boot log with an invitation to interrupt the boot process for 1 second and enter the U-Boot loader environment. At the end of the boot, a Linux login prompt appears. But none of the known ONT login / password pairs came up, so the next step in the study was to enter the U-Boot bootloader environment, which would make it possible to control the Linux boot process, including possibly allowing you to bypass the login prompt!
Start loading output:
BL LILAC STARTER VER-2.1.06.0-BL (Aug 26 2013 - 17:00:31)
SOC ID: BL_23570
Init DDR3.... 128MB
Attempt to boot from NAND...
Try to load bootloader from boot bank 0
Bootloader Loaded to DRAM
Cache enabled, start bootloader...
....
Enter 'Ctrl+C' to stop autoboot: 0
....
And now we would have to relax and, while drinking coffee, slowly looking through the U-Boot environment variables, but ONT developers presented an interesting surprise.
It turned out that the combination Ctrl + C does not work, and entering the U-Boot environment at this stage is not possible! I tried many other and even random key combinations, changed the settings of the terminal program, and the communication speed. To no avail. I suspected that sending data from a PC (RX to ONT) did not work, but at the end of the boot procedure, when the login Linux prompt appeared, keyboard input already worked. In general, working at the keyboard could not give anything. (I think there is still some kind of key combination, but ...)
I finished my cold coffee and thought about the situation. Eureka was not long in coming. At boot time, the processor reads the flash memory diligently in accordance with the steps in this download. Loads the bootloader and its parameters until it is prompted to interrupt the download and then reads the kernel of the system, etc. after one second of waiting. The idea was simple: at the moment when the countdown ticks on the screen, block the ability to read data from flash. The boot procedure will be interrupted (read error), and the transition to the U-boot console will be performed to correct the boot parameters (at least as I thought :)). Of the possible implementation options, the following was chosen as the least labor-intensive and, in my opinion, moderately safe. I decided to short the legs 43, 44 flash chips after starting the bootloader and thus block the correct reading of data at the time after a one-second delay. Which was implemented using a thin screwdriver. It turned out from the third attempt, when I more confidently began to “poke” with a screwdriver.
Flash legs:
Here is the attempt to boot with shorted lines of flash data from the moment of the reverse report:
Enter 'Ctrl+C' to stop autoboot: 0
UBI: mtd1 is detached from ubi0
Creating 1 MTD partitions on "nand0":
0x000000100000-0x000000200000 : "mtd=1"
UBI: attaching mtd1 to ubi0
UBI: empty MTD device detected
UBI: create volume table (copy #1)
UBI error: ubi_scan_get_free_peb: no eraseblocks found
UBI error: ubi_init: cannot attach mtd1
UBI error: ubi_init: UBI error: cannot initialize UBI, error -28
UBI init error -28
ERROR: failed to select 'cfg' partition
Creating 1 MTD partitions on "nand0":
0x000000100000-0x000000200000 : "mtd=1"
UBI: attaching mtd1 to ubi0
UBI: empty MTD device detected
UBI: create volume table (copy #1)
UBI error: ubi_scan_get_free_peb: no eraseblocks found
UBI error: ubi_init: cannot attach mtd1
UBI error: ubi_init: UBI error: cannot initialize UBI, error -28
UBI init error -28
ERROR: failed to select 'cfg' partition
Creating 1 MTD partitions on "nand0":
0x000000100000-0x000000200000 : "mtd=1"
UBI: attaching mtd1 to ubi0
UBI: empty MTD device detected
UBI: create volume table (copy #1)
UBI error: ubi_scan_get_free_peb: no eraseblocks found
UBI error: ubi_init: cannot attach mtd1
UBI error: ubi_init: UBI error: cannot initialize UBI, error -28
UBI init error -28
ERROR: failed to select 'cfg' partition
=>
As you can see, at the end, the U-boot command prompt appeared. Let's see what's inside (printenv):
=> printenv
bootcmd=blboot
baudrate=115200
consoledev=ttyS0
modetty0=115200n8
mtdids=nand0=nand
mtdparts=mtdparts=nand:0x100000(starter),0x100000(cfg),0x200000(uboot0),0x200000(uboot1),0x100000(cal),0x400000(linux0),0x400000(linux1),0x2800000(rootfs0),0x2800000(rootfs1),0x800000(sc_config),0x100000(bbt)
mem_reserve_low=tm=0x1400000 mc=0x400000 dsp=0x200000
EMACS_GRP_MODE=QSGMII
EMAC=EMAC0
E4_MODE=NONE
ethact=ETHMAC0
bootdelay=1
update_uboot=tftp a9d00000 u-boot.bin;blnp uboot;saveenv
update_kernel=tftp a9d00000 uImage;blnp linux;saveenv
update_rootfs=tftp a9d00000 rootfs.img;blnp rootfs;saveenv
bootargs=ubi.mtd=0 ubi.mtd=11 root=ubi0_0 rw rootfstype=ubifs console=ttyS0,115200
xx=dd
filesize=CEB800
fileaddr=A9D00000
gatewayip=192.168.1.254
netmask=255.255.255.0
ipaddr=172.21.17.188
serverip=172.21.17.155
boot_ver=1110
ethaddr=d4:21:22:xx:xx:xx
memsize=128M
stdin=serial
stdout=serial
stderr=serial
partition=nand0,0
mtddevnum=0
mtddevname=starter
Environment size: 946/262140 bytes
=>
Now you can tweak the variables. We will increase the wait pause to 3 seconds and replace the Init process with the shell / bin / sh (Why do we need login? No, we do not need login). Those. Let's make a simplified single-user download.
Environment size: 946/262140 bytes
=> setenv bootdelay 3
=> setenv bootargs ubi.mtd=0 ubi.mtd=11 root=ubi0_0 rw rootfstype=ubifs console=ttyS0,115200 single init=/bin/sh
=> saveenv
=> printenv
...
bootargs=ubi.mtd=0 ubi.mtd=11 root=ubi0_0 rw rootfstype=ubifs console=ttyS0,115200 single init=/bin/sh
...
Environment size: 966/262140 bytes
=>
We will save the changes (saveenv) and run run bootcmd or just distort the power of the ONT.
Now we wait until the ONT is fully loaded without any manipulation with a screwdriver.
The last lines of the download log:
UBIFS: file system size: 14450688 bytes (14112 KiB, 13 MiB, 112 LEBs)
UBIFS: journal size: 2967552 bytes (2898 KiB, 2 MiB, 23 LEBs)
UBIFS: media format: w4/r0 (latest is w4/r0)
UBIFS: default compressor: zlib
UBIFS: reserved for root: 0 bytes (0 KiB)
Freeing unused kernel memory: 196k freed
BusyBox v1.15.3 () built-in shell (ash)
Enter 'help' for a list of built-in commands.
/bin/sh: can'taccess tty; job control turned off
/ #
# whoami
SuperUser
Hooray, we are at rootfs.
In conclusion, a recommendation on how to increase permissions for users connecting via SSH.
Those who worked with this ONT on SSH have seen that they are not launching a very traditional Linux shell. In ONT, it is called the CLI. I found the configuration file / var / cli_pw, which contains information about CLI users (primarily SSH users) and has a syntax similar to / etc / passwd
It does not make sense to add a user record directly to this file, as every reboot / var / cli_pw is overwritten from a configuration stored elsewhere. Therefore, I used the autorun script / etc / rcS to add my user to / var / cli_pw. Each reboot this command is executed. Add something like this to / etc / rcS:
echo'alex:$1$SERCOMM$/Yr1kjT7kcnd11coqAlgN1:0:0:root:/:/bin/sh' >> /var/cli_pw
Vi editor to help.
Accordingly, user alex will have full administrator rights when connecting via SSH to ONT.
Now you can return the U-Boot variables to their original values and enjoy root access.