Restored bootargs line to original as indicated, Boot as normal. Yes indeed camera is inactive now. Thanks a lot for guidance
alastairstevenson
Staff member
Excellent!
Well, that was an interesting journey. I love it when a good end-point is reached.
You did well interpreting and following the step by step instructions.
Well, that was an interesting journey. I love it when a good end-point is reached.
You did well interpreting and following the step by step instructions.
alastairstevenson
Staff member
Yes, devinfo does need to be mounted.
I'd thought the easiest way is to run the normal rcS startup and the mount and other prerequisites will be incorporated in it.
It's likely to be
mount -t yaffs2 /dev/mtdblock9 /devinfo
edit A typo - that should have been mtdblock6
Then find the files and delete them.
Last edited:
Assembled camera, assigned credentials and static IP and tested working perfect on ONVIF . Thanks a lot for detailing tutoring and patience.
Patty
Patty
alastairstevenson
Staff member
You are welcome, it's good to be able to help.
And others on the forum may benefit too.
Thanks moped, your instruction were perfect and helped me get my ds-7608NI back up and running with the latest firmware. Very much appreciated
Hi, i did everything like you said but i couldn't find devinfo folder, here is what i got after typing ls -la
my device is DS-7216HGHI-F1/N i tried to clear password by doing upgrade but it doesn't clear it after a success update
thanks in advance
Code:
[root@dvrdvs /] # ls -la
total 16
drwxrwxr-x 16 root 4112 0 Apr 15 16:15 .
drwxrwxr-x 16 root 4112 0 Apr 15 16:15 ..
-rw------- 1 root root 703 Apr 15 16:47 .ash_history
-rw-r--r-- 1 root root 2 Apr 15 16:36 .sysstat.out
drwxrwxr-x 2 root root 0 Nov 1 2016 bin
-rw-r--r-- 1 root root 1514 Apr 15 16:47 br_m.info
drwxrwxrwt 6 root root 2980 Apr 15 15:55 dev
drwxrwxr-x 6 root root 0 Apr 15 15:55 etc
drwxrwxr-x 4 root root 0 Apr 15 15:55 home
lrwxrwxrwx 1 root root 9 Nov 1 2016 init -> sbin/init
drwxrwxr-x 3 root root 0 Apr 15 15:55 lib
lrwxrwxrwx 1 root root 11 Nov 1 2016 linuxrc -> bin/busybox
drwxrwxr-x 10 root root 0 Apr 15 15:55 mnt
drwxrwxr-x 2 root root 0 Jul 22 2016 opt
dr-xr-xr-x 51 root root 0 Jan 1 00:00 proc
drwxrwxr-x 2 root root 0 Jul 22 2016 root
drwxrwxr-x 2 root root 0 Nov 1 2016 sbin
dr-xr-xr-x 12 root root 0 Apr 15 15:55 sys
-rw-r--r-- 1 root root 8 Apr 15 15:55 sys.token
drwxrwxr-x 2 root root 0 Apr 15 15:55 tmp
drwxrwxr-x 5 root root 0 Apr 15 15:55 usr
drwxrwxr-x 4 root root 0 Apr 15 15:55 var
[root@dvrdvs /] #You are almost there, couple of enter commands give you #
Looks like nothing happen and if you verify "ls" again you will end just with two lines listed , mean the command took effect
Code:
#
#
# rm /config/*.cfg
rm: can't remove '/config/*.cfg': No such file or directory
# [01-12 02:01:52][3][641]process message routine begin...
no interrupts
reset eth0.
[ 6811.188844] ***link down status changed***.Looks like nothing happen and if you verify "ls" again you will end just with two lines listed , mean the command took effect
alastairstevenson
Staff member
That's a DVR, so it has quite a different file structure from an IP camera.
Here is an example folder list from an NVR, the DVR may be similar :
Code:
[root@dvrdvs /] # ls -al /
drwxrwxr-x 16 root root 0 Mar 27 12:49 .
drwxrwxr-x 16 root root 0 Mar 27 12:49 ..
-rw-r--r-- 1 root root 2 Jun 3 17:20 .sysstat.out
drwxr-xr-x 2 root root 0 Jun 6 2019 bin
drwxrwxrwt 5 root root 3540 Feb 24 18:54 dev
drwxr-xr-x 7 root root 0 Jun 6 2019 etc
drwxr-xr-x 4 root root 0 Jun 6 2019 home
lrwxrwxrwx 1 root root 9 Sep 23 2016 init -> sbin/init
-rw-r--r-- 1 root root 0 May 18 09:25 ipcCfgTmp.xls
drwxr-xr-x 2 root root 0 Jun 6 2019 lib
lrwxrwxrwx 1 root root 11 Sep 23 2016 linuxrc -> bin/busybox
drwxr-xr-x 11 root root 0 Oct 7 2019 mnt
drwxr-xr-x 2 root root 0 Jul 3 2012 opt
dr-xr-xr-x 57 root root 0 Jan 1 1970 proc
drwxr-xr-x 2 root root 0 Jun 6 2019 root
drwxr-xr-x 2 root root 0 Sep 23 2016 sbin
dr-xr-xr-x 11 root root 0 Jun 6 2019 sys
drwxr-xr-x 2 root root 0 Jul 3 2012 tmp
drwxr-xr-x 4 root root 0 Sep 23 2016 usr
drwxr-xr-x 4 root root 0 Oct 4 2019 var
[root@dvrdvs /] #
[root@dvrdvs /] # ls -al /home
drwxr-xr-x 4 root root 0 Jun 6 2019 .
drwxrwxr-x 16 root root 0 Mar 27 12:49 ..
drwxr-xr-x 8 root root 0 Jun 6 2019 app
drwxr-xr-x 1 1000 232 176 Jan 1 1970 hik
-rwxr-xr-x 1 root root 48 Jun 6 2019 start.sh
[root@dvrdvs /] #
[root@dvrdvs /] # ls -al /home/app
drwxr-xr-x 8 root root 0 Jun 6 2019 .
drwxr-xr-x 4 root root 0 Jun 6 2019 ..
drwxr-xr-x 2 root root 0 Jun 6 2019 cfg
-rw-r--r-- 1 root root 18589 May 25 19:41 cfg.tgz
drwxrwxrwx 3 root root 0 Jun 6 2019 exec
drwxrwxrwx 2 root root 0 Jun 6 2019 lib
---------- 1 root root 13312 Jun 6 2019 netOsd.bin
drwxrwxrwx 2 root root 0 Jun 6 2019 res
drwxrwxrwx 3 root root 0 Jun 6 2019 sysres
drwxrwxrwx 5 root root 0 Jun 6 2019 webs
[root@dvrdvs /] #
[root@dvrdvs /] # ls -al /home/app/cfg
drwxr-xr-x 2 root root 0 Jun 6 2019 .
drwxr-xr-x 8 root root 0 Jun 6 2019 ..
---------- 1 root root 4666648 May 25 19:40 devCfg.bin
---------- 1 root root 77288 Jun 28 2017 mega_cfg.bin
[root@dvrdvs /] #In there, the running configuration file is devCfg.bin which is in this case in plaintext form.
Given a tftp server - this could be extracted and the password inspected.
The problem would be though, that this has been extracted from the flash partition where the configuration data is held.
This means that deleting it will have no effect as it will be re-created from flash on the next reboot.
But the DVR may be different.
The way the DVR stores it's configuration data is likely to be different from the NVR example above - and will also vary with the firmware version.
So I suggest the first thing to do is to check out the folder structure under /home and /home/app as per the example above.
well i did inspect i found a file called devCfg.lzma and i deleted it but it come back after rebooting
Code:
[root@dvrdvs /] # ls -la /home and /home/app
ls: and: No such file or directory
/home:
total 9
drwxrwxr-x 4 root root 0 Apr 15 17:21 .
drwxrwxr-x 16 root 4112 0 Apr 15 17:41 ..
drwxrwxr-x 6 root root 0 Apr 15 17:22 app
drwxrwxrwx 1 root root 232 Jan 1 00:00 hik
-rwxr-xr-x 1 root root 4392 Apr 15 17:21 start.sh
/home/app:
total 80
drwxrwxr-x 6 root root 0 Apr 15 17:22 .
drwxrwxr-x 4 root root 0 Apr 15 17:21 ..
drwxr-xr-x 2 root root 0 Apr 15 17:21 config
drwxrwxrwx 2 root root 0 Apr 15 17:21 exec
---------- 1 root root 0 Apr 15 17:21 hicoreCrashLog.bin
---------- 1 root root 0 Apr 15 17:21 hicoreZombieLog.bin
-rwxrwxrwx 1 root root 62552 Sep 6 2018 ptzCfg.bin
-rwxr-xr-x 1 root root 9665 Apr 15 17:21 setDebug_mux
-rwxrwxrwx 1 root root 240 Sep 6 2018 sysVersion.bin
drwxrwxrwx 2 root root 0 Apr 15 17:21 sysres
drwxrwxr-x 4 4138 4140 0 Apr 15 17:21 webs
[root@dvrdvs /] # ls -la /home and /home/app/config/
ls: and: No such file or directory
/home:
total 9
drwxrwxr-x 4 root root 0 Apr 15 17:21 .
drwxrwxr-x 16 root 4112 0 Apr 15 17:41 ..
drwxrwxr-x 6 root root 0 Apr 15 17:22 app
drwxrwxrwx 1 root root 232 Jan 1 00:00 hik
-rwxr-xr-x 1 root root 4392 Apr 15 17:21 start.sh
/home/app/config/:
total 48
drwxr-xr-x 2 root root 0 Apr 15 17:21 .
drwxrwxr-x 6 root root 0 Apr 15 17:22 ..
---------- 1 root root 552 Apr 15 17:22 .pd
---------- 1 root root 18709 Apr 15 17:22 devCfg.lzma
---------- 1 root root 256 Oct 24 2018 kw.bin
---------- 1 root root 13312 Oct 24 2018 netOsd.bin
-r----x--t 1 root root 28 Apr 15 17:22 otherFile.bin
[root@dvrdvs /] #alastairstevenson
Staff member
Yes, the original data is held in the flash partition.
And devCfg.lzma may be encrypted in that firmware version.
Suggestion :
Check if the DVR has a tftp command by using the command 'tftp'
If so, install a tftp server on the PC.
Such as the 32bit version of this :
Tftpd32: an opensource free firewall friendly dhcp, syslog sntp and tftp server/service for windows, tftp client
A free tftp and dhcp server for windows, freeware tftp server
tftpd32.jounin.net
Then try this command, using the PC IP address -
tftp -p -l devCfg.lzma <PC_IP_address>
Also - again I'm not familiar with that DVR, so guessing here - try the commands -
ded -d devCfg.lzma cfgtemp
tftp -p -l cfgtemp <PC_IP_address>
And in the unlikely event that it works, zip up the files that transferred to the tftp folder and attach here.
i looked for tftp with no results is there any way else to transfer the file, here is the commands that i'm able to use
Code:
[root@dvrdvs config] #
GetAnrCfgInfo hier set3GAuth
GetAnrProcess hiew set3GMode
GetAnrRecordList hil2s set3GPrint
ShowIpcAbility himc setAPN
WebComponents.exe himd setAutoRebootTime
[ himd.l setCivilAlarm
[[ himii.r setCivilLbs
accessDvrSwitch himii.w setCloudPassword
adjustDevDecodeSetCmd himm setDbgCtrl
arp hostname setDbgLevel
ash hwclock setDebug_mux
awk i18n.tar.lzma setDspDebugInfo
basename i2cRead setEnable3G
beepTest i2cWrite setGateway
btools i2c_read setIp
busybox i2c_recv setMtu
cat i2c_send setOffLineTime
channelPlayback i2c_write setPlayTestCtrl
chmod id setPort
clearDisksMode ifconfig setSignalDetectMode
closeCoaxTest init setSignalTestType
cloudModeChange insmod setVoutIdx
config/ kill setlang
controlAntiChanging killall setoutputmode
cp ln sh
createRaid loadModules shmtty
date login show8107coreUseInfo
dd ls showCurPlayChanFileInfo
decStat lsmod showDevCapa
ded lzcat showDevMemInfo
deleteRaid mesg showDeviceTemp
df miscCmd showIpcMemInfo
dirname mkdir showNetIpcmInfo
disableHB mknod showNetLinksInfo
disableHik264 mount showPlatformInfo
disableWatchdog mpstat showPlayChanStatus
dmesg mv showPlayClipFile
dnsdomainname mytar showPlayScreenInfo
dspStatus netstat showPlayStatus
dt new_10.bin showPlayTime
du openCoaxialPrintfInfoCmd showPreviewInfo
dvrCmd/ openLocalAudio showRaidInfo
dvrLogInfo outputClose showShareSvcInfo
dvrtools outputOpen showSipSession
echo partRecDetails showSpareWorkStatus
enableHB pidof showTagSysInfo
enableHik264 ping showUserInfo
enableWatchdog ping6 showWHSession
errputClose player.zip showlogo
errputOpen poweroff shutdown
exec/ printPart signFast
false printTaskStatus signModeSet
find ps sleep
free psh ss
get3GMode pthreadInfo start.sh
getAutoRebootTime ptzCfg.bin startHeapProfiler
getCivilStatus pwd stopHeapProfiler
getDbgCtrl reboot stty
getDevDebugInfo rebootDev su
getDspInfo recorderChanInfo sysVersion.bin
getGateway recorderFileInfo sys_app.tar.lzma
getHardInfo recorderFileKeyFrame sysres/
getIp recorderHDIdle t1
getLastErrorInfo recorderMediaInfo t2
getPlayTestCtrl recorderPAllocFile tar
getPort recorderParam test
getty recorderSegExtraInfo timeout
guiChkCfg recorderSegmentInfo top
guiEnterMenuCount recorderStatus transcodeResStatus
guiPrtScr renice true
guiStatus resetPasswd turnOffCivil
gui_res.tar.lzma rm uImage
gzip rmmod udevadm
halt route udevd
helpm searchInfo umount
hicoreCrashLog.bin sendATCom unlzma
hicoreZombieLog.bin sendCoaxialTranscmd webs.tar.lzma
hiddrs set3GAccess webs/alastairstevenson
Staff member
Does
busybox tftp
do anything?
Maybe.
Let's try some ideas.
Connect a formatted USB memory stick into a USB interface on the DVR.
Let's see if it gets auto-mounted.
Then can you provide the output of these commands -
mount
df
ls -al /dev/mmc*
ls -al /dev/msa*
If there exists (unlikely, but worth a try) in the list above
/dev/msa1
then try -
mkdir /mnt/mmc
mount -t vfat /dev/msa1 /mnt/mmc
ls -al /mnt/mmc
cp -r /home/app/* /mnt/mmc
cat /dev/mtdblock0 /mnt/mmc
cat /dev/mtdblock1 /mnt/mmc
dd if=/dev/mtd0ro of=/mnt/mmc/mtd0ro_1 bs=64k count=1
Just guessing a bit here, but you never know.
It's not easy when not hands-on.
alastairstevenson
Staff member
That's good, well done.
Presumably via a USB device.
Checking the files - the devCfg.lzma is encrypted with a key and encoding method that I don't have - so I'm not able to extract the existing password.
But looking at the 'master' app, it stores 4 copies of the configuration file in segments of 2 different flash partitions.
It should be possible to write over those segments to wipe the configuration - but there would be some risk in attempting to do so as this is not a DVR I have had any access to. Almost all my experience is with NVRs, which are organised quite differently internally.
I can work up some commands to write over the 4 copies of the configuration - but I need to ask you if you are prepared to accept that there may be a risk of undesired consequences in doing so.
Presumably via a USB device.
Checking the files - the devCfg.lzma is encrypted with a key and encoding method that I don't have - so I'm not able to extract the existing password.
But looking at the 'master' app, it stores 4 copies of the configuration file in segments of 2 different flash partitions.
It should be possible to write over those segments to wipe the configuration - but there would be some risk in attempting to do so as this is not a DVR I have had any access to. Almost all my experience is with NVRs, which are organised quite differently internally.
I can work up some commands to write over the 4 copies of the configuration - but I need to ask you if you are prepared to accept that there may be a risk of undesired consequences in doing so.
Yeah sure, I accept the risk but there is something you may miss it is that I decrypted the the devCfg.lzma in config folder, did you take a look at it ?
alastairstevenson
Staff member
Yes, there is encoding as well as encryption.
I'll see if I can work out what the 'master' program is doing there.
alastairstevenson
Staff member
edit
Read this first.
Before you make any changes, I made a mistake in the previous file extract instructions, so I'm missing 2 files.
I specified this, which is incorrect :
cat /dev/mtdblock0 /mnt/mmc
cat /dev/mtdblock1 /mnt/mmc
It should be :
cat /dev/mtd0ro > /mnt/mmc/mtd0ro
cat /dev/mtd1ro > /mnt/mmc/mtd1ro
So if you could extract and attach those 2 files please as the others were done.
Then we'll probably do this below - but only after I've looked at the files.
But it would take me a little while to replicate it.
It may work OK. Or it may just move on to get the data from block3.
I'm not sure if there are 2 stored, or 4. Maybe the firmware covers more than one model-dependent redundancy scheme.
Anyway here are the suggested commands -
Let the device boot till you get to the root shell # prompt.
Then copy / paste these commands in :
dd if=/dev/zero of=/dev/mtdblock0 bs=64k count=1
dd if=/dev/zero of=/dev/mtdblock0 bs=64k count=1 skip=1
Wait a few seconds then reboot, and find out if the system has been reset to defaults.
Presumably you have temporarily modified the bootloader environment variables to get to a root shell.
Good luck!
Read this first.
Before you make any changes, I made a mistake in the previous file extract instructions, so I'm missing 2 files.
I specified this, which is incorrect :
cat /dev/mtdblock0 /mnt/mmc
cat /dev/mtdblock1 /mnt/mmc
It should be :
cat /dev/mtd0ro > /mnt/mmc/mtd0ro
cat /dev/mtd1ro > /mnt/mmc/mtd1ro
So if you could extract and attach those 2 files please as the others were done.
Then we'll probably do this below - but only after I've looked at the files.
I've found what I think is the routine that may decode the stored configuration data.
But it would take me a little while to replicate it.
I think there is minimal risk in zeroing out 2 of the stored blocks of configuration data.
It may work OK. Or it may just move on to get the data from block3.
I'm not sure if there are 2 stored, or 4. Maybe the firmware covers more than one model-dependent redundancy scheme.
Anyway here are the suggested commands -
Let the device boot till you get to the root shell # prompt.
Then copy / paste these commands in :
dd if=/dev/zero of=/dev/mtdblock0 bs=64k count=1
dd if=/dev/zero of=/dev/mtdblock0 bs=64k count=1 skip=1
Wait a few seconds then reboot, and find out if the system has been reset to defaults.
Presumably you have temporarily modified the bootloader environment variables to get to a root shell.
Good luck!
Last edited:
it didn't work and gave me an error message, i guess there is a problem in flash memory
Code:
[root@dvrdvs /] # dd if=/dev/zero of=/dev/mtdblock0 bs=64k count=1
1+0 records in
1+0 records out
65536 bytes (64.0KB) copied, 0.016158 seconds, 3.9MB/s
[root@dvrdvs /] # flash mtdblock0 maybe unormal
write tar cfg to first 64k fail
flash mtdblock0 maybe unormal
write tar cfg to second 64k fail
flash mtdblock0 maybe unormal
write tar cfg to third 64k fail
[root@dvrdvs /] # dd if=/dev/zero of=/dev/mtdblock0 bs=64k count=1 skip=1
1+0 records in
1+0 records out
65536 bytes (64.0KB) copied, 0.023587 seconds, 2.6MB/s
[root@dvrdvs /] #
Last edited:
alastairstevenson
Staff member
I didn't see this post until after I'd posted mine above , it was awaiting moderation.