Dahua – Sergei's incoherrent ramblings

Dahua IPC-HDBW4300E

Dahua IPC-HDBW4300E with 2.8mm lens.

Bought on Aliexpress, initially came with Chinese firmware, but seller helped me resolve this (was advertised as English).

Reason why I went with dome vs bullet is because I needed wider angle camera.

Here it is:

To adjust it one needs to remove the dome with Allen Key provided:

(sorry about blurry photo).

Note: The 4 pin header (on the right) is for serial (RS232), while button next to it (not visible) is the reset button (press 5 seconds to reset).

From Firmware/System perspective it is no different to Dahua IPC-HFW4300S.

Day time image quality exactly the same, except of course the HFW4300S comes with 3.6mm lens minimum while HDBW4300E comes with 2.8mm.
Night time image quality is a bit worse (due to weaker IR, and wider lens).

Here is the angle comparison:

3.6mm (HFW4300S):

2.8mm (HDBW4300E):

Rebooting IP cameras remotely

Hikvision

Complete Hikvision API documentation is available here.

To reboot remotely a Hikvision IP camera, all one needs to do is ‘PUT’ /System/reboot:

curl -X PUT --user {USERNAME}:{PASSWORD} http://{CAMERA_IP}/System/reboot

Dahua

Complete Dahua API documentation is available here.

To reboot remotely a Hikvision IP camera, all one needs to do is 'GET' /cgi-bin/magicBox.cgi?action=reboot:

curl --user {USERNAME}:{PASSWORD} http://{CAMERA_IP}/cgi-bin/magicBox.cgi?action=reboot

inside of Dahua IPC-HFW4300S

I have decided to switch back from 8mm lens to 3.6mm lens (Mega brand, sold as 3.6mm, f2.3, M12, for 1/3″ sensor).

Disassembly is fairly straight forward.

Note: there is no need to remove screw from the back of the camera. It looks like it is covering a breathing hole (the screw does not hold anything).

Unscrew the front half:

The IR LED PCB is held by couple of screws:

In case of lens change there is no need to disassemble further. But for curiosity I continued.
The SoC board is held by another couple of screws and two screw posts that IR LED PCB was screwed into. These posts can be unscrewed by flat screw driver.

Interestingly enough the camera is mostly empty space, the raised part of the body inside is used as heat sink (covered by yellow heat sink pad). There was a bag of silica gel inside.

The SoC board with lens:

Lens is simply threaded on the sensor body, secured by locking nut. Everything was finger tight. The locking nut is transferred to the new lens and then the whole thing is assembled back, except IR PCB and front cover. Focusing is done on live camera, preferably with a special pattern. The trick is slightly “over” focus, and then tighten the locking nut (while holding the lens).

Back of SoC board:

Here what states on the “CPU”:

Ambarella
A5s-CO-RH
A1407
N6WY4-AN3
1N1
A5s88

Here is the front of SoC with lens removed:

The dust speckle on the sensor was courtesy of Chinese aliexpress seller (probably when they replaced the lens to 8mm).
EDIT: the unpopulated 4 pin header (top right) is for the Serial (RS232) connector, the unpopulated 2 pin header (bottom left, next to battery) is for the reset button.

I used a bit of sticky tape to remove the dust speckle without leaving anything else on the IR filter.

The screws were one time use only (made out of Chinesium) so I replaced them with nice stainless steel screws.

exploring Dahua firmware

A sidetrack from these two posts: Extracting password from Dahua firmware image and Dahua IPC-HFW4300S

To recap: I managed to extract various UBI (NAND flash) images from firmware image.

binwalk -e {firmware_file}

Which gave me the following files:

check.img
custom-x.ubifs.img
dhboot.bin.img
kernel.img
partition-x.cramfs.img
pd-x.ubifs.img
romfs-x.ubifs.img
user-x.ubifs.img
web-x.ubifs.img

I started with romfs-x.ubifs.img as initial grep revealed it contained root password hash (matched to ‘vizxv’).

Mounting UBIFS is not a straight forward (eg cannot use loop).
With help of two guides I found (here and here) I managed to figure out how to mount these images.

apt-get install mtd-utils
modprobe nandsim first_id_byte=0x20 second_id_byte=0xaa third_id_byte=0x00 fourth_id_byte=0x15
modprobe ubi mtd=0
tail -c+65 romfs-x.ubifs.img > romfs
ubiformat /dev/mtd0 -f romfs
ubiattach -p /dev/mtd0
mkdir target
mount -t ubifs /dev/ubi0_0 target

