What is the de-bricking process for HIKVision camera and NVR firmware updates?

nstechhelp said:
I keep getting the same error as others in this post:

[2015-18-11 07:42:02] TFTP server [192.0.0.128] initialized
[2015-18-11 07:42:25] Connect client success [192.0.0.64]Success
[2015-18-11 07:42:25] Open file failure[C:\tftp\econt_Vision-AV2000]
Click to expand...

I'm having this issue as well. Using the SADP tool reveals that the NVR has a "0.0.0.0" IP address. The admin userID is not working (even with a password reset from this forum) so I can't manually set an IP address. I've tried with both a crossover cable directly into the NVR, and also connected it to the network. I plan to try (later tonight) using a switch with only the NVR and the laptop attached to it to see if that works.
 
jgatl said:
I plan to try (later tonight) using a switch with only the NVR and the laptop attached to it to see if that works.
Click to expand...
Good and bad news. I was able to use the switch suggestion as @nalastairsteveson suggested to get TFTP working. I had to change the firmware name from digcap.dav to digicap.dav. The only problem is that now the NVR is totally dead. I've rebooted the NVR several times with no luck. The SADP tool no longer shows the unit, and launching TFTP_update no longer gets past the initialization test. I've tried using both the switch and a crossover cable, neither get the NVR to respond.

Since I can't get the NVR to respond to TFTP, any other ideas on how to de-brick it?
 
The only problem is that now the NVR is totally dead.
Click to expand...
That's unlikely.
First of all - what is the model of NVR, and do you have any record of the serial number, and the originally installed firmware version?
What firmware did you install - version, supported models, link to it?

To show if there is some activity still in the NVR, you could try this:
Set your PC IP address to 192.0.0.128
At a command prompt, use 'ping -t 192.0.0.64'
Power cycle the NVR, and watch for any responses to the ping.
What would be normal is 2 or 3 responses a few seconds after power on.
If so - that suggests the bootloader may be operating normally.
 
I was unsuccessful with everything I tried. After contacting HikVision they asked me to send it back so they can flash the firmware.
 
It's in my downgrader.
 
Hello @ All,

I have a problem with one of my six IP Cams. Ok, not mine, but from a friend of mine.

These are all Trendnet TV-IP310Pi devices. As far as I know, these are re-branded Hikvision DS-2CD2032-I devices.
I was upgrading the Trendnet Firmware for all of these 6 devices, and at the last one, it failed!

They are currently connected to a PoE Switch and the working one starts as expected. Short red IR lamps on, then after a few secons cam is up and running, and I can access this device via Browser and if I enable telnet, also a connect via telnet is then possible.
If I open hikvisions "SADP" Tool, I can see both devices. The bricked one and the working one.

As I said, the bricked one seems to be in a boot-hang-freeze thing or so.
I can ping 192.0.0.64, I can see it in SADP, I can telnet this device, I can browse it via putty/telnet, I can start ftpd, but it does not start properly.
But only after I flashed a hikvision recovery 4.0.8 via TFTP which is dispayed as "DS-2CD-Min-System" whatever this mean.

Then I flashed the "5.2.5 downgrader" FW from "whoslooking", but all the same.
The device did not start properly.
Additionally to that, as soon as I have flashed the Firmware 5.2.5 or another, the SADP-Tool does not find the cam anymore.

I tried also to use the TFTP Server with the original or initial 5.1.7 Trendnet Firmware, but still the same, I cannot access via webpage, IR Lamps are on the whole time.

I did a research on the forum and via google about such errors, and found some threads where somebody wrote something about /davinci and /dav
But I have no idea how to get this fixed.


I also found out that the "/dev/initrun.sh" seems to be corrupted.
I will try to attach a screenshot as "1_putty_initrun.sh"

If I run this script manually, I get errors.
I will attach the output from putty.

