Hikvision FIRMWARE TOOLS - change language, extract files and create own firmware

[networkcameracritic]

I don't see why not, it's been done before with 5.2.0 that someone posted.

I took a look extracting initrd from mtd11 and having trouble. There's a 64 byte header, then a gzip file, When I extract this from the MTD11 dump, the file has a standard GZIP header, the only quirk is the flag is 08 which is a reserved flag and can't find much info on that and get a corruption error, even using gunzip on the camera. So the Magic header looks like this

1F 8B - GZip Magic Number
08 - compression method - deflate
08 - flags - ??? reserved
83 59 BF 53 - file mod time
02 - extra flags
03 - OS type - Unix
initrd - initial file name - zero terminated

My best guess is I can copy MTD11 from the hacked camera to an unhacked camera, but that would not help the cause of providing a firmware update with this. If I can un-zip MTD11 to initrd, I can see if there's a difference in a certain file and then update that in the firmware.

 

[scn101]

I have the unbranded Hikvision DS-7608NI-SE2/8P (actual part number HNR30P8-8) running firmware version 3.0.8 and when I tried to upgrade to 3.0.10 it fails and tells me “upgrading failed, firmware mismatches.” This happens via USB or Web based. So I changed the digicap.dav language from a 1 to a 2 with hiktools and verified the language field changed, it did. Same result, “upgrading failed, firmware mismatches.” Any ideas?

I have one camera (newbie, just starting out), a DS-2CD2332 that I upgraded from 5.1.0 to 5.2.0 successfully. The day of the week is in English, does this mean it is a US Camera? One thing I don't want to do is upgrade the NVR to 3.0.10 and have it complain about the camera's language.

Any thoughts on this?

 

[alastairstevenson]

If it's unbranded, does that mean it's an OEM product?
Can you use telnet to access the NVR and use the command 'getHardInfo' and paste the result back here - maybe obscuring the serial number.
The equivalent on the camera is 'prtHardInfo'
And what was the filename / description / origin of the firmware file you tried to update with? In the filename is usually a clue like EN_STD, CN_STD, ML etc

 

[scn101]

Here is the info:

# getHardInfo
Start at 2015-02-27 07:13:25
Serial NO : <omitted>
V3.0.8 build 140913
KernelVersion: V1.0.0 build 140722
dspSoftVersion: V1.0 build 140828
codecVersion: V1.0 build 100520
hardwareVersion = 0x400
encodeChans = 0
decodeChans = 8
alarmInNums = 0
alarmOutNums = 0
ataCtrlNums = 0
flashsize = 0x10
ramSize = 0x200
networksNums = 1
language = 1
devType:HNR30P8-8
bootPartition = 2
randomCode =
#

Here is the model I purchased: http://www.ebay.com/itm/Hikvision-M...428?pt=LH_DefaultDomain_0&hash=item3a8260935c

 

[networkcameracritic]

This is an OEM version of the NVR, hence the "Hikvison made". OEM products have a different set of firmware and you can't use Hikvision firmware. Contact the seller and ask them for the latest firmware. This is why my kid stopped carrying OEM Hik's because someone would figure out a way to force Hikvision firmware on by modifying it or TFTP and brick the NVR and the OEM refused to warranty it, putting her in the middle. So best to check on this and not try any tricks to make it work, the risk is too high.

Here's a link to the OEM - http://huntcctv.com/product/hnr30p8-8/ Their motto is "love is sharing" so tell them you want some love and share the latest firmware

 

[scn101]

Thanks networkcameracritic, I think you're right. The good news is that the NVR seems to work well and I can get to the POE cameras through its LAN connection so I'm good.

My camera has a CH in its serial number so it is most likely Chinese yet the day is in English. It is at 5.2.0, do you think I can upgrade it to 5.2.5? Or will it cause my to change to Chinese, right now it is all in English including the day of the week.
# prtHardInfo
Start at 2015-02-27 16:51:40
Serial NO S-2CD2332-I20140626CCCH46<omitted>
V5.2.0 build 140721
hardwareVersion = 0x0
hardWareExtVersion　　　　　 = 0x0
encodeChans　　　　　　　　　　　　 = 1
decodeChans　　　　　　　　　　　　 = 1
alarmInNums　　　　　　　　　　　　 = 0
alarmOutNums　　　　　　　　　　　 = 0
ataCtrlNums　　　　　　　　　　　　 = 0
flashChipNums　　　　　　　　　　 = 0
ramSize　　　　　　　　　　　　　　　　 = 0x4000000
networksNums　　　　　　　　　　　 = 1
language　　　　　　　　　　　　　　　　　　　　　　　 = 1
devType　　　　　　　　　　　　　　　　 = 38920
net reboot count　　　　　　　 = 0
SD status　　　　　　　　　　　　　　　　　　　　　　 = 0 (1:noraml;0:none)
Path: .
Working Copy Root Path: /data1/data_liwenwei/work/frontend_software_platform_IPC5.2.0
URL: https://192.0.0.140/Camera/Platform/Branches/frontend_software_platform_IPC5.2.0
Repository Root: https://192.0.0.140/Camera
Repository UUID: df2d70c3-7593-7941-af1e-571b313c0946
Revision: 84909
Node Kind: directory
Schedule: normal
Last Changed Author: chentianyong
Last Changed Rev: 84908
Last Changed Date: 2014-07-21 21:47:41 +0800 (Mon, 21 Jul 2014)
　

 

