This site used to provide a demo of identifying the real IP address of a web user, regardless of proxy settings, using a combination of client-side technologies and custom services. The demo has been offline for about two years, but the code samples and implementation details below may be of some use.


The decloaking engine is based on the following techniques.

1. When a web client tries to resolve a host name, it will send a lookup request to its configured DNS server. The client's DNS server will then send a query to the name server for the particular domain. If the host name contains a unique identifier, it is possible to correlate the IP address of the client with that of its DNS server. This can leak the ISP or company from which a given client is accessing the web, even if a proxy is in use. This leak does not occur when the proxy server is responsible for performing DNS resolution (socks4a, but not socks4).


2. When a Java applet tries to resolve a host name using the socket API, and the host name is not the same as the web site that served the applet, a security exception is raised. However, even though a security exception is triggered, the DNS request itself is still sent to the client's DNS server. This can leak the ISP or company from which a given client is accessing the web, even in cases when a DNS enabled proxy server is in use.


3. When a Java applet sends UDP packets back to the originating host, the packets are usually sent without passing through the proxy service. This will leak the real external IP address of the web client. This method may not work with newer versions of Java and the packet destination is limited to the IP address that served up the applet.


4. When Java is enabled, the host name and IP address of the web client are available by accessing the socket API. This method will leak the name of the user's workstation and the IP address, as the system sees itself. In other words, this will leak the internal IP address of the system, even if the system is behind a NAT gateway or a proxy server.


5. When the Flash plugin is installed, it allows direct TCP connections back to the originating host. These connections may bypass the proxy server, leaking the real external address of the user's workstation.


6. When Microsoft Office is installed and configured to automatically open documents, a file can be returned which automatically downloads an image from the internet. This can bypass proxy settings and expose the real DNS servers of the user.


7. When the Quicktime plugin is installed, it can be loaded with a parameter which explicitly tells it to use a direct connection for the movie and to ignore the browser's settings.


8. When the iTunes is installed, it registers the itms:// protocol handler. This protocol handler will open iTunes and do a direct connection to the specified URL. There are some restrictions on the URL you can pass, but we found a nice way around them :-)

To implement these techniques, the following components were developed.

• A custom DNS server that handles all requests for a specific domain This demonstration uses the domain spy.decloak.net and handles requests using a Perl Net::DNS::Nameserver script. A neat feature of this DNS server is that looking up any host in the spy.decloak.net domain will return the external IP address of your own configured DNS server. This server also handles UDP requests from Java and TCP requests from Flash.


• A Postgres database configured with a simple schema for cross-referencing a web user with the data obtained by the DNS server.

   Column |            Type             | Modifiers
  --------+-----------------------------+-----------
   cid    | character(32)               |
   type   | character varying(16)       |
   eip    | character varying(16)       |
   iip    | character varying(16)       |
   dip    | character varying(16)       |
   stamp  | timestamp without time zone |
  



• A Java applet that implements techniques #2 and #3.


• A Flash application that implements technique #5.