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

just wondering if anyone can provide some assistance
I have a 2CD-2032I which is a CN version and yep... bricked due to trying to apply V5.4.5_Build170123

I have tried to tftp the EN and CN versions from Brick-fix toolV2 archive with no luck,
the current status is on boot up it does the "device 192.0.0.64 test tftpserver" and goes no further.

with a serial cable connected it give me this:
Code:
U-Boot 1.3.4-100728 (Nov 11 2014 - 13:58:34)

ARM Clock: 480MHz
DDR Clock: 336MHz
Hit Ctrl+u to stop autoboot: 0
|NUL eth|
Unknown command:null
nand booting ...
load kernel...
load ramdisk...
init started: BusyBox v1.19.3 (2016-05-23 16:23:55 CST)
starting pid 375, tty '': '/etc/init.d/rcS'
Starting udev:      [ OK ]
UBI device number 1, total 192 LEBs (24772608 bytes, 23.6 MiB), available 0 LEBs (0 bytes), LEB size 129024 bytes (126.0 KiB)
waiting for /dev/ubi1_0.
pri_iUpgSuccCnt:0x1, sec_iUpgSuccCnt:0x1
UBI device number 3, total 32 LEBs (4128768 bytes, 3.9 MiB), available 0 LEBs (0 bytes), LEB size 129024 bytes (126.0 KiB)
waiting for /dev/ubi3_0.
Check dir /davinci ok! (0)
UBI device number 4, total 31 LEBs (3999744 bytes, 3.8 MiB), available 0 LEBs (0 bytes), LEB size 129024 bytes (126.0 KiB)
waiting for /dev/ubi4_0.
Check dir /config ok! (0)
diagnose_way = 15, repair_way = 1, interval = 30
route: ioctl 0x890c failed: No such process
mount: mounting none on /proc/bus/usb failed: No such file or directory
/dav
map_size = 0x300000
nr_item = 3
addr_offset = 0x0 filename = orccode.bin
addr_offset = 0x200000 filename = orcme.bin
addr_offset = 0x2a0000 filename = default_binary.bin
mmap returns 0x40265000
loading ./orccode.bin...addr = 0x40265000, size = 0x1a0a91
loading ./orcme.bin...addr = 0x40465000, size = 0x3a4fc
loading ./default_binary.bin...addr = 0x40505000, size = 0x40000
===============================
u_code version = 2016/4/6 3.0
===============================
The system is going down NOW!
Sent SIGTERM to all processes
Sent SIGKILL to all processes
Requesting system reboot


U-Boot 1.3.4-100728 (Nov 11 2014 - 13:58:34)

ARM Clock: 480MHz
DDR Clock: 336MHz
Hit Ctrl+u to stop autoboot: 0
begin to enter mini system
 check bad block failed >> read spare data error.


i can manually call tftp from the serial console and it will pull the file down but im not sure if theres any other steps i need to take:

Code:
U-Boot 1.3.4-100728 (Nov 11 2014 - 13:58:34)

ARM Clock: 480MHz
DDR Clock: 336MHz
Hit Ctrl+u to stop autoboot: 1
HKVS # tftp
[ INFO][BLD]TFTP: MAC: c0:56:e3:f7:22:d5
[ INFO][BLD]TFTP: TFTP from server 192.0.0.128; our IP address is 192.0.0.64
[ INFO][BLD]TFTP: Filename: 'digicap.dav'
[ INFO][BLD]TFTP: ################################################################################
[ INFO][BLD]TFTP: ################################################################################
[ INFO][BLD]TFTP: ################################################################################
[ INFO][BLD]TFTP: ################################################################################
[ INFO][BLD]TFTP: ################################################################################
[ INFO][BLD]TFTP: ################################################################################
[ INFO][BLD]TFTP: ################################################################################
[ INFO][BLD]TFTP: ################################################################################
[ INFO][BLD]TFTP: ################################################################################
[ INFO][BLD]TFTP: ##
[ INFO][BLD]TFTP: File size is 18495808 bytes (18062 KB)
HKVS # update
check bad block failed >> read spare data error.


U-Boot 1.3.4-100728 (Nov 11 2014 - 13:58:34)

ARM Clock: 480MHz
DDR Clock: 336MHz
Hit Ctrl+u to stop autoboot: 0
check bad block failed >> read spare data error.

