Flashed DS-2DE2103-DE3/W with 5.39 build 150910 - Login issue... SOLVED!

[developer]

Hi All.

I went from 5.2.7 build 141125 to 5.39 build 150910. This is a grey-market Chinese with English menus (CH in serial #).

I used the English version firmware and the tool to change the lang code to 2 (Chinese). Everything checksum'd properly.

The flash went fine and the cam booted up. It can be operated using rtsp and onvif, but I can't login anymore. I get:

Access Error: 404 -- Not Found
firmware language mismatch: /home/webLib/doc/page/login.asp

So, yeah... It looks like I shot myself in the foot. Ouch!

I have other cams of the same variety. Can I grab FW off one of them and reflash this, or is there an alternate method to get this back to 100% again?

I did a lot of looking around threads, but they don't really cover Hik 2DE cams.

Thanks in advance for any help.

 

[developer]

Postscript... The date & time show via the OSD. Formats are correct, but between date on left and time on right, there are 3 Chinese symbols.

 

[alastairstevenson]

is there an alternate method to get this back to 100% again?

I don't suppose the original seller would quietly supply you a copy of the 'hacked to English' firmware that was originally installed?

 

[developer]

I don't suppose the original seller would quietly supply you a copy of the 'hacked to English' firmware that was originally installed?

They were on eBay at one time, but gone now. Is there a way to grab firmware from one of my other cams?

 

[alastairstevenson]

Is there a way to grab firmware from one of my other cams?

Yes, if that version of firmware gives root shell access using telnet or SSH and you have an NFS server (eg a NAS) on the LAN.
For both donor and recipient.

See if you can telnet or SSH to a working camera.

 

[developer]

Yes, if that version of firmware gives root shell access using telnet or SSH and you have an NFS server (eg a NAS) on the LAN.
For both donor and recipient.

See if you can telnet or SSH to a working camera.

Sorry for the delay - I had to work. I enabled telnet through the gui on another cam with V5.2.7 build 141125. I confirmed that I can telnet to it and get a shell under "admin". I have a qnap on my network. Ready for the next step, and THANK YOU for your help!!!

(telnet server is apparently not enabled on the cam with the problem). Can I grab the firmware from this in dav form and use the hiktool to reflash the cam with trouble?

 

[alastairstevenson]

I confirmed that I can telnet to it and get a shell under "admin".

As long as this is a full shell, and not Hikvision 'psh' restricted shell. Type 'help' to check.
On the other camera - the newer firmware may well have either/both SSH unavailable, or be using 'psh' as the shell.
Check with the Batch Configuration Tool (this should still work) if there is a tickbox for SSH.
Download | Tools - Hikvision

I have a qnap on my network.

If it is offering either SMB/CIFS or NFS shares on the network, you can conveniently connect the working camera to it in the Storage Management web GUI, as follows (does not need to be formatted) :



Then, at the root shell prompt, the flash partitions can be copied out as per this partial example.
Your camera will be different - it's not one I'm familiar with - check the output of the 'cat /proc/mtd' command to see which mtdblocks need to be covered to extract the firmware.

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


BusyBox v1.19.3 (2014-07-11 11:25:54 CST) built-in shell (ash)
Enter 'help' for a list of built-in commands.

#
# 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)
192.168.1.201:/cctv1 on /mnt/nfs00 type nfs (rw,sync,relatime,vers=3,rsize=4096,wsize=4096,namlen=255,acregmin=0,acregmax=0,acdirmin=0,acdirmax=0,soft,noac,nolock,proto=tcp,port=65535,timeo=70,retrans=3,sec=sys,local_lock=all,addr=192.168.1.201)
#
# cd /mnt/nfs00
#
# ls -al
drwxrwxrwx    7 root     root          4096 Sep 30 15:51 .
drwxrwxrwx   13 root     root          1024 Jul 11  2014 ..
drwxrwxrwx    2 root     root          4096 Sep 30 15:42 .streams
drwxrwxrwx   15 root     100           4096 Sep 30 15:51 @Recycle
drwxrwxrwx    2 root     root         12288 Feb 21  2018 datadir0
drwxrwxrwx    2 root     root         12288 Feb 21  2018 datadir1
drwxrwxrwx    2 root     root         12288 Feb 21  2018 datadir2
#
# mkdir extract
# cd extract
# ls -al
drwxr-xr-x    2 root     root          4096 Sep 30 15:52 .
drwxrwxrwx    8 root     root          4096 Sep 30 15:52 ..
#
# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00020000 00020000 "bst"
mtd1: 00100000 00020000 "ptb"
mtd2: 00100000 00020000 "bld"
mtd3: 00100000 00020000 "hal"
mtd4: 00100000 00020000 "ano_ptb"
mtd5: 00080000 00020000 "env"
mtd6: 00080000 00020000 "param"
mtd7: 00100000 00020000 "dpt"
mtd8: 00a00000 00020000 "rcvy"
mtd9: 00800000 00020000 "krn_pri"
mtd10: 00800000 00020000 "krn_sec"
mtd11: 00400000 00020000 "rmd_pri"
mtd12: 00400000 00020000 "rmd_sec"
mtd13: 01800000 00020000 "app_pri"
mtd14: 01800000 00020000 "app_sec"
mtd15: 00400000 00020000 "cfg_pri"
mtd16: 00400000 00020000 "cfg_sec"
mtd17: 01000000 00020000 "dbg"
#
# cat /dev/mtd0ro > mtd0ro
# cat /dev/mtd1ro > mtd1ro
# cat /dev/mtd2ro > mtd2ro
# cat /dev/mtd3ro > mtd3ro
#
#
# ls -al
drwxr-xr-x    2 root     root          4096 Sep 30 15:53 .
drwxrwxrwx    8 root     root          4096 Sep 30 15:52 ..
-rw-r--r--    1 root     root        131072 Sep 30 15:53 mtd0ro
-rw-r--r--    1 root     root       1048576 Sep 30 15:53 mtd1ro
-rw-r--r--    1 root     root       1048576 Sep 30 15:53 mtd2ro
-rw-r--r--    1 root     root       1048576 Sep 30 15:53 mtd3ro
#

 

[developer]

I'm going to work on this shortly. I did look and the shell is surely crippled. No grep, no who, no su, no id, no nothing, but I can "cat".
So I took a look at the rc. That is where I think the hack is. It has a lot of tar files that it uses to overwrite the home directory on the first boot and then trashes the davinci stuff.

I downloaded the batch config tool. It fell over on install with Error # 0x80040706 - Object reference not set. Happened on my legacy XP box and on my newest W10. :-(

Going back to today's honey-do work. I'll check back later. Perhaps you know of another place to download it? Thanks very much!!!

 

[alastairstevenson]

I did look and the shell is surely crippled. No grep, no who, no su, no id, no nothing, but I can "cat".

That's OK, it's not psh.

It has a lot of tar files that it uses to overwrite the home directory on the first boot and then trashes the davinci stuff.

If it's what I think it is, from initrun.sh, that's normal.
The archives in the flash are encrypted, and are decrypted into memory, extracted, and the decrypted files deleted.
And davinci is encrypted, it gets decrypted into memory, executed, and the decrypted file deleted.

I downloaded the batch config tool. It fell over on install with Error # 0x80040706 - Object reference not set. Happened on my legacy XP box and on my newest W10. :-(

That might be an access control issue.
It should install OK.

 

[developer]

BusyBox v1.19.3 (2014-07-11 11:15:32 CST) built-in shell (ash)
Enter 'help' for a list of built-in commands.

# 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)
192.168.0.16:/cctv1 on /mnt/nfs00 type nfs (rw,relatime,vers=3,rsize=1024,wsize=
32768,namlen=255,hard,nolock,proto=tcp,port=65535,timeo=70,retrans=3,sec=sys,loc
al_lock=all,addr=192.168.0.16)

# cd /mnt/nfs00
# ls -al
drwxrwxrwx 4 root root 4096 Sep 30 2018 .
drwxrwxrwx 13 root root 1024 Jul 11 2014 ..
drwxr-x--- 2 root root 4096 Sep 30 2018 extract
drwxrwx--- 2 root root 4096 Sep 30 2018 test

# cd extract
# ls -al
drwxr-x--- 2 root root 4096 Sep 30 2018 .
drwxrwxrwx 4 root root 4096 Sep 30 2018 ..

# cat /proc/mtd
dev: size erasesize name
mtd0: 00020000 00020000 "bst"
mtd1: 00100000 00020000 "ptb"
mtd2: 00100000 00020000 "bld"
mtd3: 00100000 00020000 "hal"
mtd4: 00100000 00020000 "ano_ptb"
mtd5: 00080000 00020000 "env"
mtd6: 00080000 00020000 "param"
mtd7: 00100000 00020000 "dpt"
mtd8: 00a00000 00020000 "rcvy"
mtd9: 00800000 00020000 "krn_pri"
mtd10: 00800000 00020000 "krn_sec"
mtd11: 00400000 00020000 "rmd_pri"
mtd12: 00400000 00020000 "rmd_sec"
mtd13: 01800000 00020000 "app_pri"
mtd14: 01800000 00020000 "app_sec"
mtd15: 00400000 00020000 "cfg_pri"
mtd16: 00400000 00020000 "cfg_sec"
mtd17: 01000000 00020000 "dbg"

# cat /dev/mtd0ro > mtd0ro
# cat /dev/mtd1ro > mtd1ro
# cat /dev/mtd2ro > mtd2ro
# cat /dev/mtd3ro > mtd3ro

# ls -al
drwxr-x--- 2 root root 4096 Sep 30 2018 .
drwxrwxrwx 4 root root 4096 Sep 30 2018 ..
-rw-r----- 1 root root 131072 Sep 30 2018 mtd0ro
-rw-r----- 1 root root 1048576 Sep 30 2018 mtd1ro
-rw-r----- 1 root root 1048576 Sep 30 2018 mtd2ro
-rw-r----- 1 root root 1048576 Sep 30 2018 mtd3ro
#

So, we took bst, ptb, bld and hal and copied those to extract. It seems the layout on mine is similar to yours.

Here is where I am...

These are on the qnap in a directory called extract, but no batchconfig tool yet. I'll look for one from another site and stop back later. Thanks!

 

[alastairstevenson]

So, we took bst, ptb, bld and hal and copied those to extract. It seems the layout on mine is similar to yours.

You'll need to get them all, ideally, I just showed an example.
Though the ones of interest are 9-14

**edit** Though it depends on how the original 'hacked to English' firmware has been done.

It seems the layout on mine is similar to yours.

I may be wrong - but based on the firmware filenames on the EU portal downloads for that camera - some earlier hardware variants may be based on the R0 architecture.
DOWNLOAD PORTAL
Maybe others with that model could comment.

 

[alastairstevenson]

some earlier hardware variants may be based on the R0 architecture.

Just a stray thought - if so, the contents of mtd6ro might be interesting.
It would be quite something if the 'enhanced MTD hack' was applicable ...

 

[developer]

Batchconfig tool is installed. This was an error from installshield when it was going through its cleanup. The tool was actually installed when it crashed.

I ran it and was able to add the good cam. The other one doesn't respond when I add it. Do I add it as an offline device? Thanks!

 

[alastairstevenson]

Do I add it as an offline device? Thanks!

No, I'd have expected it to be discovered automatically.
Even though the web GUI isn't properly active, the command and control channel should be operational if it can be seen in SADP.

 

[developer]

Ok, it's up and in the batch config tool. (replaced flaky netgear switch - arghhhh).

I can see it in both tools; this and sadp. In the batch tool I was able to figure out that the Chinese symbols in the date & time are the day. When I move it to change position on the screen, it highlights in the English (today "Sun").

I will repeat the copies for all the mounted parts of the filesystem and then diff them to make sure I have good copies. What's next? I am learning a lot here. Too bad the batch tool doesn't allow me to enable the telnet server...

 

[developer]

Update... I can ssh into the cam, but it's severely restrictive. I used hxd to look at mtd6ro and the language value is 1 (English?), not 2 (Chinese?). I have all the mtd files and they are intact in the extract directory.
This is where I'm stopping. Getting late and my wife's uncle passed away. Have to go to the funeral parlor tomorrow, but I'll check back in. I take it you're on the other side of the puddle and probably sleeping. Thanks very much for all your help!

 

[alastairstevenson]

Some questions:
Are the other cameras, eg the one you pulled the flash partitions off, also CN market with CCCH in the serial number?
Presumably the SSH access is to the working camera?

I'm wondering how much of a risk it might be to use the chance the camera may be R0 architecture compatible, and try the brickfixV2 tool fixup environment to get access to a working kernel to apply the cloned flash partitions.

Please show the result of the prtHardInfo command on the working camera.
And post a zipped copy of mtd6ro

 

[developer]

Interesting...

Both cameras have "CH" in the serial #.

I am able to use SSH to get into the cam with the problem, so I'm listing the output of prtHardInfo from both.

Interesting that the language in the good one is 1 and I changed it to 2 in the bad one prior to flashing, following instructions in one of the threads. Perhaps that was the cause of the problem?

Thanks (I will be away until later, but I will check back).



From the problem camera:

# prtHardInfo

Start at 2018-09-30 16:48:12

Serial NO S-2DE2103-DE3/W20160528CCCH606753898

V5.3.9 build 150910

NetProcess Version: 1.4.0 [20:10:19-Mar 10 2015]

Db Encrypt Version: 65537

hardwareVersion = 0x0

hardWareExtVersion = 0x0

encodeChans = 1

decodeChans = 0

alarmInNums = 1

alarmOutNums = 1

ataCtrlNums = 0

flashChipNums = 0

ramSize = 0x4000000

networksNums = 1

language = 2

devType = 0x231c

net reboot count = 0

Path: .

Working Copy Root Path: /usr/local/jenkins/workspace/Frontend_BaseLine_Publish_B

uild/2015-09-10_15-33-49

URL: https://192.0.0.140/Camera/Platform/Branches/branches_frontend_software_pla

tform/IPDome_develop_branch/ipd_5.3.9_r0

Repository Root: https://192.0.0.140/Camera

Repository UUID: df2d70c3-7593-7941-af1e-571b313c0946

Revision: 148837

Node Kind: directory

Schedule: normal

Last Changed Author: liupenghui

Last Changed Rev: 148764

Last Changed Date: 2015-09-10 11:30:50 +0800 (Thu, 10 Sep 2015)



From the good camera:


# prtHardInfo

Start at 2018-09-30 18:10:31

Serial NO S-2DE2103-DE3/W20150715CCCH528520707

V5.2.7 build 141125

hardwareVersion = 0x0

hardWareExtVersion = 0x0

encodeChans = 1

decodeChans = 0

alarmInNums = 1

alarmOutNums = 1

ataCtrlNums = 0

flashChipNums = 0

ramSize = 0x4000000

networksNums = 1

language = 1

devType = 8988

net reboot count = 0

SD status = 0 (1:noraml;0:none)

Path: .

Working Copy Root Path: /data2/data_xuyeyf3/work/code/5.2.7

URL: https://192.0.0.140/Camera/Platform/Branches/frontend_software_platform_ipd

_5.2.7

Repository Root: https://192.0.0.140/Camera

Repository UUID: df2d70c3-7593-7941-af1e-571b313c0946

Revision: 102862

Node Kind: directory

Schedule: normal

Last Changed Author: wangxiaoping

Last Changed Rev: 102617

Last Changed Date: 2014-11-24 14:13:13 +0800 (Mon, 24 Nov 2014)

 

[alastairstevenson]

Interesting that the language in the good one is 1 and I changed it to 2 in the bad one prior to flashing, following instructions in one of the threads. Perhaps that was the cause of the problem?

Generally, a camera running 'hacked to English' firmware will show language=1 (EN) in prtHardInfo, even when the underlying region (as set in mtdblock6 in R0 series) has language=2 (CN).
I presume what you did when you changed the language to 2 was to use hiktools or hikpack to change the header language of the firmware.
This does not change the language of the camera, nor actually the language of the firmware, it just changes the language flag in the header of the firmware such that EN firmware would not be rejected by a CN camera during the firmware update compatibility check.

I presume the mtd6ro you attached is from the good camera.
It appears to follow the same format as mtd6ro in the R0 series cameras.
In this specific case - the language in 0x10 = 01 (EN), the devType in 0x64 (0x231C, 8988 decimal) matches what is shown in both samples of prtHardInfo output.
And the checksum in 0x04 is also correct.
These values are the essence of the 'enhanced MTD hack' that can be used on CN R0 cameras to convert to EN/upgradeable.

So that camera - despite the CCCH serial number you said it has, has been permanently changed to have an EN region / language.
It may not be running 'hacked to English' firmware, it may not need it.
It would be really interesting to get a copy of the mtd6ro of the problem camera for comparison, but on the assumption it has the 'psh' shell in the way that's not possible. Presumably the 'help' response is totally different, with few normal shell commands?

With the apparent similarity to the way the firmware is organised in the R0 series - a possible way forward would be to use the methods that work OK for R0 series to convert the camera to English.
But clearly there is some risk in that.

 

[developer]

Hi. I'm past the family dilemma and back. Interesting find. It definitely has the CCCH in the serial (as do all the ones I have). It does allow me to ssh and it is psh, unfortunately. So, using the batch tool, I tried to flash with the dav you pointed me to at the start. I figured... go for it. No matter how I set the install language flag, 1 | 2, it still gave me the wrong language error and would not go further. So, based on where we are, I'm prepared to roll the dice and do some brute force stuff to get the gui back. Do you have any suggestions as to what I should do next? Thanks Alastair.