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

alastairstevenson

Staff member
Oct 28, 2014
16,064
6,885
Scotland
*edit* 01Dec17 Text attachments now in Windows form instead of Linux form so they format properly.
*edit* 21Dec17 To make the process of unbricking and upgrading much easier to use, this has been superseded by the brickfixV2 method here : R0 / DS-2CD2x32 BrickfixV2 brick recovery and full upgrade tool - enhanced.


I was not going to post these details in public, to reduce the chance of Hikvision blocking them in future firmware - though no such inhibitions in private, quite busy on the topic!
But then this happened : Hikvision no longer selling to the end user
See also this link and the attached PDF in this post.
HikVision End of Supply 4-8-17
It's just another example of how Hikvision continues to treat their customers with contempt in their misguided and ultimately doomed 'Prop up the Authorised Resellers inflated margins' tactics.
Shame on you, Hikvision, what an awful way to do business!

Some other, for a $multi-billion business, rather un-business-like activities:
Putting Blogger Anti-Hikvision Rhetoric in Perspective
Blogger’s Cyberbullying Mission Tiresome, Destined to Fail
Hikvision Attacks IPVM
Hikvision Blogs About IPVM: "Putting Blogger Anti-Hikvision Rhetoric In Perspective"

I'm sure their main rival Dahua will be quite pleased to fill the gap that Hikvision seem to be vacating.
If the way that the postings volume in ipcamtalk.com has shifted to the now dominant Dahua away from Hikvision over the past year is an indication, maybe the customer sentiment is already moving against Hikvision.


So it's time to provide a roundup of a little help to Hikvision's stranded and unsupported R0 camera customers.

You bought your DS-2CD2x32-I camera at low cost off eBay or Aliexpress and upgraded the firmware to the published 5.3.0 version.
The web GUI menus changed to Chinese. Your Hikvision NVR now rejects the camera with a 'Language mismatch' error. Your camera no longer responds - it's bricked.
You've fallen into a deliberate Hikvision trap aimed at on-line purchasers of Chinese market cameras running seller-installed 'Hacked to English' firmware.
Go to the @whoslooking Custom Firmware Downgrader 5.3.0 Chinese to 5.2.5 English and get back to English menus.

To fix Chinese day-of-the-week or 'Language mismatch' errors connecting your 5.2.5 firmware camera to your NVR, go to the classic mtd hack from @whoslooking
Hikvision 5.2.5 & 5.2.8 Full English (INC DAYS OF WEEK) mtd Hack

If you saw the Hikvision security advice to update your camera firmware following the high-severity security vulnerability / backdoor found and reported by forum member @montecrypto and it bricked - you have fallen into the Hikvision deliberate Catch-22 trap.
Backdoor found in Hikvision cameras
Hangzhou Hikvision Digital Technology Co. Ltd.
(I wonder if the ISC-CERT referenced here is deliberately mistyped?)
Hangzhou Hikvision Digital Technology Co. Ltd.
A perfect 10 out of 10! And 8.8 for putting passwords in plain text in the configuration file. Dohh..
Hikvision Cameras | ICS-CERT
NVD - CVE-2017-7923
DS-2CD2432F-IW 3MP firmware issue after trying to upgrade to 5.4
These are very good reasons to update the camera firmware. And shame on you Hikvision for putting in measures that block this.

Now your camera won't run the updated/fixed firmware / won't downgrade as a downgrade block has been implemented. It's bricked!
Fortunately - as there is a lot of this around - there is a fix for the problem, the 'Brickfix tool'.
Tool and instructions in the attached file Brick_fix_tool.txt

Have you found that following email provider security improvements, your camera with older firmware will no longer send gmail or GMX notifications?
You know there is a fix for this, and bug-fixes and various serious security fixes in updated firmware, but you can't apply it as the Hikvision firmware has code that will stop it running on cameras bought at low cost on-line or from other than authorised resellers.
You could try the attached 'enhanced_mtd_hack.txt' guide which has been pretty successful in allowing the 'non-upgradable' cameras to be fully upgraded and making them safer and better to use. Which is something Hikvision should be encouraging, not blocking. In my view.
 

Attachments

Last edited:
Thank you Alister that was a good read and thank you for all the help you have freely given I really appreciate all you efforts I'm just waiting for my USB connector then time to play
 
  • Like
