P2P Cloud Access For Hikvision And Dahua?

I would like to suggest an article covering the peer to peer access implemented by Dahua and Hikvision. These kind of service provides external access (internet access) to the devices without port forwarding / router configuration. They are calling it "cloud" access.

Dahua: http://www.dahuap2p.com/

Hikvision: https://www.ezviz7.com/

P2P has its advantages for the less network technical individuals; however, it does add administrative overhead not initially, but in the long run of support. It is also prone to security issues as the client, server, and security devices are making connections to a cloud server exchanging information on how to connect. Have you ever captured packets on a cloud P2P, not interesting at all; a matter of fact, little bit scary considering security is the primary application.

Depending on the application and the customer, we will use VPN access back into the network or change the default port, update the password and PAT (Port forward) the necessary ports for inbound connections to the DVR/NVR/Camera.

I agree. From a security perspective, it's really terrible. Wouldn't activate it in a corporate environment. P2P uses NAT transversal techniques that can 'fool' the router to allow incoming packets in certain UDP ports, that's how Skype and torrent work.

But for a security company monitoring a lot of residential or small business, it's great to not have to deal with port forwarding and router configuration at each client.

For the end-user is also a big deal, since he can access the DVR / ip camera from his PC or mobile without having to deal with IP address, dynamic IP, port forwarding, etc.

I see P2P as a huge advantage for residential and small business market.

I wonder what is the percentage of scenarios where the NAT transversal will work properly (I guess > 85%).

UDP hole punching is the most common solution on P2P Cloud Access for CCTV; and it does have its advantages. However, with the service in the hands of a third party with no encryption, I find it unusable for a variety of other reasons too.

However, for a security company monitoring a lot of residential or small business, it's great to not have to deal with port forwarding and router configuration at each client.

Until that P2P cloud is unreachable; your customers are in the mercy of that 3rd party service.

However, for a security company monitoring a lot of residential or small business, it is great to not having to deal with port forwarding and router configuration at each client.

We have used P2P only once "TRY OUT"; and we have had to go back 4 times due to the application crashing or the P2P cloud not available. All of our solutions that have been implemented with NAT/PAT have been rock solid.

I wonder what is the percentage of scenarios where the NAT transversal will work properly (I guess > 85%)

I do not know, but it is becoming more common; if the vendors designed the P2P solution that allowed you to specify your own server, you could essentially develop your own infrastructure for that purpose; however, it might be cost prohibitive due to resources and technical skills.

We use only one vendor for our residential market and port forwards have worked out with no issues. You could argue that there is administrative overhead with static network maps with port forward solutions in where customers are jacking with the settings; however, NAT/PAT solutions has worked well for us with no issues. Futhermore, we have a clause in the contract that if any changes are made that requires us to come out and service the equipment and adjust any settings will be a billable call.

However, with the service in the hands of a third party with no encryption, I find it unusable for a variety of other reasons too.

Are you saying that these services are necessarily unencrypted?

Are you saying that these services are necessarily unencrypted?

Not my place to say whether it is necessary or not, that depends on your requirements. I am just explaining that using the service you have no control how the unencrypted data is processed between the mobile APP, cloud server and DVR/NVR/Camera.

Most remotely accessed video surveillance solutions between a mobile device and endpoint video surveillance equipment are inherently insecure in that usernames and passwords are sent in plain text. In my opinion, the best way to limit your exposure to data and service exploitation is to create a static network environment (Known network policies and parameters) of controlled access for both the endpoint and the mobile client.

In addition, it makes troubleshooting far less complicated when you have a static network environment.

From what I've seen in the Wireshark traces I've done, this isn't accurate. The P2P cameras set up a TLS tunnel (generally speaking) and then the credentials are sent and video is streamed. If you run a trace on a cloud camera, you see nothing but TLS, no RTSP, no plain text, etc. I'm sure there are exceptions, but that's what I've seen, on Hikvision, Axis, Dropcam, Samsung, and more.

This trace is from an Axis camera, but looks very similar to others.

This is Axis "one click" technology, not P2P - since the cameras will stream video only to <one> specific server. It's a server based / relay architecture, since all data goes from camera to server and then to the client software. Very secure, but it is not easy scalable (from the server side perspective) because the more cameras (or client instances) you have the more servers you need.

