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

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.

I've just come here as I've been pointed in this direction as a way to upgrade my V5.2.5 build 141201 DS-2CD2132F-IS's

This may be a stupid question, but what is the reason for not using WiFi?

2) With the PC and the camera each on a wired connection (not WiFi) set the PC IP address to 192.0.0.128, subnet mask to 255.255.255.0 The default gateway does not matter.

Although on different subnets, I can get to all my cameras directly thanks to a mini router between main router and NVR.

I can, at a push, get my laptop directly connected to the NVR.
 
This may be a stupid question, but what is the reason for not using WiFi?
The 'min-system recovery environment' and particularly the bootloader when probing for the Hikvision tftp updater has quite tight timings / timeouts for the network handshake. A direct wired connection, and even a PoE connection can both be troublesome and cause the handshake to be missed.
WiFi adds another variable, plus you'd have to have the cameras on the LAN to enable the connection. I'm assuming you don't have an AP wired to the NVR PoE ports.

Although on different subnets, I can get to all my cameras directly thanks to a mini router between main router and NVR.
The Hikvision tftp updater tool used in Stage 1, and the tftp server used for Stages 2&3, must reside on the 192.0.0.128 IP address, it's hard-coded in to the Hikvision tool and firmware. So a routed or NATed connection to a different IP address will not work.

I can, at a push, get my laptop directly connected to the NVR.
That may work OK, if by that you mean the NVR PoE ports, though be aware that PoE timing can get in the way of the Hikvision tftp updater handshake.
And you'd have to be very sure not to power cycle any other cameras, to avoid them picking up on the Hikvision tftp updater.

I can get to all my cameras directly thanks to a mini router between main router and NVR.
Out of curiosity - what's the model of NVR and the firmware version?
 
The 'min-system recovery environment' and particularly the bootloader when probing for the Hikvision tftp updater has quite tight timings / timeouts for the network handshake. A direct wired connection, and even a PoE connection can both be troublesome and cause the handshake to be missed
WiFi adds another variable, plus you'd have to have the cameras on the LAN to enable the connection. I'm assuming you don't have an AP wired to the NVR PoE ports.
OK, that makes perfect sense, thank you.

The Hikvision tftp updater tool used in Stage 1, and the tftp server used for Stages 2&3, must reside on the 192.0.0.128 IP address, it's hard-coded in to the Hikvision tool and firmware. So a routed or NATed connection to a different IP address will not work.
Got it

That may work OK, if by that you mean the NVR PoE ports, though be aware that PoE timing can get in the way of the Hikvision tftp updater handshake
And you'd have to be very sure not to power cycle any other cameras, to avoid them picking up on the Hikvision tftp updater.

OK - well I have no other way of getting to the cameras, they are powered by the NVR. I can however disconnect the ones I'm not ugrading so there is only one on the network at the time

Out of curiosity - what's the model of NVR and the firmware version?
DS-7108N-SN/P
Firmware Version V3.0.20 build 161126
Encoding Version V5.0 build 151229

I've already successfully updated to v3.0.20 - can't remember what version it was before though
 
You'd be as well just getting a 12v DC power supply for the barrel connector and doing the work with the cameras on the LAN.
I'll probably leave them then.

They're 3m up a wall.

As stated in my other post, I've managed to sort out the live view issue by changing the protocol.

But I have to change it back when I'm finished, otherwise it hangs the NVR interface
 
Thanks all for the work that went into this - you just saved another bricked camera! Instructions worked a treat, although it failed trying to update to 5.4.5 - I could only downgrade to 5.2.5. Should I be able to then upgrade immediately to the latest en 5.4.5 on hikvision website now? Or am I at risk of bricking again?
 
you just saved another bricked camera! Instructions worked a treat
That's always good to hear. Thanks for sharing!
although it failed trying to update to 5.4.5
That usually works OK, under the /dav/fixup.sh script, given that the 'enhanced MTD hack' is what's been done to mtdblock6