id appreciate any help, or if you recommend i bin it well thats probably where it will end up :)
 
It does look like there are problems trading the flash.

When you interrupt the bootloader you might be able to use the update command.
Though it may fail with the same error of the flash will not read correctly.

**oops**
I see you already tried that.
 
yeah ok im not too clued up on the other commands, but if you want to suggest some to me i'll try them, ive got nothing to lose. :)
 
I think it's unlikely though that the 'format' part of upf will fix up the problem with hiding bad blocks.
The 'problem reading spare block' sounds like it's run out of blocks to use.
 
it looks like it needs some files i dont have?
Code:
HKVS # upm
[ INFO][BLD]TFTP: MAC: c0:56:e3:f7:22:d5
[ INFO][BLD]TFTP: TFTP from server 192.0.0.128; our IP address is 192.0.0.64
[ INFO][BLD]TFTP: Filename: 'mImage'
[ERROR][BLD]TFTP: do_tftp_load:bld_udp_recv RRQ failed!rval=-110
[ERROR][BLD]TFTP: do_tftp_load:bld_udp_recv RRQ failed!rval=-110
[ERROR][BLD]TFTP: do_tftp_load:transfer error
[ERROR][BLD]BURN: Download File [FAIL]! error: tftp.
HKVS # upa
[ INFO][BLD]TFTP: MAC: c0:56:e3:f7:22:d5
[ INFO][BLD]TFTP: TFTP from server 192.0.0.128; our IP address is 192.0.0.64
[ INFO][BLD]TFTP: Filename: 'app.img'
[ERROR][BLD]TFTP: do_tftp_load:bld_udp_recv RRQ failed!rval=-110
[ERROR][BLD]TFTP: do_tftp_load:bld_udp_recv RRQ failed!rval=-110
[ERROR][BLD]TFTP: do_tftp_load:transfer error
cmd_update_app:do_tftp_load failed!
HKVS # upf
***** UPDATE START *****
[ INFO][BLD]TFTP: MAC: c0:56:e3:f7:22:d5
[ INFO][BLD]TFTP: TFTP from server 192.0.0.128; our IP address is 192.0.0.64
[ INFO][BLD]TFTP: Filename: 'mImage'
[ERROR][BLD]TFTP: do_tftp_load:bld_udp_recv RRQ failed!rval=-110
[ERROR][BLD]TFTP: do_tftp_load:bld_udp_recv RRQ failed!rval=-110
[ERROR][BLD]TFTP: do_tftp_load:transfer error
[ERROR][BLD]BURN: Download File [FAIL]! error: tftp.
[ERROR][BLD]BURN: update mini system [FAIL]!error: upf.
!!!!! UPDATE FAIL !!!!!
HKVS #


and these are in my digicap.dav
Code:
File 0 alsa-lib.tar.gz filelen=15136 filepos=1120 checksum=1974573
File 1 ambarella_eth_debug.ko filelen=8696 filepos=16256 checksum=501530
File 2 ASC16.bin filelen=1349 filepos=24952 checksum=181815
File 3 certs.tar.gz filelen=2248 filepos=26301 checksum=295398
File 4 check_config filelen=5820 filepos=28549 checksum=352773
File 5 cmemk.ko filelen=14269 filepos=34369 checksum=980102
File 6 davinci filelen=8 filepos=48638 checksum=744
File 7 davinci.tar.gz filelen=4956109 filepos=48646 checksum=677357937
File 8 da_info filelen=31012 filepos=5004755 checksum=2944808
File 9 driver.tar.gz filelen=1362837 filepos=5035767 checksum=183041981
File 10 execSystemCmd filelen=7168 filepos=6398604 checksum=536975
File 11 GBK filelen=457196 filepos=6405772 checksum=61467495
File 12 gdmak.ko filelen=5940 filepos=6862968 checksum=315506
File 13 hImage filelen=5068452 filepos=6868908 checksum=537709034
File 14 hroot.img filelen=2510644 filepos=11937360 checksum=340129173
File 15 idsp.tar.gz filelen=908129 filepos=14448004 checksum=123763199
File 16 IEfile.tar.gz filelen=2275690 filepos=15356133 checksum=290663934
File 17 initrun.sh filelen=4459 filepos=17631823 checksum=401422
File 18 libsqlite3.so filelen=612616 filepos=17636282 checksum=66775440
File 19 pppoed filelen=14164 filepos=18248898 checksum=1192542
File 20 ptzCfg.bin filelen=49015 filepos=18263062 checksum=270591
File 21 recover_mtd filelen=14269 filepos=18312077 checksum=1018725
File 22 sound.tar.gz filelen=145562 filepos=18326346 checksum=19361699
File 23 t1 filelen=23900 filepos=18471908 checksum=2497827
 