note: tail -c65 strips the header.

mounting contents of romfs-x.ubifs.img gives some insight on the root file structure:

drwxr-xr-x  2  500  500 5192 Apr  2  2013 bin
drwxr-xr-x  7  500  500  480 Feb 18  2012 dev
drwxr-xr-x  6  500  500  960 Feb 24  2013 etc
drwxr-xr-x  2  500  500  160 Jan 13  2012 home
drwxr-xr-x  2  500  500 4832 Feb 22  2013 lib
lrwxrwxrwx  1  500  500   11 Dec 31  2013 linuxrc -> bin/busybox
drwxr-xr-x 13  500  500  864 Dec  5  2012 mnt
drwxr-xr-x  2  500  500  160 Jan 13  2012 nfs
drwxr-xr-x  2  500  500  160 Jan 13  2012 proc
drwxr-xr-x  2  500  500  160 Jan 13  2012 root
drwxr-xr-x  2  500  500 2728 Dec 25  2013 sbin
drwxr-xr-x  2  500  500  160 Jan 13  2012 share
drwxr-xr-x  2  500  500  160 Jan 13  2012 slave
drwxr-xr-x  2  500  500  160 Jan 13  2012 sys
lrwxrwxrwx  1  500  500    8 Dec 31  2013 tmp -> var/tmp/
drwxr-xr-x  2  500  500  160 Jan 13  2012 usr
drwxr-xr-x  3  500  500  224 Jan 13  2012 var

looking at /etc/inittab:

...
::sysinit:/etc/init.d/dnode
::sysinit:/etc/init.d/rcS
...

the /etc/init.d/dnode sets up some of the device nodes, nothing interesting there…
while /etc/init.d/rcS contains some interesting stuff:

/sbin/ubimkvol /dev/ubi6 -s 2500000 -N config
mount -t ubifs ubi6_0 /mnt/mtd

Here what I found out from contents of each UBIFS file:

UBIFS	description
check.img	contains some hardware IDs
custom-x.ubifs.img	/mnt/custom customisation files?
dhboot.bin.img	bootloader
kernel.img	kernel image
partition-x.cramfs.img	contains partition.txt
pd-x.ubifs.img	/mnt/pd/ product description files
romfs-x.ubifs.img	/ root
user-x.ubifs.img	/usr/
web-x.ubifs.im	/mnt/web/ webUI related files

Interesting bit regarding partition-x.cramfs.img, that it contains partition.txt:


#       name                cs         offset              size         mask_flags
  U-Boot,             0, 0x0000000000200000,    0x0000000000100000, RW
  hwid,               0, 0x0000000000300000,    0x0000000000100000, RW
  updateflag,         0, 0x0000000000400000,    0x0000000000100000, RW
  partition,          0, 0x0000000000500000,    0x0000000000100000, RW
  custom,             0, 0x0000000000600000,    0x0000000000340000, RW
  product,            0, 0x0000000000940000,    0x0000000000340000, RW
  Kernel,             0, 0x0000000000c80000,    0x0000000000580000, RW
  romfs,              0, 0x0000000001200000,    0x0000000000800000, RW
  web,                0, 0x0000000001a00000,    0x0000000000800000, RW
  user,               0, 0x0000000002200000,    0x0000000001980000, RW
  syslog,             0, 0x0000000007200000,    0x0000000000400000, RW
  config,             0, 0x0000000007600000,    0x0000000000400000, RW
  backup,             0, 0x0000000007a00000,    0x0000000000400000, RW
  END

all this is effort was to find the telnet password...
~~I am missing /mnt/mtd mount point, specifically /mnt/mtd/Config/passwd file, which looks like contains telnet password (possibly?)...~~

UPDATE: solution to the password debacle is here (at the end of the article).

Now the question where the portion of the telnet password 7ujMko0 comes from? "Inspecting" (running strings) telnetd binary from flash image reveals that it is hard coded into telnetd. If Dahua ever changes that value I know where to find it now.

Extracting password from Dahua firmware image

I wanted to access my Dahua IPC-HFW4300S via telnet (as there is no ssh access).
Unfortunately Dahua does not provide the root password (purposely, as it is hardcoded backdoor).
The currently documented password (vizxv) does not work.

So I got the firmware image (which is achievement, considering Dahua stance on firmware) and managed to extract hash.

First of all the firmware image needs to be extracted from zip, I’ll skip this part and jump straight into extracting binary parts from the firmware:

