R0 / DS-2CD2x32 BrickfixV2 brick recovery and full upgrade tool - enhanced.

[frikkandel]

Need some help, I'm stuck at step 1 and cam isn't connecting anymore...

I wanted to update my DS-2CD2532F-IWS, and updating the brickfixv2EN.dav was successful.
However i was unable to get a connection on 192.0.0.64 with telnet. So i powered on/off after a few minutes.
Still no luck with the telnet connection. And i just tried the tftp updater again, but now i also are not getting a connection there.

So i'm not getting a connection, only positive is that the IR lights of the Hik. are working. ;(

EDIT: Just checking the TFTP server log, and it did update the digicap.dav two times.
Could it be that i forgot to close the tftp server, and did flash again but in the minimode state? Can that brick the Hikvision?

Model DS-2CD2532F-IWS
S/n DS-2CD2532F-IWSxxxxxxxCCCHxxxxxxxxxxxxx
Firmwarev V5.2.5 build 141201
Coderv V5.0 build 140714

[2018-02-25 16:47:41] TFTP server[192.0.0.128] initialized
[2018-02-25 16:48:11] Device[192.0.0.64] test tftpserver
[2018-02-25 16:48:19] Connect client[192.0.0.64] success
[2018-02-25 16:48:19] Start file[D:\Downloads\Hikvision\digicap.dav] transmitting
[2018-02-25 16:48:39] Completed file[D:\Downloads\Hikvision\digicap.dav] transmit
[2018-02-25 16:48:39] Device[192.0.0.64] system update completed!

 

[alastairstevenson]

It would do no harm to flash the brickfixV2 again - but after one or more power cycles you should be able to connect using telnet to 192.0.0.64 from a PC at 192.0.0.128

 

[frikkandel]

@alastairstevenson, Thanks for responding.
I made some progress. I used the SADPTool and the Hik got detected, it has another ip adress. (192.168.1.64)
So needed to adjust the network settings. Now i can ping the Hik, but still no telnet access...
Going to restart it a few times, see if that helps.

The firmware version that SADPTool detects is : V4.08 build 150120. So i suspect the Hik is indeed in minimal mode?
Using the SADPTool i changed the ip address to 192.0.0.64, but seems that after a restart it gets reset back to 192.168.1.64
Just cant make sense why there is no telnet access.

 

[alastairstevenson]

It sounds like the brickfixV2 digicap.dav has not been applied.

 

[frikkandel]

@alastairste You where right.

Found a few issues.
First you need to use a Ethernet switch. Dont use a direct UTP cable to the Hik when using Windows 10.
Seems that the small delay in starting the network (no cable found) is enough to miss the TFTP packet of the Hik. So it just boots normally.