With P2P the camera can send data directly to any client (any peer), with no relay server. The server is, by default, used only for authentication and to help with the NAT transversal. Using this architecture, there is no direct relation between the number of peers and the number of servers, dramatically reducing backend costs.

So, in theory, when you are accessing the camera video from your mobile phone, using Dahua or Hik P2P, the camera streams video directly to the phone, with no relay server.

I am sure not all P2P networks are created equal; the ones we tested did not use TLS or any version of encryption. At any rate, I think an article covering the peer to peer access implemented by Dahua and Hikvision would be a great idea.

Based off Hikvisions security issues ezviz makes me very nervous.

If you are just looking to deal with port forwarding those appliances from Dahu and Hik have UPnP. Almost all routers also have UPnP. That makes the appliance like your XBox or Playstation, it does it's own port forwarding automatically. That should get you around the port forwarding headache.

As for using the Dahua and Hik P2P .... well servers used to be in China. I am told they are now in the US. But who knows where tehy really are or who has access to them or what else may be on them.

There are many different routers out there, each one has its own UI and can be time consuming for technicians to learn them all. P2P seems nice but has it’s own problems, the biggest is security, then relying on someone else for a connection. In my opinion, the best solution is to include a router in the proposal, send it with he technicians pre configured. This ensures that your customers are going to get remote access that day and often improves their home or business network since they usually have some crappy linksys circa 2002.

We've asked Hikvision about EZVIZ a couple of times. The official response has been that it's not available in North America. But I've been able to add cameras and view them just fine. From what I remember, cloud recording didn't work, but I didn't investigate why.

We'll take a look at Dahua's P2P.

As soon as we hear back from either, we'll post here.

This is just DNS server access with a friendly GUI. We all run security risks when giving ourselves remote access.

Sorry Mike, this is not the traditional DDNS server access that we are used to see in other products. DDNS needs a valid (reachable) IP and port forwarding configuration (too difficult for the home user).

For the end user it goes like this (dahua p2p instructions):

1 - plug the DVR or camera to your cable or wifi network, with internet connection;

2 - download and run the mobile App;

3 - using the mobile app, scan the QR code that was sent with the manual.

Done, the camera will stream video directly to the phone, anywhere you go!

using the mobile app, scan the QR code that was sent with the manual.

So what's the decoding of a handful of QR codes got to say for itself ?

What's stopping you from going camera fishing by creating our own QR codes ? Default passwords ?

What's stopping you from going camera fishing by creating our own QR codes?

Nothing, but time.

Even a deprecated hash like MD5 offers unique encoding of over 340,282,370,000,000,000,000,000,000,000,000,000,000 values.

Suppose therefore that answers the first question?

So what's the decoding of a handful of QR codes got to say for itself ?

- It's an MD5 hash. - well, I assume from your remark ?

I was wondering if it was something slightly more sensible than an obfusticated / salted MAC address, perhaps as a MD5 hash. Having never seen one to decode myself I wondered if anyone else had given it a go and what the outputted data was. hint: you don't break the hash, you break the construction of it to create your own, ideally.

Since the only unique identifer for the cameras at QR code creation time is probably going to be the serial and the MAC, it's probably based on the values of one or the other. Since one can change the MAC address of many IP cameras quite easily in the bootloader (hint; TTL port), perhaps one might narrow it down from 50:50 when changing the MAC stops it working. Or change the serial if you can figure that one out.

Then one might go fishing with wireshark to see if the cam ever sends the QR ID code out to the cloud server, or just it's MAC address. If so, it's time to look in the firmware for how the camera is creating that code as it wont be written to every single one seperately - it's not efficient for production, so would be surprising.

If it's just sending MAC/serial, the unique cam ID to QR ID lookup is in the cloud server and that makes figuring it out somewhat harder & perhaps arguabley more secure.

But this all starts from decoding the QR code from a picture to characters which I haven't done as I don't have one...

You are right, the user will probably leave the defaults, unless the product enforces changing it at first access or during installation.

It's an MD5 hash. - well, I assume from your remark.

No, it could be an MD5 hash, it could also be MD6 or SHA2 or all of them together. Run twice or ten times.

You just don't know.

So you buy your camera and get your MAC and a sample QR code and then you are going try to figure out for another MAC address what the QR code would be?

