alastairstevenson
Staff member
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
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
Attachments
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)?
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
alastairstevenson
Staff member
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
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?
alastairstevenson
Staff member
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.
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.
alexander.omiz
Young grasshopper
- Joined
- Jan 14, 2015
- Messages
- 33
- Reaction score
- 8
It seems a little problem with hikvision ds-2cd2732f-is with 5.2.5. Did i do something incorrect?
Attachments
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
The area should be F4 long (So it's 15 lines and 4 bytes)
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:
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
The area should be F4 long (So it's 15 lines and 4 bytes)
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:
It seems a little problem with hikvision ds-2cd2732f-is with 5.2.5. Did i do something incorrect?
Attachments
alastairstevenson
Staff member
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.
I will let you know of the result.
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.
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.
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.
- - - 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.
Last edited by a moderator:
alexander.omiz
Young grasshopper
- Joined
- Jan 14, 2015
- Messages
- 33
- Reaction score
- 8
I'm trying to find that out. Anyway, 2032 hacked works succesfully 100% english NOT bricked with hacked mtd, Checksum-16 (97 0C -> 96 0C)
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:
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.")
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:
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.")
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.
Attachments
alastairstevenson
Staff member
Yes indeed, newly-manufactured camera with the changed checksum implementation.
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"
On my "old" 2332 labled 5.2.0 and 5.2.0 ML inside is everything ok.