Universal IP tool for Axis, HikVision, Dahua, Bosch, Hanwah, Vivotek, Panasonic, Flir, etc.

Apr 26, 2020
26
23
France
Hi everyone,

I am working on an open-source project I would like to share with people used to play with videosurveillance cameras and propose you to participate.

This is small unique tool that scan a network and can detect several camera vendors, using open protocols (ONVIF, UPnP, etc.) but ALSO proprietary vendor discovery protocols.

UniversalScanner.png

Very last build 2022-02-12 with more protocols can be found here: UniversalScanner (Portable) or here: UniversalScanner (Installer).
Added : Advantech

I am looking for Dlink camera owner, Foscam camera owner or HID Controller owner that could help me to perform tests.


You will need Windows system with dotNet v4.5.2

Today, it supports the open protocols bellow:
  • SSDP (UPnP)
  • WS-Discovery (ONVIF)
  • DNS-SD (Zeroconf)
  • GigE Vision (industrial cam protocol)
And vendor discovery protocols:
  • Axis
  • HikVision
  • Dahua
  • Bosch
  • Hanwha
  • Vivotek
  • Sony
  • 360Vision
  • NiceVision
  • Panasonic
  • Arecont
  • Ubiquiti
  • Eaton
  • Advantech
As gadget I have added also
  • Google Cast
  • VStarCam
  • Microchip
  • Lantronix
  • Eden Optima Box
I managed to detect also these brands with the open protocols :
  • Uniview: ONVIF/WS-Discovery
  • Flir: UPnP/SSDP and GigE Vision
  • Siqura: UPnP/SSDP and ONVIF/WS-Discovery
  • Mobotix: ONVIF/WS-Discovery
  • GCE Electronics: Microchip (enhanced)
  • ELA Access Control: Microchip
  • Vauban Access Control: Lantronix
  • Eden Access Control (sub-controller): Lantronix

You have a bunch of advanced options in registry (IPv6, show all protocols, show auto-config IPs, enhance ONVIF compatibility, etc.), more details here.

I was thinking to make also a Linux software port later (would be in command line) for installers who install/use camera over Linux.

You know another vendor discovery protocol that would be good to have integrated into the tool?
Then you can follow this procedure to collect enough information for me to integrate a new private detection protocol.

Thanks!
Julien
 
Last edited:
Bick?
 
  • Like
Reactions: bickford
Thanks for making the portable version available. For things I don't run often I much prefer it that way. I thought I had UPnP disabled on all of my cameras. The scanner told me otherwise and it was right. Interesting, all of the "junk" chinese market cameras let me turn it off, while a couple of 2mp starlight HDW4231 keep it enabled even when told not to. One thing that's a bug, or at least doesn't work as I'd expect, is the Scan button works only once. After I shut off UPnP on a camera, I had to shut down and restart the scanner to see the camera's UPnP removed from the results list.
 
  • Like
Reactions: UniversalScanner
Hi

Thank you for this.

Any possibility to compile this in MacOS?

I thinking to make a Linux and MacOS version but the code is make using C# and WPF, I would need to rewrite a part of the application to support Cocoa.
If I do a first version of Mac, that would as command line as first version.
 
Thanks for making the portable version available. For things I don't run often I much prefer it that way. I thought I had UPnP disabled on all of my cameras. The scanner told me otherwise and it was right. Interesting, all of the "junk" chinese market cameras let me turn it off, while a couple of 2mp starlight HDW4231 keep it enabled even when told not to. One thing that's a bug, or at least doesn't work as I'd expect, is the Scan button works only once. After I shut off UPnP on a camera, I had to shut down and restart the scanner to see the camera's UPnP removed from the results list.

Actually – and I will look like a real company technical support to answer like this, it is working as designed:
As detecting device process is not always 100% working for some reason (anti-flood timer between device response, network loss, time to start the device, etc.), you can click several times on Scan button to launch several requests; new found devices will be added to the list and already known device found before will be kept.

If you want to empty the list and restart from scratch, you can reopen the tool but it won't erase the list and start from zero at each scan.
Same, you can notice that UniversalScanner starts to listen on the network even if you haven't yet launch a scan, therefore some announcements on network can make appears some device before any scan (UPnP for example).
 
  • Like
Reactions: tigerwillow1
Bonjour UniversalScanner,

Nice project, thank you.

I scanned my cameras:
Dahua cams (IPC-HDW5231R-Z) as type IP Camera,
Amcrest cams (IP2M-481) as type IP2M-481W,
HikVision cam (DS-2CD2385FWD-I) as type DS-2CD2385FWD-I

Then hooked up some other cams not being used:
Camius cam as Dahua (GuardX) as type IP Camera,
Generic cam as HikVision (IPC3142WD-4MM) as type IPC3142WD-4MM,
Hosafe cam as WsDiscovery (Unknown model) as Network Video Transmitter.


Haven't checked out your code yet. Not sure how convertable it is, but you may want to check out WxWidgets, Qt, or python with a gui for cross-platform development.
 
  • Like
Reactions: UniversalScanner
Bonjour UniversalScanner,

Nice project, thank you.

I scanned my cameras:
Dahua cams (IPC-HDW5231R-Z) as type IP Camera,
Amcrest cams (IP2M-481) as type IP2M-481W,
HikVision cam (DS-2CD2385FWD-I) as type DS-2CD2385FWD-I

Then hooked up some other cams not being used:
Camius cam as Dahua (GuardX) as type IP Camera,
Generic cam as HikVision (IPC3142WD-4MM) as type IPC3142WD-4MM,
Hosafe cam as WsDiscovery (Unknown model) as Network Video Transmitter.