Reactions: alastairstevenson
Thank you Alister that was a good read and thank you for all the help you have freely given I really appreciate all you efforts I'm just waiting for my USB connector then time to play
And I'm fixing up a so called professional installer selling Chinese cameras go figure that out hikvision
 
A fantastic release Alistair, This one needs to be made a sticky.

cracking job!
 
Many thanks!

As someone who spent 30+ years consulting with technology companies, I can assure you Hikvision's approach is EXACTLY the wrong way to do what they are trying to do. Rather than introduce a new end-user subbrand (Hi-Watch) they should have introduced a new higher-end brand (e.g., "Hik-Plus") that was targeted at trade installers only.

Well, the good news is this will provide a great business school case for MBA studends at Harvard, INSEAD, AGSM, etc. The students will all learn about a company named Hikvision that took an enviable business position into bankruptcy though mismanagement.
 
This is great job and works! But there is one thing to note from another post by@alastairstevenson, "depending on what original firmware was on the camera (5.2.8 mostly needs this) check the bytes at 0x0C and 0x8000C in mtdblock1 and if they are 0 change them to 2." I can attest that without this my orig 5.2.8 2332 cam would brick when updating from 5.2.5 to 5.3.0. With this change, it all went smoothly.
 
  • Like
Reactions: alastairstevenson
a question about checksum
Before I change the original mtdblock6 hav it checksum 16 FD24

I change
0x10 to 0x01 for EN
0x64 to 0x07
0x65 to 0x98 for devType = 38919
Then is the Checksum FC2B

Is it true that I must have the checksume FD24 again after the changes?
 
a question about checksum
Before I change the original mtdblock6 hav it checksum 16 FD24

I change
0x10 to 0x01 for EN
0x64 to 0x07
0x65 to 0x98 for devType = 38919
Then is the Checksum FC2B

Is it true that I must have the checksume FD24 again after the changes?

No. Now just change the Checksum from FD24 to FC2B.
 
This is great job and works! But there is one thing to note from another post by@alastairstevenson, "depending on what original firmware was on the camera (5.2.8 mostly needs this) check the bytes at 0x0C and 0x8000C in mtdblock1 and if they are 0 change them to 2." I can attest that without this my orig 5.2.8 2332 cam would brick when updating from 5.2.5 to 5.3.0. With this change, it all went smoothly.
I keep meaning to write this up.
It's the 'icing on the cake' for the 'enhanced mtd hack', covering those remaining cameras that the label shows originally had 5.2.8 firmware installed.
Mtdblock1 holds a couple of signature blocks with the results of the previous firmware update, and its version number.
On some of the 5.2.8 cameras part of that data is missing.
 
I thought you always had to come to exactly the checksum you had before the change. I know the bios adjust for wlan module with hp.
 
I thought you always had to come to exactly the checksum you had before the change.
No, the checksum must reflect the current data, it's the 'Checksum-16' value of the 0xF4 bytes from location 0x09 downwards.
I just wondered if you'd worked it out correctly as it seemed larger than those I've seen.

*edit*
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.
 
Sorry, I have to translate this into German everything, so some things is not to be understood correctly.
I did not quite understand this with the Checksum.
I put the cursor before offset 09 and let me display the checksum?
I do not understand exactly where the value of the 0xF4 bytes ist.
Start by 0x09 downwards, I understand this, how far?
@alastairstevenson thank you for your patience
 

Attachments

  • mtd6_org.JPG
    mtd6_org.JPG
    135.5 KB · Views: 144
  • mtd6_change.JPG
    mtd6_change.JPG
    159.3 KB · Views: 130
In a other Tread I have found
" Select 0xF4 (244) bytes from ...."
in the Picture are 0xF4 Bytes?
Then is the calculated Checksum 0D01.
If that is correct, then why is in the original file by 0x04 and 0x05 E4 0B.
Sorry, I just do not understand it
 

Attachments

  • 0xF4.JPG
    0xF4.JPG
    134.7 KB · Views: 93
so, now I made the changes and from 0x09 to 0xFC, that must be 244. Then calculate the checksum. Does it look better now?
What happens if the checksum is wrong and I copy it back to the cam?

Copy to the cam bit the command (cp /mnt/nfs00/mtdblock6 /dev), then overwrites the original file?
Do I then still file right?
 

Attachments

  • mtd6_checksumm.JPG
    mtd6_checksumm.JPG
    160.5 KB · Views: 116