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

alastairstevenson said:
If you want to spend (even) more time on this - we could look at manually grafting the needed files in, as you've still got good access at the shell level.
Click to expand...

Let's do it! I'm actually stuck at home recovering from a major surgery, so I have all the time in the world. I don't want to get beaten by this little Chinese camera. If you are willing to keep working with me, let's get this thing fixed. Thanks!
 
Ok.
It might be a couple of days though, as I have some child care scheduled.

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.
 
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
You must log in or register to reply here.
Top Bottom