binwalk -e {Firware_File}

The binwalk utility should have extracted the following files:

check.img
custom-x.ubifs.img
dhboot.bin.img
kernel.img
partition-x.cramfs.img
pd-x.ubifs.img
romfs-x.ubifs.img
user-x.ubifs.img
web-x.ubifs.img

the file of interest is romfs-x.ubifs.img as it has hits when grep-ed for ‘root’:

root:$1$jSqQv.uP$jgz4lwEx2pnDh4QwXkh06/:0:0:root:/:/bin/sh

Now we have a hash which we can brute force with John The Ripper tool.

I settled for 1.8.0 jumbo version with CUDA support.
CUDA seems to be about 2.5 times faster on Nivida GTX560ti than a very beefy 2x Intel Xeon E5-2660 (with 20 cores total).

Particular thing to I had to do to compile (beyond wget-ing and un-tar-ing the arhive) is to modify the entry from gcc-4.6 to gcc-4.8 in Makefile, as it would throw compilation error (gcc-4.6: error trying to exec ‘cc1plus’: execvp: No such file or directory).

line 152:

CCBIN = /usr/bin/gcc-4.8

‘make’ once done that (and libssl-dev is installed), and it should compile.

to run:

./john --format=md5crypt-cuda {hash_file}

The password turns out to be ‘vizxv’ (without quotes). This is not the telnet password (possibly console password).

UPDATE:
I was directed towards correct password here: http://www.cctvforum.com/viewtopic.php?f=19&t=44381

Here are telnet credentials
username: admin
password: 7ujMko0{webui_admin_password}

For example webUI admin password is 123456 then the telnet password is 7ujMko0123456

Dahua IPC-HFW4300S

Bought from amazon for $110USD (via Youshop).
I have decided to go with Dahua as replacement of my recently purchased Hikvision DS-2CD2032-I, due to severe stream errors (shitty firmware?) on DS-2CD2032-I.
~~UPDATE: firmware update fixed the errors with DS-2CD2032-I.~~
UPDATE: the stream errors are due to nature of these cameras and UDP. The TCP stream is perfect.

Youshop managed to “lose” it, I had to “recover” it from unclaimed pile.

The camera described here was sourced from Amazon.
It came in a retail box, but with Chinese labels. The instructions where also Chinese.

The camera came with preconfigured IP address of 192.168.1.108.

The default username is admin, password is also admin.

WebUI

The web interface is somewhat OK, no video stream visible in any browser on Linux (requires ActiveX?). Typical shitty Chinese webUI.
The video settings do work.
The config Export does not work.

“Live” tab (or anything having video output) is completely useless without even bothering to tell me that “plugin” is missing.
When these idiots will learn that not everyone uses IE6?

The camera has exactly same issues with RTSP and UDP, when used with ffmpeg as . When used with -rtsp_transport tcp flag the stream is stable.
The image quality is good (very close if not better than Hikvision DS-2CD2032-I).

Streams

Picture sample (day):

Picture sample (night):

The camera has 3 streams (configured via webUI, 3rd stream disabled).

The trick was to find out the stream URL that works without authentication.
Main stream: rtsp://{CAMERA_IP}:554/cam/realmonitor?channel=1&subtype=0&proto=Onvif
Sub stream: rtsp://{CAMERA_IP}:554/cam/realmonitor?channel=1&subtype=1&proto=Onvif
Sub stream (disabled by default): rtsp://{CAMERA_IP}:554/cam/realmonitor?channel=1&subtype=2&proto=Onvif

Note: proto=Onvif is the key to bypass authentication.

The snapshot URL is: ~~http://{CAMERA_IP}:9989/~~ EDIT: the 9989 port access is unreliable, the reliable snapshot URL is: http://{CAMERA_IP}/cgi-bin/snapshot.cgi

Interesting that switch to/from IR is gradual.

Another very good thing about this camera is that it runs High profile on their h264 streams:

  Metadata:
    title           : RTSP Session/2.0
  Duration: N/A, start: 0.009967, bitrate: N/A
    Stream #0.0: Video: h264 (High), yuvj420p, 1920x1080 [PAR 1:1 DAR 16:9], 25.33 fps, 100 tbr, 90k tbn, 49.95 tbc

/proc/cpuinfo:

