Hikvision DS-2CD2x32-I (R0) brick-fix tool / full upgrade method / fixup roundup.

[Iemand91]

I have a DS-2CD2132F-IWS with firmware V5.2.5 build 141201, Multi-language.
Serial number is DS-2CD2132F-IWS20150312CCCH*********.
According to the info I've found; this camera should be able to use this hack and upgrade to all current and future updates right?

This topic pops up from time to time and the prospect of being able to upgrade the firmware is a huge attraction.
However; the instructions are not clear enough for me to do it safely (I don't want to end up with a brick)
The start is pretty understandable, but it starts to confuse me from here:

0x64 and 0x65 devType bytes set to the value from your prtHardInfo command, for example 0x9807 (ie 0798 for the correct byte order) for the DS-2CD2232-I5
0x04 and 0x05 Checksum-16 bytes Set to the Checksum-16 value as calculated by HxD for the 0xF4 bytes starting from location 0x09 remembering the correct byte order, 0x04 is the least significant byte.

This YouTube video from this thread makes it much more understandable, but still.

I'll gues I'll keep following this thread and reading this instructions a couple of times until I do understand it.
(English isn't my native language, so that complicates the whole thing a bit)

 

[markb]

First time doing anything like this managed to follow the instructions to a point but i'm now stuck.

I've set up the Windows share added it in the camera UI NAS settings and its testing successful aswell as mounting on the IP camera (I see it listed when I run # mount)

I guess I now need to copy the mtblocks to my desktop but not sure how to proceed??

# dd if=/dev/mtdblock6 of=mtdblock6_orig
1024+0 records in
1024+0 records out
524288 bytes (512.0KB) copied, 0.363808 seconds, 1.4MB/s
# 1024+0 records in
-sh: 1024+0: not found
# 1024+0 records out
-sh: 1024+0: not found

# ls -al /mnt/nfs00
drwxr-xr-x 1 root root 0 Oct 6 15:06 .
drwxrwxrwx 13 root root 1024 Oct 6 15:06 ..
-rwxr-xr-x 1 root root 282 Oct 6 14:45 desktop.ini

 

[alastairstevenson]

I guess I now need to copy the mtblocks to my desktop but not sure how to proceed??

# dd if=/dev/mtdblock6 of=mtdblock6_orig

If just prior to this point you did a 'change directory' to the mount point of /mnt/nfs00, like so :
cd /mnt/nfs00
you'd find the file already there as it would have been extracted directly to it.
However, you can also copy it to the mount point, like so, assuming the current directory is still where it was when you did the extract :

cp mtdblock6_orig /mnt/nfs00

So far, so good.
Good luck!

 

[markb]

Thanks alastair. I got the mtbdblock copied to my desktop and I have it opened in the HxD editor.

Am I right to just highlight the values I need to change and start typing or is there more to it than that?

e.g. x10 to 01 for English

and presumably x64 and 65 to 05 98 as my specific dev type reads "38917" which I translated to "9805" amd if I'm understanding the instructions correctly this has to be typed in 05 98 for correct byte order?

I'm also not sure about x04 and x05 I couldn't figure out what to change those too, they read 62 0C currently.

 

[markb]

To clarify i'm lost at this step :

0x04 and 0x05 Checksum-16 bytes Set to the Checksum-16 value as calculated by HxD for the 0xF4 bytes starting from location 0x09 remembering the correct byte order, 0x04 is the least significant byte.

I gather that the checksum must match the original unedited value and that's where x04 and x05 comes in but i'm not grasping how you calculate those or how you calculate the original checksum.

Is the highlighted area in the screenshots below the correct way to calculate the checksum?

 

[alastairstevenson]

I gather that the checksum must match the original unedited value

No, that's not correct. Where have you read that? It should be corrected.
The new checksum must be calculated from the current set of data.

Is the highlighted area in the screenshots below the correct way to calculate the checksum?

Nearly correct. Though in practice with the trailing zeroes and the simple type of checksum it doesn't affect the final result.
In both your screenshots you have selected/highlighted a total of 0xF7 bytes of data instead of the needed 0xF4 bytes.
Check the length : F7 value in the status bar at the bottom of the window.
It should be a length of 0xF4 bytes.
Then use the Analysis | Checksums menu to calculate the new checksum and apply it to the locations 0x04 (least significant byte) ans 0x05 (most significant byte).

 

[chubros]

Finally manage to fix 4 ds-2cd2032-i from 5.2.5. I messed up the checksum in one of those but i flash the brick fix en version and then the 5.3.0 downgrader. Then start from scratch and everything went fine!! Thanks again alastairstevenson

 

[alastairstevenson]

Excellent!
Another good result, well done for getting there.

You are not alone - there seems to be a great deal of this going on, bringing these cameras into a safer and more secure state despite Hikvision's rather unfortunate and misguided attempts to stop their customers doing this.
It's such a pity really, as the products are pretty good.
Hikvision - I do hope you are paying attention.
Take note how the volume of forum activity for Dahua is now dominant at your expense, despite your more capable firmware development.

 

[markb]

No, that's not correct. Where have you read that? It should be corrected.
The new checksum must be calculated from the current set of data.

I don't think I read it anywhere just came to that assumption looking at the screenshots in the following thread as the edited files always matched the origin checksum.

Hikvision 5.2.5 & 5.2.8 Full English (INC DAYS OF WEEK) mtd Hack

Nearly correct. Though in practice with the trailing zeroes and the simple type of checksum it doesn't affect the final result.
In both your screenshots you have selected/highlighted a total of 0xF7 bytes of data instead of the needed 0xF4 bytes.
Check the length : F7 value in the status bar at the bottom of the window.
It should be a length of 0xF4 bytes.
Then use the Analysis | Checksums menu to calculate the new checksum and apply it to the locations 0x04 (least significant byte) ans 0x05 (most significant byte).

Ok I think I've got it this time I hope .

I've made my edits to x10 and x64 ran a checksum on the blocks starting just after F4 and it reads a length of 0xF4 at the bottom bar (screenshot attached). The checksum value calcuated was
"0d60" so I've gone ahead and put this value in 0x04 and 0x05.

 

[alastairstevenson]

Ok I think I've got it this time I hope

Nearly!

apply it to the locations 0x04 (least significant byte) ans 0x05 (most significant byte).

You have the checksum calculation correct, but have applied it in reversed order in locations 04 and 05.
Fix that and you should be good to go.

I don't think I read it anywhere just came to that assumption looking at the screenshots in the following thread as the edited files always matched the origin checksum.

Yes, that was based on the assumption that the original checksum was correct. But, for unknown reasons, that's not the case on many cameras.
It is confusing.

 

[markb]

Another success story here, took me until bloody 2AM in the morning but my 2032 camera is now running 5.4.5 in English.

Tomorrow i'll do my other 2032 and possibly attempt my other camera, its one of the fish eye type but I forget the model.

Now I go sleep

Thanks Alistairstevenson!

 

[alastairstevenson]

possibly attempt my other camera, its one of the fish eye type but I forget the model.

Be careful.
That's likely to be a different camera series - the 'Enhanced mtd hack' is for R0 2x32 series.

 

[markb]

Another 2032 camera updated.

This one only took me 30 minutes, its easy once you know what to do.

These are the steps i personally took:

1. Setup the windows share
2. Add the share as a NAS in the camera settings and enable SSH. While you are in there double check your camera firmware version is 5.2.5 or below, you dont want to attempt this on higher firmware as it will likely result in a brick.
3. login to SSH using Putty
4. send the "mount" command to make sure your windows share is mounted
5. send the "cd /mnt/nfs00" command which basically tells the camera to change directory to your windows share
6. send the "dd if=/dev/mtdblock6 of=mtdblock6_orig" command which will extract mtdblock6 straight to your desktop
7. send "prtHardInfo" command and take note of the devtype
8. Convert the devtype which is in decimal format to hex, i did it on this website Decimal to Hexadecimal Converter
9. Open the mtdblock6 you extracted earlier in the hex editor
10. Change offset x10 to 1 for english
11. Change offset x64 and x65 to your devtype converted earlier. Note that the 2 values are reversed when entering in the hex editor so 9805 would be entered as 05 98
12. Now select the range starting from offset 9 to FC. If done correctly the bottom bar will read "Block 9-FC" with a length of "F4".
13. With the above still selected/highlighted go to "Analysis>Checksum", select "checksum 16" and press OK. You will receive a checksum value e.g. "0D3D" yours will be different. Take note of the value and just like the devtype from earlier reverse the 2 values.
14. Put the first values in offset 4 blocks e.g. "3D" and your final values in the offset 5 e.g. "0D"
15. Thats it save as and save it as "mtdblock6_mod" to your windows share, this way your not overwriting your original and will always have a backup if the worse happens.
16. There is no turning back at this point so make sure your checksums and everyhting are correct. In putty send "cat /mnt/nfs00/mtdblock6_mod > /dev/mtdblock6" which will overwrite the mtdblock6 with the changes just made
17. Now you need to check your mtblock1
18. Again in putty "dd if=/dev/mtdblock1 of=mtdblock1_orig", just like before this will put a mtdblock1 file on your desktop, open the file in the hex editor
19. Check blocks "0x0C and 0x8000C" if they are "0" just change them to "2" and like before save as "mtdblock1_mod".
20. In putty overwrite mtdblock1 with your changes, send the command "cat /mnt/nfs00/mtdblock1_mod > /dev/mtdblock1"
21. Reboot the camera and hold your breath. If you can access the camera it worked and you should now be able to update.

 

[alastairstevenson]

This one only took me 30 minutes, its easy once you know what to do.

Hey, well done!
And many thanks for the detailed step-by-step, looks good - that will help others along this path.

 

[markb]

Hey, well done!
And many thanks for the detailed step-by-step, looks good - that will help others along this path.

Thanks couldnt have done it without you Alistair!

Just checked my other camera its a DS-2CD2132F-IS serial number DS-2CD2132F-IS20150124CCCH500361126 running firmware V5.2.5 build 141201

Am i correct in saying this is an R0 camera? Its only a secondary camera so not crucial to me but still would rather not brick it if i can help it.

UPDATE: I went ahead and did the 2CD2132F. prtHardInfo listed it as R0 and the 2x32 is in the name so i just went with the presumption it was R0. Everything went smooth like the others and its now running 5.4.5.

So thats a total of 3 chinese cameras all updated. Never thought i would see the day. Big thanks to alastairstevension and all the others that made this happen.

 

[gpower07]

after I done MTD hack. then I upgraded from 5.2.5 to 5.3.0. the camera change name to 2CD-Min System. I can't login. I try TFTP the old firmware. but no response. any ideal?

 

[Iemand91]

So, I think I'm going somewhere. Please follow along if I'm doing it right.
My camera is DS-2CD2132F-IWS with firmware V5.2.5 build 141201 and serial number DS-2CD2132F-IWS20150312CCCH*********. (That camera should be able to do this hack to right?)

With the help of this post from markb I've managed to mount my NAS (my laptop didn't work) to the camera and have copied both mtdblock6_orig and mtdblock1_orig from the camera.

prtHardInfo (see Appendix) shows the real devType in decimal as "38942" which is 981E in hexadecimal.
The mtdblock6_orig looks like this:




I changed the language byte at location 10 from "02" to "01" and location 64 from "FF" to "1E" (location 65 unchanged). This results in:



Then I selected the following and did the Checksum-16 (resulted in "0DB6"):




I changed location 04 to "B6" (location 05 unchanged) which resulted in the final file:




Now for the mtdblock1 file. This is it:



Now I have to find locations 0x0C and 0x8000C and see if they are "0", if yes; change them to "2"
I've found 0x0C and changed "00" to "02" (see below), but where can I find location 0x8000C?




If I/we can find location 0x8000C and changed that number to "02" if necessary and save this file.
And if I then move both files back to the camera; and reboot; should this be OK then?

I know I'm bit of a pain in the *ss right now, but I really want to be certain about this.

 

[markb]

So, I think I'm going somewhere. Please follow along if I'm doing it right.
My camera is DS-2CD2132F-IWS with firmware V5.2.5 build 141201 and serial number DS-2CD2132F-IWS20150312CCCH*********. (That camera should be able to do this hack to right?)

I just did a similar camera DS-2CD2132F-IS today and the hack went fine, now running 5.4.5. I think aslong as its got 2x32 in the name its an R0 camera and should be ok to proceed but not 100% on this. You might want to wait for Alastair to verify.

prtHardInfo (see Appendix) shows the real devType in decimal as "38942" which is 981E in hexadecimal.
The mtdblock6_orig looks like this:

View attachment 22399


I changed the language byte at location 10 from "02" to "01" and location 64 from "FF" to "1E" (location 65 unchanged). This results in:

View attachment 22400

Then I selected the following and did the Checksum-16 (resulted in "0DB6"):


View attachment 22402

I changed location 04 to "B6" (location 05 unchanged) which resulted in the final file:

View attachment 22403

Looks good to me so far, i would just double check the checksum value as all my 3 cameras required i change both 04 and 05.

Now for the mtdblock1 file. This is it:

View attachment 22404

Now I have to find locations 0x0C and 0x8000C and see if they are "0", if yes; change them to "2"
I've found 0x0C and changed "00" to "02" (see below), but where can I find location 0x8000C?

View attachment 22405

0x8000C is way down in that file, if you scroll you will see the numbers on the left rising. When you get to 00080000 move your cursor over to the 0C column and you should see the offset at the bottom change to 8000c to verify.

I changed the first number to 2, so changed "00" to "20". I'm not sure if thats correct but it worked on all 3 of my cameras.

If I/we can find location 0x8000C and changed that number to "02" if necessary and save this file.
[/QUOTE]

And if I then move both files back to the camera; and reboot; should this be OK then?

I know I'm bit of a pain in the *ss right now, but I really want to be certain about this.

Should be good to go, looks okay to me but you might want to wait for Alastair to verify.

 

[alastairstevenson]

after I done MTD hack. then I upgraded from 5.2.5 to 5.3.0. the camera change name to 2CD-Min System. I can't login. I try TFTP the old firmware. but no response. any ideal?

If it was only a 5.3.0 version you tried, recover the camera using the '5.3.0 to 5.2.5 downgrader' from the second link here using the tftp updater : Custom Firmware Downgrader 5.3.0 Chinese to 5.2.5 English
Then extract a copy of mtdblock1 and look at the contents of locations 0x0C and 0x8000C
If they are 0, change them to 2 and rewrite mtdblock1 back to the camera.
Double-check the 'enhanced mtd hack' changes you made to mtdblock6, correct if necessary.
Reboot and do the update, don't skip intermediate major versions.

 

[alastairstevenson]

I know I'm bit of a pain in the *ss right now, but I really want to be certain about this

mtdblock6 is looking good, well done!
And as you have determined, mtdblock1 does need the tweak as well, in the location 0x0C and also in 0x8000C which as @markb has usefully advised is way down the file.
After you've done that and written tdblock6 and mtdblock1 back - you're good to go!