[wzhick]

I have the unbranded Hikvision DS-7608NI-SE2/8P (actual part number HNR30P8-8) running firmware version 3.0.8 and when I tried to upgrade to 3.0.10 it fails and tells me “upgrading failed, firmware mismatches.” This happens via USB or Web based. So I changed the digicap.dav language from a 1 to a 2 with hiktools and verified the language field changed, it did. Same result, “upgrading failed, firmware mismatches.” Any ideas?

I have one camera (newbie, just starting out), a DS-2CD2332 that I upgraded from 5.1.0 to 5.2.0 successfully. The day of the week is in English, does this mean it is a US Camera? One thing I don't want to do is upgrade the NVR to 3.0.10 and have it complain about the camera's language.

Any thoughts on this?

1. Execute cat /proc/sys/hkvs/bootpar on NVR, and post result here
2. post head decoded info from hiktools output

I think that the firmware is not compatible with your device, and it has refused to accept it. This check I do not shut off for safety reasons. BUT if you want - you can do it.
To do this, you need to disassemble the firmware you want to download, and then glue it back by taking the head of the firmware that is compatible with your device.


About IPC and NVR compatibility. Tools only modifies the properties of the firmware file that it had not been rejected by the device. As the firmware contains other languages they will be available for selection. Сhange device settings, where it is specified language is not happening. So the compatibility of your cameras and NVR should not change. The tools simply change language flag in english firmware, so that the device would believe that a сhinese firmware. No other changes in the contents of the firmware have been made.

 

[networkcameracritic]

Do you have any insight as to where the day of week characters are and how one can modify the firmware to make them English in a Chinese region code camera?

Also, the firmware contains an initrd image in hroot.img. When it makes it to the camera, it appears to be /dev/mtd11. When I bypass the 64 byte header, there's a gzip file, initrd.gz, but can't gunzip it. Any clues that may help with this? The magic header for gzip looks a little odd in that the 4th byte is 08 where it's normally 00. I'm assuming the boot loader is unzipping it or is it just mounting a file system from a zipped file?

 

[m.versteegh]

Just to be sure that I'm correct before updating my cam's firmware. I got a Chinese 2132, running V5.2.0 with a gui displaying all in English language. If I perform a firmware update, all would be in Chinese language. To prevent this, I can use this tool, change the language flag of downloaded firmware to chinese, upload it, and the gui is still in English?

 

[alastairstevenson]

Do you have any insight as to where the day of week characters are and how one can modify the firmware to make them English in a Chinese region code camera?

I was going to look into this but I don't have a camera to experiment with that displays Chinese in the weekday, they are all English.
If I had - I'd avoid trying to reverse the hicore application to figure where the incorrect reference to the weekday definitions is being made - too large, too difficult.
The firmware is generally built to be language-independent, with the translations handled by the tags definitions in each of the language-specific XML trees.
It's possible there may be a stray reference to the zh tree instead of the selected language tree when selecting the value to display for day of the week.
So an easy thing to try would be to copy the 'en' XML tree over the 'zh' and 'zh_TW' trees in the hope of changing the source of the Chinese days of the week values.

 

[wzhick]

Also, the firmware contains an initrd image in hroot.img. When it makes it to the camera, it appears to be /dev/mtd11. When I bypass the 64 byte header, there's a gzip file, initrd.gz, but can't gunzip it. Any clues that may help with this? The magic header for gzip looks a little odd in that the 4th byte is 08 where it's normally 00. I'm assuming the boot loader is unzipping it or is it just mounting a file system from a zipped file?

I extracted initrd using Far Manager, without problems, after I removed the first bytes of the file.
I think initrd это filesystem, not file.

 

[scn101]

1. Execute cat /proc/sys/hkvs/bootpar on NVR, and post result here
2. post head decoded info from hiktools output

I think that the firmware is not compatible with your device, and it has refused to accept it. This check I do not shut off for safety reasons. BUT if you want - you can do it.
To do this, you need to disassemble the firmware you want to download, and then glue it back by taking the head of the firmware that is compatible with your device.