I tried to get a recursive directory listing, but the limited busybox do not know the -R option.
So I connected via FTP filezilla, downloaded most of this stuff and did a dir /s on my windows desktop to provide a dir-listing
attached as dir-listing.txt


It would be nice if someone can help me out of this, as these cams are not mine, but from a friend of mine where I was asked to update the firmware.

Thanks a lot

.merlin
 

Attachments

That looks a little like some hardware problems.
You may have an unmapped-out bad block in the flash.
Maybe some clues in the kernel log - try 'cat /proc/kmsg' and save it somewhere to look through. It may show why the camera boots into min-system mode, as confirmed via SADP.
In that mode there are no web or application services, so you would expect errors trying to execute initrun.sh
 
Hi alastairstevenson

I tried again to flash the 5.2.5, but then I was again not able to find the device via SADP Tool.

Please find attached the requested log from cmd>cat /proc/kmsg

thanks
 

Attachments

Don't use the trendnet firmware, use the 5.16 in my signature via tftp this will recover the camera.
All trendnet camera are English region so no problems there, you should easily recover the bad flash with 5.16 then upgrade again to 5.30.
 
Hi whoslooking!

Thanks for that, but it does not work. :-(

I did it a few minutes ago, and the message in TFTP was ok at transfer and completed.
Then I closed TFTP, rebooted the cam, and since that, I cannot ping the cam, cannot find the cam with SADP, and as expected, I cannot use telnet to access the cam.

If I do again a flash via TFTP, this device is found by TFTP and I can do another flash procedure

Any ideas?
 
Thanks strange, did you get the successful message?
 
I got

1st run for 5.1.6
[2015-12-05 23:00:41] TFTP server[192.0.0.128] initialized
[2015-12-05 23:00:51] Device[192.0.0.64] test tftpserver
[2015-12-05 23:00:58] Connect client[192.0.0.64] success
[2015-12-05 23:00:58] Start file[C:\TFTP-Update\digicap.dav] transmitting
[2015-12-05 23:01:17] Completed file[C:\TFTP-Update\digicap.dav] transmit
[2015-12-05 23:01:34] Device[192.0.0.64] system update completed!


2nd try
[2015-12-05 23:06:39] TFTP server[192.0.0.128] initialized
[2015-12-05 23:06:50] Device[192.0.0.64] test tftpserver
[2015-12-05 23:07:00] Connect client[192.0.0.64] success
[2015-12-05 23:07:00] Start file[C:\TFTP-Update\digicap.dav] transmitting
[2015-12-05 23:07:18] Completed file[C:\TFTP-Update\digicap.dav] transmit
[2015-12-05 23:07:35] Device[192.0.0.64] system update completed!

EDIT:
I do not expect another message after "system update completed" right?
I am asking, because, the cam is not rebooting automatically.
I need to do a telnet initiated reboot, or have to unplug the PoE LAN Cable and plug it in again.
 
Any further Ideas?

I have somewhere read that it is important if the cam is EN or CN produced.
I cannot find the post.

What was the command to find out what version of cam I have?

And what do you think...
If my cam is maybe a CN model... ( I need to find out first )
Is it a good idea to flash the latest CN 5.3.0 and then go back to the EN 5.2.5 from the downgrader package?

Thanks
 
Hi @ All

I would very much appreciate your help to find a solution here.
I tried a lot in the meanwhile.
Falshed different FW versions, tried to understand the UBI stuf < but without luck. I did not understand this.
I tried to run the initrun.sh script, and the check scripts etc.

But I did not get the device in a runing state.
 
Excuse the delayed reply - been out on the bike today.
On your kernel log copy:

<6>Unpacking initramfs...
<0>Initramfs unpacking failed: junk in compressed archive
<6>Freeing initrd memory: 4096K
Click to expand...
That is why the camera is going into min-system mode. No initramfs (initial RAM file system) - no normal running environment.
I think this message is a bit (deliberately) misleading, we've seen it before when the 'hardware descriptor block' has been altered, maybe to affect the camera region settings.
Within that block is all the 'as-manufactured' information of the camera, including items relating to the OEM.
So I'm speculating that the real Hikvision firmware may be tripping up on the OEM-labelled hardware.
Though why this one is different from the others is guesswork.

If the device is almost 'expendable' I'd almost suggest trying to grab a copy of mtdblock5 and 6 from one of the working cameras, tweak the MAC address and maybe the serial number so it does not conflict, and apply it to the failing camera.
I'm fairly sure you could do that over telnet in min-system mode. It's long ages since I did that, I've forgotten the detail. @whoslooking - what do you think?

*edit* Someone has been 'going their dinger' with the old firmware updates ... <5>UBI: max/mean erase counter: 37/23
<5>UBI: MTD device name: "app_pri"
<5>UBI: MTD device size: 24 MiB
<5>UBI: number of good PEBs: 192
<5>UBI: number of bad PEBs: 0
<5>UBI: number of corrupted PEBs: 0
<5>UBI: max. allowed volumes: 128
<5>UBI: wear-leveling threshold: 4096
<5>UBI: number of internal volumes: 1
<5>UBI: number of user volumes: 1
<5>UBI: available PEBs: 0
<5>UBI: total number of reserved PEBs: 192
<5>UBI: number of PEBs reserved for bad PEB handling: 2
<5>UBI: max/mean erase counter: 37/23
<5>UBI: image sequence number: 245504465
<5>UBI: background thread "ubi_bgt1d" started, PID 321
<5>UBIFS: recovery needed
<5>UBIFS: recovery completed
<5>UBIFS: mounted UBI device 1, volume 0, name "app_pri"
Click to expand...
 
Last edited by a moderator:
True, that should work. same not done in a long time, but cloning works fine on 5.20 but limit the changes to just the mac address, the same serial number doesn't matter to the nvr.
 
  • Like
Reactions: forum-merlin
Okay!
thanks for that!

But to be honest, I am a little bit scared about that procedure.
I am really a newbe in IP Cams, and such things, and this device is quite new. We bought this a few weeks ago.

But If you tell me what I should do step by step for dummys, I can try it.

My questions at this point would be:

1)
what FW should I try to install on that bricked device to prepare it? Like a prerequisite. I think it should be an EN/ML Version, as all checked Trendnet Firmware were also EN/ML