By trying every combination of hash algorithm known, in any order? But that not all.

Since the only unique identifer for the cameras at QR code creation time is probably going to be the serial and the MAC, it's probably based on the values of one or the other.

Ah sure, but what about the noise they can concatenate to the MAC before hashing, like board-rev #s and lot #s and strings like "ZHEJIANG DAHUA". Remember to try all those possible permutations with all your algorithms.

Hint: you might do be able to do it, but you better really like fishing.

Ah, sorry, I thought when you mentioned MD5 that you were trying to be helpful rather than dismissive.

You appear to be expecting the P2P QR code to be some rather complex paranoia affected algorithum of mega security?

From the same companies that feature in such articles as "hikvision hacking scandal returns" and the various password and super user backdoors we have seen over the past few years.

Ah, sorry, I thought when you mentioned MD5 that you were trying to be helpful rather than dismissive.

The thing is about cracking hashes its (usually) an all or nothing affair. You try this, you figure out that, but then when you try your home brew encryption test it just fails. Even if you have it 99% percent figured out, if you have only one byte in 40 wrong, the result is gibberish just like the rest. Of course the opposite is true as well, if you do come up with anything even remotely human readable, you've got it!

So during your long fishing expedition, you're bound to have doubts, "maybe they went 256, or its a wingdings cipher" . It takes its toll on your psyche.

You appear to be expecting the P2P QR code to be some rather complex paranoia affected algorithum of mega security?

Not really. Both Hik and Dahua have implemented digest authentication (shocker, I know). This is much the same.

Are you guys reverse engineering their P2P protocol?

Are you guys reverse engineering their P2P protocol?

We tried, but their programmers are way too clever.

They coded everything as one long palindrome, so that even after you reverse it, it's just the same, P2P. ;)

So I had five minutes. As no one shared the decoding of a QR code I went looking which really did not take long. Here is a guide to how to use P2P with dahua:


Surprise surprise. It uses the serial number. Completely unobfusticated.

Try scanning the one in the PDF. See what you get.

So fishing for cameras would appear to be guessing a serial (which is constructed to a standard typically) and hoping they have not changed the default creds.
Little bit of programming, perhaps you could walk a range of serials looking for feeds with default creds and register a hit. Have they built in rate limiting?
You're not going to be able to target a specific unit this way without knowing it's serial, but you might well find interesting stuff. Just like using google to search for cams.