Sorry, but I don't understand.
This fixup method is for R0 IP cameras, not for a DVR.
Please explain a little more.

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
 
it looks like it needs some files i dont have?
mImage is the 'min-system image' - a key part of the firmware update process, and from the flash area that's giving the bad block read errors.
I'm not sure if this can be derived in the same way as I have done for G1 series - but if it can be, attached are a couple of candidates to try, when copied and renamed as mImage
The 'new' one will still have the anti-rollback block built in.
 

Attachments

mImage is the 'min-system image' - a key part of the firmware update process, and from the flash area that's giving the bad block read errors.
I'm not sure if this can be derived in the same way as I have done for G1 series - but if it can be, attached are a couple of candidates to try, when copied and renamed as mImage
The 'new' one will still have the anti-rollback block built in.

Ok tried flashing it... no luck.. might flick it in the bin :)
Code:
HKVS # upm
[ INFO][BLD]TFTP: MAC: c0:56:e3:f7:22:d5
[ INFO][BLD]TFTP: TFTP from server 192.0.0.128; our IP address is 192.0.0.64
[ INFO][BLD]TFTP: Filename: 'mImage'
[ INFO][BLD]TFTP: ################################################################################
[ INFO][BLD]TFTP: ################################################################################
[ INFO][BLD]TFTP: ################################################################################
[ INFO][BLD]TFTP: ################################################################################
[ INFO][BLD]TFTP: ################################################################################
[ INFO][BLD]TFTP: #########
[ INFO][BLD]TFTP: File size is 10485760 bytes (10240 KB)
[ INFO][BLD]TFTP: Download File [OK]
[ INFO][BLD]BURN: Writing Flash
[ INFO][BLD]BURN: ..check bad block failed >> read spare data error.
initial bad block. <block 68>
Try next block...
.......[ERROR][BLD]BURN: Write Flash [FAIL]! error: write flash.
HKVS # upa
[ INFO][BLD]TFTP: MAC: c0:56:e3:f7:22:d5
[ INFO][BLD]TFTP: TFTP from server 192.0.0.128; our IP address is 192.0.0.64
[ INFO][BLD]TFTP: Filename: 'app.img'
[ERROR][BLD]TFTP: do_tftp_load:bld_udp_recv RRQ failed!rval=-110
[ERROR][BLD]TFTP: do_tftp_load:bld_udp_recv RRQ failed!rval=-110
[ERROR][BLD]TFTP: do_tftp_load:transfer error
cmd_update_app:do_tftp_load failed!
HKVS # upr
[ INFO][BLD]TFTP: MAC: c0:56:e3:f7:22:d5
[ INFO][BLD]TFTP: TFTP from server 192.0.0.128; our IP address is 192.0.0.64
[ INFO][BLD]TFTP: Filename: 'hroot.img'
[ INFO][BLD]TFTP: ################################################################################
[ INFO][BLD]TFTP: ##################
[ INFO][BLD]TFTP: File size is 2510644 bytes (2451 KB)
img img_len is 0x002ec67c
write partition [11]
...img img_len is 0x002ec67c
write partition [12]
...HKVS # upk
[ INFO][BLD]TFTP: MAC: c0:56:e3:f7:22:d5
[ INFO][BLD]TFTP: TFTP from server 192.0.0.128; our IP address is 192.0.0.64
[ INFO][BLD]TFTP: Filename: 'hImage'
[ INFO][BLD]TFTP: ################################################################################
[ INFO][BLD]TFTP: ################################################################################
[ INFO][BLD]TFTP: ######################################
[ INFO][BLD]TFTP: File size is 5068452 bytes (4949 KB)
img img_len is 0x0055b844
write partition [9]
.....img img_len is 0x0055b844
write partition [10]

▒KVS # reset

U-Boot 1.3.4-100728 (Nov 11 2014 - 13:58:34)

