Keyun Ruan

Joshua James

Joe Carthy

Tahar Kechadi

KEY TERMS FOR SERVICE LEVEL AGREEMENTS TO SUPPORT CLOUD FORENSICS

Keywords:

ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

Cloud computing has the potential to become one of the most transformative technologies in the history of computing. Gartner [START_REF] Gammage | Gartner's Top Predictions for IT Organizations and Users, 2011 and Beyond: IT's Growing Transparency[END_REF] estimates that, by 2015, 20% of non-IT Global 500 companies will be cloud providers. However, the rapid growth and adoption of cloud computing as a "non-standard system" [START_REF] Beebe | Digital forensic research: The good, the bad and the unaddressed[END_REF] is raising significant challenges with regard to digital forensics. Cloud organizations, including cloud providers and cloud consumers, must establish forensic capabilities. Otherwise, they will face tremendous difficulties in investigating incidents such as policy violations and criminal intrusions.

Ruan, et al. [START_REF] Ruan | Cloud forensics[END_REF] have introduced a three-dimensional model that explores the organizational, technical and legal aspects of cloud forensics. They also analyzed some of the major challenges and opportunities regarding cloud forensics. This knowledge was used to develop a survey of cloud forensics and critical criteria for cloud forensic capabilities, which was submitted to digital forensic experts and practitioners from around the world. The survey received a strong response from the forensic community. Of the 156 survey responses, 75% of the respondents agreed or strongly agreed that "missing terms and conditions in service level agreements (SLAs) regarding investigations" is a challenge for cloud forensics [START_REF] Ruan | Cloud forensics[END_REF]. Additionally, 77.61% of the respondents agreed or strongly agreed that the "tools provided, techniques supported and access granted regarding forensic investigations should be included in SLAs." This paper attempts to address the needs by suggesting key terms that should be included in SLAs between cloud providers and cloud consumers regarding the organizational, technical and legal aspects of cloud forensics.

Cloud Computing

The NIST definition of cloud computing specifies three deployment models: software as a service (SaaS), platform as a service (PaaS) and infrastructure as a service (IaaS); and four delivery models: private (internal) cloud, community cloud, public cloud and hybrid cloud [START_REF] Mell | The NIST Definition of Cloud Computing[END_REF].

The segregation of duties between cloud providers and cloud consumers regarding forensic activities depends on the deployment and delivery models. For example, in the SaaS model, the cloud provider has administrative control over the application layer and total control over the middleware, operating system and hardware layers; while the cloud consumer has limited administrative control over the application layer and no control over the middleware, operating system and hardware layers. In community, public and hybrid clouds, multiple tenants share the middleware, operating system and hardware layers.

In the PaaS model, the cloud provider has administrative control over the application and middleware layers, and total control over the operating system and hardware layers; while the cloud consumer has limited programmability for the application and middleware layers, and no control over the operating system and hardware layers. In community, public and hybrid clouds, multiple tenants share the operating system and hardware layers.

In the IaaS model, the cloud provider has no control over the application, middleware and operating system layers, administrative control over the hypervisor (virtualization) and hardware layers; while the cloud consumer has total control over the application, middleware and operating system layers, and no control over the hypervisor and hardware layers. In community, public and hybrid clouds, multiple tenants share the hypervisor and hardware layers.

Forensic Data Access

Before discussing the organizational, technical and legal terms in SLAs regarding cloud forensics, it is important to review the specific cloud offering(s) that the cloud consumer may sign up for with the cloud provider. Also, it is important to understand the governance over the data and operations that are inherent to the offerings.

Encryption Keys

Currently, major cloud providers such as Amazon encourage cloud consumers to encrypt everything, or at least all their sensitive data [START_REF] Amazon | Amazon Web Services: Overview of Security Processes[END_REF]. As far as forensic investigations are concerned, it is currently impossible to analyze and examine data that is strongly encrypted.

In the survey by Ruan, et al. [START_REF] Ruan | Survey on cloud forensics and critical criteria for cloud forensic capability: A preliminary analysis[END_REF], 83.34% of the respondents agreed that "a procedure and a set of toolkits in the cloud organization to obtain keys for encrypted data in the cloud" is important or very important. The cloud provider and the cloud consumer must agree on the circumstances under which an investigation team may access the encryption keys, and stipulate the policies and procedures pertaining to key management, key access and collaboration with law enforcement during an investigation.

Logs and Forensic Artifacts

The survey by Ruan, et al. [START_REF] Ruan | Survey on cloud forensics and critical criteria for cloud forensic capability: A preliminary analysis[END_REF] noted that 74.24% of the respondents felt that "an agreement on access to and control over forensic data at all levels between cloud organizations" is important or very important.

Logs are valuable data sources in most forensic investigations. Accessing logs in the cloud is almost always a complicated scenario involving the provider and consumer. In the SaaS model, the provider has administrative control over the application logs, while the consumer has limited administrative access. In the IaaS model, the provider has no control over the application and system logs, while the consumer has total control. Also, the provider has administrative control over the hypervisor logs while the consumer has no control.

An SLA should address the right of a forensic team to access the logs at all levels from the provider and the consumer sides. Also, the agreement should address the segregation of duties that should occur when relevant logs from both sides are provided to external forensic entities and law enforcement. Language should be included in the SLA that describes the logging and retention policy, including retention duration, log storage location and the entities who are authorized to access the logs.

In a cloud environment, data is automatically mirrored to multiple locations to ensure data redundancy. Data redundancy is useful in forensic investigations because evidence that is lost or destroyed in one location may be found elsewhere. The agreement should stipulate the conditions under which the internal forensic team, external forensic entities and law enforcement can access mirrored artifacts during forensic investigations.

Data and Infrastructure Location

In the survey [START_REF] Ruan | Survey on cloud forensics and critical criteria for cloud forensic capability: A preliminary analysis[END_REF], 79.17% of the respondents agreed or strongly agreed that the loss of physical control of data is crucial to forensic investigations. The physical locations of data are needed to determine the jurisdiction of the investigation. The investigator must be aware of the physical locations of the data in order to not breach privacy or other privileges based on the jurisdiction where the data resides. Moreover, the physical location of the data should be kept confidential so as not to expose sensitive data to potential attacks. The agreement between the cloud provider and the cloud consumer must address the transparency of the physical locations of consumer data, virtual disk images and infrastructure. Example considerations include the conditions under which the cloud provider may provide information about the physical locations of consumer data and the procedures used by an internal forensic team, external forensic entities and law enforcement to obtain this information.

Organizational Dimension

The organizational dimension of an SLA covers staffing, certifications and the interactions between the cloud provider and the consumer forensic team, external forensic entities and law enforcement.

Forensic Staffing Structure

The forensic staffing structure depends heavily on the specific cloud offering. In an IaaS model, the forensic team is likely to comprise staff from the cloud consumer. In a PaaS model, forensics is a shared responsibility, so the forensic team would have personnel from the cloud provider and cloud consumer. In a SaaS model, the team would likely comprise staff from the cloud provider. It is important that the agreement between the cloud provider and cloud consumer address the segregation of duties when providing forensic staffing according to the specific cloud offering.

Some forensic activities in cloud organizations are carried out regularly, such as proactive forensic data collection and log monitoring; others are performed after the incident, such as the analysis of forensic data. Forensic teams from the provider side and consumer side would perform the majority of these forensic activities. The SLA should, therefore, address the segregation of duties between the cloud provider and consumer during incidents, responses and activities.