Second i used the brickfixv2EN.dav, and that didn't seem to work for me. Although it told me it was successful. (so dont trust that message)
So i used the brickfixv2CN.dav and that worked. ( i got a few "need to resent" Waring's during the process, but seems they can be ignored.)

Third i could not run the /dav/fixup.sh with the Hikvision TFTP server. Got "*** error transferring mtd6ro_orig via tftp to the PC. ****" errors. and no files where written locally.
Needed to use the jouinin.net tftp server (https://bitbucket.org/phjounin/tftpd64/downloads/tftpd64.460.zip) that worked fine.

Next modifying the HEX file.

EDIT : Could someone check the attached screenshot, and if i did the HEX modifying correctly.?

 

[alastairstevenson]

First you need to use a Ethernet switch. Dont use a direct UTP cable to the Hik when using Windows 10.

Yes indeed. Direct connections can be troublesome when the camera is doing an interface up / down / up as part of the probe process.

Seems that the small delay in starting the network (no cable found) is enough to miss the TFTP packet of the Hik. So it just boots normally.

You are correct. Also - a PoE power source can get in the way due to delays.

( i got a few "need to resent" Waring's during the process, but seems they can be ignored.)

Yes, no big deal that a few packets are suspect and need sent again.

Third i could not run the /dav/fixup.sh with the Hikvision TFTP server. Got "*** error transferring mtd6ro_orig via tftp to the PC. ****" errors. and no files where written locally.
Needed to use the jouinin.net tftp server (https://bitbucket.org/phjounin/tftpd64/downloads/tftpd64.460.zip) that worked fine.

Yes, that's in the step-by-step-guide. The Hikvision tftp updater tool isn't a full tftp server - it will download files, but not upload files.
Some people have found that the 64-bit Jounin tftpd doesn't work and use the 32-bit version.

Next modifying the HEX file.

Well, you've got lang=2 (CN) and the masqueraded FF98 devType for 2532
devType is 1498 for DS-2CD2532F-IS
Not so sure about whether the -IWS is different though, it's not explicitly in the devType list.
I don't suppose you have a prtHardInfo output?
Or maybe another forum member has one?

 

[alastairstevenson]

EDIT : Could someone check the attached screenshot, and if i did the HEX modifying correctly.?

If you got the 1498 devType code from your prtHardInfo command - that looks OK to me.

 

[frikkandel]

@alastairstevenson Got it up and running! Thanks for making this possible.

Flashed the "5.4.5_170123" directly without problem.
The GUI shows the "Wi-Fi" tab, and shows the wireless networks, so i assume its working.
DevType 1498 is probably ok for all DS-2CD2532F variants.

Is there a way to verify if all is patched ok now? Or just wait till the next firmware update and have the fingers crossed?

 

[alastairstevenson]

Got it up and running!

Excellent!

The GUI shows the "Wi-Fi" tab, and shows the wireless networks, so i assume its working.
DevType 1498 is probably ok for all DS-2CD2532F variants.

That's good to know, thanks for the confirmation.

Is there a way to verify if all is patched ok now? Or just wait till the next firmware update and have the fingers crossed?

My guess is that the R0 5.4.5 firmware will be the last for that series - unless Hikvision decide to create a version to undo the benefits of the 'enhanced mtd hack'.

 

[alyrian]

Hi,
Been trying to apply the fix as it seems neater having all in one place as you did, thanks for that
I tried other ways for the past year but gave up as TFTP doesn't connect, I thought I was doing something wrong, now with your fix easier to follow, I am trying again
I tried previous response with people facing connection issues in this thread but still nothing happens, here is my config:
DS-2CD2432F camera with CCCH, bought on eBay and had English format initially, tried to update it last year and it's now in Chinese, originally it had V5.1.6_140612
on SADP, it shows as 192.0.0.64 with V5.3.0 build 150513
It's on Ethernet switch with PC configured to 192.0.0.128, I can ping 192.0.0.64 from PC no problem, SADP sees the camera too no problem
I disabled all Firewalls
When I try tftpserv.exe from Custom downgrader, it stays at Initialised, nothing else ever happens, tried power cycling few times but still the same
in Browser I get Chinese page with 192.0.0.64
in Putty Telnet or SSH, no connection possible
Any pointers would be great, I have bought cable to do serial connection but havent used it or might need guidance to do so

 

[alastairstevenson]

When I try tftpserv.exe from Custom downgrader, it stays at Initialised, nothing else ever happens, tried power cycling few times but still the same
in Browser I get Chinese page with 192.0.0.64

Given access to the web GUI, even in Chinese, you should be able to make a start by using the Maintenance menu to do an update with the brickfixv2CN.dav firmware.
After this is applied, and the camera is rebooted, telnet access to 192.0.0.64 should work for running the /dav/fixup.sh script.

 

[alyrian]

Thanks for the reply and guidance
I tried it but it would not update with firmware brickfixv2CN or brickfix2EN, both saying Language Mismatch (from google translate), I tried the firmware from Custom Downgrader, CN did not update but 'EN downngrade_digicap.dav' did, camera rebooted and I was back to 5.2.5 build 141201
Telnet still did not work, web GUI was still in Chinese with login reset to admin/12345, in Systems: Telnet option doesn't exist
Tried to update in web GUI to a different firmware brickfixv..., both didnt work, tried again Custom Downgrader on top which it tried but stopped halfway through, now camera looks bricked, 192.0.0.64 ping doesnt work, nothing in SADP, no web GUI, when i reboot the camera before i could after a while the shutter but not anymore. After about 5min in SADP I can see DS-2CD-Min-System v4.0.8 build 140610 but Telnet is still not working so I cant upload a firmware onto it.

 

[alastairstevenson]

After about 5min in SADP I can see DS-2CD-Min-System v4.0.8 build 140610 but Telnet is still not working so I cant upload a firmware onto it.

It's normal that after an incompatible firmware install, with the davinci main app not running, the hardware watchdog will trigger a reboot into min-system (firmware 4.0.8) mode in 10 mins.
And the newer min-system environment does not have telnet access.

TFTP doesn't connect

This is usually OK, and will allow recovery of the camera.
Requirements are - camera and PC both wired to a switch / router, PC IP address 192.0.0.128, camera powered by external 12v DC supply.
PC firewall inbound 'allow rule' for tftpserve.exe - or Windows firewall disabled.
Firmware file named digicap.dav in the same folder as tftpserve.exe

Do you want to try the tftp updater again, see what happens?
What does the tftp updater window show?
Also try the PC with IP address 192.168.1.128

 

[xomiki]

Thanks to these tools and guide I successfully updated a grey market DS-2CD2332-I from 5.2.5 to 5.4.5.

To help others here are the steps I took and the problems that were encountered. The solutions echo some of the tips above;

• My camera was already working fine, it just had old exploitable firmware.
• Reconfigured the camera to use an IP of 192.0.0.64 prior to starting process.
• Connected to the camera using a PoE inline power device and a straight Ethernet cable. (this causes problems - keep reading)
• I could not get it to retrieve the update by hard restarting the camera by unplugging the cable. It did work when I went into the web GUI and used the 'reboot' functionality. I later learned that the PC detecting the plugged in/out cable and the detection of the cross over link incurred delays that were causing the problem.
• As per the guide, I tried brickfix2EN first, which finished with 'Completed ... transmit' and no message indicating successful update.
• Camera appeared 'bricked' as it would not respond to anything.
• After 5 minutes of uptime the watchdog kicked in (apparently) and I could ping the camera at 192.168.1.64 and see it in SADP (after switching my PC to 192.168.1.128)
• Could not get the camera to update itself on either the 192.0.0.128 or 192.168.1.128 address.
• Changed to using a PoE switch, and finally could send the brickfix2CN update using the 192.0.0.128 -> 192.0.0.64 pairing. Note that I did not use external power so unplugged the camera's ethernet cable to get it to reboot each time.
• The camera updated successfully and I was able to telnet (port 23) to the camera at 192.0.0.64.
• I used the 64 bit version of tftpd64. This worked fine, although I needed to change the 'server interface' in the app to 192.0.0.128.
• After completing the steps for update I was able to plug the camera back into the normal network and access it at 192.168.1.64. Where I immediately disabled UPnP.

Takeaways, and perhaps some additions to the guide:

• Use a switch, not an inline power device. This is more important than you may think. If your network setup doesn't allow you to 'auto update' via tftpserv your camera will effectively be bricked until you can. Depending on your ethernet card, switch or cables you may require external power.
• Using the wrong 'brickfix2XX' will actually 'brick' the camera. However you can 'unbrick' it by using the right one and tftpserv.
• If your camera is not already 'bricked' you can presumably do the first update to the 'brickfix2XX' via the GUI, but take careful note of the two points above. You may be left with a device you can't fix.
  
• To avoid that pain - perhaps use the brickfix2CN file first if you are upgrading a 'grey market' camera? Maybe there is a method to figure out which one to use. That would be a helpful addition to the guide.

Thanks for the great work to get these dodgy devices up to date. Cheers.

 

[alastairstevenson]

Thanks to these tools and guide I successfully updated a grey market DS-2CD2332-I from 5.2.5 to 5.4.5.

Well done!
And many thanks for sharing your experience, and the 'Takeaways', this will help others.

It's an interesting point about which to choose first between the EN and CN versions of the brickfixv2 firmware.
One of them will be rejected with a 'language mismatch', which would only be seen via the serial console connection.
Which one it is depends on what value for language is in mtdblock6
From what I've seen, most 'grey market' cameras have language=2 (CN) and run 'hacked to English' firmware, so the CN version of brickfixv2 is needed.
But some grey market cameras I've seen have already had the classic 'mtd hack' with language=1
If the camera is still operational - the prtHardInfo command (useful for confirming the devType value) should give a valid language indication.

 

[Denoid]

The original 'brick-fix tool' and 'enhanced mtd hack' has proven pretty useful for those with R0 cameras that had been bricked by doing a firmware update.
It's been even more useful to deal with the fallout from the 'Hikvision backdoor' disclosure where so many people are finding their cameras are being messed with from the internet, mischievously or maliciously, and need to update to safer firmware.
However - the rather techy original method to make the changes, and probably my not-very-clear instructions have been a challenge for some people.
* And I only just noticed this - my original .txt attachments were in Linux format, not Windows format, making them hard to read without proper line breaks. And no-one let me know! Dohh! *

So here is 'Brick-fix tool V2' aimed at making the process less complex, a bit automated and easier to use, with the following changes:
- After Brick-fix toolV2 has been installed using the Hikvision tftp updater, following the power cycle to activate and drop the payload, the camera will boot directly into 'min-system' mode with telnet and tftp access and a 'fixup' script ready and primed for use.
- No web GUI access or Windows shares are needed to move files in and out of the camera.
- The fixup script handles all the basics of extracting the original mtdblock6, importing and applying the user-modified mtdblock6 that has had the 'enhanced mtd hack', and initiating a firmware update.
- The Brick-fix toolV2 automatically writes a valid template into mtdblock1 that stops cameras that originally had firmware 5.2.0 or 5.2.8 from otherwise going into a bricked state when newer firmware is applied.
Attached to this post are the resources required to convert your R0 / DS-2CD2x32 cameras into full English upgradeable devices.
- The brick-fix tool V2 in both EN and CN header language versions.
- A required resource list and step-by-step guide to the fixup script.
- A description of how to do the 'enhanced mtd hack' with screenshot with a list of devType codes for those cameras that have the masqueraded values.
- A sample transcript of the fixup script going through all 3 stages - extract mtdblocks, import modded mtdblock6, apply firmware update.

*edit* 15Dec17 By popular request, a video worked example using a DS-2CD3332-I camera donated by a generous forum member.


*edit* 28Jan18 devType codes updated - thanks @hikcamuser
And check out this useful post from @Bradmph with attached resources (but use tftp32 not tftp64) : R0 / DS-2CD2x32 BrickfixV2 brick recovery and full upgrade tool - enhanced.

 

[pjetson]

Attached is a modded mtd6 from another 2032F-I that should work OK.
This will give a different serial number and MAC address - but that should not cause any problems.

I have spent a very frustrating time trying to upgrade my 2032-I, with everything looking like it worked up until the very end - the camera wouldn't come up. I tried the upgrade many times, checking each step carefully, but to no avail.

Eventually, comparing my mtd6ro_ file to the 2032F-I one that you posted, I realised that my mtd6ro_ file seemed to be corrupt - no model name, and a bunch of FF bytes where I'm guessing there should be code.

So, I used your 2032F-I mtd6ro_file, changed the devType bytes to 05 98, changed the model name string, and tried again.

Partial success this time - I got the camera back, but the Configuration tab is blank. Could this be because the mtd6ro_ file is not for my camera?

Alastair, do you have a mtd6ro_mod file for a 2032-I that you could post?

Regards, Peter

 

[alastairstevenson]

mtd6ro_ file seemed to be corrupt - no model name, and a bunch of FF bytes where I'm guessing there should be code.

Odd, that's the second one recently with a missing model string.

Alastair, do you have a mtd6ro_mod file for a 2032-I that you could post?

Yes, no problem, see attached.
Good luck!

 

[Bradmph]

When doing the updates to 5ea. Hik DS-2CDD2032-1 cameras connected to a POE and switch, and running into a second dedicated PC which is connected to a cable internet modem, Do I need to remove all the cameras that are connected to the POE & Switch except for the one I want to update.
I have tried doing the update without cabling changes, but the tftp server program only gets to (initialized) and then hangs there with no further progress. I have noticed that you do make a change in the communication setup to the PUBLIC choice on your video, which I mistakenly had set to PRIVATE during the attempted updating. I haven't yet tried switching it from PRIVATE to PUBLIC to run the update a second time at this time because I wanted to be sure it was safe to run updating firmware with all cameras still running on my POE & Switch during the updating process.
Should I also place the camera being updated to it's default login of admin/12345 or will it ask to access the camera with my password login during the firmware update.

thanks

 

[alastairstevenson]

When doing the updates to 5ea. Hik DS-2CDD2032-1 cameras connected to a POE and switch

Some members have found that the Hikvision tftp updater may not work with the camera powered over PoE as the 'probe' packet may be missed due to power-on timing.

Do I need to remove all the cameras that are connected to the POE & Switch except for the one I want to update.

Only if there is a chance that they may reboot while the tftp updater is running, and so get an unintended update. Very unlikely, but possible.

I have tried doing the update without cabling changes, but the tftp server program only gets to (initialized) and then hangs there with no further progress.

That might be the PoE switch delay problem mentioned above.
Do you have any ability to power the cameras with a 12V power supply?

Should I also place the camera being updated to it's default login of admin/12345 or will it ask to access the camera with my password login during the firmware update.

No requirement to do that - the Hikvision tftp updater does not require any logon info to do an update.