cybersecurity ezviz hikvision ip camera italy videosecurity

Part 2 – The Hikvision cloud and the Ezviz home security camera data exchange on the internet. A network traffic analysis

In part 1 of this Ezviz traffic analysis the video camera connections was introduced. Now in part 2 the cloud backend and data connections of the camera to the internet are analysed in technical detail.

The HikVision/EZVIZ cloud system processing the video feed

The video cloud backend for EZVIZ wireless security cameras allows for a view from anywhere set up: from your smartphone you see the security camera feed from anywhere you are even far from home, simply by opening the camera app on the phone. The view from anywhere system is similar version of the Hikvision Intelligent transportation integrated management and control platform Overseas Edition, or iVMS – a video surveillance system with facial recognition, automatic activities detection and object recognition and extensive search capabilities.

Passing video data from the camera or the mobile phone, to somewhere and to then process it and send it back is the way also video streaming works, except the camera is in a studio and not in the house.

Going deeper into the detail of the graph shown in part 1, the Ezviz/Hikvision security camera network traffic is represented here as well showing the data from a user and camera in Italy to abroad, depending on the services and protocol types used in the interactions:

Ezviz/Hikvision camera internet traffic to different countries depending on the data and protocol

So it is important in the case of personally identifiable information like video feed from home security cameras, that it is clear which cloud backend system it is, where it is located and what can it do and who manages it.

The following diagram shows how the Hikvision iVMS video management cloud backend system is set up:

Hikvision EZVIZ IPCamera video streaming platform structure

The system is a video surveillance system, which is described by Hikvision as follows:

[iVMS is] integrated with video surveillance – preview, video, playback, on the TV wall – checkpoint, electronic police, urban illegal evidence collection, electronic maps and other functions in one integrated management and control platform. To achieve the unified management of surveillance, capture, encoding, decoding equipment, organizations, users and permissions.

Hikvision iVMS 8600 manual

In this analysis direct connection with the Video Transmission Management (VTM) component of the system has been identified and documented. More information at the end of the article.

The data exchange between the camera and the internet

The IP addresses reached from the EZVIZ/Hikvision camera during the traffic capture:

IP addresses with amount of traffic for an EZVIZ/Hikvision in home security camera

Once it started streaming from the camera to the phone, it would send the video data to this IP address:, sending packets with length of 1412 bytes via TCP.

The video traffic from the camera to the HikVision’s uCloud server in London:

Wireshark traffic from EZVIZ camera to remote cloud

Initially the TCP packets include the camera unique ID and backend storage address.

The nature of the address of the remote server

  • The IP address belongs to: UCloud Information Technology (HK) Limited. A provider of cloud functionalities for Chinese companies home and abroad. The specific IP address is assigned from the Hong Kong internet exchange point
  • Doing a WHOIS on the IP address, some show that it is based in London, England other in Honk Kong. In the case of the hosting in London, one Whois provider is showing that this IP address is using privacy to be hidden and a Proxy-registered route object
  • The initial part of the data being sent to the video management server is: 00718:euuc_cen10.201.193.254:F91451956:1
    • is the address of the database holding the video segments
    • F91451956 is the unique camera ID
    • :1 is the camera channel

So the video feeds from security cameras of Italian users are going through London and/or Honk Kong without any scrutiny on whether the data is then relayed further or copied, indexed or viewed.

Continuing on the investigation, when the app on the mobile phone is sending API commands to the camera, the API calls are sent and received by the camera through this IP address:, which belongs to Amazon in Ireland.

The Thrift protocol with protobuffer streamed to the smartphone app carries the video feed of users.

Other protocols used by the camera to exchange information: X11, DNS, Protobuffer, NTP, SSDP, Thrift

X11 remote view protocol

Interestingly another service in constant connection with the camera, living at, and based initially in Frankfurt and being owned by Chinese Tencent cloud computing (Beijing) Co., Ltd.

X11 Protocol connection server owned by Tencent

The client-server communication:

  • the Italian user public IP address:
  • the port its using to communicate: 46345
  • the camera unique ID in XML format, via mostly the UDP protocol: F91451956
  • (possibly) the MIT-MAGIC-COOKIE-1 to authenticate to the X server: 985f68ff2efca9a75ac05fd38ae35cb2 and 4ecadd67ce5139d18d5d7f1c355977fb

The XML format used reflects also the one used in iVMS and Hik-connect.

Request from the camera:

