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

alastairstevenson · Apr 14, 2020

Well done, and thanks for sharing!

yuan0420 · Apr 15, 2020

camera: DS-2CD3T25-I3
V5.5.80 build 180912
I stuck in the step 2, [2020-04-15 14:25:05] TFTP server[192.0.0.128] initialized, and no further reaction.
could anyone klindly tell me what should I do ?

alastairstevenson · Apr 15, 2020

That's not an R0 series camera. The brickfixV2 method should not be attempted on it.

What are you trying to do, and what problem are you trying to deal with?

yuan0420 · Apr 15, 2020

alastairstevenson said:
That's not an R0 series camera. The brickfixV2 method should not be attempted on it.

What are you trying to do, and what problem are you trying to deal with?

Thank you for your quick reply.
yes. I am trying to solve the language problem as well. chinese camera

alastairstevenson · Apr 15, 2020

alastairstevenson said:
That's not an R0 series camera. The brickfixV2 method should not be attempted on it.

yuan0420 said:
I stuck in the step 2, [2020-04-15 14:25:05] TFTP server[192.0.0.128] initialized, and no further reaction.

What firmware are you trying to install?

yuan0420 · Apr 15, 2020

alastairstevenson said:
What firmware are you trying to install?

my cameras cannot be found by NVR. The camera is Chinese. NVR is multilingual. so I am trying to change the language of my cameras, so that i can use these.

alastairstevenson · Apr 15, 2020

You would need to have 'hacked to English' firmware to convert that camera to EN, as far as I know.
I do not believe it is an R0 series camera.
Maybe someone else can comment.

dark · Apr 20, 2020

Hi All,

