Converting EZVIZ C6TC from Chinese to English

rikochet

n3wb
Joined
Sep 28, 2019
Messages
13
Reaction score
3
Location
/dev/null
Hi,

TLDR; I have installed US firmware on CN hardware but unable to connect to EZVIZ service.

I purchased a couple of C6TC (CS-C6TC-32WFR) IP cams from TaoBao in an attempt to save a few dollars. What I didn't realise was that the cameras are region locked and it requires a Chinese phone number to register the account and the Chinese Android app has to be installed by a sketchy Chinese app-store.

It goes without saying that I don't want to use these cameras on the Chinese network.

The best solution would be to use these devices locally, which I can do using RTSP.. However they are extremely crippled, all PTZ commands and other related functions are transmitted over a proprietary protocol. So what I want to do is try and install the EN firmware on the CN camera so that I can get full use of the cameras.

After some googling I managed to find this datasheet for the US version:
https://s3.amazonaws.com/mfs.ezvizlife.com/C6TC+Datasheet.pdf

AFAIK it's the US version of the C6TC and you can see in the header of the specifications on page 5 that the model number is CS-CV248-A0-32WFR.

I also found the location of some US firmware for a different model:
http://usdownload.ezvizlife.com/device/LV-PDB1630-U/2.0/LV-PDB1630-U.dav

So I just substituted the model numbers and came up with this working URL:
http://usdownload.ezvizlife.com/device/CS-CV248-A0-32WFR/2.0/CS-CV248-A0-32WFR.dav

After downloading the US firmware I tried to use the Windows EZVIZ Studio to upload the firmware to the device but was met with 'upload failed!'. I tried tinkering with the DAV file but to no avail, so decided to try something a little different!

I dismantled the camera and found that there is a Micro 4-pin JST connector with nothing attached! It was just my luck that it's a serial connector and the middle pins are TX and RX. I connected them up to my FTDI and gotroot!

I poked around for a bit but couldn't really achieve anything useful, I reset the device and escaped the boot sequence. U-boot had a command (update) which installs 'digicap.dav' from the microSD card.

I dropped the US firmware on an SD card and renamed it 'digicap.dav'. I inserted the card into the device, reset and then typed 'update'. The update failed with the error 'incorrect language'.

I searched the ipcamtalk forums and found hiktools, this allowed me to change the language of the dav file to Chinese. I dropped the updated file on the SD card and ran the update again.. IT WORKED!

The update installed, I reset the camera and English audio queues played! Great!

I opened up EZVIZ studio and tried to configure the device but was confronted with the message "It's not supported" which is different from the previous "The device has not been connected to the EZVIZ"..

This is where I'm currently at; a Chinese device (CS-C6TC-32WFR) running US firmware (CS-CV248-A0-32WFR).. but still unable to connect the device to the US EZVIZ network..

Any ideas?
 

rearanger

Getting the hang of it
Joined
Feb 10, 2016
Messages
224
Reaction score
96
Location
Scottish Borders
You need to alter the files live on the cam(if you have ASH). Or inject region unlock modification into digicap.dav


iMagicNum : 484B5753 (HKWS)
iChkSumU8 : 00002287
iHeadSize : 152
iFilesNum : 2
iLanguage : 1
iDeviceClass: 2
iOEMCode : -1
iFeature : FFFFFFFF
iFirmwareVer: FFFFFFFF
bPlatformId : 120
bFlashSize : 003
bMemerySize : 001
bMajorTypeId: 115
bMinorTypeId: 202
bLanguageId : 001 (EN/ML)
bSqlite3Flg : 1
root@john-pc:/media/sf_cctv/en# binwalk -e app.img

DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
0 0x0 Squashfs filesystem, little endian, version 4.0, compression:xz, size: 5521456 bytes, 73 inodes, blocksize: 262144 bytes, created: 2018-09-06 01:18:55

root@john-pc:/media/sf_cctv/en#

