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

alastairstevenson said:
What I'll look at is loading up some 'hacked to English' firmware and figuring out the best way to graft it on.
It could be by file, or by flash partition.
Click to expand...
I'm hoping this will work for you -

These are the steps that should work to apply the partition image and bring the camera back to a working state.
As this is a Chinese camera without the ability to use the brickfixV2 method to convert and update, this is a custom image.
Unzip the file I sent in 'Conversations' into the camera-specific folder you created on the NAS NFS share.
Adjust IP addresses and NFS share names as needed.

Interrupt the bootloader and configure for a root shell.

Code: 
setenv bootargs console=ttyS0 initrd=0xc0a00000,0x400000 rw root=/dev/ram dbg=0 init=/bin/sh
saveenv
reset

After bootup completes, at the root shell use :

Code: 
/etc/init.d/rcS

ifconfig eth0 192.168.1.64 up
mount -t nfs -o nolock 192.168.1.201:/cctv1 /mnt/nfs00

cd /mnt/nfs00/DS-2CD2432F-IW

/usr/sbin/umount_ubifs_prt.sh /dav 1

cat mtd13ro > /dev/mtdblock13

Power cycle the camera, and interrupt the bootloader to put bootargs back to the original value :

Code: 
setenv bootargs console=ttyS0 initrd=0xc0a00000,0x400000 rw root=/dev/ram dbg=0
saveenv
reset

After the device boots up, check the status with SADP.
If it shows as 'Inactive', 'Activate' with a new strong password, and change the IP address as needed.
Access the camera web GUI at its IP address and check out the functions.

Good luck!
Note - this custom image is still subject to the 'Hikvision backdoor', and can't be updated as mtdblock6 still has the CN language value.
 
@alastairstevenson
Thanks for the custom firmware and steps. I was able to successfully run through all commands as listed, but upon final reboot the camera spit out a bunch of error messages and is stuck in a boot loop. I have attached all command output to the Conversation you sent the firmware in. I think the camera is probably completely dead now. LOL

Thanks!
 
I checked the transcript - it all looks absolutely fine, almost finished the full boot process, until finally the DSP is initiallised.
The applied firmware looks like it's working as it should.

Code: 
pDspInitPara->VideoInitParam.capture_mode 125967385(width = 1920, height = 1080, fps = 25, interlace = 0)
device_type: 5, vitype: 21, fps: 25.000000
find_video_mode sucusss!! mode 125967385 p_mode_table[i].vin_mode 30 vin_object.vin_fps 25.000000 vin w 1920 h 1080
set mode 30 type 21
vin_mode 2304*1296 vin_mode_temp 2304*1296 vin_mode_temp2 2304*1296enc_chan_cnt=2
vin_object.vi_param chan = 1, fps/resolution/width/height = 25/4123/1920/1080
vin_object.vi_param chan = 2, fps/resolution/width/height = 25/4097/352/288

Code: 
<DSP> ERR:setup_dsp:setup_video_input
[08-19 11:43:56][pid:852][DSP][ERROR]DSP ...
[08-19 11:43:56][pid:852][SYSINIT][ERROR]hwif_dsp_init error force sys reboot,ret=-12!!!!

I'm not sure what could be the source of that error - on the face of it, looks like hardware.
 
alastairstevenson said:
I'm not sure what could be the source of that error - on the face of it, looks like hardware.
Click to expand...
Looking at a collection of trouble-shooting transcripts from way back - I'm fairly sure this error may be associated with the legacy devType value in mtdblock6, the partition that is modified under the brickfixV2 method, to convert to EN and fix up some other values.

I've refrained from getting you to extract / edit / re-apply this as there is a tripwire that Hikvision introduced in 5.3.0 (I think) and later that deliberately bricks the camera if an attempt is made to write mtdblock6.
 
@alastairstevenson
I can't believe I missed that part of the full boot process. I just saw a bunch of scrolling errors, and the camera kept rebooting. I'm glad that it is at least trying.

alastairstevenson said:
I'm fairly sure this error may be associated with the legacy devType value in mtdblock6
Click to expand...
I think you are right. I had updated the camera to 5.3.0 by my mistake, and was able to do a downgrade to 5.2.3, but I think you are right that Hikvision set a tripwire in mtdblock6. I think this thing is a paperweight right now. It's probably a good idea to stop what we are doing, and I will buy a new Reolink for dirt cheap and call it a day. I do appreciate all of the excellent help you have provided. I learned a lot about these HikVision cameras and what a nuisance they are. LOL

Thanks again!
 
I'm tracking the solution to your problems and I can't understand why you didn't take advantage of my offer?
You could just pour the service firmware into the Chinese camera and immediately get a fully functional European product, in 5 minutes.
 
