Reverse engineering Hikvision DVR firmware

[Midsteelblue]

I have been wanting to take apart my Hikvision DVR (DS-7204 HGHI-SH) and I have finally begun by using the hikpack tool by @montecrypto amoungst several others (binwalk, mkcramfs, bless)

Firstly hikpack doesn't directly support this DVR but I have got round that mostly... but this is where I am:

* downloaded firmware update and extracted digicap.dav
This actually contains two images, a 108 byte header + cramfs.img + new_20.bin along with another 108 byte header + cramfs.img + new_20.bin after it. Using a hex editor I carved out each one and saved them to individual digicap.dav files and tested the firmwares on the DVR, the first one failed but the second one worked so I am working with the second now.

Used binwalk to extract the cramfs.img and it's contents and hikpack (using switch -t k41) to extract the header from the digicap.dav

Validated using file hashing that the hikpack encryption and decryption was working (-t k41) correctly for this DVR model firmware and I can confirm it is.

I was able to use mkcramfs to create a new cramfs.img using the unmodified files extracted from the original cramfs.img and repack the digicap.dav using the original header and new cramfs.img containing unmodified files. Hikpack recreated a new_20.bin but I also needed to adjust the devclass manually to match the original.

Firmware upgrade successful, so I know I have the right tools to do the job! Thank you everyone for that as it was your knowledge, hardwork and tools that helped me.

Now... The problem I have when I repeat the process and modify a file.

unpack everything...
decrypt start.sh, modify file, encrypt start.sh, run md5sum against encrypted start.sh
decrypt new_10.bin, change md5sum value against start.sh, encrypt new_10.bin

repack everything as before but now the firmware fails??? I suspect that there is another checksum that needs altering but I cannot find where....

I repeated both processes again for sanity check but as soon as I change anything the firmware fails even with updating the new_10.bin file with the MD5 from the modified encrypted file.

The help I need, beyond the obvious, is what is contained in the new_20.bin? is there anything else I should be looking for or modifying? Basically, help!

Thank you everyone and keep up the good work!

 

[alastairstevenson]

repack everything as before but now the firmware fails??? I suspect that there is another checksum that needs altering but I cannot find where....

new_20.bin holds the md5 for the cramfs.img
Check it out for yourself with the original cramfs.img and a decrypted new_20.bin

 

[Midsteelblue]

If I remember right the hikpack didn't decrypt the new_20 file. Is it encrypted in the same way the header is?

p.s out of curiosity, how is the header encrypted? Read something about the first 15 bytes being an XOR key which shifts left every rotation?

 

[alastairstevenson]

new_20 is encrypted in the same way as new_10
Yes, the header is obfuscated with a rotating repeating XOR pattern.

I've always decrypted/encrypted the files manually, with the built-in Hikvision 'ded' program that you'll see referenced in start.sh

 

[Midsteelblue]

I'll have a good play with this today and look around what you've mentioned. Thank you again by the way for taking the time to respond.

Had anyone managed to modify the zImage within the uImage file? I wanted to see if there was a way to keep the password and configuration after upgrading the firmware so I can update remotely without having to get hands on.

 

[alastairstevenson]

Had anyone managed to modify the zImage within the uImage file? I wanted to see if there was a way to keep the password and configuration after upgrading the firmware so I can update remotely without having to get hands on.

The configuration data is held in /dev/mtdblock1
From what I recall something like
dd if=/dev/mtdblock1 of=cfg_data bs=64k count=1
will extract a file which can simply be gunzipped with all the camera and other stuff in plaintext.
As of the 3.4.90 firmware I think it is, the admin passwords have been moved elsewhere.

Modifying the zImage is possible - but you'd need to deal with the Linux-standard uncompressor on the head to extract, after modification re-compress and fix up the file size references as even small changes can have a big effect on the compressed file.

 

[Midsteelblue]

Finally got it to work!

The issue ended up being the header CRC. Once everything was repacked I was manually changing the devclass to 0x1e but I wasn't updating the header CRC... Once I did that it was worked. Hikpack works fine using the k41 switch but needs an option for defining the devclass like you can for language and date etc... But anyway...

Next task then it's too look into what during the upgrade process removes the previous configuration. I will have a take a look at the mtdblock1 contents, thank you @alastairstevenson for your guidance!

 

[alastairstevenson]

what during the upgrade process removes the previous configuration.

It's typical that a tftp update wipes the configuration, and that a web GUI update tries to translate / patch the configuration. Provided there isn't too big a leap in the firmware versions over which the structure has been changed.

 

[Uederson Ferreira R O]

Hi all!
I need to remove the Hik logo from a firmware. If someone can do it, pls let me know. I will pay for it.
Cheers