Didier Stevens

Monday 25 February 2013

Looking Up Hosts and IP Addresses: Yet Another Tool

Filed under: My Software,Networking — Didier Stevens @ 19:30

One last thing regarding my TeamViewer research: I had to resolve a bunch of hostnames and IP addresses, so I quickly wrote a Python program that did just that. Later I took the time to make some generic and versatile programs: lookup-hosts.py and lookup-ips.py.

lookup-hosts.py takes hostnames or files with hostnames via arguments or stdin, and then uses getaddrinfo to lookup the IP addresses. And you can use a counter if you need to lookup sequentially numbered hosts, like this: master[0-20].teamviewer.com. This will instruct the program to lookup master0.teamviewer.com, master1.teamviewer.com, … and master20.teamviewer.com. If you need a leading zero, use this syntax: master[0-20:2].teamviewer.com

The programs take options, use the -h option to explore them.

As it names implies, lookup-ips.py does the opposite of lookup-hosts.py by using gethostbyaddr. You provide it IP addresses and/or subnets (like X.X.X.X/24).

20130225-194749

lookup-tools_V0_0_1.zip (https)
MD5: EB9C5BEF25EC5ED0F44297AA8A04679E
SHA256: 755E98BA0BC09C31E58ED4BF7B08CD42467BBF9B129C77DD6D558FD6B6E27124

Wednesday 20 February 2013

Update XORSearch V1.8.0: Shifting

Filed under: My Software,OSX,Reverse Engineering,Update — Didier Stevens @ 21:32

This new version of XORSearch comes with a new operation: shifting left.

It comes in handy to reverse engineer protocols like TeamViewer’s remote access protocol.

Here’s an example. When you run TeamViewer, your machine gets an ID:

20-02-2013 22-11-39

We capture some TeamViewer traffic with Wireshark, and then we use XORSearch to search for TeamViewer ID 441055893 in this traffic:

20130216-231230

And as you can see, XORSearch finds this ID by left-shifting the content of the pcap file with one bit.

Thursday 14 February 2013

Quickpost: TeamViewer and Proxies

Filed under: Forensics,Networking,Reverse Engineering — Didier Stevens @ 22:15

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).

Blog at WordPress.com.