Forensic Training and Certification

Practitioners who conduct forensic investigations should be appropriately trained and certified, and should be prepared to testify about the relevance and implications of their actions. Cloud providers and consumers should ensure that their internal forensic staff have forensic training at least annually to ensure up-to-date knowledge and skills. Likewise, when cloud consumers contract out for forensic services, they should ensure that the third-party entities are competent and knowledgeable about traditional and cloud forensic techniques and their implications.

Organizational Interactions

There is often a chain of dependencies in a cloud provider that can complicate a cloud forensic investigation [START_REF] Ruan | Cloud forensics[END_REF]. It is important that an SLA mandates the transparency of the chain of dependencies regarding key operations and addresses the reaction plan in terms of communication, collaboration and access to forensic data within the chain of dependencies. Collaboration with law enforcement when multiple cloud providers are involved should also be considered. Additionally, it is necessary to specify the situations where external forensic assistance would be necessary and the entities who would be involved in these situations.

Technical Dimension

The technical dimension relevant to an SLA deals with the technologies that are used to prepare for and facilitate forensic investigations. These include data collection, forensic tools tailored to cloud environments, incident response policy and time synchronization.

Proactive Forensic Preparation

Proactive measures can simplify cloud forensic investigations. Measures include designing forensically-aware cloud applications and proactively collecting and retaining forensic data in the cloud. In the survey [START_REF] Ruan | Survey on cloud forensics and critical criteria for cloud forensic capability: A preliminary analysis[END_REF], 83.58% of the respondents agreed that "a procedure and a set of toolkits to proactively collect forensically-relevant data in the cloud" is important or very important.

An SLA should address the segregation of duties and procedures for proactive forensic preparation and data collection in order to facilitate investigations initiated by the cloud provider, cloud consumer or law enforcement. The agreement should cover the mechanisms used for logging, authentication and auditing of access to all the identified data sources, as well as the replication and verification of data sources. Proactive data collection should include not only the logging of connections external to the provided services, but also inter-cloud communications and management requests. Furthermore, lawful data collection should be made available at every layer of the cloud infrastructure up to the end user. The mechanisms must ensure that an investigator has timely access to the collected data after an event has occurred and also allow for the validation of the collected data.

Forensic Data Collection

Cloud forensic data collection is the process of identifying and acquiring data in the cloud using procedures that allow the results to be presented in a court of law. The data includes client-side artifacts that reside on client premises and provider-side artifacts that reside in the provider infrastructure. As in traditional digital forensics, the collection process should follow procedures that preserve the integrity of data without breaching laws and regulations in the jurisdiction(s) where data is collected. Also, the process should not compromise the confidentiality of other tenants who share the resources [START_REF] Ruan | Cloud forensics[END_REF].

Due to access restrictions, it is possible that SaaS providers may not provide access to the IP logs of clients who have accessed content. Likewise, IaaS providers may not provide access to forensic data such as virtual machine and disk images. In the cloud, consumers have limited access to relevant log files and metadata at all levels. Also, cloud consumers have a limited ability to conduct real-time monitoring on their own networks and to audit the network operations of their cloud providers.

To support data acquisition by an investigator, the cloud provider, with the help of the consumer, should have previously identified all forensically-relevant data sources. Furthermore, the cloud provider and the cloud consumer, possibly with the support of a trusted third-party, should have the ability to independently take a snapshot of the current state of all consumer-related data when a malicious event is suspected.

The SLA should address the conditions under which cloud data is considered to be "deleted." Data deletion in the cloud is difficult and may sometimes be impossible. However, techniques such as crypto shred-ding [START_REF] Mogull | Cloud Data Security: Archive and Delete (Rough Cut), Securosis[END_REF] can make the recovery of the data impractical. For regulatory compliance, some data may have to be destroyed or rendered completely inaccessible. Stipulations should exist to ensure that the data management infrastructure of the cloud provider is able to fully meet all data destruction requirements; alternatively, acceptable options such as crypto shredding must be employed. It is also important to consider data retention policies when addressing data deletion issues.

Hybrid Forensic Tools

An SLA should specify the forensic tools that will be made available by the cloud provider to the cloud consumer and law enforcement. Rapid elasticity is one of the essential characteristics of cloud computing [START_REF] Mell | The NIST Definition of Cloud Computing[END_REF]. Cloud computing and storage resources can be provisioned on demand. As a result, cloud forensic tools must have dynamic scalability characteristics.

In most investigations, large-scale static and live forensic tools would be required for e-discovery, data acquisition, data recovery, evidence examination and evidence analysis. Scalable forensic data collection tools should be made available to consumers for use in investigations. Stipulations regarding data copying during investigations and the downtime and liability associated with the use of forensic tools should be clarified in an SLA.

Event correlation tools should also be made available to investigate incidents that affect multiple tenants. The correlation of log entries helps determine the scope of incidents and identify security flaws.

Incident Response and Recovery

The cloud provider and cloud consumer should work transparently to develop and agree on an incident response plan, and specify all the roles in the preparation, discovery, response, investigation, recovery and follow-up phases [START_REF] Osborne | Building an Incident Response Program to Suit Your Business[END_REF]. Forensic and security staff should work together to mitigate the impact of incidents, gather evidence and update security policies and procedures based on the lessons learned.

Virtualization is a key technology that is used to implement cloud services. Many security issues arise in the operation of virtualization technologies, especially in multi-tenant environments [START_REF] Ristenpart | Hey you, get off of my cloud: Exploring information leakage in third-party compute clouds[END_REF]. However, procedures and tools for conducting comprehensive investigations in virtualized environments have yet to be developed. Emphasis should be placed on the collection and analysis of artifacts related to incidents in virtualized environments.

Time Synchronization

Time synchronization in a network is important for security and reliability as well as regulatory compliance. The benefits of network time synchronization include prevention of operational failure, avoidance of data loss, improved security and mitigation of legal exposure. Time synchronization is important for auditing and transaction logging, a necessity for forensically-aware applications. Also, it helps ensure data reliability in the event of a breach.

In the survey [START_REF] Ruan | Survey on cloud forensics and critical criteria for cloud forensic capability: A preliminary analysis[END_REF], 62.5% of the respondents agreed or strongly agreed that "synchronization of timestamps" is a challenge in cloud forensics. It is, therefore, important that cloud providers implement secure network time synchronization throughout their infrastructures and provide audit information related to time synchronization for predetermined retention periods according to their agreements with cloud consumers. For time synchronization outside the control of a cloud provider, the provider should be responsible for auditing and logging the time differences over the predetermined retention periods.

Legal Dimension

The legal dimension of an SLA should address issues of jurisdiction, multi-tenant concerns, chain of custody, event notification, auditing and regulation compliance.

Jurisdiction

In the survey [START_REF] Ruan | Survey on cloud forensics and critical criteria for cloud forensic capability: A preliminary analysis[END_REF], 90.14% of the respondents agreed or strongly agreed that "jurisdiction" is important or very important. Also, 87.87% of the respondents agreed that "a procedure and a set of toolkits to retrieve forensic data involving confidential data under jurisdiction(s) and agreement(s) under which services are operating" are important or very important. The cloud consumer should be aware that it could be difficult, perhaps even impossible, to conduct an investigation when the data does not reside in jurisdictions with proper regulations, especially if the jurisdictions were not stipulated in the service agreement.

