alastairstevenson
Staff member
Well done, and thanks for sharing!
R0 / DS-2CD2x32 BrickfixV2 brick recovery and full upgrade tool - enhanced.
- Thread starter alastairstevenson
- Start date
alastairstevenson
Staff member
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?
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
Staff member
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
Staff member
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.
I do not believe it is an R0 series camera.
Maybe someone else can comment.
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!
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
Staff member
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.
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/rebootHi
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);
- 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
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
- 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
Staff member
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.
I'm impressed!
I think you are enjoying this.
Thanks for sharing.
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.
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 |
Attachments
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
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
Last edited:
All worked fine. Managed to mod the DS-2CD2332-I using devType 08 98 and then directly to v5.4.5 (US English) from;
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.
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.
Attachments
alastairstevenson
Staff member
Nice one. Well done, and thanks for sharing.
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.
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...
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?
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
Staff member
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 ~ $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.
alastairstevenson
Staff member
Well done, and thanks for sharing!
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)