[MCR] Hikvision packer/unpacker for 5.3.x and newer firmware

habeschi said:
Is there any description about how to search the firmware for the HKWS characters
Click to expand...
It's a standard feature in any HEX editor.
habeschi said:
Because i have never done this before.
Click to expand...
With respect, you would find major difficulties in unpacking, decrypting, modifying, encrypting and repacking firmware if you are unfamiliar with a basic tool such as a HEX editor.

What are you trying to achieve?
 
I want to change the Picture which is shown if no camera is connected.

It is true that i have used a HEX editor just a couple of times. But i want to learn that. And i think with a little help I could do it
 
Last edited:
montecrypto said:
The attached app unpacks and repacks Hikvision firmware for K41/K51 NVRs and R0/R1/R6/G0 cameras. I plan to add support for more hardware, but in many cases I need to buy cameras to extract keys from them. Your donations can help, contribute here if you feel like it:

The binary runs on x64 Linux. Enjoy.

Code: 
hikpack v2.5 Hikvision firmware packer/unpacker by montecrypto
*** No expressed or implied warranties of any kind. Use at your own risk ***
Usage:
   hikpack -t <fwtype> -i <src_dav_file>                     print dav file information
   hikpack -t <fwtype> -x <src_dav_file> -o <dst_dir>        extract dav file into directory
   hikpack [opts] -t <fwtype> -p <dst_dav_file> -o <src_dir> pack dav file from source directory
   hikpack -t <fwtype> -d <src_crypted_file> -o <dst_file>   decrypt file
   hikpack -t <fwtype> -g <src_crypted_cfg> -o <dst_file>    decrypt configuration backup file
   hikpack -t <fwtype> -G <src_file> -o <crypted_cfg_file>   encrypt configuration backup file (CRC adjusted if needed)
   hikpack -t <fwtype> -e <src_file> -o <dst_crypted_file>   encrypt file
     -t option sets firmware platform type. Currently supported: cameras: r0,r1,r6,g0 nvr: k41,k51
     ----- The following options are used by the pack (-p) command:
     -L <1,2>      set language id (1=EN, 2=CN)
     -D <YYYYMMDD> set firmware date.
     -V <ver>      set firmware version. Use hex number, e.g.: 0x05040003 for v5.4.3

For whatever reason attachments no longer work, the file is here:

hikpack_2.5.zip — RGhost — файлообменник
Click to expand...


Thanks for the info. I'm having a little trouble decrypting a configuration file I downloaded. Here is the commands that I have tried to decrypt the file.

./hikpack -t r1 -g configurationFile -o configuraton_decrypted


I also tried r6, G0, etc but nothing seems to work. Here is a copy of the device info if that helps.

<DeviceInfo xmlns="http://www.hikvision.com/ver10/XMLSchema" version="1.0">
<deviceName>TEST1</deviceName>
<deviceID>88</deviceID>
<deviceDescription>IPCamera</deviceDescription>
<deviceLocation>hangzhou</deviceLocation>
<systemContact>Hikvision.China</systemContact>
<model>DS-2CD4125FWD-IZ</model>
<serialNumber>DS-2CD4125FWD-IZ20160426CCWR596304447</serialNumber>
<macAddress>bc:ad:28:35:5f:6b</macAddress>
<firmwareVersion>V5.3.5</firmwareVersion>
<firmwareReleasedDate>build 151218</firmwareReleasedDate>
<bootVersion>V1.3.4</bootVersion>
<bootReleasedDate>100316</bootReleasedDate>
<hardwareVersion>0x0</hardwareVersion>
</DeviceInfo>
 
Hello,

I am very interested by Hikpack, unfortunately, the version of the camera I would like to modify is a G1 (5FWD). I read that the latest version is 2.8. Is there any chance G1 is supported by this one and is there an approximative date of release ?
Thank you
 
I've been poking around one of my cameras, a DS-2CD2135F-IS, and have come across something that seems unusual.

When using hiktools v2.5 against IPC_G0_CN_STD_5.3.3_150624, I get the following error:

Code: 
$ ./hikpack -t g0 -i 533_g0_digicap.dav
Magic   : 484b3230
hdr_crc : 00002414 (OK)
frm_flg : 1220060021111110021
*** ERROR *** parse -5

The other G0 firmwares I've tried extract fine. My camera will take this 5.3.3. firmware just fine, but no others. This has me wondering if there's something different in the 5.3.3 I have, can anyone shed light on the "parse -5" error?

Edit:
Looks like this earlier image is using the packing method r6.

Code: 
$ ./hikpack -t r6 -i 533_g0_digicap.dav
Magic   : 484b3230
hdr_crc : 00002414 (OK)
frm_flg : 1220060021111110021
Magic   : 484b3330
hdr_crc : 1a843bba (OK)
version : 05030003
lang_id : 00000002
date    : 150624
frm_flg : 1220060021111110021
File: _cfgUpgClass, CRC OK
File: uImage, CRC OK
File: initrun.sh, CRC OK
File: r7_app.tar.gz, CRC OK

Just moved my reply to this thread, I had erroneously replied to the hiktools thread.
 
The firmware i want to modify consists of 3 parts. 3 times Header + cramfs.img + new_20.bin. Just the last one worked on the DVR. So i will continue with the last one
Decrypting and encrypting is working because md5 values of the files are the same.

Following steps done:

