Acquired a 'bricked' DS-2CD6362F-IVS

[iMx]

Hi there,


I've acquired what I assume to be a bricked DS-2CD6362F-IVS, it seems to be a Chinese grey import (CH in the Serial number signifies this I believe?). Have read as much as I can from this forum, and tried a few things, but I'd just like to know peoples thoughts.


I have no idea what has been done with the device, or if was ever running an English language hack/firmware, the sticker on the device says firmware 5.0.9 and what I assume is a build date of 07/2015. This firmware version does seem to be an archived/legacy version from what I can see, certainly on the US Hikvision site, so I guess a bodged upgrade is a significant possibility. I've ordered the required JST connector so I can hopefully get serial console access.


The device powers up, the IR glows red, it is pingable 3-4 times briefly on start up (192.0.0.64) then stops - it does not seem to be 'looping', to get it to ping again I have to remove/replace the power. It does not try to connect to 192.0.0.128 on port 9978, wireshark dumped from a host running on 192.0.0.128, so I'm not sure that it is going to be tftp-able? Even if I leave the device to 'boot' for 15 minutes, then load SADP (both v2 and v3 tried) it does not appear in this. Firewalls/security etc all disabled on the pc, tried Windows 7 and Windows 10 fresh builds.


So, am I right in thinking that the only way to potentially recover this is with serial? If so is it possible to reflash over the serial connection? Or does it sound 'bricked-bricked'/FUBAR?


Cheers

 

[Q™]

This is a new twist on the same old story.

 

[iMx]

Haha indeed - it felt very much 'my friend...' as I was typing it!

 

[Q™]

...Have read as much as I can from this forum, and tried a few things, but I'd just like to know peoples thoughts...

Apparently you haven't read enough because the the behavior you are experiencing has been reported, and the fix discussed, many times before in many different topics. So now, perhaps some benevolent member will find it in his heart to go over the entire process. Again. Only to be repeated next week I would imagine.

 

[iMx]

I think the camera I have is in a similar state to Karol P's from the unbricking thread, with a packet dump I do not see any attempts by the camera to reach out to 192.0.0.128, although it pings briefly which is the reason for it learning the ARP, but then goes silent. Have tried restarting it multiple (at least 50 or more) times, only thing I haven't tried so far (which I see worked for some one) is an external power supply rather than POE.

I believe without the camera even attempting to reach out to the TFTP server (UDP 9978/9979) then any attempts to locate the correct firmware, which sounds like a bit of a mine field given I do not know any of the history of this camera, would be pointless.

17:22:49.343271 ARP, Request who-has 192.0.0.64 tell 192.0.0.128, length 28
17:22:49.343355 ARP, Reply 192.0.0.64 is-at c4:2f:xx:60:xx:xx (oui Unknown), length 46
17:22:49.343383 IP 192.0.0.128 > 192.0.0.64: ICMP echo request, id 17015, seq 259, length 64
17:22:49.343505 IP 192.0.0.64 > 192.0.0.128: ICMP echo reply, id 17015, seq 259, length 64
17:22:50.344915 IP 192.0.0.128 > 192.0.0.64: ICMP echo request, id 17015, seq 260, length 64
17:22:50.345040 IP 192.0.0.64 > 192.0.0.128: ICMP echo reply, id 17015, seq 260, length 64
17:22:51.349966 IP 192.0.0.128 > 192.0.0.64: ICMP echo request, id 17015, seq 261, length 64
17:22:51.350113 IP 192.0.0.64 > 192.0.0.128: ICMP echo reply, id 17015, seq 261, length 64
17:22:52.354284 IP 192.0.0.128 > 192.0.0.64: ICMP echo request, id 17015, seq 262, length 64
17:22:53.359298 IP 192.0.0.128 > 192.0.0.64: ICMP echo request, id 17015, seq 263, length 64
17:22:54.361591 IP 192.0.0.128 > 192.0.0.64: ICMP echo request, id 17015, seq 264, length 64
17:22:55.366197 IP 192.0.0.128 > 192.0.0.64: ICMP echo request, id 17015, seq 265, length 64
17:22:56.368401 IP 192.0.0.128 > 192.0.0.64: ICMP echo request, id 17015, seq 266, length 64
17:22:57.372876 IP 192.0.0.128 > 192.0.0.64: ICMP echo request, id 17015, seq 267, length 64
17:22:58.375152 IP 192.0.0.128 > 192.0.0.64: ICMP echo request, id 17015, seq 268, length 64

 

