Digging into DVRs

During the summer holidays, my friend and I installed a CCTV system at my home just to improve the general security.  I had to take a dive into the world of DVRs (Digital Video Recorders).  I found that, like most product genres, there is a distinct line between quality, branded products and budget unbranded or vaguely-branded products.  I didn’t fancy spending upwards of £300 on a DVR, so I went for a reasonably mid-quality model recommended to me by my friend. The DVR I went with is a generic, reseller-branded model sold by Aban - a Manchester-based CCTV firm.

The designation is VU-431 - but this seems to have been assigned by Aban themselves.  Inside, it’s fairly straightforward - SATA hard drive, connected to a board with a cheap SATA controller and HiSilicon Technologies CPU.  A small amount of flash memory containing the Linux (Busybox) OS and the actual Application that drives the DVR is mounted as the root and the peripherals (IR receiver for the remote and the actual video encoder chip) are available as devnodes in /dev/.  It provides an shell interface (ash) over Telnet with a root password that is immutable by the end user using the normal DVR software or client.

It works fairly well - in that it records things that happen outside my house.  That is, however, unfortunately the limit of the things it does well. The web interface is presented as an ActiveX control; an antiquated framework by Microsoft for, among other things, presenting interactive applications to the user in the browser.  Why they couldn’t have just used Flash or something, I don’t know.  In any case, I’m a geek, as you probably know, so I couldn’t just sit back and be happy with the ActiveX rubbish.  I did some digging…

I attacked the system where I felt most comfortable - the network protocol that the ActiveX client (henceforth referred to as the client in this post) utilises to talk with the DVR.  Turns out it’s a completely custom protocol designed by the manufacturer of the DVR.  I’m guessing that the protocol is common to several DVR models, as the iPhone and PC clients say they support a “range” of DVRs, so you might get lucky and find that this protocol, or a close variant works for your DVR too.  Have a Wireshark and see.

There are several, serious design issues with the DVR, both in terms of the low-level network implementation of the system and software engineering failures that mean the client is buggy, difficult to use and downright poor.  Putting this aside, here’s an excerpt from what I’ve learned about the protocol:

The Protocol

The DVR communicates with the client entirely via TCP packets.  Even video is sent via TCP (!!). The first packet I wanted to understand was the packet to request the start of a live streaming session (I.e. watching a channel from a CCTV camera in real time - not a recording).  I observed that the client sends the following packet, NUL (0x00)-padded to 500 bytes (I.e. extended to 500 bytes length with 0x00 bytes).

0000 - 00 00 00 01 00 00 00 03
0008 - 0a 00 00 00 00 00 00 00
0016 - 00 00 00 68 00 00 00 01
0024 - 00 00 00 54 00 00 00 01
0032 - 00 00 00 00 00 00 00 00
0040 - 61 64 6d 69 6e 00 00 00
0048 - 00 00 00 00 00 00 00 00
0056 - 00 00 00 00 00 00 00 00
0064 - 00 00 00 00 00 00 00 00
0072 - 31 32 33 34 00 00 00 00
0080 - 00 00 00 00 00 00 00 00
0088 - 00 00 00 00 00 00 00 00
0096 - 00 00 00 00 00 00 00 00

There are several byte ranges of significance in the packet:

• Position 31 (0x01 value) denotes the 1-based channel number that the live streaming request is for. In this case the channel is 1.
• Position 40 marks the start of a 32-byte field for the username. The field should be NUL (0x00)-padded. In this case, the value is “admin”.
• Position 72 marks the start of 32-byte field for the password. The field should be NUL (0x00)-padded. In this case the value is “1234”.

As for the rest of the packet, I’m not really sure. I guess the first few bytes designate the verb or command of the packet - indicating that it a live streaming request; but other than that I have no clue - they don’t seem to change at all.

If the request is successful, the DVR seems to respond with an 8 byte packet:

0000 - 10 00 00 00 00 00 00 00

Then, in packets of varying size not exceeding 1448 bytes, raw containerless H.264 video data.  The only mechanism to abort this seems to be to close the listening socket; the DVR detects this through lack of TCP ACKs and stops spamming video data.  Elegant, huh. I’ve learned quite a lot of other aspects of the protocol since I started tinkering and have put them together as a PDF here.  Check it out.

I also uncovered a few security-specific issues during my exploration of the DVR software.  I know this isn’t exactly a high-priority target for hackers, but still, it’s a security appliance - you’d expect it to be at least reasonably secure.

No. One blinder I discovered was the fact that the settings editing aspects of the protocol (covered on page 5 of my PDF) are completely authorisation-less. That’s right - you can just send a request for the settings to any compatible DVR and it will respond with all of them without doing any authorisation or authentication for your request. The settings typically contain the list of users and their passwords (un-hashed & unencrypted, naturally), your username and password for the PPPoE connection, if it is set up, the names of the channels for your CCTV cameras and more. Here’s a little program I wrote in C to pull the settings from a DVR by IP address. No auth needed. Additionally, though I haven’t documented the setting-changing aspect of the protocol (just the setting-retrieval), I don’t believe changing settings on the DVR needs any authorisation either.

Lovely. In any case, what you should take away from this is that these things are cheap.  They behave as such.  The UI is shoddy at best, the compatibility and openness of the standards employed are atrocious and the security is, frankly, awful.  If you’re looking to lock down your multi-million pound stock warehouse, don’t use one of these babies.  But for your 4 bedroom family home, they work pretty well.  They look OK, record reliably and aren’t too bad to get footage off once you have something you want to keep a record of.