Haven't checked out your code yet. Not sure how convertable it is, but you may want to check out WxWidgets, Qt, or python with a gui for cross-platform development.

Merci !
Thanks for your test, the type is returned by the device it self through the protocol, the tool is only displaying the text info returned by the device.

Camius is I guess a OEM of Dahua, and your Generic camera an OEM of HikVision.

Hosafe is detected via the generic protocol WsDiscovery used by ONVIF; I have checked and Hoafe should also have a proprietary discovery protocol, which look derived from UPnP on the port 1209.
If you are interested for me to integrate this protocol as well, we can work on this together, just let me know (I need to collect some data on your network to understand the protocol to be able to implement it).

The code is C# based with Windows Forms for quick development and all-in-one file results.
If a Linux or Mac version is made, I would probably write a C or C++ clone as it has to manipulate a lot bytes directly in memory (because of binary protocols), but I am not sure I would work on a GUI for Linux or Mac as first versions.
 
Thanks for the offer, but I don't use it and plan on throwing it away; I would not recommend Hosafe to anyone. Hosafe was my first cam that I bought about 6 years ago to experiment with zoneminder and blueCherryDvr. The only way to reset to factory settings is through their ActiveX web plug-in, if you forget your login/password, you are screwed, as there is no physical reset button.
 
Actually I hadn't noticed the another press of the scan button had pickd up .103 and .107
Contrary to what I stated above, the .111 device isn't running Herospeed firmware - it's Zview.

Thank you very much for your tests!

It looks the camera 192.168.1.111 has a behavior a bit different from the others.

It is mostly probable that, because the device name looks omitted, UniversalScanner discard the answer from this device.
Even if the device does not follow the strictly the protocol specification it is generally better to try to accept the answer even if malformed.

If you would like me to fix this device detection, I will need your help in order to confirm this point and see exactly the device answer.
Do you think you could follow the procedure attached and send me the result?

Please note that making this capture will contains some specific data such as Mac Address or IP addresses (you can send the file direclty to me and I would not keep it after analysis).

If you are not able / do not have time to do it, no problemo of couse, but I won't be able to garrantee that I can fix the issue without these input data :)

Thank you,
Julien
 

Attachments

  • Like
Reactions: bickford
It looks the camera 192.168.1.111 has a behavior a bit different from the others.
Agreed.
It appears OK in ODM, but not in your scanner.
It's hooked up to a couple of Hikvision NVRs as an ONVIF device, and generates ONVIF motion events.

Do you think you could follow the procedure attached and send me the result?
I'm sure you are keen to explore this.
I ran a wireshark capture with the camera MAC address as the capture filter, with the camera connected to a port on the switch mirrored to the Linux PC running wireshark.
See attached.
The camera IP address is 192.168.1.92
The capture starts from camera power-on, and then has the ODM queries from a Windows VM running on 192.168.1.15
I pressed the Scan button on the scanner a couple of times but saw no traffic to the camera.
This is not the same camera as the one in my post above, but it uses the same board, and has the same version of firmware installed.

Let me know if you want any follow-on captures, it's easy enough to do.

Interesting how much it 'calls home' despite nothing (obviously) configured in the web GUI for it to do so.
 

Attachments

  • Like
Reactions: UniversalScanner
I ran a wireshark capture with the camera MAC address as the capture filter, with the camera connected to a port on the switch mirrored to the Linux PC running wireshark.
See attached.

Thanks!

The camera implementation is not very usual:
  • The WS-Discovery answer payload is bigger than the maximum so there is packet fragmentation;
  • Fragmentation is done at IP level, it is allowed of course but not really common (makes me think their UDP stack is homemade);
  • The answer also includes useless data such as unused XML schemas, it is also allowed but useless and also partially the cause of the oversize of the payload...
  • It seems there is also a discovery protocol at Ethernet level!? This is something weird as it is not network routable (you must be connected directly with a wire to the camera to detect it, connected to a switch it will probably fails to detect it).
When I inject the raw data into my scanner I got the camera detected, so the problem comes with the IP packet reconstruction (I do not know why it does not work).

Could you do maybe a second test now from UniversalScanner but using this specific debug version and the log tool debug View ?
Please let me know if you need any help to do this.

Interesting how much it 'calls home' despite nothing (obviously) configured in the web GUI for it to do so.

You are right about this, their is some "telemetry" done toward usdev.zviewcloud.com port 32100.
If you have network firewall you can try to block the outgoing traffic on port 32100 or simplier: unset the DNS server configuration on your camera (but it might disable your NTP also).

Thank you,
Julien
 
Thank you for this! Using your tool I saw that some of my cameras still had UPnP enabled despite turning it off in the web GUI. Using the Dahua HTTP API I got them all turned off.

Dahua owners:
Go to:

http://<CAMERA.IP>/cgi-bin/configManager.cgi?action=getConfig&name=UPnP

to see your config.

Then go to

http://<CAMERA.IP>/cgi-bin/configManager.cgi?action=setConfig&UPnP.[ANY FIELD THAT IS TRUE]=false

Repeat as necessary.
 
It seems there is also a discovery protocol at Ethernet level!? This is something weird as it is not network routable (you must be connected directly with a wire to the camera to detect it, connected to a switch it will probably fails to detect it).
Yes, correct. I thought I'd give you the full detail.
I ran a wireshark capture with the camera MAC address as the capture filter, with the camera connected to a port on the switch mirrored to the Linux PC running wireshark.
I'll see about doing another capture later.