Extracting cramfs.img and its contents, decrypting, modifying, encrypting, decrypting new_10.bin, modifying MD5 values stored in new_10.bin, encrypting new_10.bin, using mkcramfs to create new cramfs.img, decrypting new_20.bin, save new MD5 value of cramfs.img new_20.bin, encrypting new_20.bin, creating dav file with hex editor.

But the update fails. i get "Upgrading failed, execute program error"

So i just tried to make a new firmware with unmodified files. But the new cramfs.img with the unmodified files is different to the one stored in the original dav file.
Even when i modifiy the md5 in the new_20.bin the update with the unmodified files fails. the DVR reads the dav file till the end and then i get the error "Upgrading failed, execute program error"

So i think the problem is generating the cramfs.img. Am i right?
 
habeschi said:
So i think the problem is generating the cramfs.img. Am i right?
Click to expand...
Maybe not.
If you are modifying new_10.bin and new_20.bin manually as you say you have - you need to pay attention to the byte alignment for the decrypt/encrypt to work correctly.
But why are you modifying manually when @montecrypto hikpack 2.5 handles this automatically for you?
 
alastairstevenson said:
Maybe not.
If you are modifying new_10.bin and new_20.bin manually as you say you have - you need to pay attention to the byte alignment for the decrypt/encrypt to work correctly.
But why are you modifying manually when @montecrypto hikpack 2.5 handles this automatically for you?
Click to expand...

Because the dav file hikpack creates doesn't work. The DVR shows the error Firmware mismatch at the beginning. it doesn't fully read the file till the end. I think Hikpack can't handle the header. I tested this with unmodified files. Hikpack can't even extract the dav file correctly. because it just creates dav_header and cramfs.img. I extract the new_20.bin manually
 
alastairstevenson said:
Ok, you can do this manually, but there may be a 4-byte re-alignment needed for the manual placement of new_20.bin
Click to expand...
I tried it with hikpack. Put every unmodified file in a folder (just used 7zip to extract the files from the original dav file)
- dav_header
- gui_res.tar.lzma
- payler.zip
- start.sh
- sys_app.tar.lzma
- uImage
- WebComponents.exe
- webs.tar.lzma
- new_20.bin

User the command ./hikpack -t k41 -p 1.dav -o 1

The dav file hikpack creates can not be opened with 7zip anymore and the hex editor shows a totally different file

To be clear: i did not decrypt and encrypt the files. The files are unmodified files from the original cramfs
 
habeschi said:
Can you explain this a little bit more, please?
Click to expand...
I'll try.
This from my notes a couple of years ago on some NVR firmware where the @montecrypto hikpack tool had not yet been published :
'ded' is the built in 3DES decrypt/encrypt program in the NVR.
There appears to be the usual 'new_20.bin' on the tail of digicap.dav, starting
at 0xF8306C with an encrypted section in it.
Both new_10.bin and new_20.bin have to be byte-aligned correctly in order for
ded to decrypt, looks like new_20.bin is misaligned by 4 bytes. I need to check the detail
on this and document it, but it doesn't matter too much when the checks/reboots are bypassed
in sc_hicore.
I suspect it will affect the web GUI update accepting or not the digicap.dav file.
(It does - see later)
Click to expand...
new_20.bin needed a bit extra though - in this case an extra 4 null bytes at the head
to give the correct alignment for ded decryption, which showed that it was only covering
an md5 value for cramfs.img
Then encrypt it again, strip off the extra 4 bytes, and append to the digicap.dav that
hiktools05r1 created.
That version was accepted OK by the web GUI update.
Click to expand...
 
I will tell you exactly what i did (maybe you can figure out my mistake):

1. decrypt whole untouched digicap.dav
2. open decrypted digicap.dav (from point 1) with hex editor and just changed the md5 value with the one from the cramfs.img and saved
3. encrypted the dav file again
5. opened untouched dav file with hex editor and deleted everything except the header
6. opened new cramfs.img with hex editor and copied everything and pasted behind the header from the untouched dav file
7. opened encrypted dav file (from point 3) with hex editor and copied new_20.bin tail and pasted after the new cramfs.img and saved everything to one new dav file.

For testing i just decrypted and encrypted tne untouched dav file and checked the new_20.bin tail and it was the same.
 
habeschi said:
I will tell you exactly what i did (maybe you can figure out my mistake):
Click to expand...
I'm sorry but I just don't understand your steps as described.
habeschi said:
1. decrypt whole untouched digicap.dav
Click to expand...
It's not encrypted - it needs to be unpacked with hiktools05R1 or @montecrypto hikpack
habeschi said:
2. open decrypted digicap.dav (from point 1) with hex editor and just changed the md5 value with the one from the cramfs.img and saved
Click to expand...
new_20.bin is encrypted - so you can't just modify the contents and expect it to be accepted. It needs to be decrypted, the md5 for cramfs.img updated, and encrypted again.
habeschi said:
3. encrypted the dav file again
Click to expand...
With what? It needs to be packed, not encrypted. And the updated new_20.bin needs to be appended.
habeschi said:
7. opened encrypted dav file (from point 3) with hex editor and copied new_20.bin tail and pasted after the new cramfs.img and saved everything to one new dav file.
Click to expand...
new_20.bin needs to be encrypted, and correctly byte-alligned to be accepted.
habeschi said:
For testing i just decrypted and encrypted tne untouched dav file and checked the new_20.bin tail and it was the same.
Click to expand...
Using the @montecrypto packer that handles new_20.bin automatically?
 
You must log in or register to reply here.
Top Bottom