A cloud consumer should have the ability to choose the jurisdictions in which his/her data resides. The cloud provider should clarify the differences in laws regarding privacy, data protection and the legal conditions that could contribute to data loss or downtime, such as the ability of law enforcement to seize hardware during an investigation. The cloud provider should also accurately track the jurisdictions in which a cloud consumer's data resides during a given retention period. The tracking of jurisdictions enables the cloud consumer and law enforcement to more easily assess the legality of a claim.

Multi-Tenant Data Issues

Multiple tenancy is an inescapable feature of community, public and hybrid clouds. In a SaaS model, tenants share middleware, operating systems and hardware. In a PaaS model, tenants share operating systems and hardware. In an IaaS model, tenants share hypervisors and hardware. An SLA must address the ability of the cloud provider to accurately and comprehensively filter forensic data sources that contain data belonging multiple tenants and release only the data related to the specific tenant.

Data Ownership

Data ownership refers to the possession of data and the responsibility for the data. Ownership implies power as well as control. Control includes the ability to access, create, modify, package, derive benefit from, sell and remove data, as well as the right to assign these privileges to others. An SLA should address issues regarding data ownership in a cloud environment so that it is clear who owns the data that is being investigated.

Chain of Custody

In the survey [START_REF] Ruan | Survey on cloud forensics and critical criteria for cloud forensic capability: A preliminary analysis[END_REF], 77.6% of the respondents agreed that "a procedure and a set of toolkits to record and maintain the chain of custody in an investigation" is important or very important. The agreement should specify that the right to privacy exists so that only authorized parties can reliably access a consumer's data, while others, including the cloud provider, cannot. Along with service-provider-independent authentication, auditing of access must be provided and agreed upon. External entities and their roles in the transmission and storage of consumer data should also be specified in an SLA.

In the cloud, much of the data that is of interest in an investigation is obtained via live forensic techniques because the system is critical and cannot be taken down or because the virtual system is not persistent. As a consequence, verifying live data using traditional post mortem methods such as hashing is impossible.

The investigator should have a clear understanding of the forensic techniques and tools used in an investigation and how they affect the system. The Association of Chief Police Officers (ACPO) guidelines specify that "[i]n circumstances where a person finds it necessary to access original data held on a computer or on storage media, that person must be competent to do so and be able to give evidence explaining the relevance and the implications of their actions" [START_REF]Good Practice Guide for Computer-Based Electronic Evidence[END_REF]. Therefore, the terms of an SLA should stipulate that all data will be extracted and verified by competent, trained forensic practitioners using approved techniques and tools.

Event Notification

An SLA between a cloud provider and consumer should address the manner and the precise timeframe within which one party should notify the other party about critical incidents and law enforcement requests. All reaction plans should be made based on the notification protocol specified in the SLA and should include back-up solutions in the event that resources are seized.

Change of Cloud Provider

The cloud consumer has the right to change cloud providers. The SLA should clarify the responsibility of the cloud provider to retain consumer data for investigative purposes if and when the consumer chooses to migrate to another cloud provider.

Auditing

The cloud provider and consumer should agree on the auditing of the key terms in the SLA. Auditing should be performed by the client, by the provider and by third parties on a regular basis, and should include onsite inspections. Third parties should be approved by the cloud provider and consumer, along with the conditions under which an audit will occur. Also, the cloud provider and consumer should agree on the information that will be provided and who provides the information during an audit.

Regulatory Compliance

Regulatory compliance covers many areas such as the location of data, validity of timestamp information and privacy. The cloud consumer should determine the regulations that apply and specify the appropriate data transportation, storage, retention and management protocols. The cloud provider also has to adhere to regulations that are imposed on providers. The cloud provider must provide a satisfactory level of regulatory compliance and demonstrate its compliance in audits by a third party. The audit results should be made available to the cloud consumer, who should be able to clearly discern areas of non-compliance.

Conclusions

As the potential for criminal incidents involving cloud resources increases, it is imperative that cloud providers and consumers work together to create an environment that supports forensic investigations of the highest quality. This paper sets the stage for this process by specifying standard terms for SLAs that support cloud forensics. The terms cover the organizational, technical and legal dimensions of cloud forensics, and, as such, could help standardize and regulate the emerging area of cloud forensics. We hope that the concepts and terms described in this paper will be analyzed, refined and augmented by the various stakeholders to help create a strong foundation for cloud forensics.


Junbin Fang

Zoe Jiang

Kam-Pui Chow

Siu-Ming Yiu

Lucas Hui

Gang Zhou

Mengfei He

Yanbin Tang

Chapter 9 FORENSIC ANALYSIS OF PIRATED CHINESE SHANZHAI MOBILE PHONES

Keywords: Chinese Shanzhai phones, forensic analysis, phonebook, deleted data

Mobile phone use -and mobile phone piracy -have increased dramatically during the last decade. Because of the profits that can be made, more than four hundred pirated brands of mobile phones are available in China. These pirated phones, referred to as "Shanzhai phones," are often used by criminals because they are inexpensive and easy to obtain. However, the variety of pirated phones and the absence of documentation hinder the forensic analysis of these phones. This paper provides key details about the storage of the phonebook and call records in popular MediaTek Shanzhai mobile phones. This information can help investigators retrieve deleted call records and assist them in reconstructing the sequence of user activities.

Introduction

The use of mobile phones around the world has increased dramatically. According to the ITU, the number of global mobile subscribers reached 5.3 billion in 2011. During the first quarter of 2011 alone, vendors shipped 371.8 million units, an increase of 19.8 percent over the previous year [START_REF] Wauters | Worldwide mobile phone market grew 20% in Q1 2011, fueled by[END_REF].

Because of their portability and constant use, mobile phones hold information about user activities, contacts and whereabouts. This can be a treasure trove of evidence in criminal investigations. Traditionally, data that can be recovered from a mobile phone includes the phonebook, call logs, short message service (SMS) messages [START_REF] Punja | Mobile device analysis[END_REF], and possibly even deleted items. Smartphones also provide e-mail, multimedia files and web browsing data. The data is stored on various storage media, includ- ing the SIM card, internal flash memory and external memory cards [START_REF] Willassen | Forensic analysis of mobile phone internal memory[END_REF]. A variety of forensic tools are available for extracting evidence from SIM cards and external memory cards. However, extracting evidence from internal flash memory is more challenging.

Chinese Shanzhai mobile phones developed by MediaTek (MTK) [START_REF] Mediatek | Product lines[END_REF] and Spreadtrum [9] have gained a massive market share due to their low cost, high performance and ease of purchase. For example, the fake iPhone 4 shown in Figure 1 costs just $130 and low-end versions can be purchased for as little as $60.

As expected, more and more Shanzhai phones are being used by criminals. However, there has been little published research related to Shanzhai phone forensics. One reason is that the huge popularity of Shanzhai phones was entirely unexpected. Another is that there is almost no official documentation about the phones, especially regarding flash memory, file systems and other details about how the phones store data.

About 90 percent of Shanzhai phones are based on "turn-key" solutions developed by MTK and Spreadtrum. The turn-key solutions are development platforms that cover mobile phone hardware, operating system and software, including the core processing chipset, peripheral hardware prototype, operating system, software platform and software development kit. As with other smartphones, internal flash memory is the major data storage component in Shanzhai phones, but extracting evidence from the flash memory of Shanzhai phones is very challenging because of the variety of phones and the absence of documentation.

