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

alastairstevenson said:
I suspect that you are correct!
As long as the brickfixV2 firmware can be installed, by whatever method, that will start the process.
But do remember to check the 'prtHardInfo' devType value just in case you have a model not covered by the sample table of values.
Click to expand...

Yep, it worked great! I took a straight-from-the-box DS-2CD2332-I with a CH serial number, did the enhanced mtd hack per your instructions, and then ran it through the major releases (5.2.0, 5.3.0, 5.4.41, and then 5.4.5). At first I tried to go straight to 5.4.41 with the fixup.sh script and received an upgrade failed message. However, substituting the 5.2.0 firmware resolved that. I did the rest of the upgrades using the web UI.

Basically the only things I did differently than your process is that: 1) I used a Mac as the tftp server (macos has one built in) and to make my telnet connections to the cam, and 2) I initially flashed the brickfixV2EN image using the curl command I typed above, also using my Mac. I did all that because we're an all-Mac household except for the Windows system running Blue Iris and I didn't want to change the IP address on that system. (I was a Unix admin in a past life so I'm comfortable with things like configuring tftpd on my own, etc.)

I have a couple of (otherwise working) cameras that I didn't know were CN-only when I flashed them up to 5.4.41 (wasn't paying close attention -- oops). Blue Iris sees them just fine but I can't access the web UI anymore due to the "firmware language mismatch" problem, and of course my day of the week is now in Chinese characters. :)

However, the web API seems to work on them so I will probably drop the brickfix image onto them the same way and get that fixed. I came here initially looking for a solution to that.

As many others have said, thank your for all your efforts enabling us to make good use of our equipment!
 
ghintx said:
Basically the only things I did differently than your process is that: 1) I used a Mac as the tftp server (macos has one built in) and to make my telnet connections to the cam, and 2) I initially flashed the brickfixV2EN image using the curl command I typed above, also using my Mac.
Click to expand...
Pretty neat!
It just shows what you can do when you try.
 
Hello,

Thanks for this topic and the clear instructions. I think I broke my DS-2CD2032F-I. The exploit was used weekly so I installed new firmware, after that the camera did not come online anymore. I eventually ended up on this page and performed all steps.

Everything seemed to go well until the last reboot. After the reboot of stage 3/3 the camera does not come online and goes back to boot mode (one or two responses from 192.0.0.64 and then stops again etc.) I tried 5.4.5 and 5.3.0. Same result.

After checking everything I discovered a difference, in the mtd6ro file i'm missing the device type (0x80 - 0x8B). See attachment. Is that a problem? In the original file (mtd6ro_mod.bak) the device type is also missing. Is this the problem?
 

Attachments

  • camera.png
    camera.png
    72.8 KB · Views: 28
Morrs said:
After checking everything I discovered a difference, in the mtd6ro file i'm missing the device type (0x80 - 0x8B
Click to expand...
Very odd! Yes, the model number is completely missing.
And the serial number seems to be offset by one byte.
Morrs said:
In the original file (mtd6ro_mod.bak) the device type is also missing. Is this the problem?
Click to expand...
It could very well be the problem, or the offset serial number.
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.
 

Attachments

  • Like
Reactions: Morrs
I have a 2332 camera which is well and truely bricked. It does note appear in SADP and does not respond to TFTP server.

The only access I have to the camera is via serial port which seems to indicate I have lost some vital files from the camera but I have no idea how to fix this or even if its possible?

Attached is log of serial connection. Can some advise if/how I can upload firmware via serial port?
 

Attachments

philkee said:
The only access I have to the camera is via serial port which seems to indicate I have lost some vital files from the camera but I have no idea how to fix this or even if its possible?
Click to expand...
Certainly that can be fixed. On the assumption that it really is a 2332 and the attachment Hik2335serial.txt is a typo ...

The camera is booting into a shell and not starting the usual app programs.
And oddly, it's an ash shell that seems to be linked to psh, so the stock firmware has been tweaked.
I'd guess that the firmware trying to run is the R0 5.4.5 judging by the 'network_deamon' parameters.

So is this a failed 'mtd hack'?
How did it get bricked?

Suggestion:
Validate the hardware signature block in mtdblock6 and refresh the stock firmware by following the brickfixV2 method here, but with a modified starting point :
Unbrick and fully upgrade your R0 / DS-2CD2x32 IP cameras -
R0 / DS-2CD2x32 BrickfixV2 brick recovery and full upgrade tool - enhanced.

Power cycle the camera and interrupt the bootloader with Control-U
Check the environment variables are normal using 'printenv', in particular ipaddr and serverip
They should look much like this (by the way - use the 'code' tags in the '+' menu, easier for you and easier for us) :
Code: 
HKVS # printenv
ipaddr=192.0.0.64
serverip=192.0.0.128
gatewayip=0.0.0.0
netmask=255.255.255.0
ethaddr=c0:56:e3:af:98:b7
loadaddr=0xc2000000
bootfile=digicap.dav
bootcmd=null
bootargs=console=ttyS0 initrd=0xc0a00000,0x400000 rw root=/dev/ram dbg=0
bootdelay=2

You should be able to get to Stage 1 of the brickfixV2 method as follows:
With the PC IP address set to 192.0.0.128, the Hikvision tftp updater running, and either brickfixv2EN.dav or brickfixv2CN.dav renamed as digicap.dav in the same folder, at the bootloader prompt use the command 'update /digicap.dav'
Then after a power cycle the min-system recovery should be running, allowing telnet to 192.0.0.64 and execution of the /dav/fixup.sh script as per the step-by-step guide.


