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

Well done for getting those R0 series updated.

On the R1 pinholes - in afraid that's not a model I've had any experience of, so I'm not sure how you'd deal with those.
Are they China region devices?

As far as I know it's a China region device, delivered with English 5.3.4 firmware (but not upgradeable).

I don't know if R1's use the same upgrade methode internally, if so I could try the R0 upgrade process...

Tried this today with my chinese DS-2CD2132F-IS that already had an English firmware on (as shipped). Previously running 5.2.5

Initially attempted manually updating mtdblock6, device rebooted OK after the update. When proceeding to apply frmware "IPC_R0_EN_STD_5.4.5_170123.zip" the device wouldn't boot.
Used the hikvision tftp server with brickfixv2EN.dav , rebooted and initially no network activity (no arp entry seen for .64). Waited 10mins for the timer and does now appear in SADP. Can telnet in but nothing in the /dav/ directory.

If I then use tftp to download "digicap.dav" (brickfixv2EN.dav or CN) the download completes, the upgrade command seems to complete OK but rebooting seems to put me back at square one (waiting 10mins for the timer).

If I flash 5.2.5 it goes on fine and boots back to English.

Any advise appreciated.

davehope said:

Initially attempted manually updating mtdblock6, device rebooted OK after the update.

Click to expand...

If you feel you can post a zipped copy of the original and modified version here I'll check it out for you.

davehope said:

Used the hikvision tftp server with brickfixv2EN.dav , rebooted and initially no network activity (no arp entry seen for .64). Waited 10mins for the timer and does now appear in SADP. Can telnet in but nothing in the /dav/ directory.

Click to expand...

This suggests that the brickfixv2 tool has not activated.
After installation, when the camera is power cycled, the brickfixv2 firmware boots up, drops the payload, de-activates itself, initialises stage1 of the /dav/fixup.sh script and reboots directly into min-system mode with telnet available and the /dav/fixup.sh script ready to run. This normally takes maybe 30 seconds. Only if the reboot into min-system mode isn't initiated does the watchdog then do this after a 10 minute timeout.

Just to double-check the steps required to get to the point where the mtd6ro_orig is presented for modification:

A copy of the brickfixv2EN.dav renamed as digicap.dav in the same folder as the tftpserve.exe tftp updater.
With the PC IP address set as 192.0.0.128 start tftpserve.exe and power on the camera.
If the result is 'system update completed' power off the camera, shut down the tftp updater, wait a few seconds and power back on.
If the result is only 'file transmitted' repeat using brickfixv2CN.dav
SADP should show firmware version 4.0.8 and telnet access using admin/12345 should be available in about 30 seconds.
The /dav/fixup.sh script should be available and ready for use.

Thanks for coming back to me so quickly, steps look inline with what I tried.

I've sent you a PM with the steps taken to modify mtdblock6 and copies of the original and modified file.

Thanks alastairstevenson for putting this together and sharing it. Great Work! I was able to use it on 4 of my 5 DS-2CD2532F-IWS running 5.3.0 cameras to get them to 5.4.5 with no issue.

The 5th camera has proven to be tricky though. It was in the middle of the bunch I so I am sure I have the process correct and the files being used are not corrupt.

The camera took the brickfixv2CH fine but unlike the others, it would not boot into Telnet mode or return a ping after. It has a serial number only a few digits off from the other cameras since they were all bought together so I would expect it to be the same CH grey market version, but I then tried the brickfixv2EN to see what happens. Still no telnet or ping. I tried both multiple times and TFTP was always successful and never did a retry on any cameras, also tried two different computers.

I have some other firmware files from a couple years ago when I learned firmware updates can brick these cameras so I don't remember much about the firmware versions, but back then I was able to get the cameras to 5.3.0. The cameras are up high on a metal building, so I cant easily access them to look at the version sticker either

