This tool demonstrates a system for identifying the real IP address of a web user, regardless of proxy settings, using a combination of client-side technologies and custom services. No vulnerabilities are exploited by this tool. A properly configured Tor setup should not result in any identifying information being exposed.

You reached this web site through the IP address 38.107.179.229.

>>  Start Test

It is now possible to embed the decloaking engine into third-party web sites, using the services hosted at decloak.net. This is a great way to track down abusive users or verify the privacy settings of your site's visitors. Keep in mind that some of the tests used by the decloaking engine can trigger popups, alerts, and sometimes crashes. Embedding the decloaking engine into a high-traffic page is a bad idea and will probably be received poorly by your visitors. Instead, setup specific pages for privacy checks or target abusive users with a URL that has as narrow an audience as possible. Any malicious use of the decloaking engine will be logged and blocked. If we see a large number of requests coming from any one site, all requests from that site will be dropped.

To get started with the embeddable decloaking engine, following these three steps.

1. Generate a unique 32-byte hexadeximal string for the specific visitor you want to test. The easiest way to do this is to generate an MD5 hash of a blob of random data. As long as your ID does not clash with an existing one, it should work fine. In PHP, an easy way to obtain a unique ID is by calling the md5() function with a combination of visitor information and a random value. The example below uses the visitors IP address and source port, along with a secret string and the current system time.
   
   
   md5("secret" . $_SERVER['REMOTE_ADDR'] . $_SERVER['REMOTE_PORT'] . time() . "secret");
   
   
2. Once a unique 32-byte hexadecimal value has been generated, embed an iframe with the following format:
   
   <iframe src="http://decloak.net/decloak.html?cid=<UNIQUE_ID>"></iframe>
   
   
3. To obtain the raw results for a given ID value, query the following URL:
   
   http://decloak.net/report.html?cid=<UNIQUE_ID>&format=text

The default settings for the decloaking engine are aggressive and can trigger popups and warning dialogs. In order to embed the decloaking engine in a way that is less intrusive, specific tests can be skipped by appending the following query string parameters to the decloak URL. The table below describes the available options.

word	This value can be set to 0 in order to skip the embedded document test
java	This value can be set to 0 in order to skip the Java applet test
flash	This value can be set to 0 in order to skip the Flash movie test
quicktime	This value can be set to 0 in order to skip the Quicktime test
itunes	This value can be set to 0 in order to skip the iTunes test

The report format is comma delimited with the following fields:

1. Timestamp: The server time that the event was received
2. Event Name: The type of event that was received
3. Address 1: This is the address seen by the web server, it is 0.0.0.0 for some events
4. Address 2: This is the internal IP address (pre-NAT) of the user, if available
5. Address 3: This is either the real source address of the user or the address of a DNS server they use

While this format is not very consistent, it can be processed with some simple rules.

1. The first event is always 'start' and records the IP address seen by the web server in the Address 1 field


2. The http, quicktime, java, word, and itms event types all use Address 1 for the IP seen by the web server and Address 3 for the DNS server used to resolve the *.spy.decloak.net host name


3. The socket and udp event types have the real decloaked IP in the Address 3 field


4. The quicktimehttp, itmshttp, and wordhttp event types have the real decloaked IP in the Address 1 field

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.