As I said, it was never going to be secure. Just a shame its quite so basic to have zero obfustication to allow simple creation of connections.
Just hope that with P2P access you cannot send system variables (it's clear from the PDF that you can request them) as that would be very tragic with default creds set.

Usual story. Change your passwords from default.

Oh a bug here, or perhaps an unintended concequence.
On some dahua products if you input the wrong password for a user account too many times it locks that account. Survives a reboot. No problem if you haven't deleted the 888888 account as you can unlock it, big problem if you have. Factory default time.

P2P serial surfing plus sending the user "admin" with random passwords to lock out the local user. Oh dear, bad day.

Hikvision do it better:


Whilst they still use the serial to ID the device. They also have a verification code which must be entered too. Although it says if there is no verification code, just use ABCDEF. I get the impression that this is user entered rather than calculated. Good, but, will many people skip it and just leave it default as ABCDEF ?

At least where it is pre-printed on the label it's not going to be a poor default. To figure out the link between the serial and the verification code would take a lot of time.
However there may be no link at all, they might just cycle through 26 letters for each of the 6 postions till they use all combinations then start over again. No link to serial what so ever. Like a one time pad, almost !!

On top of that you have the device user name and password as well.

Much better & secure from random access if there is a predefined code, or the user changes it from blank.

Surprise surprise. It uses the serial number. Completely unobfusticated.

Ha! That's not a serial number. It's a QR code. What did you expect to find?

Oh, sure Dahua may call it a SN and may even use it as one, but that does not make it one.

Why? Because serial numbers strictly speaking are "serial", consecutive integers, like 1000,1001,1002 representing the order of manufacturer.

They have the property of predictability. These likely do not.

The "completely unobfusticated" serial number that you don't show is:


And is a standard Alphanumeric single case 15 character encoding which yields:

221,073,920,000,000,000,000,000 unique values.

Take a guess how many devices Dahua actually has live in the p2p system and divide into the number above. That's how many non-numbers you have to go thru to get one good one. Probably 5 quadrillion or something like that.

I know you think its some standard Dahua scheme, so for more info here is how the one from my NVR starts:


If you still don't believe they are using a hash function, then it should be easy to prove. Just start incrementing different sections by one and then check them to see if they exist.

Remember this is base 36, so the next digit after 9 is A and keep going to Z:

  1. TZA4LF076WU17K8
  2. TZA4LF076WU17K9
  3. TZA4LF076WU17KA
  4. TZA4LF076WU17KB

Keep us posted on the first valid one you find.

The QR code is used only to find the DVR/Camera in the P2P network. You can type the address as a number (ID) too.

After connecting to the equipment, you still need to login with user:password (the auth data is stored inside the DVR/camera).

The big innovation here is the "automagical" external and direct access to a equipment that is behind a NAT device (router).

But of course, security should also be covered in the suggested review.

After connecting to the equipment, you still need to login with user:password (the auth data is stored inside the DVR/camera).

admin<enter> admin<enter>

Usually yes. But that is on the user, specially if the product suggest the password change. I don't know if Dahua or Hik does.

Again, the main aspect of this analysis would be the innovation of P2P protocol and NAT transversal (no relay server, no port forwarding).

It seems that Axis has joined P2P too:

"2. Axis solution to remote access Axis Secure Remote Access makes it possible for a smartphone or PC client to access Axis network cameras when the client and the cameras are located on different local networks. Using external mediator servers1 , the client and the camera can find each other and establish a secure peer-to-peer connection. As a fallback the communication is automatically relayed through the mediator servers, when direct communication cannot be established."

Related post here.

The Engrish is strong in this one. And that's something of a problem when it comes to trust. I think most people will trust the transactional purchase of a Chinese made/manufactured device, but not so much a Chinese service provider. The big Chinese manufacturers will need to spend considerable marketing dollars in the US to sell professional cloud services as adjunct to their hardware.

That being said it goes to show that more advanced remote access than manual port forwarding is/will be a common feature that's simply expected in all cameras/VMS. Axis provides it as a convenience and that's good.

As others have pointed out true P2P uses STUN/TURN/ICE to broker a P2P connection between the camera/client. The advantages are lower cost to the service provider since the majority of the network traffic need not traverse their network, and low latency (in the case of STUN). P2P is pretty much the only way to go when the service needs to be free. Disadvantages are that it's not always guaranteed to work 100% of the time which is problem in any professional systems.

We thought a lot and did a lot of experimentation with true P2P early on but eventually opted to go with a TLS connection to our media servers that reflect the (in our case HLS) stream between the customer site and our customer's client. We have a much more deterministic results starting a stream session and better control over the customer's experience. If the site can communicate with us at all, we can stream.

Sorry about the English. Not a native, I'm working on it.

Language aside, I agree with what you said: if you have P2P your service can be free (at least for live view). It is a nice approach to attract customers. And you don't need a huge backend as other cloud providers does (VSaaS, DropCam).

And if the problem was Dahua/Hik/Chinese security, just found out that Axis did the same implementation, so let's change the suggestion to review Axis P2P or P2P in general. I didn't know it when I started the discussion, neither did IPVM at their Axis review.

This analysis could include:

- Will Axis (and Dahua and Hik) allow VMSes to use their servers and protocols? Probably not, they will consider it proprietary. Since they don't do, they have a leverage to sell their own VMSes and cloud solution.

- Is it possible to other cloud providers to access Axis/Dahua/Hik P2P? Same as above.

- Security: which ones are using encrypted P2P (probably Axis is, others not).

- Which ones allows recording on-site (SD Card or hard disks for DVRs). Do the cloud service allow P2P searching?

- What is the success ratio using NAT transversal? How many will stream P2P directly and how many will need Axis relay servers (increasing their bandwidth and machine costs).

About the trust vs cost, I will quote:

"given a chance between paying $100 a year forever {for cloud access} vs adding some software to existing surveillance offerings for 'free', the choice for the latter is quite compelling"

Wagner, my comment about the Engrish was not directed at you (you write well enough I would have assumed you're a native English speaker with an unusual name). My comment was directed at the web sites in your original post. They use the type of clumsy language and odd marketing that gives them away as non-US services. Thus the trust issue.

Yep, they need to improve that also. Now imagine a third party, well written cloud software/service, compatible with P2P-enabled hardware from multiple vendors (Hik/Dahua/Axis).

In reading these comments I wanted to clarify a question.....does Dahua or Hikvision offer a service similar to Axis' one-click..or any other camera manufacturer? Where you can implement it and use in our software? I'd love to part ways with Axis for some customers ($$) but need that ship to site and autoconnect to work (or ship to site and installer 'one-click' it to me). Do not want to have another device onsite.

Hikivision says they do not have a one-click alternative currently but that they will be providing one in the future, release date to be determined.

Anyone generalizing that P2P is a security risk needs to know how it's implemented. It's a very secure protocol if implemented correctly. Peer to Peer (abbreviated to P2P) network protocol allows each computer accessing the application on the network to act as a client or server for the other trusted computers in the network. This allows shared access to various resources such as metadata, audio, video, access control data, event data, wireless mobile devices and sensors without the need for a proxy through a central server. The P2P protocol for sharing content such as audio, video, data, or anything in digital format allows numerous clients to view live video streams without limitations on the number of users. The P2P protocol must use distributed application architecture that partitions tasks or workloads among trusted peers using public key cryptography. Peers are equally trusted participants to video, audio and data which must also be encrypted with their data AES 128bit format or greater encryption.

When P2P is implemented correctly, there is an introduction server that makes a secure introduction between the client and server using public key cryptography. This implementation instructs the IP Camera or Server not to allow inbound network connectivity but to only listen for authorized connections from the introduction server. Thus, it protects systems from inbound security attacks. Since all Clients & Servers are utilizing public key cryptography; it protects the data transmissions and data authorization, data eavesdropping and can conceal identities/locations of the participants and authentication of the data/messages.

However, with that being said and without knowing how P2P implementation is done by these Chinese companies and their service providers, P2P could be implemented like many other protocols to exploit network security.

I agree and disagree on a few statements...

  • P2P is not a protocol, it is a communications model very much how Client/Server is a communications model and not a protocol; the model can use any protocol, typically defined when designing an application for use with a P2P Network Model.

An RFC exists that defines the model and any security considerations that one may have. The RFC document does not define P2P as a protocol but as a system. When designing the P2P model/system, an application developer can define any protocol he/she may use at the application layer (HTTPS, FTP, etc.) and bind that protocol to a specific layer 4 port utilizing UDP and/or TCP.

  • I agree that if P2P network models (not implemented), but designed correctly utilizing cryptography can be secure, but in my experience with Chinese manufactures, there are no standards, so each manufacture will design the end to end P2P model inconsistently. I have seen usernames and passwords in clear text and some in clear text, but defined with an MD5 hash, which is a joke in-itself; however, poorly implemented security is better than none I suppose.

Another point on P2P security is in section 7 of that RFC, it states:

The first issue that needs to be considered is to which extent the nodes in the system can the nodes in the system can be trusted. If all the nodes in the system are fully trusted (e.g., all the nodes are under the full control of the operator of the system and will never act in a malicious or otherwise incorrect way), P2P architecture can achieve a high level of security. However, if nodes are not fully trusted and can be expected to behave in malicious ways (e.g., launching active attacks), providing an acceptable level of security in a P2P environment becomes significantly more challenging than in a non-P2P environment because of its distributed ownership and lack of centralized control and global knowledge [Mondal2006]. Most P2P deployed infrastructures are owned by the manufactures and/or outsourced to another entity. Therefore, that P2P network cannot be trusted even with cryptography (it is no different from you launching a middle of the man attack between a host on your network to a host on a destination network that is utilizing HTTPS.

So, generally speaking, P2P in the context of the above quote from section 7 is a security risk.


P2P may not fit your defination of a protocol. But, RTMFP is a P2P protocol.

RTMFP is (rfc7016) a secure protocol is identified by Internet Engineering Task Force which has been designed to be used as a secure P2P implementation.

But, I agree with you that it won't be wise to trust any Chinese manufactuer to follow 'trusted peers' method since they would have to be one.



Dahua P2P is down today. Someone at ISC West should stop by their booth and ask why?