I could only downgrade to 5.2.5. Should I be able to then upgrade immediately to the latest en 5.4.5 on hikvision website now?
For regular web GUI updates, which is what you should be able to do now, the recommended method is to update through the major revisions as opposed to one big jump. The layout of the configuration database changes over some versions, so the new version needs to know the previous version layout and do a translation.

You'll find plenty candidates here : R0 series DS-2CD2x32x-Ixx IP camera firmware
 
@alastairstevenson thanks again for this amazing tool! I finally got to try it out on two Chinese 2332's that I have and it worked great. I had a few weird things happen along the way that I thought I would share.

After step # 7

7) Power down the camera. At this point the brickfixV2 tool has been installed but not yet activated. Power on the camera to activate the tool, it will then drop the payload, fix up mtdblock1 and reboot into min-system mode for telnet access.

I followed this step...Powered down the camera, powered it back up and attempted to move on to step 8...

8) Using PuTTY, start a telnet session to 192.0.0.64 and make sure the telnet radio button is selected. At the login prompt username=root password=12345. You should see a # prompt. The message "can't chdir to home directory '/root/'" isn't an error and can be ignored.

However, I was unable to connect to the camera via PuTTY (or any ssh / telnet application). I tried switching up the firmware as mentioned in step 3 to no avail but SADP was finding the camera in min-system mode, however I could not ping it. I decided to power the camera directly via a wall adapter and connected the computer directly to the camera and for some reason this did the trick. Not sure why but maybe there was something else on my network that was interfering. I was able to putty in and run the fixup.sh script.

Another thing that happened was on a camera that had 5.2.0 firmware on it, I could not go directly to 5.4.41, I had to flash a lower version first then was able to upgrade to 5.4.41. No big deal.

Everything is working perfectly now, the camera is on the latest firmware and in English. It's working on my IPCT NVR and also Blue Iris.

Thanks again @alastairstevenson, this is an amazing tool!
 
As an Amazon Associate IPCamTalk earns from qualifying purchases.
I finally got to try it out on two Chinese 2332's that I have and it worked great.
Hey, well done, another good result!

I had a few weird things happen along the way that I thought I would share.
You did - and it's good to share the problems and fixes.

It's odd, and unexplained, why you could not ping the camera in min-system mode on 192.0.0.64 when SADP sees it OK and the PC is correctly on 192.0.0.128 on a normal 'flat' network and no network protection on the PC. I for one don't have an explanation. All I could think of is another devices on the LAN at that same address (SADP works on broadcasts so would be affected differently) but that is unlikely.
Normally I'd have discouraged the direct connection that worked OK for you, but that sorted it.

And on the Stage 3 update - it's generally been the case that the straight jump to 5.4.5 works OK, despite the general advice to update in stages.
But maybe that extra level to 5.4.41 is a step too far. I've not tried that myself.
But taking the update in steps worked OK.
 
  • Like
Reactions: Mike
You'd be as well just getting a 12v DC power supply for the barrel connector and doing the work with the cameras on the LAN.

I'll probably leave them then.

They're 3m up a wall.

As stated in my other post, I've managed to sort out the live view issue by changing the protocol.

But I have to change it back when I'm finished, otherwise it hangs the NVR interface

Just had a thought...

I've got some PoE splitters somewhere...

Can I use them inversely!?

I'd need to source or make up some RJ45 couplers and a 2.1mm barrel Jack coupler, but can I use them to split the power from the NVR but connect the data to the laptop.

Code:
NVR PoE ----- Splitter +-- Power --+ Splitter ----- Camera
                       |           |
      Data (not used) -+           |
                                   |
Laptop -------------------- Data --+
 
I'd need to source or make up some RJ45 couplers and a 2.1mm barrel Jack coupler, but can I use them to split the power from the NVR but connect the data to the laptop.
I thought the difficulty was physically getting to the NVR in order to connect up to the camera when the NVR is powering it?
Maybe I've misunderstood.