root@john-pc:/media/sf_cctv/en/_app.img.extracted# cd squashfs-root
root@john-pc:/media/sf_cctv/en/_app.img.extracted/squashfs-root# ls
8188eu.ko dhcpd.conf libbonjour.so libwolfssl.so t1
ASC16 execSystemCmd libezDevSDK_boot.so load_module.sh udhcpd
ASC32.bin flash_eraseall libezDevSDK_Common_Module.so mav_cal.conf usb8801.ko
bcm43143.ko fw_bcmdhd_r79.bin.trx libmicrokernel.so mfgutil usb8801_uapsta.bin
bcmdl gpio_test libnl-genl.so.2.0.0 mlan.ko voice
blogo.bin hi_cipher.ko libnl.so.2.0.0 mlogo.bin voice.tar.gz
certs.tar.gz hostapd libr2_isp.so nvram_wubb-738gn.nvm wpa_cli
da_info HZK16 libsqlite3.so r2_modules.tgz wpa_supplicant
davinci initrun.sh libusb-0.1.so slogo.bin
default.script ipchelper libusb-1.0.so step_motor.ko
root@john-pc:/media/sf_cctv/en/_app.img.extracted/squashfs-root#
 

alastairstevenson

Staff member
Joined
Oct 28, 2014
Messages
15,930
Reaction score
6,778
Location
Scotland
This is where I'm currently at; a Chinese device (CS-C6TC-32WFR) running US firmware (CS-CV248-A0-32WFR).. but still unable to connect the device to the US EZVIZ network..

Any ideas?
I had a look at the firmware that you linked to.
It just holds the Linux kernel and the root file system.
The .dav file unpacks OK with the @montecrypto repacker as a k41 or k51 device.
Unusually - the davinci program (the main app) is not encrypted, and is quite small.
That might just indicate also that there is minimal tamper protection built in.

A couple of suggestions, depending on your level of Linux / reverse engineering experience ...

The device may have it's hardware configuration stored in flash, in the classic Hikvision way.
Check out the flash layout in the serial console log and dump out all the partitions, maybe to the SD card.
These can be inspected with a hex editor for a block indicative of the classic 'bootpara block'.
Check for the 'HKWS' 'SWKH' magic number.
This may be able to have the devType or serial number usefully altered to provide what you are looking for.

More demanding in terms of reversing experience -
The davinci program could be patched to hard-code the devType independant of what's in the bootpara block.

I know there isn't much detail in the above - but it's going to depend on what you'd be comfortable doing.
 

rikochet

n3wb
Joined
Sep 28, 2019
Messages
13
Reaction score
3
Location
/dev/null
You need to alter the files live on the cam(if you have ASH). Or inject region unlock modification into digicap.dav
I have root ASH access via UART and have installed the US firmware with patched region to CN. Which files should I be live editing??

I had a look at the firmware that you linked to.
It just holds the Linux kernel and the root file system.
The .dav file unpacks OK with the @montecrypto repacker as a k41 or k51 device.
Unusually - the davinci program (the main app) is not encrypted, and is quite small.
That might just indicate also that there is minimal tamper protection built in.
I managed to locate a copy of @montecrypto repacker, seems to work better than the windows Hiktool - thanks!


A couple of suggestions, depending on your level of Linux / reverse engineering experience ...

The device may have it's hardware configuration stored in flash, in the classic Hikvision way.
Check out the flash layout in the serial console log and dump out all the partitions, maybe to the SD card.
These can be inspected with a hex editor for a block indicative of the classic 'bootpara block'.
Check for the 'HKWS' 'SWKH' magic number.
This may be able to have the devType or serial number usefully altered to provide what you are looking for.
My linux skills are average, although I have zero reversing experience but am keen to learn!

Here's the initial serial console log, is this the flash layout that you were referring to?

Code:
Uncompressing Linux... done, booting the kernel.
init started: BusyBox v1.22.1 (2018-09-05 11:32:22 CST)
8188eu.ko ASC16 ASC32.bin HZK16 bcm43143.ko bcmdl blogo.bin certs.tar.gz da_info davinci default.script dhcpd.conf execSystemCmd flash_eraseall fw_bcmdhd_r79.bin.trx gpio_test hi_cipher.ko hostapd initrun.sh ipchelper libbonjour.so libezDevSDK_Common_Module.so libezDevSDK_boot.so libmicrokernel.so libnl-genl.so.2.0.0 libnl.so.2.0.0 libr2_isp.so libsqlite3.so libusb-0.1.so libusb-1.0.so libwolfssl.so load_module.sh mav_cal.conf mfgutil mlan.ko mlogo.bin nvram_wubb-738gn.nvm r2_modules.tgz slogo.bin step_motor.ko t1 udhcpd usb8801.ko usb8801_uapsta.bin voice voice.tar.gz wpa_cli wpa_supplicant
mmz_start: 0x82400000, mmz_size: 28M
0x200f0040: 0x00000000 --> 0x00000002
0x200f0044: 0x00000000 --> 0x00000002
0x200f007c: 0x00000000 --> 0x00000001
0x200f0080: 0x00000000 --> 0x00000001
0x200f0084: 0x00000000 --> 0x00000001
0x200f0088: 0x00000000 --> 0x00000001
0x200f008c: 0x00000000 --> 0x00000002
0x200f0090: 0x00000000 --> 0x00000002
0x200f0094: 0x00000000 --> 0x00000001
0x2003002c: 0x000C4003 --> 0x000C4001
I did a quick search and found this postby you, should I use this a template? or am I barking up the wrong tree?