<?xml version="1.0" encoding="utf-8"?>

Response from the Tencent iVMS server:

<?xml version='1.0' encoding='utf-8' ?>
	<Client Address="" Port="46345"/>

After the (unencrypted) UDP data exchange is being done, there is an unexpected

X11 protocol exchange process:

The X11 protocol allows for remote access via SSH for display.

Why is this necessary?

And why is this opened on a private camera?

Network Time Protocol setting time on the camera

Investigating the other IPs contacted by the wireless security camera, another one is for the Network Time Protocol: which is a IP address based in China of the “Hangzhou Hikvision digital technology Limited by Share Ltd” NTP version 4 service to sync local time with UTC.

Network Time Protocol (NTP) server of the video camera based in Hangzhou, Zhejiang, China.

Basically it is a server that helps in performing a very important function in any computer and as such a connected home security video camera, which is to sync the time on the camera device to the internet time. Setting time is an important concept of cryptography because it contributes to the random number generation of decryption keys.

SSDP Protocol and discovery of other devices in the wifi local network

The camera also supports SSDP or Simple Service Discovery Protocol which is incorporated in uPnP and in the past has been used for DDOS attacks, evidence of this is seen at:

SSDP protocol used by the Hikvision/EZVIZ wireless security camera
A backup image from the camera saved, via HTTP protocol

Backup image is saved into AWS Amazon in Ireland:

There is also a post request being made to: an AWS EC2 instance with a hostname:

Accept: *.*
Host: backupserver:8080
Connection: close
Content-Length: 23306
Content-Type: application/x-www-form-urlencoded


With the response being:

HTTP/1.1 200 OK
Date: Fri, 04 Nov 2022 10:30:59 GMT
Server: nginx
Content-Length: 54
Connection: Close


So there is an image being sent (and saved) to an EC2 AWS instance in Dublin, Ireland, but why?

This is not an IP address used by the app to share information with the camera.

Domain Name Server resolution protocol, ip address to URL

DNS protocol includes accessing the table where an IP address is linked to a URL, so that the server hosting the site at the URL can be loaded.

DNS resolutions are made to:


There is another connection, made to sending video chunk of abouot 3MBs to the phone. The IP is uCloud Information Technology (HK) Limited and also located in London.

The Thrift protocol for video data

Initially the IP Camera sends packets mostly of 1466 bytes which is video data embedded in, then at some point, only the server based in London responds with packets of size 54 bytes. After sends a RESET flag to the IP Camera, the conversation between the IP security camera and this uCloud IP ends with a request from the IP wireless security camera via the Thrift protocol using a CALL method:

EZVIZ phone app video protocol

The EZVIZ app traffic was captured using Charles Proxy with Charles’ HTTPS certificate added to the phone trust store to decrypt the communication between the EZVIZ app and the internet.

The video feed is being transmitted from the cloud in London via protobuffer which allows the transmission of data with proprietary video encryption and transmission. The other endpoint and associated metadata for receiving the video feed from the camera is:

ysproto://<UNIVERSAL_TOKEN>&weakstream=1&isretry=0&lid=2<LICENSE_ID>&biz=1&timestamp=1667559606601&timestamp=16675596066012a15228f55116d3a5b95az9f98a5982v3.6.1.20210513 2v3.6.1.20210513

Base64 decoding 2a15228f55116d3a5b95az9f98a5982, gives ~ “youoi“, a company in Shenzen, China creating components for IOT devices.

The request to, based in London, is preceded by an “options” request to the streaming address.

The response to this “options” request includes the server which will be streaming the camera feed: ys7-vtm vtmeu193.105

ys7: is the identifier for the EZVIZ OpenBiz SDK, infact redirects to and therefore HikVision.

vtm: is the Video Transmission Management Server of the Hikvision iVMS system.

So it is a EZVIZ installation of Hikvision iVMS.

As per the Hikvision manual definition on VTM:

Video Transmission Management Server(VTM)

The video transmission management server, which manages the stream media server, supports the following functions.

Stream media server cluster management and load balancing.

Streaming re-orientation: Once the client asks the VTM for streaming, according to the client required URL and load balancing strategy, the VTM selects a VTDU address from the configured cluster and assembles a result URL to the client. The client gets stream from VTDU via the RTSP protocol after receiving the result returned by VTM
In the third part of this article series, a research on the manufacturer, Hikvision, is presented, for example as to Chinese state ownership of the company and other information about its control of Ezviz.