Then I used TFTP to load on each other firmware I have to see if it would boot into a GUI or return a ping other than the first few when it looks for a TFTP server. I loaded 5.1.6, 5.2.0, 5.2.5, 5.3.0, 5.3.0 downgrader, and 5.3.3. I had a subnet mask of 255.0.0.0, so I could do a -t ping on 192.0.0.64 and 192.168.1.64. Of all the firmware, only the downgrader gave a response to the ping and booted to the GUI and showed up as 5.2.5. All others except the 5.3.3 would just wait not return a ping but after 10 minutes showed up in SADP like normal for a firmware issue. The thing about 5.3.3 is that every 45sec or so it would return a few pings with a TTL-255 like it was rebooting. But it was like a soft reboot because the link light on my switch did not cycle like it does when rebooting.

Another thing I observed is that all my cameras that took correctly would pull in the brickfixv2CH package and then after I power cycled them they would reboot(Ethernet link cycled) 3 times before ending up in the telnet mode. This problematic camera only reboots twice, like it gets stuck on the 2nd part. I tried the brickfix2 firmware multiple times even after getting the camera to load using the 5.3.0 downgrader. Tried loading it through the GUI of the downgrader firmware, and through IVMS, but always the same result of no ping, telnet, GUI, or anything after loading either brickfixv2. The downgrader GUI actually would just get stuck each time trying to load firmware, not sure if it was a browser compatibility issue or what, but didn't think much of it.

I don't have a good way to make a direct serial connection to the camera at this time, but I have enabled the telnet and SSH when running the 5.3.0 downgrader and connected to it that way. Can I run some commands in the telnet or SSH console to investigate or resolve the issue?

It sounds like you've done a lot of well-described trouble-shooting to try to figure this out.
No other devices using 192.0.0.64 that could clash with gaining telnet access to the problem camera?
I wonder if there could be a duplicate MAC address. But that would have been a problem before any update attempt.

dominatorstang said:

Can I run some commands in the telnet or SSH console to investigate or resolve the issue?

Click to expand...

A transcript of the prtHardInfo command, and a copy of mtdblock6, original and modded, might help figure this out.
Presumably you didn't change mtdblock5? Should not be necessary.
It's unlikely to be mtdblock1, which the brickfixv2 tool should handle automatically, previously there was a need on a small proportion of cameras to fix up manually. But there would be no harm in checking it.

alastairstevenson said:

It sounds like you've done a lot of well-described trouble-shooting to try to figure this out.
No other devices using 192.0.0.64 that could clash with gaining telnet access to the problem camera?
I wonder if there could be a duplicate MAC address. But that would have been a problem before any update attempt.

Click to expand...

I am using a spare POE switch with just the camera and PC.

alastairstevenson said:

A transcript of the prtHardInfo command, and a copy of mtdblock6, original and modded, might help figure this out.
Presumably you didn't change mtdblock5? Should not be necessary.
It's unlikely to be mtdblock1, which the brickfixv2 tool should handle automatically, previously there was a need on a small proportion of cameras to fix up manually. But there would be no harm in checking it.

Click to expand...

Doing some research during the issue I did run across some of what you are talking about here. This was my first reading on the mtd hack, so I know very little currently about mtdblock5 and 1. Remember, I never made it past using TFTP for the camera to pull in the firmware. I didn't get to run the script at the command prompt to pull the files and modify them.

With the camera doing the 2 reboots and not making it to the 3rd then it tells me it gets stuck on the script that brickfixv2 has it running. Granted, without the serial interface we dont know what part it is stick on.


# prtHardInfo
Start at 2018-05-21 20:51:36
Serial NO DS-2CD2532F-IWS20150530CCCH522174924
V5.2.5 build 141201
hardwareVersion = 0x0
hardWareExtVersion = 0x0
encodeChans = 1
decodeChans = 1
alarmInNums = 1
alarmOutNums = 1
ataCtrlNums = 0
flashChipNums = 0
ramSize = 0x4000000
networksNums = 1
language = 1
devType = 38932
net reboot count = 0
SD status = 1 (1:noraml;0:none)
Path: .
Working Copy Root Path: /data1/data_liwenwei/work/frontend_software_platform_5.2.7_R0
URL: https://192.0.0.140/Camera/Platform/Branches/branches_frontend_software_platform/frontend_software_platform_5.2.7_R0
Repository Root: https://192.0.0.140/Camera
Repository UUID: df2d70c3-7593-7941-af1e-571b313c0946
Revision: 103727
Node Kind: directory
Schedule: normal
Last Changed Author: liwenwei
Last Changed Rev: 103727
Last Changed Date: 2014-12-01 20:51:32 +0800 (Mon, 01 Dec 2014)