ARM Clock: 480MHz
DDR Clock: 336MHz
Hit Ctrl+u to stop autoboot: 0
|RCV UDP pack timeout|
Unknown command:null
nand booting ...
load kernel...
load ramdisk...
init started: BusyBox v1.19.3 (2013-11-01 10:10:26 CST)
starting pid 375, tty '': '/etc/init.d/rcS'
Starting udev:      [ OK ]
starting pid 606, tty '': '/sbin/iptables -A INPUT -p tcp --dport 23 -j DROP'
starting pid 607, tty '': '/sbin/iptables -A INPUT -p tcp --dport 21 -j DROP'
starting pid 608, tty '': '/sbin/inetd -f -e /etc/inetd.conf'
starting pid 609, tty '': '-/bin/sh'


BusyBox v1.19.3 (2013-11-01 10:10:26 CST) built-in shell (ash)
Enter 'help' for a list of built-in commands.

UBI device number 1, total 192 LEBs (24772608 bytes, 23.6 MiB), available 0 LEBs (0 bytes), LEB size 129024 bytes (126.0 KiB)
waiting for /dev/ubi1_0.
Check dir /dav ok! (0)
UBI device number 3, total 32 LEBs (4128768 bytes, 3.9 MiB), available 0 LEBs (0 bytes), LEB size 129024 bytes (126.0 KiB)
waiting for /dev/ubi3_0.
Check dir /davinci ok! (0)
UBI device number 4, total 31 LEBs (3999744 bytes, 3.8 MiB), available 0 LEBs (0 bytes), LEB size 129024 bytes (126.0 KiB)
waiting for /dev/ubi4_0.
Check dir /config ok! (0)
Hit Ctrl+c to stop and exec /home/initrun.sh to continue
route: ioctl 0x890c failed: No such process
/home/initrun.sh: line 16: lzma: not found
chmod: /home/process/net_process: No such file or directory
mount: mounting none on /proc/bus/usb failed: No such file or directory
/dav
map_size = 0x300000
nr_item = 3
addr_offset = 0x0 filename = orccode.bin
addr_offset = 0x200000 filename = orcme.bin
addr_offset = 0x2a0000 filename = default_binary.bin
mmap returns 0x40252000
loading ./orccode.bin...addr = 0x40252000, size = 0x1a0a91
loading ./orcme.bin...addr = 0x40452000, size = 0x3a4fc
loading ./default_binary.bin...addr = 0x404f2000, size = 0x40000
===============================
u_code version = 2016/4/6 3.0
===============================
The system is going down NOW!
Terminated
[1]+  Terminated                 /usr/sbin/guard.sh
Sent SIGTERM to all processes
Sent SIGKILL to all processes
Requesting system reboot

mark bad block failed >> read spare data error.
read spare failed. <block 1023, page 0 >
mark bad block failed >> read spare data error.
read spare failed. <block 1022, page 0 >
check bad block failed >> read spare data error.
check bad block failed >> read spare data error.
check bad block failed >> read spare data error.

U-Boot 1.3.4-100728 (Nov 11 2014 - 13:58:34)

ARM Clock: 480MHz
DDR Clock: 336MHz
Hit Ctrl+u to stop autoboot: 0
begin to enter mini system
 check bad block failed >> read spare data error.
▒

U-Boot 1.3.4-100728 (Nov 11 2014 - 13:58:34)

ARM Clock: 480MHz
DDR Clock: 336MHz
Hit Ctrl+u to stop autoboot: 2
HKVS # upf
***** UPDATE START *****
[ INFO][BLD]TFTP: MAC: c0:56:e3:f7:22:d5
[ INFO][BLD]TFTP: TFTP from server 192.0.0.128; our IP address is 192.0.0.64
[ INFO][BLD]TFTP: Filename: 'mImage'
[ INFO][BLD]TFTP: ################################################################################
[ INFO][BLD]TFTP: ################################################################################
[ INFO][BLD]TFTP: ################################################################################
[ INFO][BLD]TFTP: ################################################################################
[ INFO][BLD]TFTP: ################################################################################
[ INFO][BLD]TFTP: #########
[ INFO][BLD]TFTP: File size is 10485760 bytes (10240 KB)
[ INFO][BLD]TFTP: Download File [OK]
[ INFO][BLD]BURN: Writing Flash
[ INFO][BLD]BURN: ..check bad block failed >> read spare data error.
initial bad block. <block 68>
Try next block...
.......[ERROR][BLD]BURN: Write Flash [FAIL]! error: write flash.
[ERROR][BLD]BURN: update mini system [FAIL]!error: upf.
!!!!! UPDATE FAIL !!!!!
 
