tcpprox - An intercepting TCP proxy

December 11, 2016

On numerous occasions I’ve run into custom binary network protocols that I’ve wanted to reverse. The usual goto here is to fireup wireshark/tcpdump and view the traffic as it goes accross the wire. This works really well in most cases, but how about traffic that uses TLS to encrypt the traffic? Unless you have the private key for the server, you are stuck with viewing encrypted traffic in wireshark. Not ideal for reverse engineering.

To overcome this, I decided to find a TCP proxy capable of intercepting TLS traffic and allowing me to view the raw, unencrypted protocol, basically the same thing as what you get when using mitmproxy or Burp. Unfortunately I wasn’t able to find anything to match my needs (admittedly I did a very lazy search and decided it’s more fun to implement my own anyway). Armed with an excuse to do some more coding, tcpprox.go was born. The basic idea was to have two operating modes, plain-text and TLS enabled.

Plain-text:

In this mode we setup a listen-connect proxy (bascially a socat tunnel), where we accept a connection, establish another connection to our target server, and then shunt all traffic between the two. Simple. This works great but doesn’t really give you anything more than wireshark or tcpdump would. Natuarlly this is extendable and I’ve used it to modify traffic in-line, something along the lines of s/\x00\x01\x00\x01/\x01\x00\x01\x00/g where we simply replace byte patterns. Most of the time the nice hex-dump view is enough and what’s needed to understand a protocol’s functinality.

TLS:

Here we setup a proper mitm proxy, where we still do a listen-connect proxy, however everything gets wrapped in TLS. This is where tcpprox has really worked well for me in the past. Especially when working on the RPC/HTTP component of Ruler, as it allowed me to actually see what is going on. Trying to use Burp/Fiddler on this traffic was usueless, as these proxies showed the first bit of the connection, the initial HTTP message, but failed to display the streaming data. Burp didn’t show anything, while Fiddler stated that “RPC traffic can not be inspected”.

With tcpprox, I was able to mitm the HTTPS connection (as HTTPS is a TLS-TCP connection with HTTP traffic), and inspect the traffic flowing between the client and server. Here it was possible to spot the DCERP traffic going across the wire and figure out what is needed to setup a correct connection.