About IPC and NVR compatibility. Tools only modifies the properties of the firmware file that it had not been rejected by the device. As the firmware contains other languages they will be available for selection. Сhange device settings, where it is specified language is not happening. So the compatibility of your cameras and NVR should not change. The tools simply change language flag in english firmware, so that the device would believe that a сhinese firmware. No other changes in the contents of the firmware have been made.

Thanks for the reply. I don't have an hkvs directory (see below).

# pwd
/proc/sys
# ls
debug dev fs kernel net sunrpc vm
#

BTW, the reason I want to upgrade to 3.0.10 is this that the older firmware (v3.0.8)
has a severe security issue that you can review here: http://www.hikvision.com/europe/support_more.asp?id=309

 

[whoslooking]

Hi thanks for this, As per other info I'm trying to telnet in and do a nanddump but keep failing,
nanddump -nof mtd5_temp /dev/mtd5nanddump -nof mtd6_temp /dev/mtd6

whats wrong with these, any help would'nt go a miss as these dumps from this camera may be interesting to look at.

nanddump -nof mtd6_temp /dev/mtd6
nanddump: invalid option -- n
BusyBox v1.19.3 (2014-07-21 13:53:56 CST) multi-call binary.


Usage: nanddump [-o] [-b] [-s ADDR] [-f FILE] MTD_DEVICE


Dump the specified MTD device


-o Omit oob data
-b Omit bad block from the dump
-s ADDR Start address
-l LEN Length
-f FILE Dump to file ('-' for stdout)

 

[alastairstevenson]

Without knowing what error you are getting - it may not be possible to know what's wrong.
Are you using the mtdutils components via a mount to a network location?
Are you using an internal or external file location where there is enough space to hold the extract?
Assuming your command line above with 2 lines joined is a typo.

Here is an example using the built-in tool, storing the result in the camera:

login as: root
root@192.168.254.11's password:

BusyBox v1.19.3 (2014-07-11 11:25:54 CST) built-in shell (ash)
Enter 'help' for a list of built-in commands.
# df
Filesystem 1K-blocks Used Available Use% Mounted on
rootfs 8084 7406 678 92% /
/dev/root 8084 7406 678 92% /
udev 47716 80 47636 0% /dev
/dev/ubi1_0 20264 11856 7356 62% /dav
/dev/ubi3_0 1300 132 1068 11% /davinci
/dev/ubi4_0 1300 84 1116 7% /config
# cd /dav
# nanddump -of mtd5_temp /dev/mtd5
# ls -al mt*
-rw-r--r-- 1 root root 524288 Feb 28 17:28 mtd5_temp
# df
Filesystem 1K-blocks Used Available Use% Mounted on
rootfs 8084 7407 677 92% /
/dev/root 8084 7407 677 92% /
udev 47716 80 47636 0% /dev
/dev/ubi1_0 20264 11988 7220 62% /dav
/dev/ubi3_0 1300 132 1068 11% /davinci
/dev/ubi4_0 1300 84 1116 7% /config
#

*Edit* Some clarification and more detail now shown in the previous post.

 

[whoslooking]

Hi, using a sd card now i've been messing around with it on a NAS, but geeting no where fast, I tried to follow Camera Critics Guide on this, but seem to missing something I'm now getting this.


Filesystem 1K-blocks Used Available Use% Mounted on
udev 30096 32 30064 0% /dev
/dev/mtdblock5 10996 10996 0 100% /dav
/dev/mtdblock6 1664 308 1356 19% /devinfo
/dev/mmc01 31245376 31002128 243248 99% /mnt/mmc01




# cd /dav
# nanddump -of mtd5_temp /dev/mtd5
nanddump: can't open 'mtd5_temp': Read-only file system

thanks for your time.

 

[alastairstevenson]

I have assumed this is a Hikvision camera, running fairly recent firmware.
Now I'm not so sure, as from what you've shown above it's using an mtdblock mount for the filesystem as opposed to the more usual ubifs on the cameras.
Your /dav mount point is showing 100% utilised, read-only, so you can't save anything new there. Hence the error.
The SD card looks pretty full - but enough space for a firmware dump.


So - what's the camera model and firmware version? 'prtHardInfo' will probably show this.
What is the output from 'df'?
What is the output from 'mount'?
What is the output from 'cat /proc/mtd'
Then you could figure where you can place the extract. Then you need to get it off the camera ...
Do you have 'NAS storage' defined in the camera GUI? That's a convenient way to transfer files on and off. The 'mount' output will show that.

 

[networkcameracritic]

I'm using my own nanddump that I provided from MTDUTILS that has more options. I believe the n option is without error correction, so you can leave it out.

Hi thanks for this, As per other info I'm trying to telnet in and do a nanddump but keep failing,
nanddump -nof mtd5_temp /dev/mtd5nanddump -nof mtd6_temp /dev/mtd6