also tried this:

(any idea what happens if i try an erase all command etc)
Code:
HKVS # erase bbt
erase bad block table...
Bad block table found at block 1021, page 0 , version 0x00000001
Bad block table found at block 1020, page 0 , version 0x00000001

HKVS # upf
***** UPDATE START *****
[ INFO][BLD]TFTP: MAC: c0:56:e3:f7:22:d5
[ INFO][BLD]TFTP: TFTP from server 192.0.0.128; our IP address is 192.0.0.64
[ INFO][BLD]TFTP: Filename: 'mImage'
[ INFO][BLD]TFTP: ################################################################################
[ INFO][BLD]TFTP: ################################################################################
[ INFO][BLD]TFTP: ################################################################################
[ INFO][BLD]TFTP: ################################################################################
[ INFO][BLD]TFTP: ################################################################################
[ INFO][BLD]TFTP: #########
[ INFO][BLD]TFTP: File size is 10485760 bytes (10240 KB)
[ INFO][BLD]TFTP: Download File [OK]
[ INFO][BLD]BURN: Writing Flash
[ INFO][BLD]BURN: ..check bad block failed >> read spare data error.
initial bad block. <block 68>
Try next block...
.......[ERROR][BLD]BURN: Write Flash [FAIL]! error: write flash.
[ERROR][BLD]BURN: update mini system [FAIL]!error: upf.
!!!!! UPDATE FAIL !!!!!
HKVS # erase bbt
erase bad block table...
Bad block table not found!
Bad block table not found!

HKVS # upf
***** UPDATE START *****
[ INFO][BLD]TFTP: MAC: c0:56:e3:f7:22:d5
[ INFO][BLD]TFTP: TFTP from server 192.0.0.128; our IP address is 192.0.0.64
[ INFO][BLD]TFTP: Filename: 'mImage'
[ INFO][BLD]TFTP: ################################################################################
[ INFO][BLD]TFTP: ################################################################################
[ INFO][BLD]TFTP: ################################################################################
[ INFO][BLD]TFTP: ################################################################################
[ INFO][BLD]TFTP: ################################################################################
[ INFO][BLD]TFTP: #########
[ INFO][BLD]TFTP: File size is 10485760 bytes (10240 KB)
[ INFO][BLD]TFTP: Download File [OK]
[ INFO][BLD]BURN: Writing Flash
[ INFO][BLD]BURN: ..check bad block failed >> read spare data error.
initial bad block. <block 68>
Try next block...
.......[ERROR][BLD]BURN: Write Flash [FAIL]! error: write flash.
[ERROR][BLD]BURN: update mini system [FAIL]!error: upf.
!!!!! UPDATE FAIL !!!!!
HKVS #

Code:
HKVS # killb 68
NAND partition info:
Partition [bst]: from block (0) to block (0)
Partition [ptb]: from block (1) to block (8)
Partition [bld]: from block (9) to block (16)
Partition [hal]: from block (17) to block (24)
Partition [ano_ptb]: from block (25) to block (32)
Partition [env]: from block (33) to block (36)
Partition [param]: from block (37) to block (40)
Partition [dpt]: from block (41) to block (48)
Partition [rcvy]: from block (49) to block (128)
Partition [krn_pri]: from block (129) to block (192)
Partition [krn_sec]: from block (193) to block (256)
Partition [rmd_pri]: from block (257) to block (288)
Partition [rmd_sec]: from block (289) to block (320)
Partition [app_pri]: from block (321) to block (512)
Partition [app_sec]: from block (513) to block (704)
Partition [cfg_pri]: from block (705) to block (736)
Partition [cfg_sec]: from block (737) to block (768)
Partition [dbg]: from block (769) to block (896)
Note: will break block in partition [rcvy]
running killb stress test on block (68) ...
press space key to terminate!
check bad block failed >> read spare data error.
initial bad block. <block 68>
Try next block...

Test Finished because of bad block!
Total test count is 0x00000000
HKVS #
 
Well, you've certainly explored loads of options to try to recover the problem.
But it looks like it all comes down to a part-failed flash area leaving no spares.