EDIT: I've dumped the /dev/mtdblock* using dd here
 
Last edited:

alastairstevenson

Staff member
Joined
Oct 28, 2014
Messages
15,930
Reaction score
6,778
Location
Scotland
is this the flash layout that you were referring to?
That isn't - but I see from your Dropbox files that you've successfully identified the partition layout (cat /proc/mtd) and from the root shell, dumped them all out.

And more than that - you've identified that mtdblock2 appears to hold the familiar Hikvision 'bootpara block' that holds the device-specific information.
And have attempted to modify it to change the model number!
But that's just a string representation, which won't do anything useful.

Looking at the original mtdblock2 - my observations :
At 0x10 the value 02 means 'CN' language as opposed to 01 which means 'EN'.
At 0x64 the devType is 0x22D7 (8919 decimal). This should correspond to the value shown for devType in the shell command prtHardInfo (assuming that does exist).
At 0x55 the region byte is 01 which indicates CN as opposed to 03 which means 'World'.
And at 0x04 the checksum-16 value of 0x0C6D matches the 0xF4 range of bytes after location 0x08

Attached here is a proposed modified mtdblock2 - changed to EN language, World region, with the checksum updated.
As an experiment - this could be applied to the device to convert it to an EN / World device.
If the modded file is on the SD card, the command to apply it at a root shell would be :

cat /mnt/mmc01/mtdblock2_updated > /dev/mtdblock2
There is some risk to trying this, though, depending on any tamper protection that may be built in to the kernel.
Please be aware that messing with the bootpara data might 'brick' the device.
On R0 cameras, Hikvision created a trap for any attempts to update the 'bootpara' block on firmware at or above 5.3.0
There may be similar protection built in to your device.
A recovery method could be if there are still enough useful commands in the bootloader to read and write to the flash memory.
Of interest would be to interrupt the bootloader (maybe Control-U, see the prompts) and use

Show the environment variables :
printenv

Show the commands :
help

It's your choice whether you experiment with an attempt to convert the device from CN to EN to see if that allows the account access you are looking for.
But it may be that it's the devType that's the key, as opposed to it being a CN or EN device.

Good luck!
 

Attachments

rikochet

n3wb
Joined
Sep 28, 2019
Messages
13
Reaction score
3
Location
/dev/null
At 0x10 the value 02 means 'CN' language as opposed to 01 which means 'EN'.
At 0x64 the devType is 0x22D7 (8919 decimal). This should correspond to the value shown for devType in the shell command prtHardInfo (assuming that does exist).
At 0x55 the region byte is 01 which indicates CN as opposed to 03 which means 'World'.
And at 0x04 the checksum-16 value of 0x0C6D matches the 0xF4 range of bytes after location 0x08
Thanks for this! How do you know the block layout and which bytes to change? Also unfortunately 'ptrHardInfo' is not a valid command.


Attached here is a proposed modified mtdblock2 - changed to EN language, World region, with the checksum updated.
As an experiment - this could be applied to the device to convert it to an EN / World device.
If the modded file is on the SD card, the command to apply it at a root shell would be :