whats wrong with these, any help would'nt go a miss as these dumps from this camera may be interesting to look at.

nanddump -nof mtd6_temp /dev/mtd6
nanddump: invalid option -- n
BusyBox v1.19.3 (2014-07-21 13:53:56 CST) multi-call binary.


Usage: nanddump [-o] [-b] [-s ADDR] [-f FILE] MTD_DEVICE


Dump the specified MTD device


-o Omit oob data
-b Omit bad block from the dump
-s ADDR Start address
-l LEN Length
-f FILE Dump to file ('-' for stdout)

 

[networkcameracritic]

I extracted initrd using Far Manager, without problems, after I removed the first bytes of the file.
I think initrd это filesystem, not file.

I tried far manager, same issue. What I want to do is this. I want to take /dev/mtd11 which contains initrd and mount initrd looking for what's different. I can do this with hroot.img, no problem, but when I do the same with mtd11 it creates an initrd.gz and it has valid gzip header, but far manager, z-zip, gzip on the camera, gzip on centos, WinRAR all get errors. Far manager lets me bypass the errors but then I get a useless files, mostly x00 and small.

 

[whoslooking]

Sorry for the lack of info, Yes it's Hikvision 2cd3410

# prtHardInfo
Start at 2015-02-28 20:11:31
Serial NO S-2CD3410FD-IW20141013AACH#########
V5.2.0 build 140721
hardwareVersion = 0x0
hardWareExtVersion = 0x0
encodeChans = 1
decodeChans = 1
alarmInNums = 1
alarmOutNums = 1
ataCtrlNums = 0
flashChipNums = 0
ramSize = 0x80
networksNums = 1
language = 1
devType = 0x22002
net reboot count = 0
Path: .
Working Copy Root Path: /data1/data_liwenwei/work/frontend_software_platform_IPC5.2.0
URL: https://192.0.0.140/Camera/Platform/Branches/frontend_software_platform_IPC5.2.0
Repository Root: https://192.0.0.140/Camera
Repository UUID: df2d70c3-7593-7941-af1e-571b313c0946
Revision: 84909
Node Kind: directory
Schedule: normal
Last Changed Author: chentianyong
Last Changed Rev: 84908
Last Changed Date: 2014-07-21 21:47:41 +0800 (Mon, 21 Jul 2014



# df
Filesystem 1K-blocks Used Available Use% Mounted on
udev 30096 44 30052 0% /dev
/dev/mtdblock5 10996 10996 0 100% /dav
/dev/mtdblock6 1664 308 1356 19% /devinfo
/dev/mmc01 31245376 116432 31128944 0% /mnt/mmc01

# mount
rootfs on / type rootfs (rw)
proc on /proc type proc (rw,relatime)
none on /sys type sysfs (rw,relatime)
ramfs on /home type ramfs (rw,relatime)
udev on /dev type tmpfs (rw,relatime)
devpts on /dev/pts type devpts (rw,relatime,mode=600,ptmxmode=000)
/dev/mtdblock5 on /dav type cramfs (ro,relatime)
/dev/mtdblock6 on /devinfo type jffs2 (rw,relatime)
/dev/mmc01 on /mnt/mmc01 type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=cp437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)

# cat /proc/mtd
dev: size erasesize name
mtd0: 00040000 00010000 "bld"
mtd1: 00010000 00010000 "env"
mtd2: 00010000 00010000 "enc"
mtd3: 00010000 00010000 "usr"
mtd4: 00380000 00010000 "sys"
mtd5: 00a70000 00010000 "app"
mtd6: 001a0000 00010000 "cfg"

I did have the NAS setup, but for some reason it kept dropping out.

 

[alastairstevenson]

OK, that's pretty useful.
I'm guessing a bit here. I'm not familiar with that camera - but the flash arrangement looks more like that of an NVR.
It looks like you've wiped your SD card. Oodles of space there now.
So - mtdblock5 looks like it holds the system software, in a CRAMFS file system format (compressed ROM file system), which is a read-only mount.
If you really want to give your brain a hard time exploring what's stored, this would probably work:

cat /dev/mtdblock5 > /mnt/mmc01/mtdblock5_copy
If you have a Linux box - you can mount this directly as a CRAMFS to inspect the contents.

cat /dev/mtdblock6 > /mnt/mmc01/mtdblock6_copy
If you have a Linux box - you can mount this directly as a jffs2 to inspect the contents.

If it's done in the same way as an NVR - mtdblock0 as well as holding the u-boot loader may well hold the camera hardware info including any soft-selectable capabilities. Use HxD or similar to find the magic number SWKH as the start of that block.
cat /dev/mtdblock0 > /mnt/mmc01/mtdblock0_copy

Have fun!