Just working my way through your amazing work, having upgraded the wrong camera and bricked my Chinese 2CD2332-I :-(

The world is slightly complicated because I have no windows machine here (lots of mac/linux ... but no Microsoft unless I install a virtual machine up)

So one observation; For some reason /dav/fixup_stage1.txt didn't exist and I had to create it.

.. and a question: How is the checksum calculated? I have linux hex editors but nothing to run the windows one on.

Thanks!

alastairstevenson · Apr 20, 2020

dark said:
The world is slightly complicated because I have no windows machine here (lots of mac/linux ... but no Microsoft unless I install a virtual machine up)

OK, so how did you do the initial brickfixV2 firmware install, which needs the Hikvision tftp updater? (assuming no access to the serial console)
Maybe Scott Lamb's Python-based emulator?
Beyond Stage 1 you just need a telnet client and a normal tftp server.

dark said:
So one observation; For some reason /dav/fixup_stage1.txt didn't exist and I had to create it.

This is created on the first reboot after the brickfixV2 firmware has been installed, by this script.

Code:

#!/bin/sh
if [ -e /dav/notice ]; then
    echo "[Brick-fix tool] Initialising fixup_log.txt" > /dav/fixup_log.txt
    echo "Hello Hikvision! Enabling rollback ..."
    cat /dav/notice > /dev/mtdblock8
    rm /dav/notice
    echo "Enabled."
    echo "Payload dropped, rollback re-enabled" >> /dav/fixup_log.txt
    echo "Initialising fixup current status to stage1" >> /dav/fixup_log.txt
    rm /dav/fixup_stage?.txt
    echo "Fixup stage1 completed - rollback payload dropped" > /dav/fixup_stage1.txt
fi
echo "[Brick-fix tool] Initiating reboot into min-system " >> /dav/fixup_log.txt
/usr/sbin/set_sysflag -m 1
/sbin/reboot

And the checksum - it's the 16-bit sum of the 0xf4 bytes from location 0x09 in mtd6ro - a Checksum-16 value.

dark · Apr 20, 2020

Hi

Replacement for the TFTP hikvision tool was standard tftp server (to send brickfixv2CN.dav) + little python script that responds to the hikvision handshake on udp 9978
epol/script

Not sure how the fixup_stage1.txt file vanished previously ... seems to be ok on a re-run. Exact details below just for future reference ...

(having just done this again);

Start UDP Responder
Copy brickfixv2CN.dav to digicap.dav
Start tftp server
Boot camera

(UDP Responder gets SWKH message from port 9979)
- digicap.dav requested via TFTP
(UDP Responder gets SWKH message from port up in the 50k+)
- Stop UDP responder

- Telnet to camera on 192.0.0.64 check that /dav/notice is there ... reboot camera
(wait)
- Telnet to camera on 192.0.0.64 check that /dav/notice is no longer there and fixup_stage1.txt is.

- run /dav/fixup.sh
(mtd6ro_orig & mtd1ro_orig sent to tftp server)

So seems much happier this time round.

Will have a look at calculating the checksum. Trying to checksum the mtd6ro_orig file gives me values different to those in it, so presumably my maths is out somewhere :-(. If i can get it to agree I'll throw the script back here.

Thanks, Mark

alastairstevenson · Apr 20, 2020

dark said:
Trying to checksum the mtd6ro_orig file gives me values different to those in it, so presumably my maths is out somewhere

Not necessarily - on earlier firmware the checksum wasn't checked and could be wrong in mtd6.
I've attached a couple of valid samples for you to check.

dark said:
Replacement for the TFTP hikvision tool was standard tftp server (to send brickfixv2CN.dav) + little python script that responds to the hikvision handshake on udp 9978
epol/script

I'm impressed!
I think you are enjoying this.
Thanks for sharing.

dark said:
mtd1ro_orig sent to tftp server

A bit of a hangover - the original brickfix required that some mtd1 get a tweak as they were interpreted as an indication of prior update failure, so the camera reboots into recovery. But in brickfixV2 I get it overwritten with a valid template to save the user some effort.

dark · Apr 21, 2020

alastairstevenson said:
I've attached a couple of valid samples for you to check.

Hi ... so I've submitted and installed a virtual windows machine with HxD on it ... well didn't have much else to do overnight

Checksum Location bytes 0x04 -> 0x05
Checksummed Offset 0x9
Checksummed Range 0x09 -> 0xFC
Checksummed Length 0xF4

One thing which caught me is that the checksum generation isn't "live". For each one you need to;

load file
highlight selection
select Analysis -> Checksums -> Checksum 16 -> Selected Data -> OK

If you're doing multiple files the checksum on the bottom panel can change but is not always correct!

Verification of the valid sample files you kindly provided. (JPGs attached);

Name	Checksum from HxD	Byte Swapped from HxD	Checksum in File
mtd6ro_mod_1	0C D2	D2 0C	D2 0C
mtd6ro_mod_2	0D 5B	5B 0D	5B 0D
mtd6ro_mod_3	09 A6	A6 09	A6 09
mtd6ro_mod_4	09 A4	A4 09	A4 09
mtd6ro_mod_5	0D 21	21 0D	21 0D

dark · Apr 21, 2020

So now that I've worked out what hikvisions checksum is actually doing here's a, rather wordy, linux script to calc the checksum

https://github.com/darkorigins/hikvision/blob/master/scripts/mtd_checksum.sh

$ ./mtd_checksum.sh mtd6/mtd6ro_mod_1
HikVision Checksum : D2 0C

$ ./mtd_checksum.sh mtd6/mtd6ro_mod_2
HikVision Checksum : 5B 0D

$ ./mtd_checksum.sh mtd6/mtd6ro_mod_3
HikVision Checksum : A6 09

$ ./mtd_checksum.sh mtd6/mtd6ro_mod_4
HikVision Checksum : A4 09

$ ./mtd_checksum.sh mtd6/mtd6ro_mod_5
HikVision Checksum : 21 0D

... off to try it now

dark · Apr 21, 2020

All worked fine. Managed to mod the DS-2CD2332-I using devType 08 98 and then directly to v5.4.5 (US English) from;

https://us.hikvision.com/sites/default/files/firmware/ipc_2xx2_en_std_5.4.5_170123.zip

Serial still has reference to CCCH serial.

Device details attached for reference.

Thanks all ... !

@alastairstevenson Wondering if the shell on the device (ash?) is up to doing the checksum / writing a binary file. At which point hex editor etc isn't required.

alastairstevenson · Apr 21, 2020

dark said:
So now that I've worked out what hikvisions checksum is actually doing here's a, rather wordy, linux script to calc the checksum

Nice one. Well done, and thanks for sharing.

dark said:
Wondering if the shell on the device (ash?) is up to doing the checksum / writing a binary file. At which point hex editor etc isn't required.

Unlikely, it's limited - but interesting to try.
busybox, despite being pretty good, provides just a subset of bash capability.
This from a DS-2CD2432F-IW with a slightly better busybox than is in the stock firmware.

Code:

alastair@PC-I5 ~ $ ssh admin@192.168.1.105
admin@192.168.1.105's password:
repacked


BusyBox v1.19.3 (2017-01-13 20:51:32 CST) built-in shell (ash)
Enter 'help' for a list of built-in commands.

# prtHardInfo
Start at 2020-04-19 16:54:07
Serial NO :DS-2CD2432F-IW20141105CCCH487719881
V5.4.5 build 170123
NetProcess Version: 1.6.1 [17:24:18-Jan 13 2017]
Db Encrypt Version: 65537
hardwareVersion    = 0x0
hardWareExtVersion    = 0x0
encodeChans        = 1
decodeChans        = 1
alarmInNums        = 1
alarmOutNums        = 1
ataCtrlNums        = 0
flashChipNums        = 0
ramSize            = 0x4000000
networksNums        = 1
language            = 1
devType            = 0x9812
net reboot count    = 0
Path: .
Working Copy Root Path: /usr/local/jenkins/workspace/Frontend_BaseLine_Publish_Build_InterfaceII/2539
URL: https://192.0.0.140/Camera/Platform/Branches/branches_frontend_software_platform/IPC_develop_branch/ipc_5.4.0_R0
Repository Root: https://192.0.0.140/Camera
Repository UUID: df2d70c3-7593-7941-af1e-571b313c0946
Revision: 253120
Node Kind: directory
Schedule: normal
Last Changed Author: liudan9
Last Changed Rev: 253065
Last Changed Date: 2017-01-23 17:45:28 +0800 (Mon, 23 Jan 2017)

#
#
#
# cd /home
# df -h
Filesystem                Size      Used Available Use% Mounted on
rootfs                    7.9M      7.6M    342.0K  96% /
/dev/root                 7.9M      7.6M    342.0K  96% /
udev                     46.3M     76.0K     46.3M   0% /dev
/dev/ubi1_0              19.8M     13.2M      5.6M  70% /dav
/dev/ubi3_0               1.3M    160.0K      1.0M  13% /davinci
/dev/ubi4_0               1.3M    132.0K      1.0M  11% /config
#
# mount
rootfs on / type rootfs (rw)
/dev/root on / type ext2 (rw,relatime)
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
ramfs on /home type ramfs (rw,relatime)
udev on /dev type tmpfs (rw,relatime)
devpts on /dev/pts type devpts (rw,relatime,mode=600)
/dev/ubi1_0 on /dav type ubifs (rw,relatime)
/dev/ubi3_0 on /davinci type ubifs (rw,relatime)
/dev/ubi4_0 on /config type ubifs (rw,relatime)
#
# ls -al /mnt
drwxrwxrwx   13 root     root          1024 Jan 13  2017 .
drwxr-xr-x   20 root     root          1024 Apr 21  2020 ..
drwxrwxrwx    2 root     root          1024 Jan 13  2017 mmc01
drwxrwxrwx    2 root     root          1024 Jan 13  2017 mmc02
drwxrwxrwx    2 root     root          1024 Jan 13  2017 nfs0
drwxrwxrwx    2 root     root          1024 Jan 13  2017 nfs00
drwxrwxrwx    2 root     root          1024 Jan 13  2017 nfs01
drwxrwxrwx    2 root     root          1024 Jan 13  2017 nfs02
drwxrwxrwx    2 root     root          1024 Jan 13  2017 nfs03
drwxrwxrwx    2 root     root          1024 Jan 13  2017 nfs04
drwxrwxrwx    2 root     root          1024 Jan 13  2017 nfs05
drwxrwxrwx    2 root     root          1024 Jan 13  2017 nfs06
drwxrwxrwx    2 root     root          1024 Jan 13  2017 nfs07
# mount -t nfs -o nolock 192.168.1.201:/cctv1 /mnt/nfs00
# ls -al /mnt/nfs00/c*.sh
-rwxrwxrwx    1 503      100           1579 Apr 21 15:41 /mnt/nfs00/checksum.sh
#
#
# cat /dev/mtd6ro > mtdfile
# ls -al
drwxr-xr-x    6 root     root             0 Apr 21 16:56 .
drwxr-xr-x   20 root     root          1024 Apr 21 16:38 ..
drwxr-xr-x    2 root     root             0 Apr 19 16:53 applib
-rwxrwxrwx    1 root     root          6674 Apr 19 16:53 initrun.sh
-rw-r--r--    1 root     root        524288 Apr 21 16:56 mtdfile
----------    1 root     root             0 Apr 19 16:53 pidfile
drwxr-xr-x    2 root     root             0 Apr 19 16:53 process
drwxr-xr-x    2 3008     3008             0 Apr 19 16:53 sound
drwxr-xr-x    5 root     root             0 Apr 19 16:53 webLib
#
# /mnt/nfs00/checksum.sh mtdfile
/mnt/nfs00/checksum.sh: line 43: syntax error: bad for loop variable
#
# rm mtdfile
# umount /mnt/nfs00
# Connection to 192.168.1.105 closed.
alastair@PC-I5 ~ $

This is the line it balked at :
for((_position=0;_position<$((0x09));_position++)) do read_a_byte; done
I think it's the arithmetic capabilities that's the limitation.

dark said:
Serial still has reference to CCCH serial.

Yes - that's because the Region is still set to China.
To change that, you could change byte 0x55 from 0x01 to 0x03 in mtd6 to change the Region to World.
But - beware - do not attempt that when the running environment is firmware 5.3.0 or later - there is a quite nasty Hikvision trap in the kernel to catch any messing with the bootpara block.
Should be OK to mod that in the min-system though.

A new Hikvision tripwire.

With apologies in advance for the TL;DR aspect: Unfortunately, not an improvement to their already quite good video analytics, but a cynical and nasty trap put in place to deliberately and permanently brick a camera where the 'mtd hack' has been attempted by a customer trying to make best use...

ipcamtalk.com

dark · Apr 21, 2020

I'll see if I simplify the maths down. The for loop should be easy but the printf's may be a different issue.

So on the firmware side: If we want to get it out of China region 5.2.5 is the last working firmware? Also if, like me, we've upgraded to 5.4.5 that'll probably explode if we do any further writes to mtd6?

alastairstevenson · Apr 21, 2020

dark said:
the printf's may be a different issue.

Does this suggest that it works well enough :

Code:

alastair@PC-I5 ~ $ ssh admin@192.168.1.105
admin@192.168.1.105's password:
repacked


BusyBox v1.19.3 (2017-01-13 20:51:32 CST) built-in shell (ash)
Enter 'help' for a list of built-in commands.

#
# set
HISTFILE='/.ash_history'
HOME='/'
IFS='     
'
LOGNAME='admin'
OPTIND='1'
PATH='/usr/bin:/bin'
PPID='7228'
PS1='# '
PS2='> '
PS4='+ '
PWD='/'
SHELL='/bin/psh'
SSH_CLIENT='192.168.1.99 35964 22'
SSH_CONNECTION='192.168.1.99 35964 192.168.1.105 22'
SSH_TTY='/dev/pts/0'
TERM='xterm-256color'
USER='admin'
#
# printf  "$PATH  Hello world\n"
/usr/bin:/bin  Hello world
#
# Connection to 192.168.1.105 closed.
alastair@PC-I5 ~ $

dark said:
So on the firmware side: If we want to get it out of China region 5.2.5 is the last working firmware? Also if, like me, we've upgraded to 5.4.5 that'll probably explode if we do any further writes to mtd6?

The current re-write of mtd6ro_mod was done under the min-system recovery environment that the brickfixV2 method installed.
That's still there - and does not have that trap inbuilt - and could be used again for the same purpose, applying a modded mtd6ro.

I don't think there is a simple way to trick the camera into going into recovery mode without the use of the serial console.
There might be - give it something it can't handle, that doesn't actually break it - but it's not something I've explored.

But there is no technical reason why a repeat of the brickfixV2 process can't be done, with the only change being the 0x55 region byte, and the checksum.

fedonas · Apr 21, 2020

Thank you very much for this guide!! I have successfully upgraded a Chinese 2CD2532 to the latest firmware!
Many, many thanks, great job, I appreciate!!

alastairstevenson · Apr 22, 2020

Well done, and thanks for sharing!

dark · Apr 22, 2020

alastairstevenson said:
Does this suggest that it works well enough :

You appear to be running a newer build of busybox there. The one I have from the brick_fixv2.zip is;

Code:

BusyBox v1.19.3 (2014-03-28 16:33:55 CST)

Which doesn't appear to have printf in it. It's also objecting to some of the read command. Looking at the tools in that build it's probably something which ought to be written as a C command and integrated in. Probably more work that it's worth ...

Search

Search

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

alastairstevenson

yuan0420

n3wb

alastairstevenson

yuan0420

n3wb

alastairstevenson

yuan0420

n3wb

alastairstevenson

dark

n3wb

alastairstevenson

dark

n3wb

alastairstevenson

Attachments

dark

n3wb

Attachments

dark

n3wb

dark

n3wb

Attachments

alastairstevenson

A new Hikvision tripwire.

dark

n3wb

alastairstevenson

fedonas

n3wb

alastairstevenson

dark

n3wb