Category Archives: Cameras

Cameras and stuff

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

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

IMG_20150601_093933
(sorry about blurry photo).
IMG_20150601_093954

IMG_20150601_094002
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):
Dahua-IPC-HFW4300S-day

Dahua-IPC-HFW4300S-night

2.8mm (HDBW4300E):
2015-9-23-11-23-23-668869

2015-8-23-19-36-17-795868

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

Camera itself:
IMG_20150807_113915

IMG_20150807_113946

IMG_20150807_113937

To open pop the rear cap with fingers:
IMG_20150807_132100

There are screws behind it holding the whole camera together:
IMG_20150807_132254

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

The shell is easily separated:
IMG_20150807_132554
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).

IMG_20150807_132613

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

IMG_20150807_133216

Here is the back side:
IMG_20150807_133319

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

Under the battery:
IMG_20150807_133359

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

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

Navman_MiVue388

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

IMG_20140816_125834
IMG_20140816_125848
IMG_20140816_125901
IMG_20140816_125928

Test fit:
IMG_20140816_130112
IMG_20140816_130157

Painted and assembled:
IMG_20140816_131827
IMG_20140816_131849
IMG_20140816_132327

Finished product:
IMG_20140817_141948
IMG_20140817_142026

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:

[1389266060242]$GPRMC,221417.990,A,4533.1826,S,16737.5506,E,054.7,035.5,080114,,,A*77

[1389266060242]$GPVTG,035.5,T,,M,054.7,N,101.4,K,A*0C

[1389266060242]$GPGGA,221418.990,4533.1701,S,16737.5631,E,1,11,1.1,204.6,M,1.7,M,,0000*78

[1389266060242]$GPGSA,A,3,16,07,03,19,23,13,10,06,09,27,08,,2.0,1.1,1.7*3D

[1389266060242]$GPGSV,3,1,12,13,80,310,39,07,50,247,36,23,50,019,48,03,48,066,46*71

[1389266060242]$GPGSV,3,2,12,16,45,128,43,27,42,084,44,06,41,096,44,19,28,038,46*79

[1389266060242]$GPGSV,3,3,12,10,26,260,31,08,19,261,32,09,16,257,26,05,06,210,*77

[1389266061239]$GPRMC,221418.990,A,4533.1701,S,16737.5631,E,054.8,035.0,080114,,,A*7F

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.
dahua-ipc-hfw4300s-000
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:
dahua-ipc-hfw4300s-001

The IR LED PCB is held by couple of screws:
dahua-ipc-hfw4300s-002

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.
dahua-ipc-hfw4300s-003
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:
dahua-ipc-hfw4300s-004
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:
dahua-ipc-hfw4300s-005

dahua-ipc-hfw4300s-006

Here what states on the “CPU”:

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

Here is the front of SoC with lens removed:

dahua-ipc-hfw4300s-007
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