[alastairstevenson]

This a one of those pricey fisheye cameras?
It's listed as Series 'Other' in the spreadsheet here : http://www.hikvisioneurope.com/portal/index.php?dir=Product Firmware/Front-ends/01--IPC/&file=List of IPC R0,R1,R2,R3,R4,R6,R7_ V2.1.xlsx
And if so, there is a fair selection of firmware available here : http://www.hikvisioneurope.com/portal/index.php?dir=Product Firmware/Front-ends/01--IPC/Fisheye(DS-2CD63XXF-I(S)(V))/

This for when you get the serial connection active.

 

[iMx]

Thanks for the reply - it is I believe, yes, 6MP fisheye.

I think my only hope is being able to initiate the TFTP from the camera itself (which I see someone else did), or flashing over the serial connection itself (if this is possible?). As it stands, it makes no attempt to fire out the 'magic packet' to initiate the TFTP, will update with some details when I get a serial connection.

 

[alastairstevenson]

when I get a serial connection.

You probably know that you need 2 items - the USB to TTL serial convertor, and the 4-pin 1.5mm micro jst connector with wires.

 

[iMx]

You probably know that you need 2 items - the USB to TTL serial convertor, and the 4-pin 1.5mm micro jst connector with wires.

I do indeed, thank you - I found the post with the pins, I already have a USB to TTL from flashing/unbricking various DSL modems/routers. Although the aforementioned post says 1.25mm?

EDIT: and I just found a post from you saying to ignore that post: "[FONT=&amp]But - ignore the link in that post to the connector, I don't believe it's correct at 1.25mm."[/FONT]

 

[iMx]

1.25 arrived this morning, cable is definitely 1.5!

 

[whoslooking]

You don't need to serial connection, to recover the camera, but you may find it easie.
it's a firmware issue nothing more, but It looks like you having possibly firewall issuse with the tftp app.

 

[iMx]

You don't need to serial connection, to recover the camera, but you may find it easie.
it's a firmware issue nothing more, but It looks like you having possibly firewall issuse with the tftp app.

The traffic dump was taken from a switch port mirror, no firewall - packet capture running on a server is usually pre any firewall, as it is from the interface, firewalls are usually software, even if a firewall were blocking the initial inbound request should still be seen (but with no response). The camera does not make any attempt to connect to any port, or device, over its network connection.

My understanding, is that the following should happen:

- Camera will try to connect to 192.0.0.128, when this happens an ARP request should be seen for standard Layer 2 communication. The camera never issues an ARP request for 192.0.0.128, so it is not trying to even locate a TFTP server - seeing the ARP request would confirm it is at least trying to start a connection, but it does not occur. Only when I ping from 192.0.0.64 (the server) do I see it ARP for the camera and succeed briefly, if within the 10 seconds of the camera starting up, but the camera itself never issues an ARP request without the server initiating a ping or similar first.
- Camera should then try to send a particular packet to the server's port 9978 from the client port 9979 and expects the server to echo it back. This does not happen either, the camera makes no attempt to fire out the aforementioned UDP traffic.
- Once that happens, it proceeds to send a tftp request (on the standard tftp port, 69). As neither of the above 2 precursors happen, this does not happen either.

 

[alastairstevenson]

My understanding, is that the following should happen:

That matches my experience, and understanding, with the UDP packets holding a 'magic number' as part of the handshake.
We've seen quite a few posts where the tftp handshake just doesn't happen, presumably the bootloader has been changed.
It's quite a while back that Hikvision removed their Hikvision-specific tftp updater from their websites.
One could speculate that it made it too easy to mess with the firmware. Yet another little obstacle placed in the way of people trying to make best use of their products.

 