This paper is, to our knowledge, the first formal attempt to address Shanzhai phone forensics. It provides key details about the storage of the phonebook and call records in MediaTek Shanzhai mobile phones. This information can help investigators retrieve deleted call records and assist them in reconstructing the sequence of user activities.

Related Work

Research in mobile phone forensics was initiated in the early 2000s. Since then, a wide range of mobile forensic tools have been developed to acquire data from the flash memory of mobile phones [START_REF] Mccarthy | Forensic Analysis of Mobile Phones[END_REF]. However, most of the tools use commands and protocols that indirectly access the memory. In particular, they rely on the operating system, which means that the phone must be operational and only data that is visible to the operating system can be recovered -deleted data is not recoverable. Also, because of the manner in which they operate, the tools may change the memory contents.

Flasher tools provide the easiest non-invasive means of reading flash memory data [START_REF] Breeuwsma | Forensic data recovery from flash memory[END_REF]. They have been used in a number of mobile forensic examinations [START_REF] Gratzer | Cryptography, law enforcement and mobile communications[END_REF]. However, like traditional mobile forensic tools, flasher tools cannot ensure a complete dump of the memory and rely on the operating system. Also, if the data connector of the mobile phone is not supported by the flasher tool or the pins of the data connector are not connected directly to the pins of the main processor, then the pins on the printed circuit board must be manually connected to the flasher tool, a task that involves considerable electronic work and one that could possibly damage the device.

Physical extraction involves desoldering the internal flash memory chip from the mobile phone and acquiring the data using a chip memory reader. The extraction procedure requires considerable expertise and skill because the memory chip is easily damaged during desoldering.

Another physical extraction technique uses Joint Test Action Group (JTAG), a standard developed to automatically test the functionality and quality of integrated components on printed circuit boards. In this technique, JTAG test access ports are used to put the microprocessor in the debug mode and communicate with the memory chip, enabling the memory to be dumped bit-by-bit [START_REF] Willassen | Forensic analysis of mobile phone internal memory[END_REF][START_REF] Zhang | The research of MTK mobile phones flash file system recovery[END_REF]. The advantages of physical extraction are that it does not rely on the operating system and ensures that the entire binary image is extracted. Table 1 compares the three internal memory acquisition techniques discussed above. In our experiments, we opted for the easier technique involving the use of a flasher tool because the focus was on understanding the memory storage organization. Note, however, that the JTAG technique provides a better low-level picture of mobile phone memory.

Several mobile phone forensic tools have been developed for specific operating systems such as Symbian [START_REF] Mokhonoana | Acquisition of a Symbian smartphone's content with an on-phone forensic tool[END_REF], Windows Mobile [START_REF] Klaver | Windows Mobile advanced forensics[END_REF] and Android [START_REF] Vidas | Toward a general collection methodology for Android devices[END_REF]. However, since these tools are operating system dependent, they cannot be used to acquire data from Shanzhai phones.

With regard to MTK mobile phones, Zhang [START_REF] Zhang | The research of MTK mobile phones flash file system recovery[END_REF] has written a paper about recovering data from a flash file system. However, very few technical details are provided in the paper.

Chinese Shanzhai Phones

The minimal architecture of an MTK-based Shanzhai phone includes the MTK core chipset and an internal flash memory chip. The core chipset integrates a microprocessor unit, radio frequency transceiver module, GSM/GPRS module, multimedia modules, power management module, etc. The flash memory chip is usually integrated with random access memory (RAM) to conserve space on the printed circuit board. Note, however, that depending on the type of the flash memory, the memory allocation architecture for an MTK-based Shanzhai phone can be very different.

There are two main types of flash memory architectures: NOR flash and NAND flash. NOR flash memory can be read byte-by-byte in constant time. NOR flash memory is typically used for direct code execution, but some of the memory may be reserved for data storage (Figure 2). NAND flash memory is primarily used for general storage and data transfer. Code stored in NAND flash memory must be copied to RAM before it can be executed (Figure 3).

Shanzhai phones use both types of flash memory. NOR flash memory is usually deployed in low-end MTK chips (e.g., MT6225, MT6223 and MT6253) while NAND flash memory is usually deployed in highend MTK chips (e.g., MT6235, MT6238, MT6228 and MT6230). Since NOR flash memory has higher a cost-performance ratio than its NAND counterpart, it is used in a large number of Shanzhai phone models. Therefore, the rest of this paper focuses on NOR flash memory and the associated Shanzhai mobile phone models.

Experimental Results

Experiments were conducted on a low-end Shanzhai mobile phone model, a fake version of the Apple iPhone 4. Upon disassembling the device, we observed that the model was equipped with an MTK MT6253 chip and a 16 MB NOR flash memory chip (Toshiba TC58FYM7T8C). Our first task was to retrieve a binary image of the flash memory chip. Next, the flash memory dump was reverse engineered to extract forensically-relevant information.

Internal Memory Acquisition

A flasher tool was used to extract the memory contents of the MT6253 chip (Figure 4). Upon connecting the flasher tool to the MT6253 chip via the UART interface (RX and TX pins) on the chip, the Shanzhai phone was set to run in the factory programming mode. Next, a bootloader with a flash downloader program was transferred to the system RAM. This program dumped the flash memory byte-by-byte to the host computer.

Memory Dump Analysis

Before a hex editor such as HexWorkshop [START_REF]Hex Workshop Hex Editor[END_REF] could be used to analyze the binary image, it was necessary to understand the memory allocation scheme in the Shanzhai phone. The Toshiba TC58FYM7T8C chip integrates 16 MB NOR flash memory and 4 MB RAM. The 16 MB of NOR flash memory in the Shanzhai phone under test was divided into 14 MB of code area and 2 MB of FAT area, the default configuration in MTK's turn-key solution.

The 2 MB of FAT area comprised a user file area and a system file area. The user file area is directly accessible by normal users via the mobile phone operating system; it stores photographs taken by the phone camera, downloaded files, etc. The user file area serves as removable storage media when the mobile phone is connected to a personal computer running Windows. As shown in Figure 5, this area is about 256 bytes. The remaining portion of the FAT area is used as non-volatile random-access memory (NVRAM) for storing system files such as the phonebook, SMS messages and call history.

The NVRAM is the most important portion of the flash memory image because it contains the majority of user data. Some of the data can be read or modified using the Shanzhai phone display and user interface, but the raw format of the data is unknown and the data is inaccessible to mobile phone users. Data in the NVRAM is organized as data items and stored as files. The Data Item Management System deployed to manage NVRAM data maintains an internal lookup table to read and write data items.

Our experiments focused on understanding how phonebook entries and call records are stored. We inserted one phonebook entry with the name "PHONE0001" and the number "135704****2" (four digits are hidden to protect the privacy of the user). We then attempted to extract the information from the binary image using HexWorkshop.

As shown in Figure 6, nine bytes of ASCII characters beginning at address 0x001D1400 are used to record the name of the phonebook entry (0x50 is the ASCII code for "P" in PHONE0001). For simplicity, the hex address is the offset address shift from the absolute address 0x00E00000 (corresponding to 14 MB) in the flash image. One byte at address 0x001D143E is used to indicate the length in bytes of the stored phone number. The next byte contains 81 corresponding to an international phone indicator. The phone number is stored at address 0x001D1440 (corresponding to 0x001D1445 in the BCD scheme). Thus, the length of one phonebook entry is 86 bytes. Next, we searched the binary for the number "135704****2" in the call log. The BCD code corresponding to this number is 317504****F2. Figure 7 shows a match for the number. The time of the call is "2010-01-01, 16:19:07, Friday," which corresponds to the hex values in the upper rectangle in the figure (07 13 10 refer to the time "16:19:07" in reverse; note that the values are in hex, so that 13 corresponds to "19," 01 01 represents "January 1," 05 represents Friday and 0A refers to the "2010"). The duration for the call is "00:00:00" corresponding to a missed call; its value is indicated by the hex value in the lower rectangle in the figure. The important observation is that data in the binary image matches the data obtained by manual acquisition via the user interface of the mobile phone. The mobile phone only records time information for the last call corresponding to a phone number. Time information for all calls cannot be retrieved via the user interface. However, this information can be located in the binary as long as the data is not yet overwritten.

