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

it Sure is so many happy results
It’s good to see
Your little patient has lots of experiments and secrets to give up
Wish I could see the cricket I have Telstra coming today there line in the street is broken
I fitted my daughters nbn gateway last night and she’s only 4 streets away
 
Hello everybody,

I have a CN version DS-2CD2432F-IW cube camera on 5.2.3 firmware that I’m planning to upgrade to 5.4.5.

Other than the broken IR (still looking for a fix) the camera works fine so no need to unbrick here.

I would really appreciate if somebody could tell me the exact steps required if I only need to upgrade the firmware. I assume I need the enhanced_mtd_hack however I’m a bit lost where I need to “apply the mtd6ro_mod file to the camera during Stage 2 of the fixup script in the brick-fixV2 tool”. How is this done exactly? Thanks and appreciate it
 
Last edited:
I’m a bit lost where I need to “apply the mtd6ro_mod file to the camera during Stage 2 of the fixup script in the brick-fixV2 tool”.
This is done for you by the /dav/fixup.sh script which provides the helping hand for the brick-fix / update process.

When you run the script, it starts in Stage 1, where it extracts mtd6ro_orig from the camera, transfers it to the PC for you to edit, and sets up for Stage 2.
You then make a copy of this, named as mtd6ro_mod, make the changes to the language bytes, devType bytes and checksum bytes, as described and shown in the 'enhanced_mtd_hack.txt attachment and associated screenshot.
Then run the script again where it operates Stage 2. It automatically transfer in to the camera the mtd6ro_mod file, applies it to the camera and sets up for Stage 3.
Then run the script again where it operates Stage 3 and does the final firmware upgrade to convert the camera to full English / upgradeable.
Other than the broken IR (still looking for a fix) the camera works fine so no need to unbrick here.
But it may be as well to do the brick-fixV2 process as the script aims to do all the low-level stuff for you automatically.
All you need to do is edit the mtd6ro_mod file as required by the 'enhanced mtd hack' and pick the firmware file to upgrade to. Using 5.4.5 directly seems to work OK.
 
Alastair, you're a GENIUS man! Not only I updated my CN version DS-2CD2432F-IW cube camera to 5.4.5 but now even the IR works! WOW!
 
  • Like
Reactions: marku2
I'm happy to report that I've successfully upgraded to 5.4.5 another 4 CN version cameras (DS-2CD2032-I and DS-2CD2332-I) from various firmware versions (5.2.0 thru 5.3.0)
Thanks again Alastair for your hard work!

Now for the bad part: I noticed that picture quality got worse using the same settings. No matter what I try the picture is not the same. Anybody else noticed that or it's just me?
 
Last edited:
Updated message for Ala on Feb 8th 2018
THANK YOU THANK YOU THANK YOU for the video Alastairstevenson. This should be a great help for me and others. Forever in your dept.
============================================================

Oh my this sounds like a great thread for my DS-2CD2032-I Hik cams. Going to study the directions and see if I can giver this a go on 5 cameras when I get the chance. Great work!!!

I gathered the Hik Resource files for this firmware change into one file if anyone wants to get everything in one download. Here is the program resource list in the downloadable .zip below
alastairstevenson - Maybe you like to add this to your listing to keep it together? Up to you.
Hik_resource_files.gif
 

Attachments

Last edited:
I've attempted this, and I might be looking at a brick. First try, I was able to upload the brickfix2EN.dav file, and it said System update completed.

Then I rebooted the camera, and... nothing. I'm never able to telnet to it. And attempting to reupload a dav file with the Hik TFP server, I get: Device[192..0.0.64] test tftpserver. Then, nothing.
 
I've attempted this, and I might be looking at a brick.
What camera model have you tried this on?
Then I rebooted the camera, and... nothing. I'm never able to telnet to it.
When doing this, what's the IP address of the PC? Presumably on a wired, not WiFi connection, with both camera and PC connected to a switch as opposed to being connected together.
What do you get if you ping 192.0.0.64
Device[192..0.0.64] test tftpserver.
That does suggest the bootloader is operating.
 
  • Like
Reactions: blueone
What camera model have you tried this on?

When doing this, what's the IP address of the PC? Presumably on a wired, not WiFi connection, with both camera and PC connected to a switch as opposed to being connected together.
What do you get if you ping 192.0.0.64

That does suggest the bootloader is operating.

A DS-2CD2332-I. PC is changed to 192.0.0.128. To start I was on another network, and using PoE. Now, I am powering with a wallwart and connected directly to the PC via a crossover cable.

Generally, I cannot ping the camera, but I did run a ping -t and reconnected the camera. I get one or two responses and then it fails again.
 
connected directly to the PC via a crossover cable.
That can be unreliable when using the tftp updater, due to the interface up/down/up that occurs. Best for both be connected to a switch/router.

However, after the power cycle after brickfix install, the camera reboots straight into min-system mode and stays there to allow the telnet access at the 'ipaddr' value that's set in the bootloader environment variables, usually 192.0.0.64
I get one or two responses and then it fails again.
Oddly enough - that's what occurs on a normal bootup, where the tftp probe is done with the IP=192.0.0.64 then on no response the kernel is booted and the default IP address configured.

As an experiment, maybe try for any ping responses on 192.168.1.64
 
Okay. I put them isolated on a hub, and tried to wireshark it.

4 51.987700 Hangzhou_e1:42:e5 Broadcast ARP 60 Who has 192.0.0.128? Tell 192.0.0.64
5 51.987797 Microsof_9d:17:60 Hangzhou_e1:42:e5 ARP 42 192.0.0.128 is at 58:82:a8:9d:17:60
6 51.988245 192.0.0.64 192.0.0.128 UDP 62 9979 → 9978 Len=20

Then it rolls over to trying some IPv6, then nothing.

If the TFTP server is running, it seems to respond to the UDP request:

4 0.001529 192.0.0.128 192.0.0.64 UDP 62 9978 → 9979 Len=20

Gets no response, tries to call out the camera three times, then gives up.

... Microsof_9d:17:60 Hangzhou_e1:42:e5 ARP 42 Who has 192.0.0.64? Tell 192.0.0.128

And then I never see anything related on the line again.
 
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.




I have one DS-2CD2132F-I camera, it is hacked chinese to english, its firmware is V5.3.0 build 151016,it is working now not brick,, can I follow your steps to upgrade v 5.4 english firmware ,which step should I begin with? thanks
 
Last edited:
can I follow your steps to upgrade v 5.4 english firmware ,which step should I begin with? thanks
Yes, for that camera, this process should work OK.
Follow the step-by-step guide in the attachments of the first post.
It does not matter that the camera is not bricked - but if you can enable SSH (if not on the menus, enable with the Batch Configuration Tool Hangzhou Hikvision Digital Technology Co. Ltd. which is pretty useful to have anyway) and run the command prtHardInfo and look for the devType value.
 
4 0.001529 192.0.0.128 192.0.0.64 UDP 62 9978 → 9979 Len=20
That does look like the tftp updater handshake has been completed as normal.
And suggests there is no firewall blocking the dialogue.
But the camera is not following through on the next responses. Odd.
The brickfixV2 tool has the same min-system contents as the original brickfix tool, which has been extensively used.

If you feel able to spend more time on this, could you try a couple of things?
If you're using wireshark, I'm guessing you may also have nmap

With the PC IP address=192.0.0.128, power cycle the camera, wait a minute and use
nmap 192.0.0.64
Wait just over 10 mins and do the same.

With the PC IP address=192.168.1.128, power cycle the camera, wait a minute and use
nmap 192.168.1.64
Wait just over 10 mins and do the same.

Where are you based?
 
I'm GMT -8, Portland.

Neither of those produce any results. (0 hosts up).

I do have some managed switches here, so maybe later I'll put in a port there and see if I can watch what it does.
 
I'm GMT -8, Portland.
OK, not local to me then.
If you're curious enough and keen enough to pursue this further, the next step would be to hook up to the serial console to see what's going on.
It's easy enough to do once you have the parts - though the connectors can take a while :
PL2303HX-based USB to TTL serial convertor - maybe a couple in case of breakage, they are low cost.
4-pin 1.5mm ZH JST wired connectors, they usually come in 10-packs, from China.
 
OK, not local to me then.
If you're curious enough and keen enough to pursue this further, the next step would be to hook up to the serial console to see what's going on.
It's easy enough to do once you have the parts - though the connectors can take a while :
PL2303HX-based USB to TTL serial convertor - maybe a couple in case of breakage, they are low cost.
4-pin 1.5mm ZH JST wired connectors, they usually come in 10-packs, from China.

I have a cp2102 usb to ttl, and a connector that fits JP1. I'll just need to crimp some connectors on the other end.

Edit: Eh, nm. I had it sitting open and a coworker came over to look at it. Now I'm not getting the IR or network leds to light up when I plug it in. So, I think it was bricked then killed again.
 
Last edited: