Long-shot help request - Hikvision DS-2CD3335D - G0 series IPC.

alastairstevenson

alastairstevenson

Staff member
Oct 28, 2014
16,064
6,885
Scotland
As this is a less common, Chinese market turret camera, and even less likely that someone will have unpicked its internals, I recognise that this is a long-shot request.
I've had this G0 3335D for a while - but CN menus, and has rejected all stock and tweaked firmware thrown at it by whatever method, even the newly-published IPC_G0_CN_STD_5.4.41_170710 specifically for this model.
While trying this new firmware, via the serial console, I accidentally issued the 'upf' (Upgrade - factory only) command.
This has the effect of erasing the entire set of flash partitions, bar the bootloader, in preparation for a factory-issue firmware pack. Dohh...

It was an interesting exercise in tftp booting and figuring out how the firmware environment is organised (it's a kind of hybrid of R0 and R7 series) that has got me to the point of correctly repopulating the kernel and app partitions.
But I'm missing what will be the equivalent of mtdblock5/6 in the R0 series, so the camera now boots OK but won't start up normal services as there is no hardware information.
I don't even know in which partition or where the 'hardware descriptor block' is located that would allow a spoofed copy to be made.

So my rather optimistic help request is:
Does anyone know where the hardware descriptor block (the mtdblock5/6 if it was an R0 camera) is located, or, even better, have a copy of the relevant partition, or even the entire flash as an image file?
Many thanks in advance.
 
  • Like
Reactions: aster1x
Don't know abour 3335, but other G0 cameras store it in the EMV chip.
Here is flash layout from another G0 (mtd0-mtd12):

Code: 
name   size     start   
bld    0x0100000 0x0     
env    0x0080000 0x0100000
enc    0x0080000 0x0180000
sysflg 0x0080000 0x0200000
dpt    0x0100000 0x0280000
sys0   0x0800000 0x0380000 <-kernel
sys1   0x0800000 0x0b80000 <-kernel
app0   0x2600000 0x1380000
app1   0x2600000 0x3980000
cfg0   0x0400000 0x5F80000
cfg1   0x0400000 0x6380000
syslog 0x1000000 0x6780000
resv   0x0880000 0x7780000

Also check your PM
 
Last edited:
  • Like
Reactions: aster1x, alastairstevenson and fenderman
Very many thanks, that's much appreciated.
The partitions are a match.
montecrypto said:
Don't know abour 3335, but other G0 cameras store it in the EMV chip.
Click to expand...
I did wonder if the camera was using this method to store the hardware info - I've read your posts on the topic, and there is some WATCHDATATimeCOS code in the unpacked uImage.
But then I thought - why would they wipe that as part of a firmware update?
I probably guessed wrong - I'll know soon!
 
Well, with the really useful help from @montecrypto , this camera is back working again.
Moreover, it's previously impenetrable security shell has been truly breached.
Code: 
login as: admin
admin@192.168.1.64's password:


BusyBox v1.19.3 (2016-07-12 16:09:01 CST) built-in shell (ash)
Enter 'help' for a list of built-in commands.

# prtHardInfo
Start at 2017-08-22 16:17:31
Serial NO :DS-2CD3335D-I20150619AACH524222564
V5.4.20 build 160726
NetProcess Version: 1.7.1.204140 [16:40:42-Jul 11 2016]
Db Encrypt Version: 65537
Db Major Version: 1176
Db svn info:
Path: /Camera/Platform/Branches/branches_frontend_software_platform/db_process_f                    or_5.4.20
Last Changed Rev: 201703
Last Changed Date: 2016-06-17 09:43:40 +0800 (Fri, 17 Jun 2016)
hardwareVersion = 0x0
hardWareExtVersion      = 0x0
encodeChans             = 1
decodeChans             = 1
alarmInNums             = 0
alarmOutNums            = 0
ataCtrlNums             = 0
flashChipNums           = 0
ramSize                 = 0x100
networksNums            = 1
language                        = 2
devType                 = 0x22501
net reboot count        = 0
vi_type                 = 32
Path: /Camera/Platform/Branches/branches_frontend_software_platform/IPC_develop_                    branch/ipc_e0_g0_r3_5.4.20
Last Changed Rev: 210205
Last Changed Date: 2016-07-25 21:49:11 +0800 (Mon, 25 Jul 2016)


# help
Built-in commands:
------------------
        . : [ [[ alias bg break cd chdir command continue echo eval exec
        exit export false fg getopts hash help jobs kill let local printf
        pwd read readonly return set shift source test times trap true
        type ulimit umask unalias unset wait

#
3335D_1.jpg

So now I need to see if the 'hacked to English' tweak to Davinci works on this G0 firmware, and find out if Hikvision have layered a bit more protection on than exists in the R0 5.4.5 firmware.
 
upf does not delete anything important. It is just a "restore factory defaults". It is also very easy way to reset password because it will erase config partitions (sqlite db's).

G0 model you have to hook one call and thats it. Inside hook you return what is needed to make davinci happy. And add some lic features if needed.
No real need to reverse emv functions.
Using Monte's tool you can insert .so to do a job.

Maybe I said too much...
 
It does sound like you have done some exploration of the G0 series, thanks for the hints.
JAFO said:
upf does not delete anything important. It is just a "restore factory defaults". It is also very easy way to reset password because it will erase config partitions (sqlite db's).
Click to expand...
It erased the sys partitions (mtdblock5,6) and the dav partitions (mtdblock7,8) and the config partitions (mtdblocks9,10 )and stopped the camera working.
Maybe the bootloader in the camera is different from those you've looked at.
I never did get the camera with it's original 5.3.3 CN firmware to accept any updates, by any method I tried, tftp, web GUI, bootloader, Batch Configuration Tool, ONVIF.

The camera is now fully recovered after re-writing those partitions using a tftp booted uImage.
In fact after a tiny davinci code (I never did read it ...) tweak (3 bytes out of 9MB) the camera has had a personality change and now talks English instead of Chinese, which is pretty good because the NVR no longer shuns it when it wants to make friends with it.

*edit*
And it was a pleasant surprise to find that, unlike in the 5.4.5 firmware, there were no 'software watchdogs' sneaking around in the background looking for things that may have changed to give an excuse for rebooting.

Code: 
# prtHardInfo
Start at 2017-08-24 20:10:48
Serial NO :DS-2CD3335D-I20150619AACH524222564
V5.4.20 build 160726
NetProcess Version: 1.7.1.204140 [16:40:42-Jul 11 2016]
Db Encrypt Version: 65537
Db Major Version: 1176
Db svn info:
Path: /Camera/Platform/Branches/branches_frontend_software_platform/db_process_for_5.4.20
Last Changed Rev: 201703
Last Changed Date: 2016-06-17 09:43:40 +0800 (Fri, 17 Jun 2016)
hardwareVersion = 0x0
hardWareExtVersion      = 0x0
encodeChans             = 1
decodeChans             = 1
alarmInNums             = 0
alarmOutNums            = 0
ataCtrlNums             = 0
flashChipNums           = 0
ramSize                 = 0x100
networksNums            = 1
language                        = 1
devType                 = 0x22501
net reboot count        = 0
vi_type                 = 32
Path: /Camera/Platform/Branches/branches_frontend_software_platform/IPC_develop_branch/ipc_e0_g0_r3_5.4.20
Last Changed Rev: 210205
Last Changed Date: 2016-07-25 21:49:11 +0800 (Mon, 25 Jul 2016)


#
 
Last edited:
  • Like
Reactions: maoratanak
upf == "update and format". "update" in uboot means tftp digicap.dav loading so you have to have it. In that way it is not destructive.
 
  • Like
Reactions: maoratanak
JAFO said:
In that way it is not destructive.
Click to expand...
Unfortunately, it is when the camera refuses to take any of the many versions of G0 firmware (and even others) that is offered to it.
JAFO said:
upf == "update and format".
Click to expand...
In reality it's 'format and update' so if it can't update, like this camera would not (I still have no idea why), it's wiped.

But actually my accidental 'upf' has turned out really well, as the full Chinese camera could not be used on the NVRs ('language mismatch') and would not update.
So now, having been forced to reconstruct the contents, it's been 'hacked to English' and is usable. Supports h.265 also.
I'm going to change the lens from 6mm to 4mm and swap out the last DS-2CD2032-I where spider webs are such an annoying feature.
 
A DS-2CD3335D doing face detection? Surely not!
Well, yes, but not very well.
 

Attachments

  • 3335D_facedetect_1.jpg
    3335D_facedetect_1.jpg
    176.8 KB · Views: 114
  • 3335D_facedetect.jpg
    3335D_facedetect.jpg
    397.8 KB · Views: 114
roland2000 said:
Do you mind sharing how you did this step by step?
Click to expand...
Yes, no problem :

This is a summary of what I did to recover my 3335 that I wiped by mistake.
What you will need to do this:

Access to the camera serial console via a serial TTL to USB convertor, and a good terminal program such as PuTTY.
If you don't have these already, a couple of items are needed -
A PL2303HX-based (or similar) serial TTL to USB convertor. Loads on eBay, often for use with Arduino.
A wired 4-pin 1.5mm JST ZH connector - again, loads on eBay.
There are a few posts on the forum about UART connections to Hikvision serial consoles, should resolve via 'search'.

A standard tftp server.
An NFS network share.
An unpacked copy of the G0 firmware, split into uImage and all the rest of the files.
Ideally some familiarity with working at a command line.
I'm not sure which of these things may be familiar or not, let me know of any questions and I'll try to help.
Don't feel daunted, it's not too bad.

-----------------------------------------------------------
Assuming the serial console is hooked up (115,200 baud, 8 bits no parity) and shows lots of readable info when the camera is powered on -
Interrupt the bootloader with Control-U
It's handy to set some of the environment variables to suit your network.
First of all though, make a record of existing settings by using the following command, and copying the screen rollback in PuTTY to a text file to save in your work area:

printenv

Use the following commands to set the camera IP address and the TFTP server IP address:

setenv ipadrs <your_choice_for_the_camera>
setenv serverip <your_TFTP_server_address>
saveenv

Then the kernel bootargs need to be changed to get the kernel to boot into a debug mode:

setenv bootargs console=ttyAMA0,115200 init=/bin/sh rootfs=0x82000000 rootfstype=initrd debug single loglevel=9
saveenv

-------------------------------------------------------------
Copy the kernel image uImage to your tftp root folder.

Boot over tftp and the camera should end up at a shell prompt, hopefully not a psh prompt.

tftp uImage
bootm

-----------------------------------------------------------
It's really handy to be able to copy / paste command lines from a text file (eg via Notepad) into the PuTTY command line.
These can be done singly or in multiple.
If the modified bootargs do boot into an ash shell, that's great as it will provide the access to do the needed work.
But at that point, the environment is not yet complete.
These commands are needed to take it a few steps further:
Adjust the IP addresses to match your network and your NAS for the NFS share and sharename.

/bin/mount -t proc proc /proc
/bin/mount -t sysfs none /sys
/bin/mount -t ramfs ramfs /home

/etc/S_udev

ifconfig eth0 192.168.1.64 up

mount -t nfs -o nolock 192.168.1.201:/cctv1 /mnt/nfs00

cd /mnt/nfs00

----------------------------------------------------------------

At this point there is a fully usable linux environment.
The uImage kernel can be applied to mtdblock5 & 6 (sys0, sys1) and all the remaining files from the unpacked firmware copied into /dav both when it's mounted from mtdblock7 and also mtdblock8 (app0 and app1).
Finally - reboot, interrupt the bootloader with Control-U and put the bootargs environment variable back the way it was to begin with so that the camera no longer boots into a shell in debug mode.

I'm idly curious why you need the details.
Do you have a camera that needs fixed up?
 
  • Like
Reactions: Andrey Khabibulin, vasycara, nithin and 2 others
alastairstevenson said:
I'm idly curious why you need the details.
Do you have a camera that needs fixed up?
Click to expand...

Sorry I didn't make it clear enough but it wasn't about firmware wipe out.
Long story short, I bought five DS-2CD3345-I with CN firmware v5.4.20 while I was in China for holiday late last year.
Early this year I bought a DS-7616NI-I2/16P NVR, with no knowledge about the well known language mismatch issue at that time.
Have been kicking myself for months and now trying to look for a solution to make them work together.

Thanks a lot for the guide, will try my best to follow it.
 
Last edited:
roland2000 said:
Sorry I didn't make it clear enough but it wasn't about firmware wipe out.
Click to expand...
That's what the post above is all about, reviving an erased camera.

roland2000 said:
Long story short, I bought five DS-2CD3345-I with CN firmware v5.4.20 while I was in China for holiday late last year.
Click to expand...
That's not the same series of cameras as the 3335, which is G0 series.

What version of firmware is on your NVR?
I found that on the 3.4.90 version of firmware, connecting the Chinese 3335 camera as ONVIF no longer gave a 'language mismatch'.
That may be worth testing.
See this thread : Language Mismatch.
 
alastairstevenson said:
What version of firmware is on your NVR?
I found that on the 3.4.90 version of firmware, connecting the Chinese 3335 camera as ONVIF no longer gave a 'language mismatch'.
Click to expand...
NVR firmware is 3.4.92. I've tried previously connecting it as ONVIF, no luck.
Sorry for hijacking your post, I thought your 3335 was the same series as mine.
Had been a bit desperate after a lot of searching without finding a solution then all in a sudden saw your 3335 now talked in English...
 
roland2000 said:
Had been a bit desperate after a lot of searching without finding a solution then all in a sudden saw your 3335 now talked in English...
Click to expand...
I did have to modify the firmware in order to give it languages other than CN lol!
roland2000 said:
Sorry for hijacking your post, I thought your 3335 was the same series as mine.
Click to expand...
Not a problem - with such a large forum, there may be other contributions.
 
Actually, looking more closely, the 3345 is listed in section 08 here, alongside the 3335 : 海康威视是全球领先的以视频为核心的物联网解决方案提供商
My usual reflex reaction that what appears to be a 4MP camera (ie the xx4x) is usually not the same series as the 3MP camera (ie xx3x) may not be correct n this case. Maybe others can confirm.
Do you feel inclined to get hold of a serial TTL to USB converter and connector and experiment?
Where are you based?
 
alastairstevenson said:
Do you feel inclined to get hold of a serial TTL to USB converter and connector and experiment?
Where are you based?
Click to expand...
Now I feel like the hope is back.
I definitely like to get my hands dirty.
I believe I already have the TTL to USB converter, but will need to get the JST ZH connector. Will get back to you when I have it. In the meantime, will get myself familiar with the software tools you mentioned earlier.
I'm based in Melbourne Australia.
 
You must log in or register to reply here.
Top Bottom