Whether your daisychain would work depends totally on what type of splitters, active or passive. Presumably these output 12V.
It looks like you are thinking of taking 12V power from the left 48V PoE splitter and feeding it into the right hand splitter where the 12V would normally exit.
With no power for the camera?
I don't see how that would work, event with a passive splitter on the right.

If you have some cables and two RJ45 joiners, you could just run the laptop to a spare NVR PoE port, and extend the camera and NVR PoE cables down to the laptop so you can break the connection for the power cycle.

But, as has been stated, the Hikvision tftp updater probe function can be troublesome with a PoE-powered connection and also a direct cable connection.
 
Apologies if I have been unclear.

The NVR is awkward, but not impossible to access.

The cameras are powered by the PoE, so trying to feed them 12v is not an option, as getting to the cameras themselves it's the issue, although I will have to do this at some point to sort out the foam rings.

I have splitters, that as far as I can tell, simply pair off 2 of the cat5 wires to a barrel jack. Used in pairs with one at the camera end and one at the source end to inject and then split out 12v.

If I'm right that they are just pin to pin connected, I thought it might be possible to plug one into a port on the NVR to split out the power (I would need to make sure it's emitting 48v through the jack though.

Connecting the barrel jacks together to inject the 48v to the camera, but plugging the data into the laptop, not the NVR - so the NVR is only supplying the power. Does that make sense.
 
Hello,

I have a DS-2CD2x32 Hikvision camera that I bricked a few years ago (trying to upgrade the firmware ...). I had lost all hope to get my cam back and found your BrickFix tool with all the success stories we can find on the forum !

The S/N is DS-2CD2632F-IS20150203CCCH502294118

I successfully ran the process to the step 7 with the brickfixV2CN file.
The problem is that after the reboot, I cannot see the camera on the network (no response to ping on 192.0.0.64).
I ran a Wireshark to see if the IP has changed and ... the IP is briefly set to 192.0.0.64, then it's changed to 0.0.0.0

upload_2019-2-4_23-39-41.png

Any help will be appreciated :D

Thx !
 
The wireshark capture shows the normal probe by the camera looking for the Hikvision tftp updater on 192.0.0.128 but getting no response.

After installing the brickfixv2 firmware the camera should be power cycled, and it should reboot into the min-system mode.
But it doesn't seem like it's done that.

Check the status with SADP. IP address, firmware version.
 
Hello,
I made a mistake during my Wireshark test : I tested with direct PC-Cam cable wire. And this method did not work to run the process, I had to connect thru my box to get it work.
So, I ran again the Wireshark :

upload_2019-2-5_22-59-40.png

Everything seems indicate the cam IP is 192.0.0.64, but, I still have no ping response. SADP tool (last release) cannot find the camera either ... :banghead:
 
Everything seems indicate the cam IP is 192.0.0.64, but, I still have no ping response. SADP tool (last release) cannot find the camera either

It does look like the camera is not going into the required min-system recovery mode, but going through the normal updater probe at startup.
Suggestion:
If the bootup is continuing to the brickfixV2 firmware - which will not show on SADP, nor respond to browser access, there is a hardware watchdog timer which will activate after about 10 minutes, and should initiate a reboot.
If you've not already left it that long, it may be worth a try.
 
My DVR model is DS-7208HGHI-E1. The problem is my DVR does not store the settings like record settings etc. I am trying to upgrade DVR firmware through USB pen drive and ivms-4200 but in both cases, the message displayed that successfully update and restart but there is no changing in firmware also the DVR previous password already present and nothing change also old firmware version displayed. I am trying to do with RS232 based connection through putty and try to update the firewall but here in last its display
Erasing SFI flash...done
writing SFI flash ....done
update check ......failed
and there is no update of DVR firmware. I am trying to change the firmware approx 50 times from Hikvision website but nothing change
so I am decided to do the bricking process but the same problem and does not brick the DVR
BrickfixV2
Any help is appreciated.