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”:


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:


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:


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/ /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

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.

Dahua IPC-HFW4300S

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

The default username is admin, password is also admin.


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).


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:

    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


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


Linux version (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 ( 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):

I have upgraded firmware from:

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

WEB Version


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

WEB Version

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):
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 .

Good picture quality.
Solid metal construction.
High profile is available for h264 streams.

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: