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
![]()
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
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
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 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.
Is there any tools to analysis the checksum?
I've got a new 2332 labled 5.2.8 and 5.2.0 ML inside....
("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"
On my "old" 2332 labled 5.2.0 and 5.2.0 ML inside is everything ok.