1. KaZaA: Behind the Scenes Shreeram Sahasrabudhe Lehigh University sas4@lehigh.edu

2. Fasttrack network Created in Mar 2001, Fasttrack was a software company that developed a software library for a P2P network. KaZaA was their first application to use the library. Today, Grokster and iMesh are other licensed clients of the Fasttrack network.

3. Why Fasttrack? KaZaA has over 200million downloads and shows over 4 million users online at any time. It’s a closed protocol All Traffic is encrypted Minimal information available about the network – scalability, robustness and operation.

4. What we know? 2-tier Architecture: nodes & supernodes Supernodes are high bandwidth users who aid searches of neighborhood nodes. Supernode {File 1?} Supernode Peer 1Peer 2Peer 3 File 2 File 4 File 5 File 1 File 3 File 6 File 3 File 7 File 10 Search query {File 1?} Peer 2: File 1 GET File 1 A detailed study was done earlier by…?? RIAA of course

5. Project Idea / Goals To understand how the Fasttrack network works. No focus on cryptanalysis of the traffic. Understand behavior (communication, allocation etc.) of supernodes. Establish patterns in supernode communication.

6. Methodology Ran KaZaA software on a lab machine for about 4 weeks. Using a custom packet sniffer we logged the packet information such as: Date & Time of Packet, Source Address, Destination address and Protocol. Analyzed the log files using Perl scripts to give us detailed report of each log file: Total Unique Destination IP Addresses List of destination IP addresses and number of packets sent to each. Total Unique Source IP Addresses List of source IP addresses and number of packets received from each. Besides this, we also analyzed the traffic during the login of KaZaA.

7. Install & Login Observations The available KaZaA setup file is just a web install. During setup, it connects to a peer and downloads the KaZaA install file – kmd210.exe Each time you try to install it connects to a new peer with varying download speeds. At login Connects to a central login server rr1.kazaa.com (7 IP addresses) in Denmark. Sends information like country, client, version etc.

8. Immediately after, the peer sends ICMP ping messages to about 4 – 5 other peers. Those who reply to these messages are then contacted by a separate TCP connection on specific destination ports. The purpose of this communication seems to be to let the peer know of a port to contact us. On repeated attempts to login – different sets of peers are contacted! If none of the peers reply to initial ping messages then a different set of peers are sent UDP packets. Then the same procedure as above.

9. Traffic Analysis and Observations Parsed the list of IP addresses in each report to get their frequency. About 7 address were communicating with our machine on a regular basis for over 4 days. (3 from Lehigh ;), 3 from other universities and 1 broadband) These were our candidates for supernodes. Also, our node had reached the status of Guru (309 points). A new node starts with a status of medium (100 points). We were now set to do further detailed analysis with an improved packet sniffer when …

10. …the Traffic Stopped!

11. This is not the first of its kind. The giFT project, a relatively big project, was successful in reverse engineering the Fasttrack protocol. Fasttrack changed their protocol (and encryption) and things were back to where they started. Currently two projects are working on this task: Project Fasttrack www.projectfasttrack.comwww.projectfasttrack.com RapidRoad www.rapidroad.tkwww.rapidroad.tk None of the above companies have released any public software or documentation to validate their claimed progress.

12. Queries? Thank You!