Time Sequence Reconstruction

As discussed above, only the most recent call data is obtained via the mobile phone operating system. This is a problem in criminal investigations, especially when a comprehensive call history is required. However, the binary image often contains multiple copies of data that are created and stored at different points in time. This is an outcome of the flash memory erasure and allocation mechanisms. Since flash memory can only be erased one block at a time and arbitrary random-access rewrites and erases are not permitted, we observed that when a data item in NVRAM is updated, the mobile phone may modify the old data items in RAM and copy the entire block to a new address and mark the memory address of the old data item as invalid. This produces multiple copies of data items, which persist until the memory space is overwritten by other data. While the creation times of the copies are not stored, it is still possible to construct the time sequence corresponding to when the copies were created. Note that data that has been deleted by the mobile phone operating system can also be retrieved and used to construct the time sequence.

To understand the situation, we performed the operations listed in Table 2 sequentially on the Shanzhai phone. The operations modified the data items contained in the phonebook.

After all the operations were performed, a flash memory image was dumped for analysis. Using the hex editor, we found multiple copies of various entries. The results are presented in Table 3.

Five memory segments (short for M EM SEG P HB) are shown in Figures 9 through [START_REF] Zhang | The research of MTK mobile phones flash file system recovery[END_REF]. With the help of the user interface of the mobile phone, we discovered that the current phonebook contains three entries, where M EM SEG P HB-5 in Figure 13 shows the storage of the current data item. Since each modification operation performed on the data item generates one copy, we can deduce that M EM SEG P HB-4 in Figure 12 is the previous version of M EM SEG P HB-5 because the memory space for entry "SZSMSC" in M EM SEG P HB-5 is filled with 0xFF values. Upon comparing M EM SEG P HB-4 and M EM SEG P HB-3 (Figure 11), we see that the difference between the two segments is the entry "PHONE44444." Thus, it can be deduced that M EM SEG P HB-4 is the updated version of M EM SEG P HB-3.

M EM SEG P HB-1 shown in Figure 9 only contains one entry of "PHONE0001," which has the smallest number of entries but the largest number of copies. Thus, M EM SEG P HB-1 should correspond to the earliest version of phonebook.

M EM SEG P HB-2 in Figure 10 has a new entry of "PHONE0002" appended to "PHONE0001." Thus, M EM SEG P HB-2 is the newer version of M EM SEG P HB-1. This line of reasoning can be used with the data in the five memory segments to reconstruct the time sequence of user activities.

Thus, historical versions of phonebook data and call entries are retained until they are overwritten. However, even when some data items in memory are overwritten, it may still be possible to use the duplicated copies of phonebook data and call entries to establish the time sequence of phone calls. Note that, because this feature is a direct result of the flash memory read/write mechanisms, the approach can also be used to establish the time sequence of other types of content such as normal data files.

Conclusions

The analysis of memory dumps from an MTK-based Shanzhai mobile phone reveals important details about how the system handles the addition and deletion of phonebook data and call entries. Although only the most recent phonebook items and call entries are obtained when querying the memory using the mobile phone operating system, valuable historical data pertaining to duplicated copies of phonebook data and call entries can be obtained from a memory dump as long as the associated memory locations have not been overwritten. This information can be used to establish the time sequence of phone calls as well as other content.

Our future research will focus on using the JTAG interface to obtain a complete image of internal memory, including the spare area. We will also attempt to apply reverse engineering techniques to obtain a detailed understanding of the allocation architecture for phone calls, phonebook entries, SMS messages and other related data. Finally, we will conduct research on Spreadtrum-based Shanzhai phones, another popular variety of Chinese-made pirated phones.

Figure 1 .

 1 Figure 1. Chinese Shanzhai phone (fake version of iPhone 4).

Figure 2 .Figure 3 .

 23 Figure 2. NOR flash memory architecture.

Figure 4 .

 4 Figure 4. Connecting a flasher tool to a Shanzhai phone.

Figure 5 .

 5 Figure 5. Directory of the user file area.

Figure 6 .

 6 Figure 6. Phonebook entry in the binary image.

Figure 7 .

 7 Figure 7. Call log entry (missed call).

Figure 8 .

 8 Figure 8. Call log entry (call duration of "00:00:40").

Figure 8

 8 Figure 8 shows another example. In this case, the call log entry is for a call with a duration of 40 seconds.The important observation is that data in the binary image matches the data obtained by manual acquisition via the user interface of the mobile phone. The mobile phone only records time information for the last call corresponding to a phone number. Time information for all calls cannot be retrieved via the user interface. However, this information can be located in the binary as long as the data is not yet overwritten.

Figure 9 .

 9 Figure 9. Memory segment of phonebook (1).

Figure 10 .

 10 Figure 10. Memory segment of phonebook (2).

Figure 11 .

 11 Figure 11. Memory segment of phonebook (3).

Figure 12 .

 12 Figure 12. Memory segment of phonebook (4).

Figure 13 .

 13 Figure 13. Memory segment of phonebook (5).

Table 1 .

 1 Comparison of internal memory acquisition techniques.

		Desoldering	JTAG	Flasher Tools
	Chip Damage Risk	High	Low	Low
	Data Modification Risk	Low	Low	Medium
	Complexity of Use	High	Medium	Low
	Electronic Soldering	High	Medium	-
	Data Completeness	High	Medium	Medium

Table 2 .

 2 Number of copies of various phonebook entries.

	Sequence Operation	Contact	Phone Number
	1	Add one entry	PHONE0001	135704****2
	2	Add one entry	PHONE0002	13800138000
	3	Add one entry	SZSMSC (in Chinese) 13800000755
	4	Add one entry	PHONE0044444	110101
	5	Delete one entry SZSMSC (in Chinese) 13800000755

Table 3 .

 3 Copies of various phonebook entries.

	Contact	Phone Number Copies
	PHONE0001	135704****2	5
	PHONE0002	13800138000	4
	SZSMSC (in Chinese) 13800000755	3
	PHONE44444	110101	2


Ricci Ieong

Kam-Pui Chow

Pierre Lai

VALIDATION OF RULES USED IN FOXY PEER-TO-PEER NETWORK INVESTIGATIONS

Keywords: Peer-to-peer networks, Foxy, first seeder, network simulation

Rules have been specified for identifying first seeders in the Foxy peerto-peer (P2P) network. However, these rules have not been validated due to difficulties in repeating download scenarios. This paper describes a rule validation scheme that uses a network simulation environment. The Type I and Type II error rates of Foxy network monitoring rules over 100 simulation experiments covering ten scenarios are measured and analyzed. The error rates reflect the limitations of the monitoring rules and demonstrate the importance of using network simulations for rule validation.

Introduction