[whoslooking]

the echo will only respond with a clear path to the tftp and any delay, firewall / pack check will prevent the tftp to respond. it's a simple process and normally something simple in the setup stops it from working.

especially on older firmware builds.

 

[iMx]

U-Boot 2.0.8-93288 (Sep 26 2014 - 16:10:53)

*** Warning - bad CRC, using default environment
crc=0x8f1a8b9b,env.crc=0xffffffff
ARM Clock: 152MHz
DDR Clock: 528MHz
Cortex freq: 750MHz
Hit Ctrl+u to stop autoboot: 0
|BIND err|
Unknown command:null
nand booting ...
load kernel...
load ramdisk...
init started: BusyBox v1.19.3 (2014-09-11 13:45:58 CST)
starting pid 457, tty '': '/etc/init.d/rcS'
Starting udev: [ OK ]
starting pid 687, tty '': '/sbin/iptables -A INPUT -p tcp --dport 23 -j DROP'
starting pid 688, tty '': '/sbin/iptables -A INPUT -p tcp --dport 21 -j DROP'
starting pid 689, tty '': '/sbin/inetd -f -e /etc/inetd.conf'
starting pid 690, tty '': '-/bin/sh'


BusyBox v1.19.3 (2014-09-11 13:45:58 CST) built-in shell (ash)
Enter 'help' for a list of built-in commands.

UBI device number 1, total 192 LEBs (24772608 bytes, 23.6 MiB), available 0 LEBs (0 bytes), LEB size 129024 bytes (126.0 Ki
B)
waiting for /dev/ubi1_0.
Check dir /dav ok! (0)
UBI device number 3, total 32 LEBs (4128768 bytes, 3.9 MiB), available 0 LEBs (0 bytes), LEB size 129024 bytes (126.0 KiB)
waiting for /dev/ubi3_0.
Check dir /davinci ok! (0)
UBI device number 4, total 32 LEBs (4128768 bytes, 3.9 MiB), available 0 LEBs (0 bytes), LEB size 129024 bytes (126.0 KiB)
waiting for /dev/ubi4_0.
Check dir /config ok! (0)
#

First boot... eth0 was not up, nor did it have an IP assigned. Only ports listening were for telnet:

# netstat -tanp
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:23 0.0.0.0:* LISTEN 689/inetd

Manually assigned an IP to eth0, brought the interface up, flushed iptables, and now have a telnet login:

laptop:~ $ telnet 10.x.x.171
Trying 10.x.x.171...
Connected to 10.x.x.171.
Escape character is '^]'.


Ambarella login:

No 'upgrade' binary in the bin path, so tftp from busybox and running upgrade is not going to work.

