Hikvision Checksum

AKalm

Young grasshopper
Dec 2, 2014
79
12
Does anyone know how to calculate a new checksum, if I have modified something (mtd5/mtd6)? And where is the calculated checksum saved/located?

Thanks
 
That depends on which parts of mtdblock5 / 6 you have modified.
The blocks that hold the hardware descriptors such as model, serial number, language etc have their own checksum. Not all of those blocks are active.
The bootparams segment has a checksum according to u-boot documentation for its version.

In this hardware block example, the F4 is the number of bytes covered by the checksum, and the 0A64 is the checksum itself. This same block exists usually 3 times and is active in mtdblock6

attachment.php
 

Attachments

  • cksum.jpg
    cksum.jpg
    255.7 KB · Views: 450
Thanks for quick reply,

I am modifying the 1620th byte in mtd5 and 16th byte in mtd6.
How can I calculate a new checksum for them? If done, can I modify the checksum just like entering the new one on the circled are shown in your picture (just on a differente byte)?

That depends on which parts of mtdblock5 / 6 you have modified.
The blocks that hold the hardware descriptors such as model, serial number, language etc have their own checksum. Not all of those blocks are active.
The bootparams segment has a checksum according to u-boot documentation for its version.

In this hardware block example, the F4 is the number of bytes covered by the checksum, and the 0A64 is the checksum itself. This same block exists usually 3 times and is active in mtdblock6

attachment.php
 
In my example image, using HxD, the F4 byte circled is the number of bytes covered by the checksum.
The bytes that are highlighted in HxD are those F4 bytes.
Then HxD can calculate the checksum of the highlighted region for you, as shown at the bottom of the image, using the Analysis menu.
Then you can modify the actual checksum bytes, the 640A circled, and save the updated result.
Be aware that there a 3 such segments on mtdblock6
 
Wonderful, thanks!

In my example image, using HxD, the F4 byte circled is the number of bytes covered by the checksum.
The bytes that are highlighted in HxD are those F4 bytes.
Then HxD can calculate the checksum of the highlighted region for you, as shown at the bottom of the image, using the Analysis menu.
Then you can modify the actual checksum bytes, the 640A circled, and save the updated result.
Be aware that there a 3 such segments on mtdblock6
 
Is hikvision using Checksum16 for mtds like in your example? Or shall I try other algorythms if I want to modify it?

In my example image, using HxD, the F4 byte circled is the number of bytes covered by the checksum.
The bytes that are highlighted in HxD are those F4 bytes.
Then HxD can calculate the checksum of the highlighted region for you, as shown at the bottom of the image, using the Analysis menu.
Then you can modify the actual checksum bytes, the 640A circled, and save the updated result.
Be aware that there a 3 such segments on mtdblock6
 