@Oleglevsha,
I am sure your solution would have worked, but this thread is devoted to @alastairstevenson BrickfixV2 solution which worked for all my other cameras except for one that had a a tripwire in mtdblock6 set when I did an accidental firmware upgrade to v5.3.0. I trust @alastairstevenson and his solutions. Maybe you can start your own thread and promote it as a similar solution to freeing the Chinese cameras and allowing them to run on US/European firmware? Cheers!
 
glockgabe said:
@Oleglevsha,
I am sure your solution would have worked, but this thread is devoted to @alastairstevenson BrickfixV2 solution which worked for all my other cameras except for one that had a a tripwire in mtdblock6 set when I did an accidental firmware upgrade to v5.3.0. I trust @alastairstevenson and his solutions. Maybe you can start your own thread and promote it as a similar solution to freeing the Chinese cameras and allowing them to run on US/European firmware? Cheers!
Click to expand...
this is worthy of respect
 
  • Like
Reactions: alastairstevenson and glockgabe
alastairstevenson said:
@glockgabe - worth trying the potential solution offered by @Oleglevsha
It would be interesting to see how it deals with the conversion of the legacy devType that I think is the remaining problem.
Click to expand...
if you are interested, then you can try it for a start
Change your R0 series camera to the Chinese region using your method and fix it back using the service firmware
 
I'm not sure how we will do this. The camera is not booting fully right now, and is stuck in an endless boot loop. No web interface, no TELNET, I can gain access to the TTL header and issue commands that way. I tried to XMODEM the BrickFixV2 .dav file onto the camera and it threw a corrupt memory error about 75% through the process. I think the Chinese b0rked this one.
 
glockgabe said:
I'm not sure how we will do this. The camera is not booting fully right now, and is stuck in an endless boot loop. No web interface, no TELNET, I can gain access to the TTL header and issue commands that way. I tried to XMODEM the BrickFixV2 .dav file onto the camera and it threw a corrupt memory error about 75% through the process. I think the Chinese b0rked this one.
Click to expand...
Show the original and modified mtdblock6, I also tend to conclude
alastairstevenson about an error in changing this block
 
Oleglevsha said:
This only works with serviceable IP cameras that load normally and can transmit data about the devType for the script to work
Click to expand...

Code: 
#!/bin/sh
sleep 1
cd /home
chmod 777 checksum32
sleep 30
cd /dav
    VAR=`dd if=/dev/mtdblock6 skip=16 bs=1 count=1 2>/dev/null`
if [ $VAR == $'\002' ]
 then
    echo -e '\033[32;40m' Chinese "\033[0m"
    cat /dev/mtdblock6 > /home/doc/mtdblock6.img
    DvT=`prtHardInfo | awk ' /'devType'/ {print $3} '`
    DvT1=`printf '%x\n' $DvT | sed "s/\(..\)/\1 /g" | awk ' /''/ {print $2} '`
    DvT2=`printf '%x\n' $DvT | sed "s/\(..\)/\1 /g" | awk ' /''/ {print $1} '`
    sleep 1
    echo -ne "\x01" | dd conv=notrunc of=/home/doc/mtdblock6.img bs=1 seek=16
    echo -ne "\x03" | dd conv=notrunc of=/home/doc/mtdblock6.img bs=1 seek=85
    echo -ne "\x$DvT1" | dd conv=notrunc of=/home/doc/mtdblock6.img bs=1 seek=100
    echo -ne "\x$DvT2" | dd conv=notrunc of=/home/doc/mtdblock6.img bs=1 seek=101
    /home/checksum32 /home/doc/mtdblock6.img 0x0
    echo -e '\033[32;40m' /home/checksum32 /home/doc/mtdblock6.img 0x0 : $? "\033[0m"
    echo -ne "\x01" | dd conv=notrunc of=/home/doc/mtdblock6.img bs=1 seek=131088
    echo -ne "\x03" | dd conv=notrunc of=/home/doc/mtdblock6.img bs=1 seek=131157
    echo -ne "\x$DvT1" | dd conv=notrunc of=/home/doc/mtdblock6.img bs=1 seek=131172
    echo -ne "\x$DvT2" | dd conv=notrunc of=/home/doc/mtdblock6.img bs=1 seek=131173
    /home/checksum32 /home/doc/mtdblock6.img 0x20000
    echo -e '\033[32;40m' /home/checksum32 /home/doc/mtdblock6.img 0x20000 : $? "\033[0m"
    echo -ne "\x01" | dd conv=notrunc of=/home/doc/mtdblock6.img bs=1 seek=262160
    echo -ne "\x03" | dd conv=notrunc of=/home/doc/mtdblock6.img bs=1 seek=262229
    echo -ne "\x$DvT1" | dd conv=notrunc of=/home/doc/mtdblock6.img bs=1 seek=262244
    echo -ne "\x$DvT2" | dd conv=notrunc of=/home/webLib/doc/mtdblock6.img bs=1 seek=262245
    /home/checksum32 /home/doc/mtdblock6.img 0x40000
    echo -e '\033[32;40m' /home/checksum32 /home/doc/mtdblock6.img 0x40000 : $? "\033[0m"

