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

Does hikpack allow you to load newer FW in a Chinese 2xx2 (r0) camera that ran 5.2.8 originally from the factory and run 5.4.0 in English (with no NVR language mismatches?)
If one wants to repack with modifications (e.g., changing language from Chinese), specify "-L 1" to tell it to convert the image to an English version:

hikpack alone will not convert cameras into EN. The -L switch only changes the language in the firmware update container ( so you can pack for flashing on both EN and CN cameras).
For cameras where language flag is stored in flash (those include R0), you will need to change it there.
 
any chance that you will support R7 cameras in the near future.
I have a DS-2DE4220IW-D here on chinese firmware 5.40. :-(
 
  • Like
Reactions: mrpeenut24
The unpacker unpacks the files mostly OK - I get a series of expected files and an image of a chunk of the filesystem. But the .tar.gz files inside are not valid. Is that expected?

vI5NGv0.jpg
 
Hello,
I purchased one DS-2CD3T10 camera, firmware 5.4.15, and searching how to change it to english I found it is E2 platform.
What is special on this platform and why I can't apply this tool to change to english?
Thanks
 
the boot params decryption key to your tool?
Can you elaborate?
Which firmware has bootparams encrypted?
What I've seen is that the bootparams are just stored in plaintext in the relevant mtdblocks (eg mtd5, mtd6 for R0 series, mtd1 for the E-series NVRs) but the kicker is that on current firmware, the kernel has been compiled to either hide these (NVRs) or write-protect them (IPCs).
The firmware accesses these areas via one of many ioctl calls.
 
I mean the area in the memory chip. In the NVR E-series, this area is located at 0x2E000. In the DVR series F / N, this area is located at the address 0x3F000. I change it using a programmator, previously desoldering the chip.
 
I change it using a programmator, previously desoldering the chip.
That is the long and hard way, and it requires some soldering skills, particularly with cameras that use TSOP48 flash chips with .5mm pin pitch. I only use this method when there is no other obvious way to access the OS. Once you get shell access, you can just write NAND programmatically.

To answer your question: Hikpack will probably not explicitly support bootparams decryption. I am already losing it trying to manage dozens of crypto keys for various hardware and purposes. I do not know how Hikvison engineers maintain all those keys, nor understand why they exhibit this clearly masochistic behaviour. Most of the keys are very loosely protected and not difficult to retrieve from hardware, so why use them at all?

And a couple of hints:
- You do not always need to encrypt bootparams. For older hardware, you can write plain bootparams over encrypted, and it will work just fine because firmware accepts both for backward compatibility reasons.
- Your bootparams sector overwrite method will not work with newer cameras (R6, G0) that store bootparams in watchdata EMV chips. Ironically, it is easier (relatively speaking) to extract them from the EMV chip than from NAND because SOIC8 chip is much easier to desolder..
 
I tried to disassemble the firmware, but I could not. Why could such an error appear?
----------------------------------------
kot@kot-VirtualBox:~/unpack/5.3.3/1$ ls
digicap.dav hikpack
kot@kot-VirtualBox:~/unpack/5.3.3/1$ ./hikpack -t g0 -x digicap.dav -o ./1
Magic : 484b3230
hdr_crc : 00002414 (OK)
frm_flg : 1220060021111110021
*** ERROR *** parse -5
-----------------------------------------------
thk
IPC_G0_CN_STD_5.3.3_150624
 
@montecrypto, I have a camera wich is e0 . are you planing any release for this platform ?

Maybe... The problem is that different cameras use different keys and packing methods and in many cases you need hardware access to extract keys. I cannot buy every hikvision camera on the market.