The Foxy peer-to-peer (P2P) network [START_REF] Wikia | The Encyclopedia of Virtual Communities in Hong Kong on Foxy[END_REF], which uses the Gnutella 2 protocol, was one of the most popular Chinese file sharing applications. It was designed to share files with traditional Chinese character keywords or file names in a search-based network. In 2009, the Government of Taiwan took down the publisher of the Foxy client application [START_REF] Wikia | The Encyclopedia of Virtual Communities in Hong Kong on Foxy[END_REF]; however, the Foxy network is still used for P2P file sharing. In fact, with the aid of the Foxy-specific GWebCaches server (Gnutella 2 web cache server for Foxy), Foxy clients can still connect to the Foxy network. Some widely-publicized information leakage incidents led us to focus on the problem of identifying first uploaders (seeders) in the Foxy network [START_REF] Chow | BTM -An automated rule-based BT monitoring system for piracy detection[END_REF]. In general, there are two types of P2P networks for file sharing: link-based networks such as BitTorrent, and search-based networks such as eDonkey, Gnutella, Gnutella 2 and Foxy. As it turns out, the identification of first seeders in search-based P2P networks is more complicated.

In a link-based P2P protocol, the preparation and publication of links and source files are interrelated. Only after the resource links are published can the associated files be downloaded. An investigator can immediately start monitoring the files to be shared based on the links provided, and can detect the users who possess 100% of the files from among the swarms of downloaders. Since an uploader is unable to share a file before the publication of the resource link, monitoring the first appearance of the resource link is sufficient for the investigator to detect the first seeder [START_REF] Chow | BTM -An automated rule-based BT monitoring system for piracy detection[END_REF].

In 2007, we developed BTM, a tool for monitoring the BitTorrent protocol [START_REF] Chow | BTM -An automated rule-based BT monitoring system for piracy detection[END_REF]. BTM monitored public web forums visited by BitTorrent users to collect torrent files (seed files for download in BitTorrent). By mimicking a BitTorrent client, BTM collected communications information from trackers and peers. Based on the analysis of the collected data, including the percentage of file content possessed by peers, it was possible to identify the users who possessed 100% of the files -these users could be assumed to be the first seeders.

However, not all P2P protocols allow a file requestor to determine the percentage of a file possessed by a peer. For example, the BTM strategy cannot be applied to the Foxy file sharing network. This is because the Foxy network client uses Gnutella 2, a search-based P2P protocol, to locate files.

A search-based P2P protocol [START_REF] Ieong | Forensic investigation and analysis of peer-to-peer networks[END_REF] does not require a user to announce or perform any publishing prior to sharing a file. Also, it does not include a mechanism for a peer to determine the percentage of a file possessed by another peer. Indeed, a file can be published at any time, even before the keywords of the file are announced on the Internet. Because there is no direct link between publishing a file and announcing the keywords, a different strategy is required to identify first seeders in a search-based P2P network.

In 2009, we introduced heuristic rules for Foxy P2P network investigations [START_REF] Ieong | A model for Foxy peer-to-peer network investigations[END_REF]. One of the key rules is: Rule 1: If a seeding peer is found to be reachable and connectable during the slow-rising period, then the seeding peer is the first uploader.

To support this rule, we introduced two supplementary rules to determine the slow-rising period and two restriction rules to address failure situations [START_REF] Ieong | Identifying first seeders in Foxy peer-to-peer networks[END_REF]. These rules can be used to identify first seeders, but the accuracy of the rules was not validated.

The rules in question could not be validated because the platform for performing the validation was not defined. In a peer-to-peer file sharing environment, the first uploader would be unlikely to announce himself as the first seeder. Therefore, it would be difficult to confirm that the identified uploader is, indeed, the first uploader in the Foxy network, even if such an uploader has been identified.

In one experiment, we set up a controlled environment and published a seed file for download. However, we observed that unless the seed file was popular and attracted a swarm of downloaders, the file was not searched for, let alone downloaded.

Our download experiments performed on the actual Foxy network were well planned [START_REF] Ieong | Identifying first seeders in Foxy peer-to-peer networks[END_REF]. We designed the experiments by monitoring and selecting medium-to large-sized files of popular animation series videos. By selecting animation series with new episodes each week, we knew that the files for each episode would not be created or published before a particular time (i.e., screening time). Therefore, it was possible to reduce the waiting period for the uploaded file.

However, there was considerable uncertainty regarding the experimental results. First, we suspected that a single observable seeder should be the first seeder, but we could not confirm that the seeder was, in fact, the first seeder. Because it is not possible for any one entity to monitor the entire Foxy network using current technology, the single observed seeder may not be the first seeder. Second, we observed that some factors (e.g., level-off effects at a Foxy hub) could not be evaluated in the real Foxy environment. In the Foxy network, hubs and swarms are defined based on the situation and the program settings. Thus, increases and decreases in the number of hubs connected to the Foxy network could not easily be achieved. Third, without control factors for defining the experimental environment (e.g., arrival times of incoming downloaders and the file transfer ratio of the uploader and downloader), it was impossible to repeat any experiments. Thus, instead of using a real environment to validate the rules, we decided to use a simulator that would faithfully reflect the behavior of the Foxy network environment.

This paper presents revised versions of the previously-specified heuristic rules for monitoring the Foxy P2P network [START_REF] Ieong | Identifying first seeders in Foxy peer-to-peer networks[END_REF][START_REF] Ieong | Forensic investigation and analysis of peer-to-peer networks[END_REF][START_REF] Ieong | A model for Foxy peer-to-peer network investigations[END_REF]. A validation scheme is proposed for assessing the accuracy and error rates of the monitoring rules. The validation scheme is implemented using a Foxy P2P network simulator developed with the ns-3 network simulation environment.

Rule Validation

This section describes the new Foxy monitoring rules and the rule validation procedure.

Foxy Monitoring Rules

Before we proceed to specify the Foxy network monitoring rules, we list the notation used in this work: X: Number of seeders.

T i : Time when the i th seeder appears.

T 1 : Time when the first seeder (X = 1) appears. R j,i : Rate of change of the number of seeders (=

X j -X i T j -T i ) .
T e : Time when the slow-rising period ends.

T R : Upper bound of the time when the second seeder appears (derived in [START_REF] Lai | Profiling Internet Pirates[END_REF]).

The following heuristic rule was proposed in [START_REF] Ieong | A model for Foxy peer-to-peer network investigations[END_REF]:

Rule 1: If a seeding peer is found to be reachable and connectable during the slow-rising period, then the seeding peer is the first uploader.

Rule 1 is refined as the following Foxy monitoring rule: Rule R1: From T 1 to T s , the first observed seeder is the initial seeder.

To satisfy the requirement of Rule R1, we define the end time of the simulation T s based on two schemes, Scheme 1 and Scheme 2, where T s = min(T R , T e ): Scheme 1: We use a fixed time T . The upper bound of T R = T 1 + f ilesize datarate (from [START_REF] Lai | Profiling Internet Pirates[END_REF]).

Scheme 2:

We dynamically measure T e based on the change of the slope of the increment of seeders over time. As shown in Figure 1, if R e+4,e > R e,1 , then T e should be the end of the slow-rising period. Note that T e is the time when the curve enters the rapid rising period.

From the simulation results in Figure 1, T s = 110, 304 seconds and the number of seeders X = 1. According to Rule R1, the single observed seeder is the first seeder.

Experimental Set-Up

