Rooting K9608-2W
Let's say you have one of these and you want shell access for some reason, like setting the date & time programatically. By adding a couple magic files to a USB mass storage device, connecting it to your NVR and rebooting, you will be able to login via telnet.
Login to the web user interface of your NVR, go to Settings (wrench and screwdriver icon). If you see the following info listed in the DevInfo tab, then these instructions should work for you. This may work with other software versions too but no promises.
| Dev model | K9608-2W |
| HW version | 2.1.0 |
| SW version | 2.7.13.0_22922330 |
| Reldatetime | 2018/10/26 10:58 |
Grab a thumb drive or whatever USB mass storage device is handy. Make sure the partition table is simple and has fat32 as the first primary partition. This is usually the default setup for a new device so you probably don't have to do anything. Mount it and get started making the three files as below in the top level directory.
me@here:/media/me/SANDISK$ echo 1000000001 > enable_log_forever
me@here:/media/me/SANDISK$ cat <<EOF>dvr_app
#!/bin/sh
/usr/sbin/telnetd &
exec /media/usb1/dvr_app_chain "\$@"
EOF
me@here:/media/me/SANDISK$ cat <<EOF>dvr_app_chain
#!/bin/sh
umount /root/dvr_app/dvr_app
exec /root/dvr_app/dvr_app "\$@"
EOF
me@here:/media/me/SANDISK$ Unmount/eject, pop it in the NVR, reboot the NVR, wait a bit and then telnet to it using the same IP or hostname you used to get to the web interface. Login with username root and password j1/_7sxw
me@here:~$ telnet nvr-host
Trying 192.168.31.337...
Connected to nvr-host.
Escape character is '^]'.
(none) login: root
Password:
Welcome to HiLinux.
# uptime
05:42:38 up 2:35, 1 users, load average: 13.88, 12.32, 11.89
# ls /
a.out bin etc linuxrc mnt oem root sys usr
a2.out dev lib media nfsroot proc sbin tmp var
# One of the startup scripts contains the following snippet:
if [ -e $MOUNT_DIR/enable_log_forever ];then
echo "enable log2 found."
rv=$(cat $MOUNT_DIR/enable_log_forever)
if [ "$rv" == "1000000001" ];then
if [ -e $MOUNT_DIR/dvr_app ];then
echo "mount bind dvr_app."
mount --bind $MOUNT_DIR/dvr_app /root/dvr_app/dvr_app
fiIn short, if the file enable_log_forever exists and contains 1000000001 then bind-mount dvr_app from the USB device over the top of the normal /root/dvr_app/dvr_app before running it later in the same startup script.
The shell won't allow us to unmount dvr_app from inside of the script running as that name, so we pass off execution to an arbitrary script called dvr_app_chain directly from the USB mountpoint. From there, we can unmount our dvr_app and run the orriginal with the arguments that were passed along the way. Any additional commands that we want to run can be added to either script.
One side effect is that logs will be written to your USB device. Rebooting without this USB device present will revert to running normally without telnetd.
- Kill run_IOTDaemon.sh. It's the script responsible for spawning IOTDaemon once a minute. This service reaches out to ngw.dvr163.com offering remote access to your video along with all sorts of other controls, including a reverse shell.
- Change the root password. Using bind-mount, you can set up a passwd file on your USB mass storage device.
- Run dropbear instead of telnetd.
- Update the squashfs with all of your changes so that you don't depend on the USB mass storage device any more. For extra credit, add an NFS mount to hold larger packages.
- Run ntpd. The clock drift on this thing is terrible. The built in mechanism for ntp is to stop recording, update clock, then start recording again. This is appropriate for a big time shift, but not so hot for regularly maintaining time sync.
Please post comments with suggestions or requests for this document. Have a device you want root on and don't mind sending one to me? Tweet at @octosavvi.
I'm assuming that you have replaced and in the URLs above. These are the credentials used in the web interface on the NVR. For me, the default user is "admin". Leaving those blank really shouldn't work. and also can't be blank for me. To see what URL the web interface is using, start up Chrome and load the NVR webpage. When you are at a point where you can do something interesting, like request a still from a camera, press F12 to open the Developer Tools, select the Network tab, then go click the link of interest on the NVR page. In the developer tool-pannel, you should see the URLs being loaded in the File column. Right click and Copy when you find the one you want. There are frequently more parameters provided by the stock web interface than are actually required. So you can experiment with removing things to simplify the URL. Worst case, it will cause the NVR to crash/reboot. But there shouldn't be any harm in that. Maybe it is best to avoid late night tinkering when the NVR could be capturing video that you will want to review later.
Running
brctl show br0will describe the bridge Iface listed in your route output above. Based on the routing table, it appears to include the 172.20.14.0/24 and 192.168.0.0/24 networks. There may be an IP/routing issue on the source computer side. Making sure you set a static IP of 172.20.14.123 or similar and that should be all you need unless the NVR is doing some. Check for packet filtering withiptables -nvL.There does appear to be a routing issue on the NVR where it is trying to route packets destined for unknown hosts (Internet) via two different gateways: 192.168.0.20 and 192.168.0.1 which may indicate an issue with the DHCP gateway configuration on your network. With two default routes having the same Metric, some packets may be lost if one of those gateways fails. But as previously mentioned, letting this thing talk to the internet is a risk. So broken routing doesn't need to be fixed. This won't impact hosts on the wired network claiming to be in the 172.20.14.0/24 network.
Another option for talking to cameras is to route and NAT through the NVR instead of relying on bridging.
Then anyone in the 192.168.0.0/24 should be able to talk to a 172.20.14.23 camera by adding a static route for 172.20.14.0/24 to the 192.168.0.x address of the NVR.
To get a little more info about what hosts your NVR sees, try
arp -nato list neighbor devices (cameras) that it has been talking to recently. Andifconfigwill show you the 192.168.0.x IP which you probably already know.