cat /home/doc/mtdblock6.img > /dev/mtdblock6 
echo -e '\033[32;40m' cat /home/doc/mtdblock6.img : $? "\033[0m"
rm -rf /home/doc/mtdblock6.img

 elif [ $VAR == $'\001' ]
    then echo -e '\033[32;40m' English "\033[0m"
        fi
#End
 
Last edited:
That's neat.
I see how you deal with the legacy form of devType - get the firmware to translate it, and just plug it back in to the bootpara block.
And tweak the region code.
And very thorough in updating all 3 instances of the bootpara block.

Have you noticed that when mtdblock6 is written under firmware newer than 5.3.0 that the kernel places a null in the language byte?
This signals the firmware, and the bootloader, to error, resulting in a bricked device.
 
alastairstevenson said:
Have you noticed that when mtdblock6 is written under firmware newer than 5.3.0 that the kernel places a null in the language byte?
This signals the firmware, and the bootloader, to error, resulting in a bricked device.
Click to expand...
No, I have not seen such a manifestation, since I was unable to change mtdblock6 using a firmware version higher than 5.3.0
therefore, the service firmware is based on the early version 5.2.5
in addition, with the possibility of downgrading the version from 5.3.0 and higher to version 5.2.5
 
  • Like
Reactions: alastairstevenson
Successful on R0 v5.2.5 build 141201 which I bricked, used the brickfixv2EN version.
Firmware used V5.4.5_Build170123.
Ran pcap against the intf (for more info)

Issues I had:
  1. ensure all other intfs on PC are disabled (as TFTP seems to grab all my others first).
  2. several power cycle attempts required at step5
  3. step8 did not work at first, repeat was the same, dropped in the new firmware(ran out of ideas!), TFTP reported successful load, but no access
  4. repeated step7 again, this time it worked, all other steps from this point were OK.
Thanks!
 
Hello evryone,

after speding 5 hours on my own I am frustrated (or to be honest angry. Angry about my stupidity, angry because of Hikvisions strange update policy).

So I would really appreciate any help I can get.

I have a DS-2CD2432F-IW camera. It is a grey market modell with CH in the serial number. Date on the sticker says 09/14
So when I tried to upgrade the UI was all chinese afterwards (which I did not know at this point).

So I have the camera (not bricked) at Firmware 5.2.0 build 140721 (taken from the ui)
On the sticker at the back of the camera it is also written that this cam was delivered with 5.2.0 build 140721

I can connect to the camera via my browser. it appears in the SADP tool.
However I am not able to flash a new firmware with internet explorer and the enabled active x element.
It is instantly displaying a ! in a orange trinangle framed by chinese symbols.

So yesterday I fould this fantastic article and thought to myselft: I will try to update it to the latest english firmware or at least revert it to english.

So I downloaded the necessary software.
I wired my Lenovo Tiny desktop to a standallone mikrotik switch and attached the camera on another port of that switch.
I set the IP to 192.0.0.128 , Subnet 255.255.255.0, switched off the Wifi module, switched off the Windows Firewall for all networks and started the Hikvision TFTP Server.

It displayed [Date and Time] TFTP server[192.168.128] initialized.

I power cycled the camera and waited...
nothing was happening in the TFTP Server log.

After 15min I retied. No change.
In SADP the camera appeared with a 169.254... somewhat IP.
So I manually set the cameras IP to 192.0.0.64

connection was working via the browser.
Ping -t was working.
So I power cycled

Ping -t took longer than I would expect it to be able to ping the camera (40secs perhaps) but nothing happening in the TFTP server software.

So I changed the IP of my desktop to 192.168.1.128
and the camera to 192.168.1.64

nothing.

So I tried it without the switch, direct link, also not working.

I gave up at that time.

This morning I took a server grade computer with a Intel NIC, another mikrotik switch (same model)

I repeated all the above steps (without switching off the wifi, because this board does not have any wifi) with exact the same result:
Nothing is appearing in the TFTP Server.

Any ideas?

As the camera is not bricked (in the common understanding) I think the serial console thing would not do any good right now.

Is there perhaps an option in the chinese UI that I need to enable first to get the ARP request from the CAM to the tftp server?
Or is this request just initialized when the cam can not boot?

I am so lost....

please help me
 
You must log in or register to reply here.
Top Bottom