*** You go Hang Zhou! *** [R6 camera (DS-2CD2x42) firmware encoding method]

[montecrypto]

Xuefeng Qian, Hikvision's head of R&D is on the mission to use as many crypto, hashing, and CRC algorithms as his team can possibly fit in firmware.

So far we have:

• md5
• sha1
• dumb add crc
• XOR with rotating key
• XOR with computed key
• crc32
• 3des
• aes256

All this obfuscation mess has no cryptographic value because the keys are easily recoverable, but nothing can stop Mr. Xuefeng. He has a vision and he proudly autographs firmware images as "sunxuefeng3":

00000000 30 33 4B 48 │ 7F CA 31 C7 │ 80 0B 00 00 │ 2A 00 00 00  03KH. 1ǀ ...*...
00000010 01 00 00 00 │ 02 00 00 00 │ 01 00 00 00 │ 00 03 F1 07  .............. .
00000020 3B 61 90 66 │ F6 7B 8C 01 │ B8 4E 02 00 │ 08 00 03 05  ;a f { . N......
00000030 00 00 00 00 │ B0 DA 3B 65 │ CE 69 87 3C │ 00 00 00 00  ....  ;e i <....
00000040 73 75 6E 78 │ 75 65 66 65 │ 6E 67 33 00 │ EA 4A 3D 92  sunxuefeng3. J=

I recently got a few R6 4MP cameras with 5.3.8 firmware and I was very annoyed by psh. I can now decrypt R6 digicap.dav and here is the info that should save a lot of time for some of you:

• The digicap.dav header (HK20) is XOR-ed using the the same standard rotating 16-byte key.
• The HK20 header is very similar to HKWS and it contains a list of files (only one file in the 5.3.8 fw).
• File "names" start with "120", which is 0x78, which is the device id, which is important.
• The file inside has a HK30 header, of which 16 bytes are xored (same key) and the rest is AES256-encrypted.
• Figuring out the key will let you decrypt and dump about 40 files.
• There are actually four static AES256 keys, and they are en-xored with a dynamic sequence that depends on the language ID (1 for US, 2 for CN) and device ID (0x78 for R6 cameras). Two of the keys encrypt the header and two of the keys encrypt files.
• The language ID is read from sysflags (256-byte block, starts with "SFLG") that is stored in NAND and returned by one of the /dev/hikio IOCTL calls
• boorparams block is also AES-encrypted. The key is in the kernel.

Most of the crypto code appears to be inappropriately borrowed from the mbed tls library.

Oh, and it is possible to turn US cameras into CN and vice versa.

 

[Oleglevsha]

cool, you can lay out the decrypted image for reference

 

[msalerno]

Very cool stuff - so when do we get a 5.3.8 English firmware with a real shell for SSH?

I'll take a peak over the weekend and see if I can decode any of that you gave us. Thanks!

I have two 2042 cameras at 5.3.8 and while they do everything I need them to, I'm annoyed that there's more to them that I can't access.

 

[montecrypto]

R6 camera (DS-2CD2x42) may support face detection

I have not explored it yet, but 2042 firmware includes face classification library.... Stay tuned.

 

[Tolting Colt Acres]

There is also a v5.4 (build 160401) firmware. I've been using it on my 2042's for about a week now.

 

[whoslooking]

Now the cats out of the bag, its time for a new tools.

 

[Del Boy]

Great work everyone involved.

 

[alastairstevenson]

Well done indeed @montecrypto for what will have been many many hours of poring over disassembled code. Done a bit of that myself ... but with more limited results.
It's pretty clear that Hikvision's efforts in all this are pretty pointless, as there are lots of really smart people around who take it as a challenge to break the protection, either for the lulz, or for profit from the on-line resellers who are still able to sell hacked cameras at good prices.

Maybe worth a mention is that Hikvision clearly have several separate product teams doing firmware development, with different approaches.
The NVR firmware team obviously feels pretty comfortable inside their unchanging encryption layer (3DES), which can be readily figured out, and the tamper protection (MD5), which can be easily ducked, because everything is pretty open and obvious when you get inside.
And when you think about it - each product has the ability to do firmware updates - which implies that there is built in code that has to be able to handle all the protection mechanisms of the newer firmware - so when you extract that, you get chapter and verse on how the stuff works.
Not quite the Rosetta stone, as there is a lot to wade through, but a very good reference.

 

[kayl669]

Hello everyone. Montecrypto, thank you for your post. Really useful information. But unfortunately, my knowledge is not enough to use it. Alastairstevenson, thank you very much for your detailed answer to Jansko. It helped me solve my problems with some NVR. But now, an area in memory chip of NVR (the same as in the ip camera) where the region code is stored is encrypted. And even dump reading does not solve the problem. I can not decrypt this area. And I can not define the algorithm. Can you give some advice what to do?

 

[montecrypto]

But now, an area in memory chip of NVR (the same as in the ip camera) where the region code is stored is encrypted.

It also appears to be write-protected using security features of the flash chip (MX25L12835F in my NVR). You can buy a new chip for $3 and program it to your taste. Cameras use generic NAND memory that cannot be write-protected and it is easier to permanently change region in them. Encryption mechanism is in the kernel.

 

[alastairstevenson]

You can buy a new chip for $3 and program it to your taste.

That's quite an advanced technique that does require some hardware skills and equipment.
I'm quite tempted to try it, just for fun.

But now, an area in memory chip of NVR (the same as in the ip camera) where the region code is stored is encrypted. And even dump reading does not solve the problem. I can not decrypt this area. And I can not define the algorithm. Can you give some advice what to do?

Another approach is to ignore decoding and re-writing the 'hardware descriptor block' and to change the routines that use the settings within it.
That opens up the possibility of doing anything, it's very open-ended.
For example, for the language setting, instead of modifying the value stored in the descriptor block, change the routine that reads the descriptor block such as if it had read another value for language. Hikvision have used good programming practice and gathered a large number of core, or platform, routines in one place making the reverse engineering pretty straightforward. And being a kernel 'shared object' it disassembles very nicely.

 

[mayfer]

So there is hope of "fixing" our language flags (Lang=2) on the nvr ?

 

[alastairstevenson]

So there is hope of "fixing" our language flags (Lang=2) on the nvr ?

Yes, this can be done, but there are quite a lot of pre-requisites.
The act of changing the result in the routine that gets the language byte implies the files in the firmware have been decrypted, that the multiple integrity and ant-tampering checks that are triggered for even a 1-bit change have been neutered, and that the firmware has been able to be repacked such that it can be applied.

I did find originally that the easiest way had been to start with a firmware version that gave EN menus on CN NVRs, such as 3.0.8 and do web GUI updates only, such that the device configuration was updated / translated at each step, which retains the EN menus setting. So there is also a language flag in the device configuration file.
But as we know - Hikvision have now added an 'unrollback' (their word) fix that stops you going back in firmware versions to get some of the benefits of the earlier versions. Such as less strict camera language checks.

 

[kayl669]

Yes. I was just working on a kernel decompilation. But, as I said before, my knowledge level in this area is not so high, so this will take some time

 

[kayl669]

That's quite an advanced technique that does require some hardware skills and equipment.
I'm quite tempted to try it, just for fun.

I do this all the time. In my opinion the easiest way.

Another approach is to ignore decoding and re-writing the 'hardware descriptor block' and to change the routines that use the settings within it.
That opens up the possibility of doing anything, it's very open-ended.
For example, for the language setting, instead of modifying the value stored in the descriptor block, change the routine that reads the descriptor block such as if it had read another value for language. Hikvision have used good programming practice and gathered a large number of core, or platform, routines in one place making the reverse engineering pretty straightforward. And being a kernel 'shared object' it disassembles very nicely.

Yes, I've been thinking about it. But in the new XVR, which I bought on Taobao, the encrypted area is not 256 bytes, as it was in previous models, and 512 bytes. If I replace a block of 256 bytes, the device can be a brick.

 

[kayl669]

Alastairstevenson, sorry, accidentally I put my reply to your original post. I do this all the time. In my opinion the easiest way.

 

[uint32_t]

Mr. Xuefeng is actually Xue Feng, or Mr Xue. Family names in China are written first, according to my wife who comes from Guangzhou.

The sellers on aliexpress using "hacked to english" firmware sometimes post files on the Chinese equivalent of dropbox at http://pan.baidu.com/. Use the search engine www.baidu.com to find the links, and use Chinese input.

eg search baidu for: 海康威视 摄像 英文

 

[montecrypto]

It also appears to be write-protected using security features of the flash chip (MX25L12835F in my NVR). You can buy a new chip for $3 and program it to your taste. Cameras use generic NAND memory that cannot be write-protected and it is easier to permanently change region in them. Encryption mechanism is in the kernel.

I stand corrected. Hardware write-protection in dvr serial flash is actually not used because Hikvision's production processes need to modify bootparams multiple times to set configuration values, such as memory sizes, model name, and yes, region and language codes. What this means for us is that it is possible, with some kernel and ioctl tinkering, to PERMANENTLY change model name, features, language and region code in DVRs and cameras.

All you need to do is edit bootparams (256-byte block stored at sector 0x2E000 for DVRs, don't remember for cameras), recalculate its checksum, and write it back.
I now have a DVR that used to be a Chinese-language DS-7608N. It now presents itself as an English-language DS-7608NI and it takes unmodified EN firmware.

HIKVISION: if you change the obfuscation method again, and I have to spend more time figuring it out, I will release an app that can edit everything in bootparams and write it back to flash.

 

[uint32_t]

I don't know why they even bother, I'm sick of the way they separate out the market by region coding cameras and mandating Chinese market cameras to Chinese only. Buying genuine hikvision products from correct region is almost impossible in some countries not to mention also expensive. Just take a look at the following:
http://sergei.nz/buying-hikvision-cameras-in-new-zealand/

I'm from NZ and also enquired with the same distributor atlas gentech and they are a total rip off, not to mention they only sell to trade only customers not the average Joe Bloggs who wants one or two cameras for his house. This makes it so difficult to buy genuine cameras in NZ and hisvision wonder why people are hacking Chinese cameras?I will continue buying off taobao and aliexpress for my installs. My customers usually don't care about gear being mandated to Chinese since they don't have to configure anything, I do all that. All they want is to view their cameras on their smartphones and look at recordings remotely using the nvrs web interface which is English anyway.

 

[kayl669]

All you need to do is edit bootparams (256-byte block stored at sector 0x2E000 for DVRs, don't remember for cameras), recalculate its checksum, and write it back.

It was easy earlier. But now this sector is encrypted. And it has 258 byte in new NVR and 517 byte in XVR. In new XVR this block is stored at sector 0x3F000.