cat /mnt/mmc01/mtdblock2_updated > /dev/mtdblock2
I tried to write the updated block file to mtd however I get a write error.. :(

Code:
/mnt/mmc01 # cat /mnt/mmc01/mtdblock2_updated > /dev/mtdblock2
cat: write error: Operation not permitted
I have added _dmesg.txt to the Dropbox, line 16 reads:
Code:
Kernel command line: mem=38M console=ttyAMA0,115200 init=/bin/sh mtdparts=hi_sfc:256k(bld)ro,64k(env),64k(enc)ro,64k(dp_info),3136k(sys),6m(app),512k(cfg),6m(backup)
One would assume that 64k(enc)ro means read-only..

Any ideas on how to make it writable?

EDIT:
I just found this post by you..
Well, that confirms that mtdblock2 does not have a mount point set, but the kernel has it tagged with a read-only attribute.
It will not be practical to be able to change that unfortunately.
That sucks a bit :/

Is it possible to inject this paraBlock into the dav? or can you think of any other possible solution? TIA
 
Last edited:

alastairstevenson

Staff member
Joined
Oct 28, 2014
Messages
15,930
Reaction score
6,778
Location
Scotland
One would assume that 64k(enc)ro means read-only..
Yes, it does. Pity. Simple but effective, telling the kernel to not allow writes.

Some potential ways round that, if Hikvision haven't already closed them off :
Interrupt the bootloader at startup.

Check the environment variables with
printenv

The kernel command line may be set with tha 'bootargs' variable.
(optimistic) See if it can be modified to omit the 'ro' with
Code:
setenv bootargs mem=38M console=ttyAMA0,115200 init=/bin/sh mtdparts=hi_sfc:256k(bld)ro,64k(env),64k(enc),64k(dp_info),3136k(sys),6m(app),512k(cfg),6m(backup)
saveenv
Though looking at the defaul variables in mtdblock1 the bootargs variable isn't being used for the partition definitions.

Interesting about the 'init-/bin/sh'
That's usually a sneaky way to inhibit the main app and get a root shell.

Also at the bootloader - see if there are any flash read/write comands still in there.
List the apparent commands with
help
 

rikochet

n3wb
Joined
Sep 28, 2019
Messages
13
Reaction score
3
Location
/dev/null
As suggested, I set the bootargs..

dmesg now outputs the following, so I guess the kernel is just appending the string an overriding the u-boot bootargs :facepalm:

Code:
Kernel command line: mem=38M console=ttyAMA0,115200 init=/bin/sh mtdparts=hi_sfc:256k(bld)ro,64k(env),64k(enc),64k(dp_info),3136k(sys),6m(app),512k(cfg),6m(backup) mtdparts=hi_sfc:256k(bld)ro,64k(env),64k(enc)ro,64k(dp_info),3136k(sys),6m(app),512k(cfg),6m(backup)
Here's the list of commands supported by the bootloader.. Hopefully you can find something useful in there!

Code:
HKVS # help
?       - alias for 'help'
base    - print or set address offset
bootm   - boot application image from memory
bootp   - boot image via network using BOOTP/TFTP protocol
cmp     - memory compare
cp      - memory copy
crc32   - checksum calculation
ddr     - ddr training function
ext2load- load binary file from a Ext2 filesystem
ext2ls  - list files in a directory (default /)
fatinfo - print information about filesystem
fatload - load binary file from a dos filesystem
fatls   - list files in a directory (default /)
format  - format flash except bootloader area
getinfo - print hardware information
go      - start application at address 'addr'
gos     - go xxx.bin thru serial
help    - print command description/usage
loadb   - load binary file over serial line (kermit mode)
loadk   - load kernel to DRAM
loady   - load binary file over serial line (ymodem mode)
loop    - infinite loop on address range
md      - memory display
mii     - MII utility commands
mm      - memory modify (auto-incrementing address)
mmc     - MMC sub system
mmcinfo - mmcinfo <dev num>-- display MMC info
mtest   - simple RAM read/write test
mw      - memory write (fill)
nm      - memory modify (constant address)
ping    - send ICMP ECHO_REQUEST to network host
printenv- print environment variables
protect - enable and disenable protect flash
rarpboot- boot image via network using RARP/TFTP protocol
reset   - Perform RESET of the CPU
saveenv - save environment variables to persistent storage
setenv  - set environment variables
sf      - SPI flash sub-system
tftp    - tftp  - download or upload image via network using TFTP protocol
upa     - update app image
update  - update digicap.dav
updateb - update bootloader
upf     - update firmware, format and update (factory use)
upk     - update uImage
usb     - USB sub-system
usbboot - boot from USB device
version - print monitor version
 

alastairstevenson

Staff member
Joined
Oct 28, 2014
Messages
15,930
Reaction score
6,778
Location
Scotland
You have sf that should allow read/write/erase of the flash.
And tftp to move data in and out.
That's promising.

I'll try and work up some commands for you.
Try sf by itself, or help sf to see what subset of commands are available.
 

rikochet

n3wb
Joined
Sep 28, 2019
Messages
13
Reaction score
3
Location
/dev/null
Code:
HKVS # help sf
sf - SPI flash sub-system

Usage:
sf probe [bus:]cs [hz] [mode]   - init flash device on given SPI bus
                                  and chip select
sf read addr offset len - read `len' bytes starting at
                                  `offset' to memory at `addr'
sf write addr offset len        - write `len' bytes from memory
                                  at `addr' to flash at `offset'
sf erase offset len             - erase `len' bytes from `offset'
Code:
HKVS # sf probe 0 0 0
16384 KiB hi_fmc at 0:0 is now current device
looking back at _dmesg.txt, the offsets should be as follows

Code:
Creating 8 MTD partitions on "hi_sfc":
0x000000000000-0x000000040000 : "bld"
0x000000040000-0x000000050000 : "env"
0x000000050000-0x000000060000 : "enc"
0x000000060000-0x000000070000 : "dp_info"
0x000000070000-0x000000380000 : "sys"
0x000000380000-0x000000980000 : "app"
0x000000980000-0x000000a00000 : "cfg"
0x000000a00000-0x000001000000 : "backup"
I tried the following, but have no idea what I am doing as I don't see the SWKH I was expecting..
Code:
HKVS # sf read 0x000000050000 0 10000

HKVS # md 0x000000050000
HKVS # md 0x000000050000
00050000: eb003a31 e2505000 159f00c8 11a01006    1:...PP.........
00050010: 1a000024 e5944008 e59f10bc e1a00004    $....@..........
00050020: e3a02005 eb003a28 e3500000 0a000020    . ..(:....P. ...
00050030: e1a00004 e59f10a4 e3a02006 eb003a22    ......... ..":..
00050040: e3500000 03a03002 0a00001a e1a00004    ..P..0..........
00050050: e59f108c e3a02008 eb003a1b e3500000    ..... ...:....P.
00050060: 03a03004 0a000013 e1a00004 e59f1074    .0..........t...
00050070: e3a02006 eb003a14 e3500000 03a03008    . ...:....P..0..
00050080: 0a00000c e1a00004 e59f105c e3a02006    ........\.... ..
00050090: eb003a0d e3500000 03a03010 0a000005    .:....P..0......
000500a0: e59f0048 e1a01004 eb001b7f e3e05000    H............P..
000500b0: ea000005 e3a03001 e59f2034 e59f0034    .....0..4 ..4...
000500c0: e1a01004 e5823000 eb001b77 e1a00005    .....0..w.......
000500d0: e8bd8070 80828469 8082846d 8082a18b    p...i...m.......
000500e0: 8082848d 80828493 8082cce0 8082849b    ................
000500f0: 808284a1 80832b3c 808284c5 e2421002    ....<+........B.
 

alastairstevenson

Staff member
Joined
Oct 28, 2014
Messages
15,930
Reaction score
6,778
Location
Scotland
I tried the following, but have no idea what I am doing as I don't see the SWKH I was expecting..
0x000000050000-0x000000060000 : "enc"
That's reading from offset 0 (bootloader) for 0x10000 into RAM at 0x50000


Here is what I've come up with.
But you do need to know there is risk - though there are some checks / stops in the procedure - only proceed if you understand there might be adverse consequences. Or maybe the opposite!


You need a normal tftp server - this one usually works OK - TFTP server
Place the mtdblock2_updated file in its root.

And we need to know what RAM location could be used to store data.
The environment variables usually provide a good clue - but you've not shown them so far.
I'm going to assume 0x2800000 - from the vmalloc value in dmesg
The IP camera and tftp server addresses can be set arbitrarily for convenience - and don't need to be saved.
Code:
setenv ipaddr 192.0.0.64
setenv serverip 192.0.0.128
First, let's check we can read mtdblock2 off the flash.
Code:
sf probe 0
sf read 0x2800000 0x50000 0x10000
md 0x280000 80
Check that the display matches the head of the mtdblock2 that you extracted.
If not - don't proceed.

Now check we can read the mtdblock2_updated over the network.
Code:
tftp 0x2800000 mtdblock2_updated
md 0x280000 80
Check this shows the modified mtdblock2_updated - for example that byte 0x10 is 01 instead of the original 02
If not - don't proceed.

Now for the risky part.
Your choice whether to proceed, knowing it could have adverse consequences. Or positive consequences.
Code:
sf erase 0x50000 0x10000
sf write 0x2800000 0x50000 0x10000
sf read 0x2800000 0x50000 0x10000
md 0x280000 80
And check that the modified values have been read back OK.

And now with fingers crossed :
Code:
reset
and observe the result.
 

rikochet

n3wb
Joined
Sep 28, 2019
Messages
13
Reaction score
3
Location
/dev/null
You sir, are a magician!

The good news!
Using tftp I was able to write the modified paraBlock.. There was one slight hiccup in that you had a typo with vmalloc address (should be 0xc2800000) but I was able to locate the correct value quickly thanks to your verbose instructions. :-D

The bad
When pairing via the EZVIZ android app it still reports "Operation failed. The device is not supported." and the Windows also errors with "It's not supported"

I guess I need to figure out how to spoof the Serial Number or devType..

Btw I managed to symlink prtHardInfo..

Output before patch:
Code:
Start at 2019-10-11 22:27:37
Serial NO :CS-C6TC-32WFR0120190806CCCHD47011475
V5.2.3 build 180906
hardwareVersion = 0x0
hardWareExtVersion      = 0x0
encodeChans             = 1
decodeChans             = 1
alarmInNums             = 0
alarmOutNums            = 0
ataCtrlNums             = 0
flashChipNums           = 0
ramSize                 = 0x4000000
networksNums            = 1
language                        = 2
devType                 = 0x222d7
zone                            = 1
wifiSupport             = 1
videoStandard           = 0
Output after patch:
Code:
/bin # prtHardInfo
Start at 2019-10-11 23:12:15
Serial NO :CS-C6TC-32WFR0120190806CCWRD47011475
V5.2.3 build 180906
hardwareVersion = 0x0
hardWareExtVersion      = 0x0
encodeChans             = 1
decodeChans             = 1
alarmInNums             = 0
alarmOutNums            = 0
ataCtrlNums             = 0
flashChipNums           = 0
ramSize                 = 0x4000000
networksNums            = 1
language                        = 1
devType                 = 0x222d7
zone                            = 3
wifiSupport             = 1
videoStandard           = 0
Thanks for all your efforts so far, I really appreciate it :)
 

alastairstevenson

Staff member
Joined
Oct 28, 2014
Messages
15,930
Reaction score
6,778
Location
Scotland
Oops - sorry about the typo. I didn't proofread it properly.

Interesting about the prtHardInfo
You can see the language changes from CN to EN
And the region in the serial number change from CCCH (China) to CCWR (World).

The serial number is part computed as opposed to being created literally.
I'd guess that the devType might be the key.

You could experiment. Carefully.
 

rikochet

n3wb
Joined
Sep 28, 2019
Messages
13
Reaction score
3
Location
/dev/null
I found this post for a different camera which I believe is not Chinese.

Code:
# prtHardInfo
Start at 2019-08-11 15:55:00
Serial NO :CS-CV110-A1-68R20180304AAWR181184768
V5.5.3 build 180122
OEM INFO: DZ20171013_100
NetProcess Version: 5.10.2 [20:30:31-Jul 18 2017]
Path: /Camera/Platform/Trunk/FSP_network_protocol
Last Changed Rev: 299284
Last Changed Date: 2017-07-14 17:00:38 +0800 (Fri, 14 Jul 2017)

Db Encrypt Version: 131072
hardwareVersion = 0x0
hardWareExtVersion      = 0x0
encodeChans             = 1
decodeChans             = 1
alarmInNums             = 0
alarmOutNums            = 0
ataCtrlNums             = 0
flashChipNums           = 0
rms                             = 0x200
networksNums            = 1
language                        = 1
devType                 = 0x22a69
net reboot count        = 0
vi_type                 = 47
hardwareType            = 1
firmwareCode            = 0000000200000100000000010c91bc6f000000010000000100000001ffffffff050500030012011600022a69
Path: /Camera/Custom/Custom_Project/2017/201711/%E6%B5%B7%E5%A4%96/PJ01C20171013100_%E5%8C%97%E7%BE%8E%E8%90%A4%E7%9F%B34K%E7%9B%B8%E6%9C%BA%E4%BD%8E%E6%88%90%E6%9C%AC%E6%96%B9%E6%A1%88%E5%AE%9A%E5%88%B6
Last Changed Rev: 358564
Last Changed Date: 2018-01-22 14:58:27 +0800 (Mon, 22 Jan 2018)
So I modified the paraBlock so that the devType was 2a69 and patched mtdblock2 again using your tftp method. The device loads up fine and prtHardInfo reports the new devType.

Code:
/bin # prtHardInfo
Start at 2019-10-12 00:26:53
Serial NO :CS-C6TC-32WFR0120190806CCWRD47011475
V5.2.3 build 180906
hardwareVersion = 0x0
hardWareExtVersion      = 0x0
encodeChans             = 1
decodeChans             = 1
alarmInNums             = 0
alarmOutNums            = 0
ataCtrlNums             = 0
flashChipNums           = 0
ramSize                 = 0x4000000
networksNums            = 1
language                        = 1
devType                 = 0x22a69
zone                            = 3
wifiSupport             = 1
videoStandard           = 0
However the EZVIZ software still reports the device as unsupported.

One thing that I wonder about is that I am using US firmware which I patched to CN using Hiktool and have now patched again using mtd method. Do you think it's worth putting the CN firmware back on the device and trying the mtd method again?

EDIT:
Hmm... I re-flashed the Chinese firmware via U-Boot, but the mtdblock2 persisted.. So I thought I'd try and upload the firmware via the EZVIZ application however it can't upload to the camera. The UART terminal outputs the message:

Code:
the minortype is 115201001
the minortype is 115201001
[12 01:08:34][UNI_IF][ERROR]update_flag = dev:120003001115201001(firm:1200030011152010021)
[12 01:08:34][UNI_IF][ERROR]update package dismatch!!!
[12 01:08:34][SDKCMD][ERROR]digcap update type dismatch, retVal = -37.
Is there a factory reset or something that I can do to the flash? or is it possible the US version is newer than the CN firmware and there is some protection again downgrading?
 
Last edited:

alastairstevenson

Staff member
Joined
Oct 28, 2014
Messages
15,930
Reaction score
6,778
Location
Scotland
mtdblock2 will be untouched by a firmware update.
The update process will validate a match against a selection of devType s.
Did you put the devType back to how it was before trying the firmware update.

I'd normally expect the now-converted device to reject CN firmware. But your as-delivered device did not reject the US firmware, which surprised me.
 

rikochet

n3wb
Joined
Sep 28, 2019
Messages
13
Reaction score
3
Location
/dev/null
I've been trying different combinations in the paraBlock but think I am missing something...

Could you please be a little more specific by what you mean below?
And at 0x04 the checksum-16 value of 0x0C6D matches the 0xF4 range of bytes after location 0x08
TIA :)
 