Here a list of what FW I have:
Code: 
CN_Versions
=============
516digicap.dav.cn
525digicap.dav.cn
530downgraderdigicap.dav.cn
IPC_R0_CN_STD_5.3.0_150513.digicap.dav.cn

EN/ML_Versions
================
IPC_R0_EN_STD_5.2.3_141024digicap.dav.en.ml
DS-2xx2_v5.3.3_150912(For Chrome45).digicap.dav.en.ml

Trendnet_Versions all EN/ML
===================
FW_TV-IP310PI-5.1.6.dav.en.ml                        
FW_TV-IP310PI-5.1.7.dav.en.ml
FW_TV-IP310PI-5.1.8-150311.dav.en.ml

all listed FW were checked with "hiktools05R1.exe"

NOTE:
I rename the FW to "digicap.dav" when I run the TFTP to flash the Software to the device.

2)
I enabled telnet on a workling Trendnet Cam via Webbrowser Config Page, but I was not able to to connect due to a wrong user or password.
What is the password for telnet?
I tried 12345, then the admin password I had to set during the configiration, I tried root and admin as user and also as password but no luck. I googled the standard password, and what I found was the FTP Configuration to save things on a FTP


3)
If I can then access the working Trendnet...
Is it somehow possible to do a fullbackup/dump/...to use this to flash the bricked cam? If yes, how?
If not, what is then the next step?
Is it this what I found here ?? Link:

