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

OK here is the result...

It did NOT work.
Same as before.

I did exactly what you wrote. except the MAC Address part.
As I knew the mac from the working cam, and I knew the MAC from the bricked cam, I changed the MAC in HxD then so that it matched to the bricked defice.
I used the search function in HxD to make sure that the HEX String for the MAC was found.
I changed it then in mdt5_source and mtd6_source and saved them then as mtd5_modifed and mtd6_modified.

Then I wollowed the rest of the procedure and it felt quit good.
Then I did the reboot and checked what the bricked device was doing.
I saw that the red IR Lamps did a short flickering after i pressed enter for the reboot and it is still the same as before.
red IRs still glowing, I can access via telnet, SADP finds the device and still the DS-2CD-Min-System is shown

Then I started TFTP again and tried to flash the initial Trendnet 5.1.7 Firmware.

After a reboot then, or also after a power off / on the SADP shows the device and also Min System and same as before


Mabe another hint...
Everytime when I logon via telnet the initial message is:
Code: 
(none) login: root
Password:
login: can't chdir to home directory '/root/'
# cd /
# ls -la
drwxrwxrwx    2         0 Jul 14  2014 lib
drwxrwxrwx    2         0 Jul 14  2014 sbin
drwxr-xr-x    2       160 Dec  9 12:35 davinci
drwxrwxrwx    3         0 Jul 14  2014 usr
drwxr-xr-x    2         0 Dec  9 12:36 home
drwxr-xr-x    2       160 Dec  9 12:35 config
drwxrwxrwx    2         0 Jul 14  2014 bin
drwxr-xr-x    2      1792 Dec  9 12:35 dav
drwxr-xr-x    2      1792 Dec  9 12:35 dav_sec
drwxrwxrwx    3         0 Jul 14  2014 etc
drwxr-xr-x   11         0 Dec  9 12:36 sys
-rwxrwxrwx    1         6 Jul 14  2014 VERSION
drwxrwxrwx    2         0 Jul 14  2014 tmp
drwxrwxrwt    3      3120 Dec  9 12:36 dev
dr-xr-xr-x   59         0 Jan  1  1970 proc
lrwxrwxrwx    1         9 Jul 14  2014 init -> sbin/init
drwxrwxrwx   16         0 Jul 14  2014 ..
drwxrwxrwx   16         0 Jul 14  2014 .
#
So there is no /root home folder for root user

as soon as I create a root folder with
cmd>mkdir /root
logoff / logon this message is gone.

Bit see the attached Screenshots. The telnet window with the colored folders is from the trendnet cam whcoh is working
the other is from teh Min-System bricked device

Is this normal?

Additionally...

Is it normal that the bricked device has a /dav and a /dav_sec ??


Why is the working one showing the permissions and also owner and group details and the bricked one not?



Hope that you still have ideas to get this thing back to workign state.

Thanks

merlin


working_cam_telnet.jpgbricked_cam_telnet.jpg
 
You did well to get through that lot.
A shame there was no good result though.

(none) login: root
Password:
login: can't chdir to home directory '/root/'
Click to expand...
That's normal and means nothing - if I remember right it's some faulty line in 'profile' if I recall, in some firmware versions.

On the different styles of listing:
With no 'initrd' (Initial RAM file system) the camera is missing all the normal utilities that are found there, such as busybox, and /etc/profile both of which affect how items are displayed in the shell.
I've not explored the 'min-system' - but it's a stripped down old kernel that will run an old ls for example.

What's required is to figure out the cause of the 'junk in compressed archive' message. Which I don't believe means what it says.
Quite a while back, when Hikvision changed the way that the checksum covering the 'hardware descriptor block' was scoped, I did a few tests to try to figure out what the new coverage region was.
I soon gave up as it was a tedious testing process.
But when you invalidated the checksum, on bootup the error was 'junk in compressed archive' and the camera went into min-system mode. @whoslooking promoted the method (driven by the genuine need to change region when cameras got Chinese menus after firmware updates) of taking one bit off the region byte, and adding one bit somewhere else that didn't matter, which did not compromise the checksum validation as it was still a simple sum - Checksum-16
There could be other integrity checks that give the same bootup error.
But I'm wondering if your camera is having a checksum problem.
The original scheme was easy enough to figure.
If you look at mtdblock6 here: https://www.ipcamtalk.com/showthrea...-2-8-Full-English-(INC-DAYS-OF-WEEK)-mtd-Hack,
the value in 0x04,0x05 is (in HxD parlance) the Checksum-16 sum of (the number of bytes in 0x08 [usually 0xF4]) that immediately follow 0x08.