Note: will break block in partition [rcvy] running killb stress test on block (68) ... press space key to terminate! check bad block failed >> read spare data error. initial bad block. <block 68>
Interesting - killb is not a command I've ever used - maybe seemed too drastic.
The command gives an interesting view of the flash layout and partitions, and confirms the bad block is in the partition where the min-system recovery environment is located.
This is the code that gets booted by the tftp update process.
I'm pretty sure that the web-based update process doesn't use that - it has its own update code.

A stray thought occurs to me (despite knowing that the value of the effort put in to fix up a problem can often far exceeds the cost of simply buying a replacement - but we do it for other reasons) that a way in might be a tftp boot of a uImage, to get a running environment from which flash areas (but not the rcvy one) can be restored.
I used that on a couple of G0 cameras where the flash apart from the bootloader had been erased.
 
@alastairsteveson thanks mate you are a legend. I have 4x Chinese 3332-I that i was having issues with. Upgraded 1 and monitored it for a while and its working a treat. 3 more to go.
I had a small issue with my QNAP not logging on to the upgraded camera, but i tried an alternative device and it worked, and then when i went back to the original QNAP it was fine. No idea what happened.
Thanks again.
 
  • Like
Reactions: alastairstevenson
thank you so much for this. i have 2 chinese 2cd2432-ifw cameras and accidently updated them tonight not thinking about this problem. after a few hours i was able to recover both and get them on 5.4.5. The only hiccup i had was stage 3 wouldn't work using 5.4.5 so i found a version of 5.3.0 and then was able to complete the upgrade. thank you again.
 
  • Like
Reactions: alastairstevenson
(any idea what happens if i try an erase all command etc)
It depends on whether you re-boot before re-writing the bootloader ...
I did that once - the result is a truly bricked camera that was only recovered by unsoldering and replacing the flash memory chip with one that still had valid data.
Allegedly there is a low-level 'fast boot' facility burnt in to the CPU, but it needs an SDK tool and some specific startup values on a couple of pins to use it, but Hikvision apparently don't have this enabled.

Does wa=Western Australia?
 
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 (brick_fixv2.zip).
  • 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

