Sorry for the lack of recent posts, I’ve been ill and had to catch up with a lot of work.
Braden Thomas wrote an interesting series of posts on reversing the TeamViewer protocol.
I want to add my own observation: when TeamViewer is forced to communicate over an HTTP proxy, it will issue GET statements with parameter data that can be decoded in a similar way as Braden describes for the direct protocol (i.e. without proxy).
First of all, to identify TeamViewer traffic in proxy logs, you look for this User Agent String: “Mozilla/4.0 (compatible; MSIE 6.0; DynGate)”.
You will see HTTP GET requests like this one:
hxxp://178.77.120.6/dout.aspx?s=55194936&p=10000001&client=DynGate&data=FyQSAAExtjSytzoeqisTMbe3NzKxujS3tza3sjKemJMzHqkyu…
When you decode the value of the data= parameter as base64, you can identify the version of the protocol (first 2bytes) and the command (3rd byte):
0x1724 0x12
0x12 is a CMD_MASTERCOMMAND. By left-shifting the data from the 5th byte with 1 bit, you can decode the arguments of a MASTERCOMMAND, like this:
client=TV&connectionmode=1&f=RequestRoute2&homeserver=&ic=708710721&id=123456789&id1=123456789&id2=987654321&licensecode=…
When parameter f (the function) is RequestRoute2, you know that the TeamViewer user issued a command to connect to another TeamViewer client. Parameter id identifies the originating client (123456789 in my example), and parameter id2 identifies the destination (987654321 in my example).
Didier Stevens 