Good luck!
 
How does the overall process change if the camera is currently functioning as hacked CH to ENG and sits on the network?
I would like to upgrade all to 5.4.5 / EN

qoOHJNm.jpg
 
MadamImAdam said:
How does the overall process change if the camera is currently functioning as hacked CH to ENG and sits on the network?
Click to expand...
If already running, with, say 5.2.5 or lower firmware, you can enable telnet and run the shell command 'prtHardInfo' to be sure what the needed 'devType' value is, in case you have a model that's not already in the devType list.
But the camera does not have to be bricked to run the brickfixV2 process. Bricked or not, the Hikvision tftp updater is the convenient starting point.
 
alastairstevenson said:
Certainly that can be fixed. On the assumption that it really is a 2332 and the attachment Hik2335serial.txt is a typo ...


So is this a failed 'mtd hack'?
How did it get bricked?
Click to expand...

Thanks for the reply.

It is a 2332 and yes it was a fail mtd hack.

Will try your suggestions later and report back.
 
Hi,
First off, a big thank you for this. I just managed to upgrade four DS-2CD2232-I5 cameras that i thought was dead.
However, i have one DS-2CD2132F-I that i just can't get to work.
It connects to my tftpserver and downloads the digicap.dav file (Brickv2EN), it completes the download but it never says that the system has been upgraded.

How should i proceed with this camera?

Kind Regards
ehsab
 
ehsab said:
First off, a big thank you for this. I just managed to upgrade four DS-2CD2232-I5 cameras that i thought was dead.
Click to expand...
Excellent!
ehsab said:
It connects to my tftpserver and downloads the digicap.dav file (Brickv2EN), it completes the download but it never says that the system has been upgraded.
Click to expand...
Try the brickfixv2CN.dav - what works as an upgrade depends on the language value that's been set in mtdblock6 location 10 hex.
That varies with the origin of the camera.
 
alastairstevenson said:
If already running, with, say 5.2.5 or lower firmware, you can enable telnet and run the shell command 'prtHardInfo' to be sure what the needed 'devType' value is, in case you have a model that's not already in the devType list.
But the camera does not have to be bricked to run the brickfixV2 process. Bricked or not, the Hikvision tftp updater is the convenient starting point.
Click to expand...

Does tftpserve only attempt to connect to a camera at 192.0.0.64? or does it scan all cameras on the network? so I would first set cam to 192.0.0.64, then PC to 192.0.0.128, then proceed?

And what option does my camera need to have enabled for tftpserve to do anything? at the moment it just sits there without connecting to the camera.


----------------------------

TYVM Alastair!

All five cameras now on 5.4.5!!!
very cool ;)
 
Last edited:
alastairstevenson said:
Excellent!

Try the brickfixv2CN.dav - what works as an upgrade depends on the language value that's been set in mtdblock6 location 10 hex.
That varies with the origin of the camera.
Click to expand...

Why didn't i try that when i was onsite?
It is a remote site, i have ssh access to an old NAS (Qnap 209 Pro II) and i have tried to get a tftpd server on that NAS, but i don't yhink there is any chance to get it to run a tftpd :(
So i need to wait until next time i will visit that remote site.

Kind Regards
ehsab
 
alastairstevenson said:
You should be able to get to Stage 1 of the brickfixV2 method as follows:
With the PC IP address set to 192.0.0.128, the Hikvision tftp updater running, and either brickfixv2EN.dav or brickfixv2CN.dav renamed as digicap.dav in the same folder, at the bootloader prompt use the command 'update /digicap.dav'
Then after a power cycle the min-system recovery should be running, allowing telnet to 192.0.0.64 and execution of the /dav/fixup.sh script as per the step-by-step guide.

Good luck!
Click to expand...

Hi Alastair

Tried your suggestions, environment variables OK (similar to yours) but when I try to 'update /digicap.dav' it just hangs. Left it running for about ten minute, nothing happens.

Tried telnet after restart.....can't connect to camera.

Don't know where to go to from here.

FYI the camera originally came with v5.3. I got it upgraded to v5.4.5 but it was in Chinese so I went back and tried your brick fix again but something went wrong in the process and I ended up here.

Regards
Phillip
 
MadamImAdam said:
All five cameras now on 5.4.5!!!
Click to expand...
Great result!
MadamImAdam said:
Does tftpserve only attempt to connect to a camera at 192.0.0.64? or does it scan all cameras on the network? so I would first set cam to 192.0.0.64, then PC to 192.0.0.128, then proceed?
Click to expand...
To answer your earlier question, now not needed : The tftpserve.exe tftp updater program simply waits for any probes from Hikvision devices and when received, responds to complete a handshake, following which transfer of digicap.dav takes place.
 
Does it work with any tftp server to upload digicap.dav file to cameras when they boot?
Or does it have to be the one from Hikvision?

Kind Regards
ehsab
 
philkee said:
when I try to 'update /digicap.dav' it just hangs. Left it running for about ten minute, nothing happens.
Click to expand...
That's a bummer, and a bit odd.
If the tftp client that's used by the update command can't connect, there is usually a timeout and the camera is left running the min-system kernel.
Did the tftp updater show 'initialised at 192.0.0.128' in the status window?
Does the switch/router link detect light show active?
Can you ping the camera at 192.0.0.64 ?

philkee said:
Don't know where to go to from here.
Click to expand...
Where are you based?
 
You must log in or register to reply here.
Top Bottom