Yes. But why try other algorithms when you can see what's in use, I don't follow.
You can confirm this for yourself if you take any unchanged mtdblock5 or 6 hardware descriptor segment, highlight the number of bytes spanned by the checksum (F4 above, but doesn't have to be that), get HxD to do a Checksum-16 calculation, and compare the result with the checksum that's already stored in the segment.
But there are other checksums in other places that work differently.
 
It seems a little problem with hikvision ds-2cd2732f-is with 5.2.5. Did i do something incorrect?
attachment.php
 

Attachments

  • mtd.jpg
    mtd.jpg
    105.3 KB · Views: 384
Have you changed the 02 to 01 at 1620th byte? (0x654) (Chinese to english)? Looks like not.

I think you highlighted the wrong/not enough bytes, anyway you have to write to new checksum there, where I've highlighted it in the first picture - B2 08

attachment.php


The area should be F4 long (So it's 15 lines and 4 bytes)

attachment.php


If you highlited it, analysis menu - checksum .. - checksum16, you'll se the code in the footer, and write in as I did: 08B2 -> B2 08 (2 bytes before F4)

Mtd6 ended up with the same checksum:

attachment.php

It seems a little problem with hikvision ds-2cd2732f-is with 5.2.5. Did i do something incorrect?
attachment.php
 

Attachments

  • b208.jpg
    b208.jpg
    270.7 KB · Views: 391
  • b208_checksumarea.jpg
    b208_checksumarea.jpg
    265.5 KB · Views: 382
  • b208_checksumareamtd6.jpg
    b208_checksumareamtd6.jpg
    266.8 KB · Views: 386
  • Like
Reactions: scn101
It seems a little problem with hikvision ds-2cd2732f-is with 5.2.5. Did i do something incorrect?
Interesting. It looks like the type of checksum used here has changed in the newer versions of these cameras. That will presumably also limit the lowest version of firmware that could be installed. Unless you want to swap out the bootloader.
It's not a checksum type that HxD natively supports, it needs a bit of research.
 
I have one with 5.2.8 on the boxlabel, but 5.2.5 inside on the cam. I am going to check/update that one now.

I will let you know of the result.

Interesting. It looks like the type of checksum used here has changed in the newer versions of these cameras. That will presumably also limit the lowest version of firmware that could be installed. Unless you want to swap out the bootloader.
It's not a checksum type that HxD natively supports, it needs a bit of research.
 
Last edited by a moderator:
True, 2732 has a different checksum

I've done a 2332 without bricking it, but this one really needs research. I will have a look at a 2032, 2132 and 2232 as well.

I have one with 5.2.8 on the boxlabel, but 5.2.5 inside on the cam. I am going to check/update that one now.

I will let you know of the result.

- - - Updated - - -

True, 2732 has a different checksum

I've done a 2332 without bricking it, but this one really needs research. I will have a look at a 2032 and 2232 as well.

Interesting. It looks like the type of checksum used here has changed in the newer versions of these cameras. That will presumably also limit the lowest version of firmware that could be installed. Unless you want to swap out the bootloader.
It's not a checksum type that HxD natively supports, it needs a bit of research.
 
Last edited by a moderator:
Mtd hack works on 5.2.8 (5.2.5) cameras!!

Just need to calculate a new checksum when you are modifying the mtd's (change 02 to 01 that's done at the red circled byte), analysis - checksum.. - checksum-16, and write the result 2 bytes before F4, pictures attached for example:

attachment.php
attachment.php


This works for 5.2.8 (5.2.5) cameras:
2032, 2232, 2332 tested 100%

Still bricking: 2132, 2732 (different type of checksum)

Not tested: 2432, 2532, 2632 (don't have 5.2.8 at home)


("
You can confirm this for yourself if you take any unchanged mtdblock5 or 6 hardware descriptor segment, highlight the number of bytes spanned by the checksum (F4 above, but doesn't have to be that), get HxD to do a Checksum-16 calculation, and compare the result with the checksum that's already stored in the segment.")
 
...
("
You can confirm this for yourself if you take any unchanged mtdblock5 or 6 hardware descriptor segment, highlight the number of bytes spanned by the checksum (F4 above, but doesn't have to be that), get HxD to do a Checksum-16 calculation, and compare the result with the checksum that's already stored in the segment.")
I've got a new 2332 labled 5.2.8 and 5.2.0 ML inside.
The calcutated Checksum in the unchanged mtdblock5/6 is not the same as the stored one.
The language flag is "66" :confused:

attachment.php
attachment.php


On my "old" 2332 labled 5.2.0 and 5.2.0 ML inside is everything ok.
 

Attachments

  • mtd5.JPG
    mtd5.JPG
    153.6 KB · Views: 253
  • mtd6.JPG
    mtd6.JPG
    158.3 KB · Views: 252
The seller of the Cam (labled 5.2.8 and 5.2.0 ML inside) wrote me: "Do not try to change the camera's firmware. The results will be bad."
I'll let out my hands off for now.
 
Don't do the hack, or you'll brick. Have to find out the new checksum type/algorithm

I've got a new 2332 labled 5.2.8 and 5.2.0 ML inside.
The calcutated Checksum in the unchanged mtdblock5/6 is not the same as the stored one.
The language flag is "66" :confused:

On my "old" 2332 labled 5.2.0 and 5.2.0 ML inside is everything ok.