They have a more technical description of the process further down in the article, in the grey box: "IP addresses and physical server locations are inherently

They have a more technical description of the process further down in the article, in the grey box: "IP addresses and physical server locations are inherently difficult to find on the Tor network. So how did VG’s computer expert get the forum to disclose this information? 1. Profile picture upload The forum allowed users to upload a profile picture. This picture could also be fetched from a user-supplied URL. 2. The leak This is where the information leak occurs. Configured for optimal security, the forum’s software and/or server would fetch the remote profile picture via Tor. Childs Play did not – all traffic to external sites originated from the server’s real IP. 3. The IP address is exposed By telling the forum to fetch a picture from a server Stangvik controlled, he could see in his server logs that the originating IP was with a hosting provider in Sydney – Digital Pacific. Stangvik went on to confirm that outgoing DNS requests originated from the same provider, and that the forum’s software also loaded images included in forum post previews from the same IP. 4. A proxy, VPN or Tor Exit? The next question was whether the IP belonged to a Tor Exit Node, a VPN or a proxy server. An IP can hide just about anything. How could he confirm that this was the forum’s location, rather than just a node in a chain of redirects? Stangvik applied three improvised techniques: 5. Timing between the servers He rented a virtual server with Digital Pacific – the same place as where the suspected IP was located. He then updated the profile picture URL to point to this server. Upon receiving an incoming profile picture request, Stangvik’s server would respond with a redirect to another URL on the same virtual server. Repeating this redirection process several time, Stangvik was able to isolate and measure the roundtrip-time between the two servers. The measurements yielded very low times, consistent with a forum server in close vicinity of his rented server. 6. Measuring intermediate nodes Stangvik also paid attention to so-called «Time To Live» values on the incoming data packets. These provide some insight into how many intermediate parties are involved from the sender to the recipient. In this case, the values indicated that there were at most one intermediate – a typical result if the servers were located in the same room. 7. Measuring packet size The final test started to get advanced: Measuring MTU (Maximum Transmission Unit) and packet fragmentation. Each packet in a computer network has a maximum transmission size, based on which intermediates it passes through. Each encapsulating technology, such as VPNs, can result in the total packet size increasing beyond the maximum size, and local networks usually have larger maximum sizes than the “tubes” found on the internet. If the maximum size is surpassed, the packet will be broken into multiple fragments. By crafting long profile picture URLs, and setting specific packet flags, in the redirects returned by his custom web server software, he could see that the MTU was consistent with that of high-speed local area network traffic, and also ruled out VPN configurations."