# ls /bin/
[ cp egrep gunzip mknod pppoe sync uname
[[ cut env gzip mount ps tail uniq
ash date expr iostat mpstat pwd tar vi
awk dd false kill mv rm test wc
bash df fgrep ln netstat rz top zcat
busybox dmesg free login ping sed touch
cat du fsync ls ping6 sh true
chmod echo grep mkdir pppd sleep umount

On reboot....

# reboot
The system is going down NOW!
Sent SIGTERM to all processes
Sent SIGKILL to all processes
Requesting system reboot


U-Boot 2.0.8-93288 (Sep 26 2014 - 16:10:53)

*** Warning - bad CRC, using default environment
crc=0x8f1a8b9b,env.crc=0xffffffff
ARM Clock: 152MHz
DDR Clock: 528MHz
Cortex freq: 750MHz
Hit Ctrl+u to stop autoboot: 0


BusyBox v1.19.3 (2014-04-03 14:08:33 CST) built-in shell (ash)
Enter 'help' for a list of built-in commands.

Formatting ................................................................................................................
...................................................................................... done!
[ INFO][MIN]TFTP: TFTP from server 192.0.0.128
[ INFO][MIN]TFTP: Filename: 'digicap.dav'
###########################################################################################################################
###########################################################################################################################
###########################################################################################################################
###########################################################################################################################
###########################################################################################################################
##############################################################################################################################################
[ INFO][MIN]TFTP: Download File [OK]
[ INFO][MIN]BURN: File size is 19402629 bytes (18947 KB)
Flashing hImage to /dev/mtd9 OK
Flashing hImage to /dev/mtd10 OK
Flashing hroot.img to /dev/mtd11 OK
Flashing hroot.img to /dev/mtd12 OK
Flashing /dav/initrun.sh OK
Flashing /dav_sec/initrun.sh OK
Flashing /dav/HZK16.bin OK
Flashing /dav_sec/HZK16.bin OK
Flashing /dav/ASC16.bin OK
Flashing /dav_sec/ASC16.bin OK
Flashing /dav/certs.tar.gz OK
Flashing /dav_sec/certs.tar.gz OK
Flashing /dav/IEfile.tar.gz OK
Flashing /dav_sec/IEfile.tar.gz OK
Flashing /dav/execSystemCmd OK
Flashing /dav_sec/execSystemCmd OK
Flashing /dav/da_info OK
Flashing /dav_sec/da_info OK
Flashing /dav/pppd OK
Flashing /dav_sec/pppd OK
Flashing /dav/pppoe OK
Flashing /dav_sec/pppoe OK
Flashing /dav/pppoed OK
Flashing /dav_sec/pppoed OK
Flashing /dav/check_config OK
Flashing /dav_sec/check_config OK
Flashing /dav/alsa-lib.tar.gz OK
Flashing /dav_sec/alsa-lib.tar.gz OK
Flashing /dav/idsp.tar.gz OK
Flashing /dav_sec/idsp.tar.gz OK
Flashing /dav/t1 OK
Flashing /dav_sec/t1 OK
Flashing /dav/driver.tar.gz

Then, after flashing/reboot:

U-Boot 2.0.8-93288 (Sep 26 2014 - 16:10:53)

*** Warning - bad CRC, using default environment
crc=0x8f1a8b9b,env.crc=0xffffffff
ARM Clock: 152MHz
DDR Clock: 528MHz
Cortex freq: 750MHz
Hit Ctrl+u to stop autoboot: 0
|RCV UDP pack timeout|
Unknown command:null
nand booting ...
load kernel...
load ramdisk...
init started: BusyBox v1.19.3 (2014-09-11 13:45:58 CST)

Note that this time there was no 'BIND err' as there was with the boot initially:

|BIND err|

Perhaps if I'd have used an external power supply (which I didn't have) this might have worked around it, it looks almost like the network interfaces are not initialised fast enough when booting over POE - firmware bug perhaps? But when you soft reboot via the console, the interface is already up and so 'binds' correctly.


I also note that there was no RCV UDP timeout in the first boot, perhaps confirming that it wasn't attempting to tftp at all:

|RCV UDP pack timeout|

Anyway, seems to be resolved, many thanks @alastairstevenson for bouncing ideas/thoughts. And to scotlamb for producing the python TFTP server for us *nix users:

https://github.com/scottlamb/hikvision-tftpd

EDIT: So, curiosity got the better of me, to try and reproduce - flashing the 5.3.5 from Hikvision USA site, returns the camera to the state I initially had it in. Again you see the 'bind err' on boot, to get it to tftp you need to run 'ifconfig eth0 up' from the console, then reboot the camera via the console again, it will then attempt to tftp on the next boot.

 

[alastairstevenson]

Brilliant! Well done indeed. And good observations, quite pertinent.

No 'upgrade' binary in the bin path, so tftp from busybox and running upgrade is not going to work.

Could be in /usr/bin but also I have a vague recollection there is an update or upgrade in some of the Hikvision-specific u-boot.
You might want to (carefully) try a saveenv in u-boot to clean up the configuration complaint.
Interesting that the initial boot was to /bin/sh - was that you, or the result of the 'default environment'?