We developed FoxyNS3, a new Foxy simulator, to help validate the Foxy monitoring rules. Our previously-developed discrete event simulator SimFoxy was not used because it was unable to fully simulate and explain important aspects of network connectivity and congestion behavior that occur in real P2P networks.

Our SimFoxy simulator focused on discrete event simulation. All downloading events were simulated based on the estimated file packet transfer time. The transfer time was calculated based on the packet size and the bandwidths of the downloader and uploader. When additional downloaders appeared in the network, the available network bandwidth was assumed to be shared by the downloaders. However, in a real Foxy network, the bandwidth is not merely shared by the downloaders -traffic congestion in the network also affects the download time.

Another problem with SimFoxy was that the maximum number of network connections was not simulated. Thus, the effect on the download time induced by the limits imposed on uploader and downloader connections was not considered.

More importantly, SimFoxy was created to analyze only the file transfer protocol. The file searching mechanism and the Foxy network topology were neither considered nor simulated. However, because of the limits on the number of leaf nodes connected to a hub and the number of hubs connected to a leaf node, search query responses could not be fully recorded in any part of the real Foxy network. Clearly, this impacts the accuracy of the Foxy network simulation results.

Our new FoxyNS3 simulator was built using ns-3, a popular discreteevent network simulator. The ns-3 simulator, which is wrapped with Python, incorporates a C++ library that provides a set of network simulation models implemented as C++ objects. An important advantage is that ns-3 is able to simulate the Gnutella 2 protocol at the network level. In fact, network activities can be simulated in terms of file packet exchange.

FoxyNS3 was developed as a C++ program that interacts with the ns-3 simulation model library. The main simulation configurations, simulation network topology and network configuration parameters are defined in the file test-gnutella.cc, which controls the entire simulator.

We employed the CSMA network topology in our experiments. This topology has been used in network simulations of other P2P file sharing protocols. The FoxyNS3 configure.txt file defines all the node connection settings, including the connection set time, search time, node connection rate, network departure time and re-search time.

The FoxyNS3 simulator models a Foxy network using three key components: bootstrap server, hub node and leaf node models. The file bootstrap.cc defines the behavior of the GWebCache Server. The bootstrap program collects a list of available hub nodes and returns the list to a newly-connected leaf node. To reduce network connections and the memory used during a simulation, the bootstrap server disconnects from the leaf and hub nodes after connecting a leaf to a hub.

The hub node model (hub-node.cc) is used to simulate the behavior of hub nodes in a Foxy network. It has some features of a real Foxy hub node. In particular, it serves as a node that is connected to leaf nodes; however, the number of leaf nodes that can be connected to a particular hub node is limited. New leaf node connection requests are rejected after the maximum number of leaf nodes that can be connected to a hub node is reached. The available uploader lists are also maintained. When a connected leaf node or hub node submits a file request to a hub node, the node checks if the requested file is available at any of the nodes. Then, it relays and broadcasts a file request to its leaf nodes or hub nodes when the file request does not exceed the time-to-live limit.

In our simulation, we simplified hub searches by only returning the hubs that could be connected by leaf nodes instead of providing hubs that could not be accessed. In other words, a hub node cannot and will not participate in file downloading. This speeds up the initial setup of the network without affecting the topology.

The leaf node model (leaf-node.cc) is a simplification of a leaf node in the real Foxy network. A simplified version of the Gnutella 2 protocol was also implemented in the simulator. Although the ping/pong packets and other network communication packets were not coded as precisely as in the Gnutella 2 protocol, the behavior of the protocol was simulated adequately. All the search and download features are initiated from the leaf node model. After a leaf node obtains the hub list from the bootstrap server, it connects to three hubs. After the connection is established, the leaf node uses UDP packets as ping and pong to maintain connectivity. A leaf node assigned to participate in file sharing activities searches the connected leaf nodes. The file transfer feature was developed using a modified version of the HTTP Content-Range protocol; this simulates the download and upload behavior, albeit without certain download features.

Simulation Assumptions

As mentioned above, the FoxyNS3 simulation model implemented Foxy clients in the CSMA network topology. To reduce network congestion, an Internet stack was used and the backbone network in the simulation was set to 1 Gbps.

The leaf and hub nodes were disconnected from the bootstrap server after the server lists for establishing connectivity were collected. In the real Foxy network, the bootstrap server sends the hub list to a leaf node whenever the leaf node issues a request. However, this activity is not performed frequently. Therefore, our simulator limited the request to one time only, assuming that the leaf node would only collect this information once after the connection was established -this reduces network traffic between the bootstrap and leaf nodes. Moreover, to streamline the Foxy network simulation, all the leaf nodes were pre-set to connect to the hub within the first 100,000 seconds. All file search and download activities were configured to start after 100,000 seconds.

Based on settings established by experiments on the real Foxy network, each leaf node was permitted to access and connect to no more than three hub nodes. Also, each hub node was permitted to connect to a maximum of 200 leaf nodes and three neighboring hub nodes.

To focus the simulation on file sharing activities between the leaf nodes, leaf nodes were permitted to depart after completing their downloads, but hub nodes were forced to be connected to the network. Thus, the scenario of a hub leaving the Foxy network was not simulated.

The upload and download connectivity were pre-set in the FoxyNS3 simulator. As in the real Foxy network, all Foxy clients were configured to support a maximum of three downloads and three uploads.

The file fragment size used in the simulated Foxy network was the same as in the real network. The transferred file fragments were set at 512 KB per packet, the packet size in a download packet request query in the real Foxy network. Thus, in our experiments, around 26 512 KB packets are downloaded by the leaf node for a 13 MB sample file.

Simulation Experiments

More than 100 simulations were performed using FoxyNS3. 50 of the simulation experiments were used for rule validation. The experiments were performed by varying four parameters: T arr-s : Average inter-arrival time of search queries. Upload and download data transfer rates for all the peers. Certain parameters in FoxyNS3 were pre-set. The file size was fixed at 13 MB, the same size as in the experiment with the real Foxy network. The file packet size was set to 512 KB, the same size used in the Foxy network. The download slot limit in the uploader, which is the number of maximum downloading peers an uploader can handle simultaneously, was found to be and set to three. The number of simultaneous downloader connections to the uploader was also set to three.

The simulation experiments were divided into four sets:

Set 1: This set of simulations focused on the sequential search time. In Sets 1(a), 1(b) and 1(c), experiments were performed by varying the inter-arrival time of search queries (T arr-s ). In Set 1(d), 40 out of 100 downloaders were submitted to the Foxy network in sequential order, while 60 out of 100 downloaders were submitted randomly.

Set 2: This set of simulations focused on the random search time.

In Sets 2(a), 2(b) and 2(c), the search query time entries were pregenerated, kept in the configure.txt file and used as the query time in the experiments. In Set 2(d), the simulation was conducted with Poisson time set to 100,000 seconds.

Set 3: This set of simulations focused on the number of hubs present in the Foxy network. Sets 3(a) and 3(b) were performed using the same set of search query times as Sets 2(a) and 2(b), but were measured at the hub level instead of the overall view. In our simulation environment, leaf nodes were connected to hubs; also, according to the connectivity restriction, a leaf node can connect to no more than three hubs. Thus, the first seeder and other downloaders cannot connect to all ten hubs. The rule accuracy was evaluated by collecting the results from each hub during each simulation.