Processor       : ARMv6-compatible processor rev 5 (v6l)
BogoMIPS        : 526.25
Features        : swp half fastmult edsp java 
CPU implementer : 0x41
CPU architecture: 6TEJ
CPU variant     : 0x1
CPU part        : 0xb36
CPU revision    : 5

Hardware        : Coconut
Revision        : 13ec300a
Serial          : 0000000000000000

kernel:

Linux version 2.6.38.8 (jenkins@localhost.localdomain) (gcc version 4.6.1 (Sourcery CodeBench Lite 2011.09-70) ) #1 PREEMPT Tue Sep 30 18:53:02 CST 2014

free -m:


             total         used         free       shared      buffers
Mem:           131           83           47            0            0
-/+ buffers:                 83           47
Swap:            0            0            0

df -h:


Filesystem                Size      Used Available Use% Mounted on
ubi0:romfs                4.9M      4.9M      4.0K 100% /
devtmpfs                 65.6M         0     65.6M   0% /dev
tmpfs                    65.7M    576.0K     65.2M   1% /var
ubi1_0                   21.1M     14.3M      6.8M  68% /usr
ubi2_0                  708.0K     60.0K    648.0K   8% /mnt/custom
ubi3_0                  708.0K     72.0K    636.0K  10% /mnt/pd
ubi4_0                    4.9M      3.3M      1.5M  68% /mnt/web
ubi5_0                  708.0K     84.0K    552.0K  13% /mnt/syslog
ubi6_0                  708.0K    232.0K    404.0K  36% /mnt/mtd
ubi7_0                  708.0K     44.0K    592.0K   7% /mnt/backup

Similar to Hikvision DS-2CD2032-I this camera runs very "hot" CPU wise: sitting around loadavg 10.

In all aspects IPC-HFW4300S is very similar to DS-2CD2032-I hardware wise. Same CPU, same clock frequency, similar amount of RAM (128MB for Dahua and 96MB for Hikvision).
Linux wise they run same kernel version (2.6.38.8). Although Dahua runs older busybox version (v1.18.4 vs Hikvision v1.19.3).

Both of these manufacturers violate GPL badly..

It looks like the developers at Dahua use Jenkins, specifically this error message gives it away:

00:00:08|[prc] ERROR  (/home/jenkins/jk_slave_centos6/workspace/IPC_DH3.S0507_IPCAmbarella2.420/tmp_build_dir/PRC_A5S/build/platbuild/../../src/module/submod/i2c/prc_i2c.c|I2C_isr|454): I2C0 dev0x68 wait ack timeout

Even though Dahua are very protective with the firmware, I found newer firmware here (will install once I get shell on the camera):
http://wrightwoodsurveillance.com/forum/thread-89.html

I have upgraded firmware from:

Software Version
2.210.0000.11.R, build : 2014-01-15

WEB Version
3.2.1.164499

to:

Software Version 
2.420.0003.0.R, build : 2014-09-30

WEB Version 
3.2.1.223527

without any issues...

The rest

Now for the shitty part of the camera:

The camera is configured with telnet.
There is no SSH service. It does not look like telnet can be disabled from WebUI (or SSH enabled).

Trying to login to telnet with default admin password fails.

I have managed to extract root hash from firmware file (see here):
$1$jSqQv.uP$jgz4lwEx2pnDh4QwXkh06/
Googling it reveals nothing.
After running JtR for a few hours on GPU, I got the password as 'vizxv' (without the quotes).
The password did not work for any of user combinations...
Still trying to access the telnet...
UPDATE: as per these findings telnet username is admin and password is 7ujMko0{webui_admin_password}, so if webUI admin password is admin then the telnet password is 7ujMko0admin .
Pros:
Good picture quality.
Solid metal construction.
High profile is available for h264 streams.

Cons:
Really shitty support.
No official firmware available.
Windows-centric Web UI.
Telnet is always ON.
~~Telnet is set up with a different, hard coded root password (Dahua back door).~~
RTSP urls are a bit long.

UPDATE: after upgrading the firmware the "Live" tab now has controls, as well as option to download plugin. Well almost, the download link http://{camera_ip}/webplugin.tar.bz2 gives you nice 404. Fucking idiots.

The config import/export still does not work.

NOTE: if camera is used with OpenCV make sure to add ?tcp at the end of the url!!! This camera is even more buggy than Hikvision DS-2CD2032-I and it drops UDP packets on even small sub streams. Here is example of the url needed for OpenCV to work reliably:

rtsp://{camera_ip}:554/cam/realmonitor?channel=1&subtype=0&proto=Onvif?tcp