Main menu

User Rating: 4 / 5

Star ActiveStar ActiveStar ActiveStar ActiveStar Inactive
 

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/

 

 

Comments   

0 #1 pgl 2011-07-01 18:17
Cheers for posting this.
Quote

Add comment


Security code
Refresh