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

I am not sure whether that network disconnect issue was fixed in 5.4.41 or not.
From what I recall, all they did was to change the command-line parameters on the network_deamon (sic) checker program.
The problem, only seen on some switches when a camera isn't being accessed and there is no outbound network traffic, is not limited to the R0 series cubes, it's across several models and series.
 
I have a CN DS-2CD2032-I that had English hack, and made mistake of flashing EN 5.4.5 before following this guide.

Followed this guide. SADP can't find it after the last power cycle.

SADP finds it after flashing 'brickfixv2EN.dav'. After flashing en_std_5.4.5_170123 --> Firmware update appears to be successful. --> Power cycle --> SADP doesn't see anything

Any ideas? I've tried flashing older EN versions and they appear to be successful, but I don't think this camera is booting correctly.

Edit: Ended up reverting back to CN everything, including HEX values, and started the conversion from scratch. Didn't seem to work.

Took everything apart and was going to order 1.25mm JST T-1 4-Pin for further troubleshooting, but decided to try reseating the thin 40 pin (i think) ribbon cable between the two boards. I was messing around earlier and possibly had them seated incorrectly. SADP detects 192.168.1.64, web page is accessible, and it's fully EN.

Everything seems to load faster on 5.4.5 as well. Sadly, I will be selling this and looking 8mp h265 options, however, this cam served well.
 
Last edited:
decided to try reseating the thin 40 pin (i think) ribbon cable between the two boards. I was messing around earlier and possibly had them seated incorrectly. SADP detects 192.168.1.64, web page is accessible, and it's fully EN.
That makes sense.
The davinci program as it initialises needs to communicate with the sensor, and if it can't will eventually give up, and not get to the point where services such as SADP support and web are running.

By the way - just in case of any future requirements, the Hikvision serial console connector is 4-pin 1.5mm JST ZH, not 1.25mm.

Thanks for sharing!
This always adds to the problem-solving pot for others.
 
  • Like
Reactions: aduz
Is the 2CD2522FWD-IS (mini dome) not an R0?

I have what seems to be a Western Region model, was running 5.4.1, now on 5.5.53

I wanted to apply the brickfix so as to revert to an older firmware (so i can set a simpler password to match
a running older NVR - long story) but none of the brickfix.dav files seem to 'stick'. Tried the original brickfix and the V2's,
as well as the CN variants for good measure. transfer completes, but never get the 'update completed' message.

The only .dav's I can apply via tftpd are the official firmwares for this cam from the web site (5.4.1 and 5.5.53) from here:
2 MP Network Mini Dome Camera

What am i doing wrong? TIA...
 
Is the 2CD2522FWD-IS (mini dome) not an R0?
I don't believe it is, so the brickfixV2 firmware, which is based on R0, will be rejected.

Hikvision's model naming with the new FWD suffix is confusing.
DS-2CD2522F-I(S)(W) is in the list of R0 cameras but the 2CD2522FWD-IS is not, I believe it's an R6 series camera.
The 'downgrade block' will almost certainly apply to a camera that has had 5.5.53 running, preventing downgrading to any 5.4.x version.
And the 5.5.x firmware is not yet susceptible to manipulation from any publicly available repacker tools - Hikvision have again changed the firmware coding.
But like any cat and mouse game, it won't be long.
@montecrypto has already cracked this, but is keeping the code private for now.
 
I researched before asking but couldn't find a definitive answer.

Can you tftp to a R0 camera through a Hikvision NVR with POE? I would disconnect all the other cameras from the NVR and update them one by one. I ask because it's a hassle to either climb into the attic to provide 12V power or remove the camera from the outside and do it from there if I'm running without the POE of the NVR. I could purchase a POE switch and bypass the NVR but I wanted to ask here for making that commitment.

Also, if it can be done, do I need to change the subnet of the NVR so it's on the xxx.xxx.0.xxx ip?

Thanks!
 
if this were to be do-able at all, you'd need to set the INTERNAL NIC address of the NVR to 192.0.0.1/24,
AND create a static route on yourLAN router to direct traffic for the 192.0.0.0/24 network to the NVR's LAN address.

a cheap Poe switch or just a PoE injector may be a simpler solution...
https://www.amazon.com//dp/B07F9C8BRR/ref=sr_1_13
 
As an Amazon Associate IPCamTalk earns from qualifying purchases.
  • Like
Reactions: proxybox
I'm on 5.1.6, already patched mtdblock6, may I upgrade directly to latest 5.4 via web?
Maybe, it depends on a couple of things:

If you did the 'enhanced MTD hack' that covered not just the language byte at 0x10 and the checksum bytes at 0x04, but also the devType bytes at 0x64 that's good. But if the devType byte at 0x64 shows FF that needs attention as the later firmware will baulk at that.

Also - some 5.1.6 firmware cameras had values in mtdblock1 that the later firmware considered to be error flags.
Check the block of 0x40 bytes at the beginning of mtdblock1
If all erased (ie FF) then that's OK as the firmware will write a new valid template over it.
But if locations 0x0A and 0x0C do not hold 01 then mtdblock1 will need to be changed.
There is also a checksum at 0x04 but I don't think it is verified.
 
Thanks for reply. I did 'enhanced MTD hack' , just lang from 0x2 -> 0x1 at 0x10 was necessary + checksum ajdust. devType was correct at place already. Checked also mtdblock1 and thare are just 0xFF at all.

Is it better to go to 5.2 -> 5.3 and finally to 5.4 due to preserve configuration?
 
Last edited:
Just updated my 1st cam: DS-2CD2532F-IWS from v5.1.6
Steps:
  1. manual mtd hack adjusting of mtdblock6 based on steps for 'enhanced MTD hack'
  2. upgrade to 5.2.3 via webUI
  3. upgrade to 5.3.0 via webUI
  4. upgrade to final V5.4.41 build 170312 via webUI
Cam is connected via Wifi, all configs preserved - no need to reconfigure from zero, just latest FW forced me to change default password as expected
Now 2 remaining cams are waitings for upgrade DS-2CD2732F-IS and DS-2CD2632F-IS;)

Thanks for your help and usefull thread @alastairstevenson. If you have Paypal, msg me your email, will send you few bucks to buy a beer :):)
 
Last edited:
  • Like
Reactions: alastairstevenson
if this were to be do-able at all, you'd need to set the INTERNAL NIC address of the NVR to 192.0.0.1/24,
AND create a static route on yourLAN router to direct traffic for the 192.0.0.0/24 network to the NVR's LAN address.

a cheap Poe switch or just a PoE injector may be a simpler solution...
https://www.amazon.com//dp/B07F9C8BRR/ref=sr_1_13

Great advice. I bit the bullet found a guy on OfferUp who was selling POE switches and picked up an Asus Gigabit POE+ 8 port swtich for $25. It'll be nice to have it on reserve in the event my NVR poops out.
 
As an Amazon Associate IPCamTalk earns from qualifying purchases.
  • Like
Reactions: alastairstevenson
All 3 cams are on V5.4.41 build 170312 now.
Bit dissapointed there is no support for Chrome browser live view plugin yet. But main reason for upgrade was working line crossing events for notify surveillance center, downside is I lost possibility for adding more crossing lines.
 
  • Like
Reactions: alastairstevenson
I too was successful! I had a few hiccups but in the end everything worked great. I had to use the CN version because the EN hung on TFTP and I never got the System Update Completed confirmation.

It did change the ip of the camera to 192.168.1.64 but after re-tftping it took the CN version without issue. After getting the firmware fully loaded, my cameras default did remain at 192.168.1.64.

Thanks Alastairstevenson..
 
  • Like
Reactions: alastairstevenson