Reverse Engineering a cheap Chinese DVR 2: Electric Boogalo

Bonjour!

I'm assuming you're back for more.

We left off from the last article by looking at a basic overview of the DVR. If you haven't read that article yet, I got you fam--here is a link to it.

Now that you're all caught up, let's get back to the breaking of cheap chinese shit for fun. (Ideally not, but hell; anything is possible with something made to retail for under $43 dollars.)

Where we left off last time was that basically we have a printed circuit board (PCB) with several unpopulated connection pinout points.

(A pinout is a term used to describe a small number of connections that don't have anything soldered to them. Think of them like, wires, connectors or plugs that could be connectors or plugs if someone had bothered to add the connectors or plugs.)

Here's the same photo from before.
pinouts

The connectors we were looking at exploring last time round were as follows: J2, CN3, CN6, CN8, CN10, CN29.

So, let's start with the obvious.

J2 is more than likely an interface for expansion I/O of various kinds. I'm not certain at the moment, but I do believe it's intended to receive input from various sensors for alarm purposes and communication with Pan/Tilt/Zoom cameras using a serial connection. That sort of thing.

CN8 is another SATA port. You can tell because it shares similar dimensions as the existing SATA port (which has the red cable plugged into it.) Also, because CN7 is a SATA port, it'd stand to reason that CN8 is also a SATA port.

(SATA is the name of the interface standard for connecting hard drives to computers. It's been the standard for a bit now and was preceded by the IDE/PATA interface.)

CN3, CN6, CN10 and CN29 are unknown at this point. I'll be looking closely at them soon.

In the meantime, I've elected to perform some basic configuration and testing of the DVR.

Essentially, this means I've plugged it in and setup an old analog camera destined for the scrap heap on it. It's from a pile of cameras I appropriated from work for testing.

Unfortunately, most are damaged and need to be recycled but other than a broken housing and a faulty focus mechanism this one appeared to produce a picture which is all I need. I'll be recycling it as well when I'm done with it.

screenshot

Here's a screenshot using VLC as a streaming mechanism for viewing the Real Time Streaming Protocol (RTSP) feed for channel 1 on the camera.

The exact URL I used to connect to the camera was:

rtsp://192.168.1.10:554/user=admin&password=&channel=1&stream=1.sdp?real_stream--rtp-caching=100

The username and password by default are admin and password respectively. Pretty generic.

So, onwards with the result of a man in the middle attack I staged on the DVR using my computer as a stand-in for a router.

The DVR appears to facilitate remote user connectivity to view their cameras by sending a UDP packet to two webservers. The two webservers are as follows:

112.124.0.188 - First outbound host
Owner: Aliyun Computing Co., LTD

54.84.132.236 - Second outbound host
Owner: Amazon AWS.

These both seem to run a web interface for users to login to their cameras. Essentially, as long as these two hosts are running; endusers can login to the website and connect directly to their cameras despite things like internet IP address changes.

I'm not yet ready to move ahead with doing what I said I would earlier by using a serial interface to interuppt the boot process and capturing a file system image from the DVR for analysis. I'll be doing this down the road to basically pick apart the configuration to look for things like backdoors and the like.

So, tune in next week. Same bat time, same bat channel. (In this case, channel 1.)