alastairstevenson

Staff member
Joined
Oct 28, 2014
Messages
15,930
Reaction score
6,778
Location
Scotland
Could you please be a little more specific by what you mean below?
Pretty easy to do this with the very good Windows hex editor HxD. HxD - Freeware Hex Editor and Disk Editor | mh-nexus

Open the file with HxD.
Position the cursor on the byte at 0x09 - after the 0xF4 which specifies the scope number of bytes. (Strictly speaking it's after 0x00F4 ie byte at 0x0A but makes no difference with the training nulls)
Drag / select down until there are Length : 0xF4 bytes selected - as shown in the bottom status bar.
Use the Analysis menu and select Checksum-16
The resultant 2-byte value shows in the status bar.
Type these 2 values into the bytes at 0x04 remembering it's little-endian so LSB then MSB
As shown in the screenshot below.

Check out this post for some info on the 'bootpara' block of data : R0 / DS-2CD2x32 BrickfixV2 brick recovery and full upgrade tool - enhanced.

1570882131299.png
 

rikochet

n3wb
Joined
Sep 28, 2019
Messages
13
Reaction score
3
Location
/dev/null
Thanks for your clear explanation, it makes perfect sense now! :)

After some tinkering I have managed to get the camera connected to the EZVIZ network! - VICTORY! :headbang:

I am now trying to replicate the process on a secondary camera, once I have the steps to reproduce I shall publish them here :)

Thanks again for all your help! There's absolutely no way I could have done this on my own.
 

alastairstevenson

Staff member
Joined
Oct 28, 2014
Messages
15,930
Reaction score
6,778
Location
Scotland
After some tinkering I have managed to get the camera connected to the EZVIZ network! - VICTORY!
Wow!
That's a great result, well done.

I'm curious what the tinkering consisted of.
Was it a matter of changing the devType held in mtdblock2 ?
 
Top