ILDVR INC-MH40D06 or hacking cheap chinese camera

Continuation of ILDVR INC-MH40D06

Since manufacturer will not divulge the super secret telnet password, and not having ability to turn off the telnet from web ui, I have decided to get access to camera via more brute method.

Continue reading ILDVR INC-MH40D06 or hacking cheap chinese camera

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


inside of Mini0806

Update: if you ever thinking about buying this camera, don’t! Unless you wish to buy five them to get one good. It is plagued with issues, from assembly problems (jammed cable), crappy firmware, stability issues, poor choice of power supply IC (only 0.5V head room), random crashes to shitty plastic case that melts at 100’C.

Below is the breakdown of mini0806 dashcam.

The packaging contents:

Camera itself:



To open pop the rear cap with fingers:

There are screws behind it holding the whole camera together:

Notice torn cable inside of the ring? This is a common assembly/design fault:

The shell is easily separated:
The beefy heat sink is a good thing to have, I believe it is relatively easy to add a micro fan there (maybe with minimal case cutting).


The two boards held together quite tight. Here is the camera side:


Here is the back side:

Notice how battery is simply jammed between two halves? It is held by double sided tape…

Under the battery:

I have added insulation tape around battery area in case the battery swells in future:

Camera is easily assembled back, one thing to watch out for is the power/GPS cable that feeds through the ring. It can be easily jammed and torn by adjusting the angle, if it is not assembled carefully. I bolted the contact pad last which allowed me to check if the cable is jammed.

Navman (Mio) MiVue 388


I bought Navman MiVue 388 for holiday in Australia, as I was going to do a few thousands kilometres worth of driving.
This camera is sold everywhere else under Mio brand. It is not a Navman product.
When I was purchasing this dash camera I had few prerequisites (which it met, somewhat):
1) 1080p
2) suction cup mount (for easy removal from rental)
3) Modest size
4) Available next day
5) Reasonably priced (under $250)
6) GPS
So basically the only product in New Zealand that met those was this camera.

Whatever you do, do not buy this dash camera. There is nothing really positive I can write about it (apart that it supports 64GB VFAT formatted card, despite the specifications). It pales in comparison to a much cheaper G1W, or Mini0806 (also crap! DO NOT BUY THESE!) or even my dated Blackvue DR400G-HD II. If you are after a good value for money camera get G1W for ~$60USD. Same applies to MiVue 338/358.

Image quality is very grainy:

I didn’t test the camera with optional CPL filter as Navman didn’t sell it at the time (it could have been sources from eBay as Mio branded).

Beyond image quality there are other major issues:

* Suction cup mount is a standard GPS mount, is way too big and vibration prone. It is not very good and falls off after few hours. Not possible for discreet mounting in a smaller car without major view obstruction.
* After 1 month of operation the face plate (screen cover) fell off. It was stuck on by two short strips of double sided tape. After reattaching second time, I gave up and now the camera is used without it.
* Occasionally it decided to completely lose time settings and gets stuck on Setup Time screen. While in that state it does not record!!!
* Cannot turn off blue pixelated “MiVue388” logo on top of the screen (without hacking firmware).
* Battery life is hopeless (about 1 minute and 30 seconds). Good luck actually using park mode.

Two of the issues were because of the climate in New Zealand; this camera is not suitable for being attached permanently on the windscreen due to heat. It is probably far worse for it in Australia.

To address the shitty mount I have decided to build my own mount (secured by not suction cup but double sided tape).
The materials I used are the following:

* Piece of scrap aluminium plate (some random cut off)
* A random drawer knob that I found at hardware store (a 16mm ball with threaded hole and a screw).
* 3M moulding tape
* Black paint


Test fit:

Painted and assembled:

Finished product:

With my mount the dash cam no longer blocks the view, in fact it is almost not visible (apart from status LED) from drivers seat. It is also very discreet from outside as it is masked by mirror contour.

Converting Blackvue Dashcam gps log

It appears that Blackvue dashcams log GPS data in “almost” NMEA format.
It is possible to convert the file using gpsbabel utility into KML format that google maps/earth can understand.
All you need to do is strip time stamp appended to each line in the log and them process the output with gpsbabel:

cat {BLACKVUE_GPS_LOG}.gps | awk -F ']' '{ print $2 }' | egrep -v '^$' > {BLACKVUE_GPS_LOG}.nmea
gpsbabel -i NMEA -f  {BLACKVUE_GPS_LOG}.nmea -o KML -F {BLACKVUE_GPS_LOG}.kml

This is what log looks like:









Rebooting IP cameras remotely


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


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


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.