4)
I found out, that as soon as I can find the bricked device via SADP Tool, I can select it and can change the IP to a working IP which matches to my internal Network. then I am able to use putty instead of the windows XP embedded Telnet on my old Notebook.
Is it maybe possible to arrange a Screenshare with one of you guys via Teamviewer or so?
Please do not hate me. I am working in Customer Support and I know that this is really a bad request in this state but...
I am so sorry. But sometimes, I am too scared to do things just so. (without knowledge and as this is not my own device)


Thanks
BR

merlin
 
But to be honest, I am a little bit scared about that procedure.
I am really a newbe in IP Cams, and such things, and this device is quite new. We bought this a few weeks ago.

But If you tell me what I should do step by step for dummys, I can try it
Click to expand...


If you are feeling adventurous, here is something you could try, to hopefully bring the non-working camera back to a working state.
These steps are a guide, as opposed to an exact procedure, so apologies in advance for any errors.
And there is some risk that the outcome may not be good. But it should be reversible.
And I do not know if the TrendNet models have some difference that may invalidate this.
The idea would be to take a copy of mtdblock5 and mtdblock6 from a working camera, modify a byte within the definition of the MAC address so that there is no conflict on your network, and apply it to the failed camera.
Then it should be possible to load the same firmware as you loaded to the camera that the mtdblocks were taken from.
The assumption is that the firmware is old enough that the checksum does not matter. Though the checksum 'balance method' could be used.

Start a tftp server on the same LAN segment as the cameras are on. The Jounin one works well. http://tftpd32.jounin.net/
With a telnet or SSH client (PuTTY works well), log in to one of the working cameras.
The username=root, the password=whatever is the admin password for the web GUI.
At the command prompt, create a copy of mtdblock5 & 6 and save it off the camera
cat /dev/mtdblock5 > mtd5_source
tftp -p -l mtd5_source IP_address_of_tftp_server
rm mtd5_source
cat /dev/mtdblock6 > mtd6_source
tftp -p -l mtd6_source IP_address_of_tftp_server
rm mtd6_source
That's an 'l' for local in the tftp command line.
Save these files on the PC, labelled as 'donor mtdblocks' and make working copies.

On the working copies, use a hex editor (HxD works well) to modify the MAC address definition in the 'hardware descriptor block'.
There are 3 of these blocks in total, with the magic word SWKH at the start. I don't know which is active for the MAC address, so change all of them.
Take a look at the sample images here: https://www.ipcamtalk.com/showthrea...-2-8-Full-English-(INC-DAYS-OF-WEEK)-mtd-Hack
The MAC address is the group of 6 bytes beginning C0 above the serial number. Yours will differ.
Pick one of those bytes, say the third, and change the value by one bit, eg E3 to E2, and save. Do this on all 3 (1 plus 2) blocks, those beginning SWKH.
Now you have the modified donor mtdblocks that can be applied to the failing camera.
Save these files, labelled as 'modified donor mtdblocks'.

With a telnet or SSH client (PuTTY works well), log in to the failed camera in min-system mode.
At the command prompt, create a copy of mtdblock5 & 6 and save it off the camera
cat /dev/mtdblock5 > mtd5_save
tftp -p -l mtd5_save IP_address_of_tftp_server
rm mtd5_save
cat /dev/mtdblock6 > mtd6_save
tftp -p -l mtd6_source IP_address_of_tftp_server
rm mtd6_save
Now apply the modified blocks.
tftp -g -r mtd5_donor IP_address_of_tftp_server
cat mtd5_donor > /dev/mtdblock5
rm mtd5_donor
tftp -g -r mtd6_donor IP_address_of_tftp_server
cat mtd6_donor > /dev/mtdblock6
rm mtd6_donor
reboot

And see what happens.
Depending on what firmware you last loaded, you presumably will need to re-apply the updated Trendnet firmware.
Good luck.
 
  • Like
Reactions: forum-merlin
You must log in or register to reply here.
Top Bottom