From a talk on hardware embedded analysis at REcon on the 10th of July. In addition to some of the information I’ve presented before, as well as some updates, myself and photographer Hanna Fuhrmann spent the better part of a couple months prior working on making the documentation of these techniques and tools more digestible with an esthetic twist.

I will be giving a workshop at the CCCB in Berlin on Embedded Analysis (starting the 12th at 20:00). Anyone is welcome and attendees are asked to bring a potential target (router, mp3 player, phone, etc) for analysis. I will walk through the process of documenting and analysis based on the information and tools I released the CCC congress last year (Video, Tutorial). If you plan to attend please let me know. If you have a target send me the details, or place them on the wiki, so that we can help find details (datasheets, etc) and create an attack plan already. If you need a place to stay feel free to contact me, perhaps I can find something.

The schedule: on the 12th we will go over the tools and attack plans. During the two weeks that follow I will be at the CCCB and people can come and go as they like to continue work on the various projects. On the 26th everyone will present their own findings. ph-neutral is on the 27th+ so anyone attending that, feel free to piggy back.

I look forward to learning something new!

It’s simple: if we can determine the network latency between a proxy user and their proxy we can begin to make educated guesses about their location or at least how close they are to the proxy. This latency can be determined by analyzing any sequential serialized traffic. As an example imagine a website that has early in the HTML header code a request for a script. The browser will begin processing the HTML and then immediately request the script:

1: Users_browser     GET index.html  -->  Server
2: Users_browser <-- index.html data      Server
[browser processes index.html and see's a required script] 
3: Users_browser     GET script.js   -->  Server
4: Users_browser <-- script.js data       Server

If the user is sending and receiving via a proxy we need to figure out the latency between the user and the proxy, as well as the distance between the proxy and the server. The requests, with mnemonics representing the latency we need to determine (l_pu = latency between proxy and user, l_ps =  latency between proxy and server), look as follows:

                [       l_pu       ]     [l_ps]
1: Users_browser     index.html --> Proxy  --> Server
2: Users_browser <-- index.html     Proxy <--  Server
3: Users_browser     script.js  --> Proxy  --> Server
4: Users_browser <-- script.js      Proxy <--  Server

Determining l_ps can be done in many ways, the simplest being sending a ping request from the server to the IP address of the proxy. To determine l_pu the server sets a time stamp when it sends back the index.html data (line 2) and subtracts this from the time it receives the request for script.js (line 3). The result is the total round trip time between the user and the server (tRTT). Now l_pu can be calculated as:

l_pu = (tRTT - (l_ps * 2)) / 2

This simplification ignores a lot. Such as the latency overhead added due to how different browsers process certain content or the discrepancy between different users and proxies with differing types of uplinks that effect the latency (dialup, DSL, ISDN, cellular GPRS and UMTS). Even with such caveats this technique can still be used for applications such as restricting content to users that “should” be close to their exit node or proxy. If the caveats can be handled the potential exists for using a basic latency map of long haul cross continent network backbones to give clues such as if a proxy user accessing a system in the UK is coming from the west, south america or the east. On its own the use is limited but as one clue along with others it has more relevant application.

This technique can be applied with greater accuracy to other systems. Dor Levi and I developed a basic server based application to show users that might be using a proxy server-side. But this could be done client side as well. For example, a Flash applett could be built and included in online auctions so that both the seller or the auction house could detect when suspicious bids are coming from behind a proxy.

I would be interested to hear of other research in this area. Personally I am a strong advocate and sporadic developer that helps where I can in building stronger anonymity systems. I am also an absolute technologist and believe that evolution in this field requires progress from all directions.