After the second time one of our parked cars was run into by reckless (probably drunk) drivers who never leave a note, I decided to install some security cameras. To avoid giving even more detailed insight into my comings and goings to Lord Bezos, I wanted a wired setup that required no internet access. I wound up getting the "Night Owl 4K UHD Wired Security System" from Walmart for $189 which I thought was quite reasonable.
The kit comes with 4x cameras model CM-DP8lSA-B, 4x BNC+power cables and a DVR model DVR-BTD8-81-VT3. The wall warts for the DVR and cameras have the same connectors and look identical except that the DVR is 12v and the cameras are 15V, so watch out. The cameras seem fine and the picture is reasonably clear, so as usual the software is where we run into trouble.
Here is the internals of the DVR box. I did not remove the heatsink for fear of ruining the thermal compound so I can't say for sure what the CPU is.
By connecting a logic analyzer to the serial console I captured a partial boot log. Lots of interesting stuff in there:
This UART is definitely ripe for further investigation (for starters, connecting a real UART to it for rx+tx) but I have not done more because I'm not ready to start soldering headers to it just yet.
The advertising emphasized that this is not some IOT always connected nonsense, but of course the instructions "strongly recommend" connecting it to the internet anyway. I don't want this thing sending images or joining botnets on the internet, but I would like to be able to use it over LAN so I don't have to find another monitor just for this DVR. I connected it to a monitor and ran through the setup wizard, set a password, assigned a static IP and skipped all the internet/bluetooth steps.
After unplugging and plugging the DVR in a few times, I noticed that the clock reverted to year 2000. Other settings remained as I had set them so either those settings are stored separately in NV memory (probably the EEPROM) and the CMOS battery is dead, or the software just wasn't calling "hwclock --systohc" often enough. If the password is stored in the EEPROM it probably means resetting the password is not just a matter of removing the CMOS battery for a few minutes.
To prevent this thing from phoning home or other mischief, I connected it to a new VLAN on my home network. Here are the open ports:
$ nmap -p 1-65535 192.168.20.10 Starting Nmap 7.93 ( https://nmap.org ) at 2023-04-08 12:47 CDT Nmap scan report for 192.168.20.10 Host is up (0.0070s latency). Not shown: 65528 closed tcp ports (conn-refused) PORT STATE SERVICE 80/tcp open http 554/tcp open rtsp 9333/tcp open litecoin 9530/tcp open unknown 12901/tcp open unknown 34567/tcp open dhanalakshmi 45611/tcp open unknown Nmap done: 1 IP address (1 host up) scanned in 2.53 seconds
Look! Port 80! Can I just login with a web browser?
I can only assume there was some horrific vulnerability and instead of fixing it or removing the server they just replaced the webpage with one that does nothing.
I found this zero day description with links in chinese and russian which I fed into google translate. The claim is that port 9530 can be used to unlock a telnet port, however I was not able to get it working with use of the magic strings described on those websites. Maybe they patched it or maybe I'm just not doing it right.
I ran "binwalk -Me" on the DVR-BTD8-8_1.3.2.bin firmware I downloaded from the Night Owl website. Lots of interesting stuff in there. I do see the string "Telnet:OpenOnce" in the dvrbox binary, but no "OpenTelnet:OpenOnce" string which supports the guess that they have removed that feature. Other interesting bits include a binary "dvr_cgi" which by the name sounds like it could be exploitable and a bunch of the software appears to be written in some language called "Squirrel".
Port 554 is RTSP, which is one of those "standards" which is not really standard. I tried the obvious next step which of course did not work:
$ mpv rtsp://192.168.20.10:554 [ffmpeg/demuxer] rtsp: method DESCRIBE failed: 401 Unauthorized [lavf] avformat_open_input() failed Failed to recognize file format. Exiting... (Errors when loading file)
Luckily somebody on the internet has already found the correct path for viewing live video. It tripped me up that in the GUI the username shows as "Admin" capitalized, but is lower case for RTSP.
$ mpv "rtsp://192.168.20.10:554/user=admin&password=...&channel=1&stream=0.sdp" [ffmpeg/video] hevc: ignoring invalid SAR: 0/0 (+) Video --vid=1 (hevc 3712x2160 5.000fps) File tags: Title: RTSP Session [ffmpeg/video] hevc: ignoring invalid SAR: 0/0 [ffmpeg/video] hevc: ignoring invalid SAR: 0/0
I found that "0.sdp" gives me the 4K (with extreme compression) while "1.sdp" gives a downscaled copy.
That's all for now. I can view the live video but to access recordings I still need to dig out a monitor and hook it up. If I get ambitious I'll wire a UART to the console port and see if I am able to log in. If I could set up SSHFS or NFS I could probably just copy the files I want directly from the hard drive.