dominatorstang said:

I never made it past using TFTP for the camera to pull in the firmware. I didn't get to run the script at the command prompt to pull the files and modify them.

Click to expand...

OK, so for reasons unknown the brickfixv2 firmware, whilst apparently installing OK, is not executing and dropping its payload.
But you can install the 'downgrader' OK and get to the web GUI.
Your devType for this camera=9814

So a couple of suggestions:
Keep SADP running for convenience, to check the status using the refresh button. When the min-system is running, the firmware version will show as 4.0.8
See if the brickfixv2 (probably the EN version, but try both) can be installed via the web GUI when you are running the 'downgrader'.
If that appears to work, power cycle the camera and see if min-system comes up in a few 10s of seconds.
If so - telnet to 192.0.0.64 should work and /dav/fixup.sh can be used.

An alternative to trying to get brickfixv2 to work would be to manually do the 'enhanced mtd hack'.
For convenience, a NetHDD destination is easiest.
If you don't have a handy NAS, a Windows SMB/CIFS share is easy enough to provide.
See the attachment for instructions on how to create the share and extract mtdblock6.
Just in case it's one of the anomalous ones, extract mtdblock1 also.
Then see the attachment for the 'enhanced mtd hack'.
Apply the modified mtdblock6 and reboot.
Then try web GUI updating, through the main versions, 5.2.5 --> 5.3.0 --> 5.4.0 --> 5.4.5

Good luck!

Thanks all,

Two DS-CD2332-I cams with 5.2.0 successfully updated to 5.4.5.

I did mess up on the second camera and applied the same modified mtdblock6 as I'd applied to the first camera.
The result being that both cameras ended up with the same MAC address and so only one could connect to the network.
Quickly found the location of the MAC code in the mtdblock6, changed the MAC, recalculated the checksum and successfully applied the mtdblock6.

All good now

yorkiebar said:

Quickly found the location of the MAC code in the mtdblock6, changed the MAC, recalculated the checksum and successfully applied the mtdblock6.

Click to expand...

Hey, well done!

I haven't had a Yorkie Bar for a few years - it used to be one of my weekly treats to myself for being a good boy, loved them.
Until I managed to steer on to a healthier lifestyle.

alastairstevenson said:

I haven't had a Yorkie Bar for a few years - it used to be one of my weekly treats to myself for being a good boy, loved them.
Until I managed to steer on to a healthier lifestyle.

Click to expand...

I'm quite partial to the raisin and biscuit variety, although the good ole classic plain Yorkie is still a winner.

Keep on truckin'

alastairstevenson said:

So a couple of suggestions:
Keep SADP running for convenience, to check the status using the refresh button. When the min-system is running, the firmware version will show as 4.0.8
See if the brickfixv2 (probably the EN version, but try both) can be installed via the web GUI when you are running the 'downgrader'.
If that appears to work, power cycle the camera and see if min-system comes up in a few 10s of seconds.
If so - telnet to 192.0.0.64 should work and /dav/fixup.sh can be used.

Click to expand...

Thanks for the advice alastairstevenson. Any firmware I tried to install from the web GUI using IE, IE compatibility mode, or chrome, would gray out the window a bit and stay at 0% spinning with no data moving across the network. after a few minutes of this I would then try to load the camera web interface in a new tab and the login page would only partially load and the browser would have an error that had to okay. A reboot would get it back to the login page. it was transferring the firmware using the IVMS and TFTP software. but then it never fully boots to access it. I keep SADP and a -t ping going.