Resource List
Step By Step Guide:
Here are the steps to take when using the brick-fixV2 tool to recover a bricked camera, and running the fixup script to change the camera to English / upgradeable. The camera doesn't have to be bricked to run the brick-fix tool if all that's required is a helping hand doing the 'enhanced mtd hack'.
  1. Create a folder on the local drive of your Windows PC to hold the Hikvision tftp updater, the chosen tftp server program (e.g. jouinin.net version), the unzipped 'brick-fixV2' files, and the Hikvision firmware to use for updating. The HxD hex editor should be installed on the PC.
  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.
  3. Make a copy of brickfixV2EN and name it as digicap.dav If the EN version does not work, e.g. "System update completed" is not displayed in step 5 or you don't get the login prompt when trying to telnet in step 8, try the CN version.
  4. Start the Hikvision tftp updater tftpserve.exe and if a Windows firewall popup appears, click OK to accept what the program needs.
  5. Power on the camera and observe the status messages in the tftp updater. Hopefully you will see 'System update completed' after 2 or 3 minutes.
  6. Close the Hikvision tftp updater, delete the digicap.dev file from step 3 and make a copy of the Hikvision firmware to use for updating and name it digicap.dav.
  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.
  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.
  9. Start the normal tftp server (not the Hikvision tftp updater). If it's the jouinin.net version, the program is tftpd32.exe

    At this point, Stage 1 of 3 is ready to be executed.
    At the telnet command prompt, type:
    /dav/fixup.sh
    and watch the on-screen messages.​

    • On success with Stage 1, check the PC folder that the tftp server is running in for the presence of the file 'mtd6ro_orig'. You may have to hit F5 to refresh. Make a copy of mtd6ro_orig rename to mtd6ro_mod. Do the 'enhanced mtd hack' on it, using the instructions in the spoiler below.
    These are the steps that are used to do the 'enhanced mtd hack' to mtdblock6 in an R0 IP camera.
    • Extract a copy of mtdblock6 from the camera. The 'Brick-fixV2 tool / fixup script' will conveniently do this for you, or it could be done manually by other methods.
    • Make a copy of the mtdblock6 file and name it mtd6ro_mod
    • Open it with the HxD hex editor.
    • Referring to this image
      View attachment 24161
    • Check / change as needed the language byte at location 0x10 to ensure it is 01
    • Check the devType value in locations 0x64 and 0x65
    If the value shown is FF98 - then the FF value needs to be replaced with the true numeric value. Ideally the true value is determined from the 'devType' line from the prtHardInfo shell command, but as that is going to be unavailable on a bricked camera use this (partial) cross-reference list, paying careful attention to the exact model number.

    There is some slight uncertainty here - it would be good if any forum members could confirm / supplement the content.

    devType - Model
    2698 - DS-2CD2032F-I
    2698 - DS-2CD2032F-IW
    0598 - DS-2CD2032-I
    0698 - DS-2CD2132-I
    1E98 - DS-2CD2132F-IS
    1E98 - DS-2CD2132F-IWS
    0798 - DS-2CD2232-I5
    0898 - DS-2CD2332-I
    1298 - DS-2CD2432F-IW
    1498 - DS-2CD2532F-IS
    1098 - DS-2CD2632F-IS
    0E98 - DS-2CD2732F-IS
    0698 - DS-2CD3132-I
    1C23 - DS-2DE2103-DE3/W​

    • Replace the FF in location 0x64 with the first 2 digits of the numeric devType value.
    • If location 0x64 already has a 2-digit numeric value, no change is needed.
    • Starting at location 0x09, drag to select and highlight a length of F4 bytes, as shown he the HxD bottom status bar.
    Using the Analysis / Checksum menu, double-click Checksum-16 to calculate the new checksum. This will show as a 2 byte value in the Checksums tab at the bottom of the screen. These need to be applied using the correct 'endian-ness', which is the reverse of how the values are presented on the screen.

    The left hand byte (0x0C in the screenshot) is the most significant byte and should be used in location 0x05

    The right hand byte (0x5F in the screenshot) is the least significant byte and should be used in location 0x04

    Use your own just-calculated values - not those from the screenshot.

    Click File | Save and the mtd6ro_mod file has had the 'enhanced mtd hack' and is ready to be applied to the camera.

    This is done during Stage 2 of the fixup script in the brick-fixV2 tool.​

    Good luck!

    At this point, Stage 2 of 3 is ready to be executed.
    At the telnet command prompt, type:
    /dav/fixup.sh
    and watch the on-screen messages.

    This will bring in the modified mtd6ro_mod and apply it to the camera to convert it to English / upgradeable.

    At this point, Stage 3 of 3 is ready to be executed.
    At the telnet command prompt, type:
    /dav/fixup.sh
    and watch the on-screen messages.

    This will attempt a firmware update using the Hikvision firmware file digicap.dav that you placed in the same folder as the tftp server.​
  10. Assuming a successful result, shut down the tftp server and power cycle the camera. Interestingly, on testing I did find that a straight jump to the 5.4.5 firmware version worked OK. YMMV. But worth trying.
  11. Start SADP and check for the camera presence running the firmware version used for the update.
  12. If you used the 5.4.5 firmware, the camera will require 'activation' with your choice of strong password.
    If already active, if earlier firmware was used for the upgrade, log in with the admin password=12345
    Change the IP address to what you want the camera to use.
How To Upgrade
  1. Rename the firmware to digicap.dav
  2. Put the firmware under the same folder of this TFTP
  3. Set the IP of computer as 192.0.0.128
  4. Camera's IP can be anyone.
  5. Run the tftpserv.exe
  6. Power off and power on the DVR/DVS/IPC. The device will search the new firmware and upgrade it automatically.
  7. Please wait until TFTP shows "Device [192.0.0.64] system update completed!" It takes about 5 minutes.
  8. Close the TFTP before the camera reboots.
  9. DVR/DVS/IPC will restart automatically after upgrading.





Can i use this method for unbrix Hikvison DVR ds7204hqhi k.
 
It depends on whether you re-boot before re-writing the bootloader ...
I did that once - the result is a truly bricked camera that was only recovered by unsoldering and replacing the flash memory chip with one that still had valid data.
Allegedly there is a low-level 'fast boot' facility burnt in to the CPU, but it needs an SDK tool and some specific startup values on a couple of pins to use it, but Hikvision apparently don't have this enabled.

Does wa=Western Australia?

yeah western aust.
im giving up with this camera its going in the bin :)