- Dec 10, 2016
- 451
- 166
Hello,
A few days ago I tried the P2P feature of the Escam QD900 using a generic P2P camera client software on my Smartphone and also on a my PC from a different Internet access point.
As expected it worked well, zero setup, I just had to enter the UID that is unic for each camera (depending the camera's vendor the structure of this UID may differ but mine is something like ABCD-012345-ABCDE) a login and a password.
Then I wondered how it was possible to make this thing so easy with no usual NAT translation, DynDNS stuff...
So I started digging trying to understand how this P2P camera protocol works and did some network sniffing.
First the camera send some info to a server "somewhere" and transmit its UID so the server can associate IUD and IP address source (public IP of the router) a bit like any DynDNS service.
After that I also wondered how the video stream flow could work between client and camera as both are behind a router with internal private IP addr no DMZ and not port redirection/NAT or also no uPNP configured (checked on both side's routers).
So I did some network sniffing that showed some UDP communication with three kind of packets :
At the begining the P2P Client sent some "request for info packet" to some server with the UID of the camera I entered during configuration.
Then I saw direct UDP communication between the camera and the P2P Client.
The first UDP packets contained the IUD so I suppose they first checked "are you camera IUD XXXX" ?
Then came some http-like GET requests to check if some user account login/password exist in the camera, and a few more to retrieve some technical info from the camera and finally the video stream started but as you can see the packets are clear text with full login/password !!! so the video stream may not be encrypted too :-( but may be this P2P protocol allow encryption and it is the camera (or the P2P client) that do not support it, but I have no info about this but may be some reader of this thread will have an answer.
The video stream itself is a mixed content of 1032 bytes incoming UDP packet containing the video stream and UDP 10 bytes out (I guerss some ACK), plus some GVSP UDP packets (GigE Vision - Wikipedia) but as I did no NAT nor uPNP I suppose the camera (did not fully sniff that side yet) initiated some outgoing UDP forged packet to let the router allow the UDP packet answer back with the IP src of the P2P Cient that may have been comunicated by the server to the camera so from now we do have direct video stream between Camera and P2P client, and the server is not used anymore and is not used as a "proxy" as it should have been done if protocol has been TCP not UDP.
One user of this forum @Fastb said that one of its P2P camera used more than 2Go/month without any P2P Client watching the stream and this is very strange as my camera do not send anything out if no P2P client is connected (except a few packets time to time to the chinese server but those represent only a few bytes per day).
But may be there are multiple ways this P2P protocol is implemented ? or may be someone hacked into its system I don't know some investigation/network sniffing would be interesting @Fastb
So this is how far my investigation is about this P2P camera protocol and I am fully open to any explanation because I am really curious about it and especially the security aspect that for what I saw is non-existent... it's open bar !
regards.
A few days ago I tried the P2P feature of the Escam QD900 using a generic P2P camera client software on my Smartphone and also on a my PC from a different Internet access point.
As expected it worked well, zero setup, I just had to enter the UID that is unic for each camera (depending the camera's vendor the structure of this UID may differ but mine is something like ABCD-012345-ABCDE) a login and a password.
Then I wondered how it was possible to make this thing so easy with no usual NAT translation, DynDNS stuff...
So I started digging trying to understand how this P2P camera protocol works and did some network sniffing.
First the camera send some info to a server "somewhere" and transmit its UID so the server can associate IUD and IP address source (public IP of the router) a bit like any DynDNS service.
After that I also wondered how the video stream flow could work between client and camera as both are behind a router with internal private IP addr no DMZ and not port redirection/NAT or also no uPNP configured (checked on both side's routers).
So I did some network sniffing that showed some UDP communication with three kind of packets :
At the begining the P2P Client sent some "request for info packet" to some server with the UID of the camera I entered during configuration.
Then I saw direct UDP communication between the camera and the P2P Client.
The first UDP packets contained the IUD so I suppose they first checked "are you camera IUD XXXX" ?
Then came some http-like GET requests to check if some user account login/password exist in the camera, and a few more to retrieve some technical info from the camera and finally the video stream started but as you can see the packets are clear text with full login/password !!! so the video stream may not be encrypted too :-( but may be this P2P protocol allow encryption and it is the camera (or the P2P client) that do not support it, but I have no info about this but may be some reader of this thread will have an answer.
The video stream itself is a mixed content of 1032 bytes incoming UDP packet containing the video stream and UDP 10 bytes out (I guerss some ACK), plus some GVSP UDP packets (GigE Vision - Wikipedia) but as I did no NAT nor uPNP I suppose the camera (did not fully sniff that side yet) initiated some outgoing UDP forged packet to let the router allow the UDP packet answer back with the IP src of the P2P Cient that may have been comunicated by the server to the camera so from now we do have direct video stream between Camera and P2P client, and the server is not used anymore and is not used as a "proxy" as it should have been done if protocol has been TCP not UDP.
One user of this forum @Fastb said that one of its P2P camera used more than 2Go/month without any P2P Client watching the stream and this is very strange as my camera do not send anything out if no P2P client is connected (except a few packets time to time to the chinese server but those represent only a few bytes per day).
But may be there are multiple ways this P2P protocol is implemented ? or may be someone hacked into its system I don't know some investigation/network sniffing would be interesting @Fastb
So this is how far my investigation is about this P2P camera protocol and I am fully open to any explanation because I am really curious about it and especially the security aspect that for what I saw is non-existent... it's open bar !
regards.
Last edited:
