Hikvision NVR and Camera's and DHCP/POE

[archjeb]

Folks,

First post here on ipcamtalk - hoping you can point me in the right direction.

I just upgraded & replaced my old Foscam IPCAM's that I've had in place for several years with a bunch of Hikvision IPCAMs and a DS-7616NI-Q2 NVR which has the 16 ports of POE on the back of it.
I probably should have just used a standard PoE switch and provided DHCP for all my IPCAMs, but that is for another discussion.

So what I'm trying to figure out is why this NVR is kind of a half baked DHCP server? I tried to plug my laptop in it, and I don't get a DHCP offer. It looks like a bunch of SSDP packets blasting out the ports. Ok no big deal, I can hard set my IP to the 192.168.254.0/24 network which was the default Hikvision subnet for this integrated PoE switch...

When I plug my camera's into the NVR, the addresses seems to be handed out haphazardly and not really sequentially.

I guess what I would have really liked was a way to have a DHCP reservation for each IPCAm so it was predictable of which IP would be offered to each camera. So trying to work with this NVR, I tried to hard set the IP for each camera in the 192.168.254.0/24 network which was the default subnet for the NVRs built-in switch/PoE interfaces.

I also put a NAT/firewall on one of the ports (port 16) so I could have remote access to the 192.168.254.0/24 network (yes I see there is Virtual Host support...but I don't trust this NVR when I really need direct access to the ip cams). This works just fine...and I can get direct access to each camera. I'm doing Source NAT from my private network so all the IP CAMs on the PoE switch think I'm 192.168.254.254. So this works like a champ.

My cameras are working for the mos t part, but I don't like the fact that the IP's are all over the place and when I move a camera from one PoE port to another, sometimes it takes a while for the NVR to get it get plug-n-play crap to work. So I really want to statically configure everything.


So here is the deal:

-Now when I log into a camera and I hard set the IP to something a little more programmatic like Cam in PoE port 1 gets an IP of 192.168.254.101/24, Cam in port 2 gets an IP of 192.168.254.102/24, etc.etc. I can hard set the IP on the camera and when it reboots, this new (hard set IP) is ping-able for a few seconds and then the darn NVR seems to try to push the old IP address to the camera! Now I didn't even have DHCP check box enabled on the IPCAM. I also hard set the port on the NVR to 'manual' from the original 'plug and play / Hikvision' setup. So why in the heck is this NVR trying to over ride what I'm trying to hard set? Is there a way to do what I want to do?

Is there a way to clear all of the IP CAMERA management settings on the NVR without doing a total factory reset on the NVR? I click on the 'delete' IP CAM on the NVR under Camera Management...and the Web UI just hangs...so that doesn't appear to work.
I'm a Linux geek...so I would have rather just had a dhcpd.conf file to edit and call it good. But it appears that I'm fighting this NVR's pseudo-play-n-play interface.

Any suggestions on how to best deal with this?

Thanks,

-J

 

[John Williamson]

I wouldn’t bother resetting the NVR - you’ll initially get sequential addresses but the first time you replace/swap a camera you’ll be back where you started. Starting from scratch the NVR uses 192.168.254.1 for accessing its web server on the POE ports then .2 for cam 1, .3 for cam 2 and so on. As said if you put 8 cameras on cam 8 will be .9 and let’s say you go on to replace cam 2 later - rather than adopt the previous .3 address it will assign the next sequential address .10 using plug n play.

Option 1 - put up with the random plug n play addressing. It’s easier to just access the individual camera web page using virtual host via the NVR’s LAN side IP address. For example if your NVR address is 192.168.0.1, you’ll access camera 5 at 192.168.0.1:65005. There’s no need to connect to a spare POE port and regardless of the plug n play IP address assigned, the port number will always be 65001-65016 according to the POE port position.

Option 2 - if you’re a little obsessive about things being orderly (something I’m guilty of). Activate and program your 8 cameras in the range 192.168.254.101 - 192.168.254.108 (example) - you need only change the IP address, no need to touch the other network parameters, just set the admin password. Important - BEFORE reconnecting the cameras to the NVR, access the NVR GUI camera section and edit each cameras setting from plug n play to manual and enter the IP address and the password you’ve assigned. Then when you plug the cameras back in they’ll connect without the NVR attempting to override what you’ve set in the camera. You can then (using my previous example) access camera 3 at either 192.168.0.1:65003 while on the LAN or 192.168.254.103 while connected to a spare POE port.

 

[SecurityCams]

I have the same NVR Re-branded from getscw.com and the manual let me know if you want a copy

 

[alastairstevenson]

So what I'm trying to figure out is why this NVR is kind of a half baked DHCP server?

It's not - it simply has management control of all the camera configuration elements via the Hikvision API.

When I plug my camera's into the NVR, the addresses seems to be handed out haphazardly and not really sequentially.

The addresses uses are those defined in the NVR PoE channels.

I can hard set the IP on the camera and when it reboots, this new (hard set IP) is ping-able for a few seconds and then the darn NVR seems to try to push the old IP address to the camera!

You need to define those addresses in the NVR PoE channels.

So why in the heck is this NVR trying to over ride what I'm trying to hard set? Is there a way to do what I want to do?

That's because the NVR has the camera management role via the Hikvision API over the 'command and control' port 8000.

(yes I see there is Virtual Host support...but I don't trust this NVR when I really need direct access to the ip cams)

If you add a static route to the 192.168.254.0/24 subnet via the NVR LAN interface IP address (and set the camera default gateway to the NVR PoE interface IP address 192.168.254.1) then you'll get direct access to the cameras using the NVR Linux 'IP_forward' kernel facility.

 

[archjeb]

If you add a static route to the 192.168.254.0/24 subnet via the NVR LAN interface IP address (and set the camera default gateway to the NVR PoE interface IP address 192.168.254.1) then you'll get direct access to the cameras using the NVR Linux 'IP_forward' kernel facility.

How do you enable ip_forwarding on this NVR? It appears to be a tweaked version of busybox that doesn't have cat or echo commands.

'''
# # cat /proc/sys/net/ipv4/ip_forward
'cat' Not Supported, Try 'help'
'''

 

[alastairstevenson]

How do you enable ip_forwarding on this NVR?

Before Hikvision introduced the 'Virtual Host' feature, I modded a startup script in the firmware to hard-code the ip_forward setting in the kernel, so I could access the NVR PoE-connected cameras directly as needed.
But when Hikvision introduced Virtual Host, enabling it implicitly sets ip_forward to 1 so the tweak was no longer needed.

alastair@PC-I5 ~ $ telnet 192.168.1.210
Trying 192.168.1.210...
Connected to 192.168.1.210.
Escape character is '^]'.

dvrdvs login: root
Password:


BusyBox v1.16.1 (2016-06-29 13:49:45 CST) built-in shell (ash)
Enter 'help' for a list of built-in commands.

psh: applet not found
[root@dvrdvs /root] # cat /proc/sys/net/ipv4/ip_forward
1
[root@dvrdvs /root] #

The shell you encountered is Hikvision's 'psh' 'protected shell' that has none of the useful commands of a regular shell.
There is a command to exit it (debug or zhimakaimen) but the challenge/response has been well protected by Hikvision.

 

[archjeb]

Thanks for the quick response.

 

[archjeb]

So I got all my IP's sequentially set via manual. As long as I hard-set it to manual under the Camera Management on the NVR...and then logged into each individual camera directly on their 192.168.254.x interface and hard set the IP to whatever I manually configured on the NVR...then it worked just fine. If I did it the other way around and was not fast enough, the NVR would over write my config change.

The only other issue is with the DS-KB8112-IM that i'm using as a video source on one of the channels. Since its a different issue, I created another thread on that issue.

Thanks again for the pointers and the quick feedback.

-J

 

[bashis]

The shell you encountered is Hikvision's 'psh' 'protected shell' that has none of the useful commands of a regular shell.
There is a command to exit it (debug or zhimakaimen) but the challenge/response has been well protected by Hikvision.

Did some research on this, and to me it looks like the base64 encoded string contains of: [03000000][MAC of the device in binary][Random]

Where the Random (Ghidra) pseudo C code is:

  else {
    gettimeofday(&local_20,(__timezone_ptr_t)0x0);
    DAT_00085e94 = local_20.tv_sec;
    DAT_00085e98 = local_20.tv_usec;
    __seed = time((time_t *)0x0);
    srand(__seed);
    iVar2 = rand();
    uVar1 = DAT_00085e84;
    DAT_00085e04 = DAT_00085e88;
    _DAT_00085e08 = (undefined2)DAT_00085e8c;
    DAT_00085e00 = DAT_00085e84;
    DAT_00085e0a._0_2_ = (undefined2)iVar2;
    DAT_00085e0a._2_2_ = (undefined2)((uint)iVar2 >> 0x10);
    __seed = DAT_00085e8c & 0xffff;
    param_1[1] = DAT_00085e88;
    *param_1 = uVar1;
    param_1[2] = __seed | iVar2 << 0x10;
    *(undefined2 *)(param_1 + 3) = DAT_00085e0a._2_2_;
    *param_2 = 0xe;
    memcpy(&DAT_00087eac,&DAT_00085e00,0x9c);
  }
  return uVar3;

Example: [03 00 00 00] [aa bb cc dd ee ff] [6c b1 59 28]

This base64 encoded code seems to be used by Hik to decode and RSA encrypt the binary string (to what I have seen), and should be confirmed with this URL.

I've found three Public RSA keys, where the first seems to be the one to decrypt (the other two has no XREF)

-----BEGIN PUBLIC KEY-----
MIGJAoGBAOZwSLecBmsjYjEixnXdeYfDeZJ39mDk6CH/cduiKSYz9KHAT6uqvWsY
A5kT6JtWfitnl6fnPSd4/K9DYsVEMxs8esFElmV+HqVo8owInBkHAol++kbH4SPw
4L+RxkOgZ5zQuVlrZ1l6Lr08+Uli6clxxG2f7WxH8bEtyURJqPLzAgMBAAE=
-----END PUBLIC KEY-----

-----BEGIN PUBLIC KEY-----
MIGJAoGBAOZ/oBw5FGMQ1PLhZZUw3ckz1f4MtpeQhyMOeU5gwoBDiZzBdnFTPubA
q9CJ7/ynhP33S/fM WavGjCDXwVvVtw+PxpUwYvbQW7fOC5Hh0V/QoiGaiXR+gic
Q4m2bXRQfM8bcZRZJuhBO5pX8SU4MYWMjJ+TWsyNA0DjwN7wQDucTAgMBAAE=
-----END PUBLIC KEY-----

-----BEGIN PUBLIC KEY-----
MIGJAoGBAPc7aLp/0eSmRVJ+bakzbZMi90WPUN+yZGAo0ywwoZKxWP+YlyG+5n7D
8qJFryrGne/K+O1K UIlpRG4LNqP3nagb+8ONe0kk71l+Y1NhhRVsUrNTOutAECF
S5oZhLQCKDuYmft0iTgfFocouqqluFeF83RSlywZeLyXf8H0JQ8YBAgMBAAE=
-----END PUBLIC KEY-----

What's needed now, is the private RSA key... (to confirm above)

 

[alastairstevenson]

Did some research on this, and to me it looks like the base64 encoded string contains of: [03000000][MAC of the device in binary][Random]

I looked at this ages back - but found it quite hard to figure.
I presumed that there would be either a phone or web-based app that would provide the needed response.

What's needed now, is the private RSA key... (to confirm above)

And that would be the 'key to the (Hikvision) kingdom!

 

[bashis]

And that would be the 'key to the (Hikvision) kingdom!

Yeah, tried to recover the private key with RsaCtfTool, but that did not work out...