Set 4: This set of simulations focused on the random data transfer rate. In the other simulation sets, the data transfer rates were pre-set to fixed rates in order to minimize randomness in the simulations. However, in the real Foxy network, data rates are not fixed and variations in the data rates affect the overall download speed for the Foxy swarm. In Sets 4(a) and 4(b), experiments were performed with 500 nodes, 200 downloaders and a mean data rate of 100 Kbps.

Simulation Results

Simulations were performed on two Linux machines running the ns-3.11 version. In each simulation experiment, the following information was collected from each inspected node with the downloader and uploader participating in file sharing: IP addresses of the uploader and downloader nodes. The results were stored in a text file (csv format). The seeder curves, representing the number of uploaders observed in the Foxy network, were created by analyzing the downloader completion time and file download completion order. Although each set of simulation experiments was performed using the same values of node connection time and start search time, the network behavior and the selection criteria related to the order of the hubs varied randomly. Therefore, when congestion occurred in a simulation, a deviation from the expected mean was observed.

Figure 2 shows the mean and standard deviation values for typical seeder curves. Note that the graphs plot the seeder appearance time versus the number of seeders. The average within an experiment set is shown as a solid line while the deviations are shown as horizontal error bars. The results demonstrate that the deviations for Sets 2(a) and 2(b) are within a reasonable range. shows that the simulated seeder curve reflects much of the detail in the real seeder curve. This demonstrates that the simulation replicates the behavior in the real Foxy network.

Validation Results

After performing the simulations, we applied Rule R1 in an attempt to determine if the first seeder could be identified. The rule validation scheme involves three steps:

Step 1: If at time T s , a single seeder is observed and the seeder is the first seeder, then the finding is considered to be correct.

Step 2: If at time T s , more than one seeder is observed, then the finding is classified as a Type I error.

Step 3: If at time T s , the seeder is rejected, then the finding is classified as a Type II error.

Rule R1 Results

Table 1 presents the rule validation results. Several observations can be made based on these results.

Effect of T arr-s : In Sets 1(a) through 1(d), when the inter-arrival search times (T arr-s ) were shorter than the download time for a single file, Rule R1 could identify the first seeder. When the T arr-s times were much longer, Rule R1 failed to identify the first seeder. The rule also incorrectly classified 20% of downloaders as the first seeder. Thus, when the time T arr-s is shorter, there is a higher likelihood of identifying the first seeder in the swarm.

Effect of Random T arr-s : In Sets 2(a) through 2(d), the interarrival search times were changed from a fixed search schedule to random search times across the 100 downloaders. In all cases, it was possible to successfully identify the first seeder using the monitoring rule. However, the higher Type I errors are observed compared with Sets 1(a) through 1(d). With the change in search start time, the download completion time affected each downloader and, thus, more downloaders were incorrectly classified as first seeders.

Observations of Hub Effect: In the case of Sets 3(a) and 3(b), we observed that the seeder curve at each hub node shown in Figure 3 (corresponding to Set 3(b)) differed from the overall seeder curve in Figure 2(b). When more hubs were involved, the shape of the seeder curve deviated more from the single hub seeder curve. This caused difficulties when using Rule R1 to identify the first seeder. Without the overall view of the download, it was possible to simply rely on Rule R1 and its supplementary rules to determine the first seeder. In the Set 3 simulations, because seven out of ten hubs did not connect to the first seeder, simply relying on Rule R1 could incorrectly identify a normal downloader as the first seeder. Although the Type I errors shown in the validation results are just over 50%, when more hubs were involved in a download, the likelihood of incorrectly identifying a downloader as the first seeder increases. variation in the data transfer rate adds more stepwise details to the seeder curve. The validation results indicate that the error rates are not affected by a data transfer rate variation.

Observations of Transfer Rate:

Observations

Several observations can be made based on the simulation results.

When no nodes are permitted to leave the network, Rule R1 can identify the first seeder when the download time of a file is longer than the inter-arrival time of search queries. In other words, if the swarm of downloaders is interested in a file and the file size is sufficiently large, then there is a higher likelihood of identifying the first seeder.

If the inter-arrival time of search queries is shortened, then the Type I error increases. That is, more downloaders are incorrectly identified as the first seeder.

In contrast, if the inter-arrival time of search queries is lengthened, then the Type II error increases and the first seeder is likely to be rejected. This is because no slow-rising period is observed in the seeder curve. Thus, the seeder curve cannot be used to determine if the single uploader observed is the first seeder or just a downloader who has remained in the network.

Most search-based P2P networks such as Gnutella 2 and Foxy P2P client rely on hub nodes to separate a swarm into islands. With these hubs, monitoring the first seeder based on the number of seeders leads to high Type I errors. For example, the results of the simulations involving ten hubs demonstrate that more than 50% of the first seeders were incorrectly identified.

Conclusions

Identifying first seeders is critical in P2P network investigations of illegal file sharing. Monitoring rules can help identify first seeders. However, the rules must be validated in order to estimate the likelihood that an identified first seeder is, in fact, the first seeder.

It is well known that the error rates of P2P monitoring rules are typically high and that the error rates are even higher when data is collected from a fragment of the entire network. Since it is not possible to collect all the data from a real P2P network, rule validation based on data collected from an extensive network simulation using a simulator such as FoxyNS3 is a promising approach.

Our future research will focus on identifying new attributes to enhance the P2P monitoring rules. We will also extend our experiments to incorporate more hubs and permit uploaders to leave the network during the slow-rising period. These extensions will help refine the monitoring rules to better accommodate real-world P2P network scenarios.

Figure 1 .

 1 Figure 1. First 30 downloaders in the seeder curve.

N

  p : Number of downloaders interested in a target file during the simulation period. N h : Number of hub nodes in a Foxy network swarm.

  Start connection time, start search time, first packet received time, download completion time, download completion duration time, leave time, reconnection time and search time for each node. File download completion order. Number of successful and failed download requests (generated from an inspected node). Hub(s) to which each leaf node was connected. Number of file packets and data volume shared or uploaded by each node.

Figure 2 .

 2 Figure 2. Mean and standard deviation values for Sets 2(a) and 2(b).

Figure 3 .

 3 Figure 3. Seeder curves for the real and simulated Foxy networks.

Figure 3

 3 Figure 3 shows the real and simulated seeder curves. In Figure 3(a), details of the first twenty incoming seeders in a slow incoming download scenario of a 100 MB file are recorded in the seeder curve.Figure 3(b)

  Figure 3 shows the real and simulated seeder curves. In Figure 3(a), details of the first twenty incoming seeders in a slow incoming download scenario of a 100 MB file are recorded in the seeder curve.Figure 3(b)

Figure 4 .

 4 Figure 4. Seeder curves collected at ten hubs in Set 3(b).

Figure 4

 4 shows the overall and zoomed-in portions of the seeder curve corresponding to Set 4(b). The

Figure 5 .

 5 Figure 5. Overall and zoomed-in portions of the seeder curve in Set 4(b).

Table 1 .

 1 Validation results.

	Experiment Correct Type I Type II
		Seeder	Error	Error
	Set 1(a)	0%	0%	0%
	Set 1(b)	100%	20%	0%
	Set 1(c)	100%	0%	0%
	Set 1(d)	100%	20%	0%
	Set 2(a)	100%	100%	0%
	Set 2(b)	100%	100%	0%
	Set 2(c)	100%	100%	0%
	Set 2(d)	100%	0%	0%
	Set 3(a)	30%	60%	0%
	Set 3(b)	30%	50%	0%
	Set 4(a)	100%	100%	0%
	Set 4(b)	100%	0%	0%