So here is a suggestion to try if you are up for it:
With HxD, check out the donor, unchanged mtdblock6 and see if the stored checksum matches the Checksum-16 value of the 0xF4 bytes that are covered.
If it does (or maybe even if it doesn't), use the donor mtdblocks unchanged in the failing camera and see if it boots OK.
You'll need to unplug the donor camera to avoid a duplicate MAC address on the network.
In the unlikely event that does something useful, you could try the 'balance method' of changing the MAC address, one byte up a bit, one byte down.
 
Last edited by a moderator:
  • Like
Reactions: forum-merlin
Hi alastairstevenso

Thanks for your help so far.
I did what you wrote, and tried to modify again the source from the working cam and this time I changed the MAC but at the end I had the same checksums

mtd5_mod2 had the same checksum as mtd5_source and also mtd6_mod2 had the same checksum as mtd6_source

I uploaded it via TFTP and modifies the /dev/mtdblock5 and 6 as written.
Code: 
tftp -g -r mtd5_mod2 10.11.12.97
tftp -g -r mtd6_mod2 10.11.12.97

cat mtd5_mod2 > /dev/mtdblock5
cat mtd6_mod2 > /dev/mtdblock6

rm mtd5_mod2
rm mtd6_mod2

reboot

Then I tried to flash the Trendnet Firmware 5.1.7 to the device which was the FW i tried to update to 5.1.8 when it failed.

Then after a while the SADP shows the Device again with the modified MAC, but still the same 4.0.8 Min system

then I disconnected the source cam where I extracted the mtd5_source Files and uploaded them to the bricked device

Same situation.

Maybe I do something wrong by "installing" the Trendnet Firmware?

I downloaded the official Trendnet Firmware
Is is then a "FW_TV-IP310PI-5.1.7.dav"
I rename it to digicap.dav and copy it to the TFTP Server Folder

Then I disconnect the PoE Cable and start TFTP Server
Then I plug the cable back to te cam and I can see all the messages to transfer the FW to the Cam. Then after the "completed" message appeard I close the TFTP Server Software, connect via telnet, and type reboot
I can see then a very short flickering of the IR Lamps and thats it.
Then it takes a few minutes (2min or so) and I can see the device again in SADP Tool

then,as it is still the min-System, I select the cam in SADP Tool and adjust the IP and so on. Then I can access the cam again via telnet

Any further suggestons?

Could you, or @whoslooking
help me via a short remote session?

I prepared everything

HxD Editor, saved files, putty, TFTP, etc.

Thanks

merlin
 
Hi @ All

here is a short update.
The bricked cam is up and running again.
But, with a wrong MAC Address from one of my other Cams

Why this could be...
I had a chat with @alastairstevenson
And we checked the mtdblock 5 and 6 and tried to modify it to get the device back to a normal boot.
Code: 
cat /dev/mtdblock5 > mtd5_source
tftp -p -l mtd5_source 192.168.1.97
rm mtd5_source

cat /dev/mtdblock6 > mtd6_source
tftp -p -l mtd6_source 192.168.1.97
rm mtd6_source
But they did not look too bad.


Then we found out that the initd seems to be a or the problem. This initd is in mtdblock11
So I wanted to download the mtd11 from the bricked cam and got a
Code: 
# cat mtdblock11 >mdt11_brickedcam
cat: read error: Input/output error
#

So I checked what to expect from a working cam, and this was without a problem.
I also noticed that the working mtdblock11 was 4096KB
The bricked had only 140KB


Then I checked all mtdblock`s and found out that mtdblock13 and mtdblock14 had the same output as mtdblock11
Code: 
# cat mtdblock13 >mdt13_brickedcam
cat: read error: Input/output error
#
#
# cat mtdblock14 >mdt14_brickedcam
cat: read error: Input/output error
#
All others were without that I/O Error


However...
I only took the mtdblock11 from a working cam and uploaded it to the bricked cam and did a reboot via telnet.
Nothing happend. Same as before. IR Lights on, but nothing more.

Then I flashed the original Trendnet Firmware 5.1.7 via TFTP, did a reboot and... Tadaaaa, the Cam is back again.
It is working.
I can access the webinterface, can see the live view etc.

BUT,
I noticed that I have now a MAC from the source Cam.
And this is a conflict in the network, and this mean I need to modify this now.

Where (in what mtdblocks) do I need to tweek this with HxD ?




Thanks

merlin
 
Hey, well done!
Go to the top of the fast learning and problem solving class!
So it looks like the entry in the kernel log 'uncompressing initrd - junk in compressed archive' was real, and not just a (deliberately) misleading message as I had thought.
But there has been some sort of problem with the flash memory that has caused mtdblock11 and 13 to be corrupted.

On the MAC address - it's my understanding that it is defined in those bytes in the 'hardware descriptor block' that you already modified from the copy from the working camera.
Is the serial number of the camera that is now working the same now as that of the source camera?
If so - is there a possibility that the source mtdblock5 & 6 are still in the camera that is now working?
So it should be the case that changing mtdblock5 and 6 should change the MAC address.

On the original cause - the flash memory has some redundancy, so that the camera can still operate with a secondary segment if the primary segment is faulty:
Code: 
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"
So it may be worth checking the kernel log (cat /proc/kmsg) just to see if there is any mention of I/O errors, bad blocks or flash problems.
 
  • Like
Reactions: forum-merlin
Someone was happy too soon - me!
:-(

Now the device is not working...
What I tried to do is...


I put the mtdblock5 and 6 back to get the right MAC back.
SADP found the device again with the right MAC but still Min-System

Then I put the mtdblock11 from the working cam to the bricked, flashed the Trendnet 5.1.7 again and now the device is again in Min-System mode

hmmm...


what is with mtd8 ??
This sounds like RECOVERY?
Can I do something with it?
Code: 
# 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"
#
 
This is starting to sound like a hardware problem - maybe the flash is corrupted again.
You may get a clue in the kernel log cat /proc/kmsg then Control-C to exit. And maybe dmesg gives different and useful information.
I do not know for sure - but would speculate that mtd8 holds the min-system recovery environment.
 
I think so too. After I did all this stuff, I found out that the "cat /dev/mtdblock11 > mtd11_sav2 " failed again with an I/O Error

But I am back again to my MAC. this is important I guess for a RMA

Attached, you can find the today´s dmesg and kernel messages.

If you see something like "Ahhh! Here it is, do this and this and it will work" I am happy.

If not, also not a problem. I think I will tell my buddy to send this cam back and ask for a replacement.

I would like to take the chance to say "THANK YOU ALL FOR YOUR HELP!, and have a nice christmas!

Thanks

Merlin!
View attachment dmesg_2015-12-13.txt
View attachment cat-proc-kmsg_2015-12-13.txt
 
Hi all,

I sent this defect cam back to the seller and ask for a new device. Still waiting for the new device.
As this was for a friend of mine, I was then thinking for a while to order some devices for me personally.

So I am going to buy directly from china via aliexpress.com.
Today I discussed the details with the seller in the chat.
This is the Seller http://s.click.aliexpress.com/e/bQTigEBq

He told me that the devices have Multi Language Firmware 5.2.5 on it. And cannot be updated if I want, otherwise they will be chinese then. And they have the Hikvision Logo on the device and also the Chiniese Symbols as Logo.

I know the threads where I can modify the FW then to get it back to EN then.
But my question is...

Is it somehow possible to do a Fullbackup of the existing status?
I have learned that I can do it for mtdblock`s via cat command and pipe it to a file and put then the file via TFTP to a Storage outside a cam.

Is this a possible way to backup the original Firmware or is there another way available?


Thanks

merlin.
 
I have learned that I can do it for mtdblock`s via cat command and pipe it to a file and put then the file via TFTP to a Storage outside a cam.
Click to expand...
This is certainly possible - but the question would be how do you then use the result to create usable firmware that could be applied? I don't know - perhaps others may comment.
Maybe you could ask the reseller for a copy of the firmware that they have applied to the camera. Then with a copy of the configuration after you have set it how you like, you'd have the fallback position.
 
darrylb said:
Hello everyone,

I am trying to unbrick my 5.2 that went wrong... I run the tftp server, assign it 192.0.0.128 on my desktop (ip), I see the "TEST" statement show, but never get a connection. When I ping 192.0.0.64, I get about 3 ping responses and then it stops. a few minutes later, I get consistent pint replies. Any suggestions? I have tried another TFTP server, no success.

Thanks.

UPDATE: I am using the HIKTOOL right now, in an attempt to get this to work. It shows "HIKTOOL TEST", but nothing beyond that. I have turned the firewall off on my PC. I am using wireless, but only because I don't have a computer device I can use in the garage. Seems my work has group policy set on my work laptop to prevent me from using static ip...
Click to expand...


Hi,
i have the same issue where i updated the fw and now i cannot access the camera. i have reset it and when i ping it, i get 2-3 pings every 10 or so responses. it seems to be auto booting.
i dont know what to do. Any ideas would be great.
Cheers
 
You need to upgrade with compatible firmware - it sounds like it's in a boot loop.
i dont know what to do. Any ideas would be great.
Click to expand...
Loads and loads of threads on this forum on that topic.

But without any info, it's not easy to give definite suggestions. Just put yourself in the position of the reader.
What camera?
What firmware version and date on the label?
What region is the camera, as shown in the serial number?
What firmware did you use to update it and how?
What does SADP show if anything?
etc
 
alastairstevenson said:
You need to upgrade with compatible firmware - it sounds like it's in a boot loop.

Loads and loads of threads on this forum on that topic.

Hi Alistair,
Thanks for replying,
I have filled in requested info.

But without any info, it's not easy to give definite suggestions. Just put yourself in the position of the reader.
What camera? DS-2CD2532F-IWS
What firmware version and date on the label? V5.3.0_150513
What region is the camera, as shown in the serial number? 528376053 or OAQYVP
What firmware did you use to update it and how? IPC_R0_EN_STD_5.3.0_150814.zip then from cameras page
What does SADP show if anything? nothing shows up in it.
etc
Click to expand...

I have another camera which works fine

Cheers
George
 
Hi Alistair,

the tftpserv is picking up the camera 192.0.0.64 but that's it - no more progress from there. When I ping that ip in get about 10 pings then nothing.
I've followed the procedure to the letter but no luck.

cheers
George

update - it finally appeared in SADP but I can't update it. as you can see, the ip is 192.168.1.64 and some of the fields are greyed out and I'm unable to update.
 

Attachments

  • sadp.png
    sadp.png
    15.3 KB · Views: 17
  • sadp1.png
    sadp1.png
    12.6 KB · Views: 18
Last edited by a moderator:
It's running in the 'min-system' recovery mode, as indicated by the 4.0.8 firmware version. A minimum system, no web services.
This is usually due to incompatible firmware being installed.
the tftpserv is picking up the camera 192.0.0.64 but that's it - no more progress from there.
Click to expand...
Is that the 'test tftp server' message?
Make sure your PC isn't running on WiFi, ensure the digicap.dav file is in the same folder as tftpserve.exe and try power cycling the camera a few times. Sometimes it doesn't work first time round.
 
alastairstevenson said:
It's running in the 'min-system' recovery mode, as indicated by the 4.0.8 firmware version. A minimum system, no web services.
This is usually due to incompatible firmware being installed.

Is that the 'test tftp server' message?
Make sure your PC isn't running on WiFi, ensure the digicap.dav file is in the same folder as tftpserve.exe and try power cycling the camera a few times. Sometimes it doesn't work first time round.
Click to expand...

Hi Alastair,


thanks for all your help, much appreciated!!

I had a thought today - maybe my issue is with the laptop i was using so i installed the tftp serv on a different PC. i put the tftpserv and digicap.dav in a tftp folder in the root directory then ran tftpserv. To my surprise it worked, it unbricked my camera. i have reset all the settings i want on the camera.


Just a side note - the reason i tried to upgrade the firmware in the first place was because the SD card i put in the camera wasn't formatting. i still isn't formatting - Any ideas on that?


Cheers
George
 
Excellent, well done!
Now export the camera settings (maintenance menu) and save them somewhere safe.
What's different between the laptop and the PC? (may help others with similar symptoms) Win10 vs Win7 maybe?

On the SD card - maybe try another - it wasn't a cheap possibly fake by any chance?
What size is it - should be OK if 32GB or less. For larger I think newish firmware is needed, though I don't recall the specifics.
 
it is this cheap chinese one - 32GB Micro SD Card TF Flash Memory MicroSD Micro SDHC Class 10


I have put it in a laptop and formatted it and it seems to work but not in camera. i'll try a different one

alastairstevenson said:
Excellent, well done!
Now export the camera settings (maintenance menu) and save them somewhere safe.
What's different between the laptop and the PC? (may help others with similar symptoms) Win10 vs Win7 maybe?

On the SD card - maybe try another - it wasn't a cheap possibly fake by any chance?
What size is it - should be OK if 32GB or less. For larger I think newish firmware is needed, though I don't recall the specifics.
Click to expand...
 
You must log in or register to reply here.
Top Bottom