User Rating: 4 / 5
So one of the first things I played with when I got my Google+ was the Hangout feature - to kinda give a quick overview, it allows you and 9 others to create a room where you can see and talk using your Webcam and Mic, there is a Chat box and the options to share youtube videos. But thats not what this is about - this is about HOW it works, I'm a hacker after all ;)
So first things first, we wanted to check out the TCP connections - At first glace those are easy to see but what was interesting about it was the connections were only to Localhost - this wasn't analysed yet to see what those were for, I'm assuming it has to do with interconnects between some backend process and the web plugin.
Today, I started looking at the UDP packets, and to my surprise (After clearing out all of Skype connections) there was only ONE UDP stream, and only going to ONE IP address.
This IP has the following information:
me@server:~# nslookup 209.85.225.127 Server: 10.0.0.1 Address: 10.0.0.1#53 Non-authoritative answer: 127.225.85.209.in-addr.arpa name = iy-in-f127.1e100.net. Authoritative answers can be found from: 225.85.209.in-addr.arpa nameserver = ns3.google.com. 225.85.209.in-addr.arpa nameserver = ns1.google.com. 225.85.209.in-addr.arpa nameserver = ns4.google.com. 225.85.209.in-addr.arpa nameserver = ns2.google.com. ns3.google.com internet address = 216.239.36.10 ns1.google.com internet address = 216.239.32.10 ns4.google.com internet address = 216.239.38.10 ns2.google.com internet address = 216.239.34.10
So it looks like all the Video and Audio traffic is going though the one server (in this instance)
The process handling this traffic is:
udp 0 0 10.0.0.100:50437 0.0.0.0:* 12349/GoogleTalkPlu
udp 0 0 10.0.0.100:42549 0.0.0.0:* 12349/GoogleTalkPlu
udp 0 0 10.0.0.100:56608 0.0.0.0:* 12349/GoogleTalkPlu
All with the same Destination port of: 19305
Update 1:
Another interesting point is that the SERVER is sending STUN requests with the username attribute set to a random string to the client - to which the client is sending back the username and the servers "client" address.
Update 2 (Biggie):
Seems there is a little Data Leakage and infrastructure data. My client will also send out STUN requests to the server, however, when the SERVER responds - It returns an 10.13.32.10 - Safe to say, that isn't my internal, nor external IP address. This seems to suggest the servers are being load balancers and the STUN server isn't seeing MY external IP, but the internal IP of the load balancer. -- It's also reporting back a different port then any port in my captures.
Update 3:
Control and Chat are sent via encrypted XMPP - Nothing really surprising there to say the least. However, switching into YouTube mode, did not provide an XMPP event. (The Youtube request I found out is carried out by in the HTTPS stream) This XMPP server is located at 209.85.225.125 Duh, should have checked this - this turned out to be my GoogleTalk account ;)
Update 4:
Starting a new stream (and no one joined yet) - The same Server IP addresses and ports where seen. Random Client side ports are used, as expected. However, upon deeper inspection, a 4th port is used. The full list of ports used for the plugin is (New session then above):
me@server:/usr/local# netstat -anp | grep Google tcp 0 0 127.0.0.1:50981 0.0.0.0:* LISTEN 13116/GoogleTalkPlu tcp 0 0 127.0.0.1:50981 127.0.0.1:53486 ESTABLISHED 13116/GoogleTalkPlu tcp 0 0 127.0.0.1:50981 127.0.0.1:53458 ESTABLISHED 13116/GoogleTalkPlu tcp 0 0 127.0.0.1:50981 127.0.0.1:52903 ESTABLISHED 13116/GoogleTalkPlu udp 0 0 10.0.0.100:42102 0.0.0.0:* 13116/GoogleTalkPlu udp 0 0 10.0.0.100:35009 0.0.0.0:* 13116/GoogleTalkPlu udp 0 0 10.0.0.100:44302 0.0.0.0:* 13116/GoogleTalkPlu udp 0 0 10.0.0.100:36667 0.0.0.0:* 13116/GoogleTalkPlu unix 2 [ ] DGRAM 1814743 13116/GoogleTalkPlu @google-nacl-GoogleTalkPlugin unix 3 [ ] SEQPACKET CONNECTED 1833112 13116/GoogleTalkPlu unix 3 [ ] SEQPACKET CONNECTED 1830401 13116/GoogleTalkPlu unix 3 [ ] STREAM CONNECTED 1790867 13116/GoogleTalkPlu
The interesting part is the localhost connections. These connections only appear to be TCP packets with [PSH,ACK] and an [ACK] reply. There is data in the PSH packet, looks like statistics and maybe some control details. Example Data:
["jmidata","This email address is being protected from spambots. You need JavaScript enabled to view it.","c2018723930","1890",[[{"b":763553,"en":114,"fl":-1,"j":-1,"p":23916,"rtt":-1,"s":3493708127,"t":"s"}],[{"b":0,"fir":15,"fps":12,"h":360,"nack":457,"nbr":176000,"p": t["jai","This email address is being protected from spambots. You need JavaScript enabled to view it.","c2018723930","0",["0",[]],"5"] n["comment","SSRC 2 render input fps: 14,12,12,12,11,13,12,12,12,12 output fps: 14,12,12,12,11,13,12,12,12,12"] n["comment","SSRC 2 render input fps: 14,12,12,12,12,12,12,12,12,12 output fps: 15,12,12,12,11,13,12,12,12,12"] ["trstate","This email address is being protected from spambots. You need JavaScript enabled to view it.","c2018723930",{"allWritable":true,"anyRelay":false,"anyTcp":false,"anyWritable":true,"smoothedBWRecv":229738,"smoothedBWSend":495285}]
So there is some FPS stats, and state date communicated via loopback in the same processes. Interesting, using GDB I caused a restart of the process - it kept the old ports open and created new threads.
Update 5:
Turning to the Binary we found these interesting strings:
received-voice.rtpdump
sent-voice.rtpdump
received-video.rtpdump
sent-video.rtpdump
application/aecdump
application/rtpdump application/x-bzip
google:jingle
urn:xmpp:jingle:1
stun.l.google.com
Seems there is also some references to the GIPS codec (http://www.voip-info.org/wiki/view/GIPS) and H.264 (http://en.wikipedia.org/wiki/H.264/MPEG-4_AVC) and what appears to be ICEMediaStreams. This domain also popped up: http://www.vidyo.com/