alastairstevenson said:

An alternative to trying to get brickfixv2 to work would be to manually do the 'enhanced mtd hack'.
For convenience, a NetHDD destination is easiest.
If you don't have a handy NAS, a Windows SMB/CIFS share is easy enough to provide.
See the attachment for instructions on how to create the share and extract mtdblock6.
Just in case it's one of the anomalous ones, extract mtdblock1 also.
Then see the attachment for the 'enhanced mtd hack'.
Apply the modified mtdblock6 and reboot.
Then try web GUI updating, through the main versions, 5.2.5 --> 5.3.0 --> 5.4.0 --> 5.4.5

Click to expand...

I believe this will be my next learning. Thanks for the info, I will give it a try soon and report back with my findings.

I was able to pull the mtdblock1 and 6 files using your instructions and have attached them below. I was then able to boot back into the GUI but needed to move the camera back to a different switch. I was never able to boot into the GUI after the 2nd boot. Maybe an error in my setup, but I didn't find one.

I then used TFTP to put on 5.3.0 which took fine and I used the GUI to load 5.4.5. I know I skipped 5.4.0, I just didn't have a copy downloaded and my other cameras made the jump fine so I took the risk.

Thanks again for you help!

This reply would have gone out yesterday but for a broadband fault. I'm away from home just now.

dominatorstang said:

I used the GUI to load 5.4.5. I know I skipped 5.4.0, I just didn't have a copy downloaded and my other cameras made the jump fine so I took the risk.

Click to expand...

I'm slightly confused by this - does this mean you've made the changes and have 5.4.5 installed OK? Or is it back to 5.2.5 ?

Anyway - here is the original reply, assuming the camera is starting from the 5.2.5 'downgrader' :

Your prtHardInfo shows 5.2.5 - that will be OK - the 5.2.7 referenced is just the development folder structure.

Attached is the modified mtdblock6


Your mtdblock1 is OK, no changes needed.
Remember to update through the major versions. Web GUI should work OK.

Good luck!

Sorry for the confusion. Yes, I did make the changes and was then able to update to 5.4.5.
I am still puzzled by why it never would boot using the firmware package you put together even though my other 4 cameras booted with it fine and all cameras had close to the same serial numbers and were running the same firmware.

Well, all's well that ends well.
You did ok.
Yes it's odd that the brickfixV2 didn't execute on that camera. It's been a pretty good and fairly easy solution to getting Chinese R0 cameras fully updated.

I used your tool and upgraded my cam to the latest! It works in english and is perfect!

One questions, how can i change the time to 12 hour format? I didn't see an option in the time settings. Thanks

hasteveha said:

I used your tool and upgraded my cam to the latest! It works in english and is perfect!

Click to expand...

Excellent! Well done.

hasteveha said:

One questions, how can i change the time to 12 hour format?

Click to expand...

Usually under Configuration tab | Image | Time Format dropdown (far right)

I need help! I have six Hik cameras and successfully updated 5 of them. Yay!
But, the first one I attempted (when I didn't know what I was doing) should of worked, but I must of done something to super brick it. It is a DS-2CD2532F mini dome camera (I have 3 of these and 2 I did successfully)

SADP cannot see it, my PC set a 192.0.0.128 cannot ping it, IP Scanner software can see it at 192.0.0.64. The FTPserve.exe program will display Device [192.0.0.64] test tftpserver everytime I unplug and plug it back in. But that is it. It will not go further. I've waited up to an hour and NO GO.

My PC is connected to a 24 port switch and so is the camera, but it goes through a 8 port POE power injector before going into the switch. My other 5 cameras go through this same POE port and no issues. In other words, with the same hardware, I managed to upgrade 5 of the cameras. So I assume it cannot be my hardware setup?

I can add that since this was the first one I attempted, I do recall that it did allow me to proceed past this stage and it did complete the upgrade, but I must of unplugged it instead of closing down the program or something to that effect to render it useless. Any help to get this back? I was contemplating tossing it and getting a new one...