Articles / Linux : Hacking A Reolink NVR -- edman007.com

• Home
• Articles
• Rivian
• Linux
• Plants
• Troubleshooting
• News
• RC Sub
• Images
• Downloads

Hacking A Reolink NVR

So I recently saw a great Amazon deal, the Reolink NVR (RLN8-410) with 4 POE cameras was $320 so I grabbed that and 1 Amcrest 4K camera (IP8M-2493EW). I got it setup and immediately found two things, while it completely supports ONVIF (an open, XML-SOAP based protocol to communicate with security cams and NVRs), there is no web interface (they claim there is, but it's an browser addon that only works on Windows and Mac). They also have a desktop client, but surprise it too doesn't work on Linux.

I then tried getting my Amcrest camera working, and it oddly doesn't work, it sees it, and then says it's offline, and then finds it again when I hit scan, but with a different port (port 80) and refuses to connect, trying to delete it or scan again just crashes the UI. So obviously it's connecting and not working. All well.

All of this has made me determined to change the NVR software, get something open, that I can get to read my 4K camera, that will allow me to download history via Linux, and something with a functional web interface. This is going to be my story on hacking the RLN8-410


Note: If you just want to know how to root your NVR, jump to the bottom

So my first thought, check for telnet/ssh or something easy to get shell access with:



Nope, nothing easy, but I might investigate them later.

So my next thought is these things are never designed with security in mind, so lets grab the firmware from their site, RLN8-410_180811/HI3535_NVR_8IP_REOLINK_L300_0811_4509_1606.6MP.pak, I already flashed it after buying to see if that fixed my problems, it didn't. My first thought was see if I can just unpack it (sometimes these things are tarballs that are unpacked prior to flashing).



Nope, no idea, what about hexdump?



Now we are getting somewhere, uboot is a popular embedded bootloader, so can uboot read this file?



Nope, it doesn't do anything, I'm really not sure what is that (I'd assume some sort of bootloader thing, but I still don't know). I am still struggling to figure out what is at the front of this firmware file, if I want to reflash this device I need to understand the firmware, reading it isn't enough. If anyone know what this is (and more importantly, how to generate it).

My next thought was let's see if we can find anything in it, and for that there is binwalk, lets see what that does.



Now that's helpful, the CRC32 table is checksums, if I ever want to reflash it I'll need some tool to regenerate it. The uImage header is further down in the file, and there is an xz blob, two CramFS images, and then some sort of image.


I extracted all the data (binwalk makes this easy with the -e option), and then I had something to work with.

* The xz data - That's the compressed Linux kernel (decompressing it and running strings on it makes that easy)
* The next is a CramFS filesystem, that is the root filesystem for the NVR
* The next CramFS filesystem, that's more binaries, but I don't recognize the file structure, I'll deal with it later
* An image, I extracted it to get the boot splash. Not very exciting.

Inspecting the RootFS

The rootfs provides a lot of opportunities to see any security holes. First step, /etc/passwd, and /etc/passwd- ...what is that doing there? That's an editor backup, and should never be on your released product. So far piss poor security has already been confirmed. But first the contents of /etc/passwd:



That's got a hash, john the ripper can crack it. After a night of cracking, I got a root password, 20120515. Nice and easy, but I had nowhere to use it. So I continued on.

Next step is the boot process, if I want access I need to know what it does when it boots. In linux that is init, this is the process that calls the first initscript, it's also what setups your login terminals and such. It's configuration file is /etc/inittab, so lets check that out:



So, first thing... "Auto login as root ..." What? Really? that's ttyS000, that means a root shell is just always open on it's serial port (what serial port?). So I finally broke down and opened it up, and right in the middle was an empty connector labeled "UART", which is low voltage serial. So I just need a UART device to connect to it. I looked around and I had both a BeagleBone and a Raspberry Pi near me with UART. So I grabbed the BeagleBone and pulled the front panel USB cable off the NVR (this used the same connector as the UART connector), in the process I broke the connector (it was glued in place) but that was fine. I plugged it in, use the voltmeter and checked the voltages with respect to ground (the chassis), the rear most wire was 5V (power), the front most was 0V (ground), and the middle two were 3-ish. I isolated the 5V power so as to not back power the BeagleBone's power supply and connected the rest up. It just worked, I got a "#", so I had a root shell.





And I've confirmed that it's linux, some poking around shows it's busybox (and not much else), /mnt/sda is the internal hard drive (where it saves all the videos), the root filesystem is read only (so I can't change the password or services that start on boot, not without flashing it). /mnt/app is where the second CramFS image is mounted, it appears to be the SW reolink wrote. Their application is "dvr", so /mnt/app/dvr starts up the Reolink SW. There appears to be some sort of watchdog device running as well, if I kill the dvr process the device reboots a few minutes later. I need more if I want to put my own SW on it. Though now it's not looking too bad, adding a few lines to a boot script somewhere can get me to run my own code on boot, and I can access it via /mnt/sda, I have plenty of space.


So onto boot scripts, I checkout out the rest of the boot process, in /etc/init.d, and I found more good news in /etc/init.d/S90StartSuvr .



That's right, if there is a thumb drive present, formatted as vfat, it will just go ahead and run the script "autoexec.sh" on boot, as root, and let you do whatever. Now that's the lousy security I expected in this kind of device.

So now, the easy way to root this NVR:

1. Get a thumb drive, format it as FAT32 (vfat).
2. Put this script on the root of the drive, named autoexec.sh

3. Put the thumb drive in and reboot
4. Login via telnet, username is root, password is 20120515

As a note, it seems to be dependent on the thumb drive a bit, my first try was an old crap thumb drive, and I guess the scripts give udev 3 seconds to find it, if it doesn't show up in 3 seconds it won't work. I ended up switching to a nicer USB microSD reader with a high speed microSD card, that works well.

My next step is going to be using debian to get some good SW on here and run whatever I want on it.

---

Comment

Name:
Email (For new comment notifications, optional):
What is 1 + 2 minus one?
Comment:

Copyright edman007.com, All Rights Reserved
All code posted under the MIT license unless specified otherwise
All images are licensed under a Creative Commons Attribution-Noncommercial-Share Alike 2.5 License unless otherwise specified.