M OBILE P HONE F ORENSICS Diploma Thesis

submitted in: by: First Examiner: Second Examiner: Advisor:

October 2009 Michael Spreitzenbarth Prof. Dr. Ing. Felix C. Freiling Prof. Dr. Ing. Wolfgang Effelsberg Dr. Thorsten Holz

University of Mannheim Laboratory of Dependable Distributed Systems D – 68131 Mannheim http://pi1.informatik.uni-mannheim.de/

2

Eidesstattliche Erkl¨ arung Ich versichere, dass ich die beiliegende Diplomarbeit ohne Hilfe Dritter und ohne Benutzung anderer als der angegebenen Quellen und Hilfsmittel angefertigt und die den benutzten Quellen woertlich oder inhaltlich entnommenen Stellen als solche kenntlich gemacht habe.

Mannheim, den 30.09.2009

Michael Spreitzenbarth

4

Abstract Nowadays, there is a huge need for forensic investigatiors to understand which evidence can be obtained from a mobile phone. Call logs, SMS messages, calendar entries, and images can be stored on modern mobile phones as well as audio and video recordings. All those mentioned evidence items can be obtained from the flash memory, obstructed in the phone. The major focus within this diploma thesis is to develop more sound forensic procedures and tools which should enable the process of loading a memory image which was previously created, with the help of Twister Box. This retrieved data is then subsequently converted into plain text to finally draw conclusions about the relevance of the content in the context of forensic analysis. This procedures and tools are then used for analyzing some mobile phones. This diploma thesis also includes a chapter discussing the possibilities of securely deleting stored data directly from the mobile phone.

Zusammenfassung Heutzutage ist es f¨ ur Ermittler von enormer Bedeutung welche Daten sich auf dem Flash-Speicher eines Mobiltelefons befinden. Darunter sind zum Beispiel SMS-Nachrichten, Kalendereintr¨ age, das Adressbuch und Anruflisten. Das Hauptaugenmerk der Diplomarbeit liegt in der Entwicklung eines forensischen Programms, welches die Analyse eines zuvor mit Hilfe der Twister-Box erstellten Speicherabbildes eines Mobiltelefons durchf¨ uhrt. Dieses Programm wird im weiteren Verlauf verifiziert indem einige Mobiltelefone damit analysiert werden. Als weiteren Teil der Diplomarbeit wird das sichere L¨ oschen von Daten auf dem Mobiltelefon diskutiert.

0 Contents

Listings

iii

List of Figures

v

List of Tables

vii

1. Introduction 1.1. Motivation . . . . . . 1.2. Tasks . . . . . . . . . 1.3. Results of the Thesis 1.4. Outline . . . . . . . 1.5. Acknowledgements .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

1 1 3 3 4 5

2. Background on Mobile Phone Forensics 2.1. Dumping the Memory . . . . . . . . . . . . . . . . . . 2.1.1. Twister Box . . . . . . . . . . . . . . . . . . . . 2.1.2. Symbian Software Agent . . . . . . . . . . . . . 2.1.3. Windows CE . . . . . . . . . . . . . . . . . . . 2.1.4. OS X iPhone . . . . . . . . . . . . . . . . . . . . 2.2. Selection of Existing Tools . . . . . . . . . . . . . . . . 2.2.1. Gammu . . . . . . . . . . . . . . . . . . . . . . 2.2.2. Oxygen Forensic Suite . . . . . . . . . . . . . . 2.2.3. Cell Phone Analyzer . . . . . . . . . . . . . . . 2.3. Differences in the Operation Systems of Mobile Phones 2.3.1. Nokia Series40 . . . . . . . . . . . . . . . . . . 2.3.2. Symbian OS . . . . . . . . . . . . . . . . . . . . 2.3.3. Windows CE . . . . . . . . . . . . . . . . . . . 2.3.4. OS X iPhone . . . . . . . . . . . . . . . . . . . . 2.4. Summary . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

7 8 8 9 11 12 13 13 15 18 19 20 21 24 26 26

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

i

Contents 3. Mobile Phone Forensic Toolkit 3.1. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2. System Overview . . . . . . . . . . . . . . . . . . . . . . . . 3.3. Implementation of the Wrapper Class . . . . . . . . . . . . . 3.3.1. Gathering Information about the Handheld . . . . . 3.3.2. Gathering Information about the Lastly Inserted SIM 3.3.3. Decoding Call History . . . . . . . . . . . . . . . . . 3.3.4. Decoding SMS . . . . . . . . . . . . . . . . . . . . . 3.3.5. Decoding Address Book . . . . . . . . . . . . . . . . 3.3.6. Decoding Calendar . . . . . . . . . . . . . . . . . . . 3.3.7. Decoding Stored Files . . . . . . . . . . . . . . . . . 3.3.8. Report Function . . . . . . . . . . . . . . . . . . . . 3.4. Implementation of the Symbian Software Agent . . . . . . . 3.5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

29 29 30 31 33 33 34 34 36 38 38 39 40 43

4. Analyzing Mobile Phones 45 4.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 5. Secure Deletion 5.1. Wear Levelling . . . . . . . . . . . . 5.2. Secure Deletion on Symbian Phones 5.3. Verification . . . . . . . . . . . . . . 5.4. Summary . . . . . . . . . . . . . . .

. . . .

85 85 88 92 93

6. Analyzing the SIM 6.1. GSM and the SIM . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2. Data Acquisition . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

95 95 97 103

7. Conclusion and Future Work 7.1. Summary . . . . . . . 7.2. Limitations . . . . . . 7.3. Future Work . . . . . . 7.4. Conclusion . . . . . .

105 105 106 106 107

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

A. Appendix

109

B. Source Code

121

Bibliography

123

ii

0 Listings

2.1. Command for dumping the iPhone memory . . . . . . . . . . . . 13 2.2. Device nodes for iPhone disks . . . . . . . . . . . . . . . . . . . . 26 3.1. Arguments and cue of the decoding tool . . . . . 3.2. Cutting the original memory dump file . . . . . . 3.3. Block 35 of the dump file . . . . . . . . . . . . . 3.4. Convert date from GSM to DEC . . . . . . . . . . 3.5. Decoding PDU encoded SMS . . . . . . . . . . . . 3.6. Memory excerpt of a saved SMS Message . . . . . 3.7. Decoding stored files based on their file headers . 3.8. Script for opening the report in favourite browser 3.9. XML-file of a saved SMS after decoding . . . . . . 3.10.XML-schema for a saved SMS . . . . . . . . . . . 3.11.Creating a Panoptes SIS-file . . . . . . . . . . . . 3.12.Backup function of Panoptes . . . . . . . . . . . . 3.13.Creation of the Panoptes log file . . . . . . . . . . 5.1. 5.2. 5.3. 5.4.

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

31 32 33 34 35 36 38 39 40 40 41 41 42

Secure deletion of contacts used in SecDel . . . . . . . . . . . . Code excerpt of SecDel which changes the date and time values Build-in update functionality of SecDel . . . . . . . . . . . . . . Excerpt of build-in remote deletion functionality . . . . . . . . .

. . . .

89 91 91 92

6.1. Logging function of SIMspy . . . . . . . . . . . . . . . . . . . . . 98 6.2. Excerpt of the generated XML file . . . . . . . . . . . . . . . . . . 102 6.3. Excerpt of the file allocation table . . . . . . . . . . . . . . . . . . 102 A.1. A.2. A.3. A.4.

PERL script to convert Gauss-Krueger coordinates [1] XML-schemata for cached SMS messages . . . . . . . XML-schemata for calendar entries . . . . . . . . . . XML-schemata for call logs . . . . . . . . . . . . . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

111 117 117 117

iii

Listings A.5. A.6. A.7. A.8.

iv

XML-schemata for saved contacts . . . . . . . . XML-schemata for handheld and SIM card infos XML-schemata for saved SMS messages . . . . XML-schemata for URL entries . . . . . . . . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

118 118 119 119

0 List of Figures

1.1. Statistical data of telephone surveillanc by means of criminal proceedings within the years 1998 to 2007 [2] . . . . . . . . . .

2

2.1. Faraday Shield made by Paraben Forensics . . . . . . . . . . . . 2.2. Twister Box with attached Nokia 3510i . . . . . . . . . . . . . . 2.3. Exemplary part of a PM file . . . . . . . . . . . . . . . . . . . . 2.4. The classic client-server workflow [3] . . . . . . . . . . . . . . . 2.5. The MIAT workflow [3] . . . . . . . . . . . . . . . . . . . . . . 2.6. Wammu phone configuration wizard . . . . . . . . . . . . . . . 2.7. Wammu missing configuration at first start . . . . . . . . . . . . 2.8. Oxygen Forensic Suite Assistant for analysis selection . . . . . 2.9. Oxygen Forensic Suite overview on found address book entries 2.10.Oxygen Forensic Suite overview on found calendar entries . . . 2.11.CPA [4] select phone and file typ for analysis . . . . . . . . . . 2.12.Excerpt of the CPA [4] report for SMS . . . . . . . . . . . . . . 2.13.Excerpt of the CPA [4] report for mobile phone information . . 2.14.Summary of the Java technology supported by the Series40 platform [5] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.15.Comparison of the different platforms [5] . . . . . . . . . . . . 2.16.The capabilities available in each trust tier [6] . . . . . . . . . 2.17.Virtual address space managed by Windows CE [7] . . . . . . .

. . . . . . . . . . . . .

7 8 9 10 10 14 15 16 16 17 18 19 19

. . . .

21 22 24 25

3.1. 3.2. 3.3. 3.4. 3.5. 3.6.

. . . . . .

30 32 34 35 36 38

Schematic system overview . . . . . . . . . . . . Terminal view while script runs the decoding . . Callhistory in a Series40 memory dump . . . . . SMS message in a Series40 memory dump . . . . Address Book Entries in a Series40 memory dump Callendar Entries in a Series40 memory dump . .

. . . .

. . . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

v

List of Figures 5.1. Schematical illustration of ways in which the solid state memory may be operated [8] . . . . . . . . . . . . . . . . . . . . . . . . 5.2. Flow diagram showing a preferred operation of the memory system [8] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3. SecDel overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5.4. SecDel select contacts which should be deleted . . . . . . . . . 5.5. SecDel contact entry after renaming it . . . . . . . . . . . . . . 5.6. Nokia E90 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . .

87 89 90 91 93

6.1. 6.2. 6.3. 6.4. 6.5. 6.6. 6.7.

. . . . . . .

98 99 99 100 101 101 101

ASEDrive IIIe USB V2 Smartcard reader [9] . . . . . . . . Extract from the SIM data with the help of SIMspy [1] . . Extract from the SIM register with the help of SIMspy [1] SIM card status and ATR . . . . . . . . . . . . . . . . . . Authentication status of the SIM card . . . . . . . . . . . Possible acquisition modes for SIMbrush . . . . . . . . . . Summary of the acquisition . . . . . . . . . . . . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. 86

A.1. TwisterBox DCT4 flash window . . . . . . . . . . . . . . . . . . . 110

vi

0 List of Tables

1.1. Statistical data of telephone and SIM card analysis conducted by the German BKA [10] . . . . . . . . . . . . . . . . . . . . . . . .

2

3.1. Coding 7-bit data into octets . . . . . . . . . . . . . . . . . . . . . 37 4.1. Summary of the analysis of the mobile phones of Chapter 4 . . . 83 6.1. Content of the SIM [11] . . . . . . . . . . . . . . . . . . . . . . . 96 A.1. SIMbrush generated file allocation table of analyzed SIM card . . 116

vii

1 Introduction

1.1. Motivation These days mobile phones constitute one of the most commonly used electronic devices. In this context, one should also mention that the mobile communications market is one of the largest growing markets worldwide [12]. Amongst all available mobile communication technologies, it is the GSM standard which dominates with a share of 75% of all mobile phones. Global system for mobile communications (GSM) is used in 200 countries and holds 1.2 billion subscribers in more than 630 networks [13]. Today’s mobile phones combine a variety of different technologies. That is why they offer in addition to excellent mobile availability and connectivity also highspeed data transfer via universal mobile telecommunications system (UMTS) and wireless local area network (WLAN) for the user. Moreover, they are multimedia capable due to their integrated digital camera or music player, and not to forget, they serve the function of text-based communication via email, multimedia messaging service (MMS), and short message service (SMS). Consequently, they are used increasingly as a ‘mobile office’, thanks to the various office applications available for mobile phones. Another aspect which should not be neglected is the fact that current mobile phones are more frequently equipped with GPS-Modules which enable the user to make use of the mobile phone for navigation purposes. By means of the above stated quantity of data and the continuously increasing number of criminal actions in which mobile phones play an essential role, not only for the criminal action itself but also within the investigation of those, it becomes evident how important the classification, the backup, as well as the recovery of a mobile phone’s contents are. In order to emphasize this aspect, the development of telephone surveillance within the Federal Republic of Germany (BRD) from 1999 to 2007 is depicted in Figure 1.1. Similarly, those circumstances become apparent if we look at Table 1.1. This table shows the numbers

1

1. Introduction of analyzed mobile phones and SIM-Cards within investigations conducted by the German Federal Criminal Police Office (BKA) from 2003 to 2008. According to Palmer [14], such a digital investigation is the use of scientifically derived and proven methods toward the preservation, collection, validation, identification, analysis, interpretation, documentation, and presentation of digital evidence derived from digital sources for the purpose of facilitation or furthering the reconstruction of events found to be criminal, or helping to anticipate unauthorized actions shown to be disruptive to planned operations. year 2003 2004 2005 2006 2007 2008

total number 346 430 638 721 1108 1324

percentage change +0 + 24,3 + 48,4 + 13,0 + 53,7 + 19,5

Table 1.1.: Statistical data of telephone and SIM card analysis conducted by the German BKA [10]

Figure 1.1.: Statistical data of telephone surveillanc by means of criminal proceedings within the years 1998 to 2007 [2]

2

1.2. Tasks

1.2. Tasks Although there are already tools existent which are able to extract evidence, it cannot be denied that there is a huge demand to develop more sound forensic procedures and tools in order to analyze data from a previously created dump, as well as from the mobile phone itself. This aspect will be a major focus within this diploma thesis. The developed tool should enable the process of loading a memory dump which was previously created, with the help of Twister Box or an software agent running under Symbian OS on the phone. The data retrieved this way, which are dependent on the producer and are available in coded form, will be subsequently converted into plain text to finally draw conclusions about the relevance of the content in the context of forensic analysis. Within all those operations a set of principles [15] guiding the process were suggested and are quoted below. • No actions performed by investigators should change data contained on digital devices or storage media. • Individuals accessing original data must be competent to do so and have the ability to explain their actions. • An audit trail or other record of applied processes, suitable for independent third-party review, must be created and preserved, accurately documenting each investigative step. • The person in charge of the investigation has overall responsibility for ensuring the above-mentioned procedures are followed and in compliance with governing laws. This diploma thesis also includes a chapter discussing the possibilities of securely deleting stored data, directly from the mobile phone. Additionally, in the second part of this diploma thesis, we test the functionality as well as the applicability of the developed tool on several mobile phones by analyzing extracted data in a forensic way. The last part of this thesis constitutes the forensic analysis of the subscriber identity module (SIM) card. We consider this important since important data (e.g. location information, which can play a vital role in resolving a crime) are stored on the SIM card. In order to successfully conduct such an analysis, the personal identification number (PIN) is needed, implying an active commitment of the suspected person.

1.3. Results of the Thesis Within this diploma thesis we have, amongst others, developed a wrapper-class which automatically analyzes memory dumps of Series40 phones. Those have

3

1. Introduction been created with the help of Twister Box beforehand. The results are presented in reports, either in HTML- or XML-format. In addition, we developed a software agent. When we use this agent it is possible to dump secured data from a Symbian smartphone and analyze them subsequently. This step has become necessary due to the fact that the Twister Box is not able to create complete memory dumps when dealing with Symbian OS mobile phones. We have to install the software agent on the smartphone. However, this step is forensically questionable as data stored on the device become altered. From a current technological perspective, no other option exists to get to the relevant data. Moreover, we developed another tool called SecDel, a Python script solution, which is intended to securely delete data on Symbian phones. First of all, this approach overwrites existent data with many ‘X’ ; afterwards those entries are deleted again. In addition, an option to start this tool remotely is included, which allows to delete private or business data on a phone even if it has been lost. Within subsequent chapters we tested software solutions being currently available on the market, with respect to their strengths and weaknesses. Those tools are intended for both, the analysis of SIM cards, as well as the analysis of mobile phones. In this context we recognized that many of those tools are not intended for a forensic purpose.

1.4. Outline This thesis is outlined as followed: Chapter 2 gives a background on mobile phone forensics, the different operating systems and discusses the existing approaches of some related work. Chapter 3 provides detailed insight into the implementation of the developed tool. After determining design goals and providing an overview of the system layout as well as the control flow, the individual components of the system are described in detail. After this, both the outcome of the implementation, and effectiveness tests based on analyses of different mobile phones are presented in Chapter 4. Afterwards, the Symbian OS and the possibilities of secure deletion are discussed. Chapter 5 provides some information about the SIM. Finally, Chapter 6 concludes this thesis with a short summary, discussing the limitations of the system and in this context figures out the remaining work on this project that could possibly be done in the future.

4

1.5. Acknowledgements

1.5. Acknowledgements First of all, I want to express my deepest gratitude to Prof. Dr. Felix C. Freiling for giving me the opportunity to work on such an interesting project for my diploma thesis. It was especially very exciting to work on the cutting edge of mobile phone forensics. Furthermore, I would like to thank Prof. Dr. Wolfgang Effelsberg for being my second examiner. I also want to thank Dr. Thorsten Holz, who was my advisor, for his incessant support and very valuable feedback. Another important concern to me is to thank him and Michael Becher for supplying me with mobile phones and the necessary hardware which enriched my evaluation a lot. I want to thank the phone-forensics community [16] as well, which has given great support to me in the field of specific mobile phone problems. Last but not least, I want to thank my girlfriend for proof reading my thesis and for her valuable suggestions and my family for every time giving me backup and support throughout my thesis.

5

1. Introduction

6

2 Background on Mobile Phone Forensics

The factors we have depicted in Section 1.1 necessitate further investigation and research within the field of mobile phone forensics. Before addressing the tool which we have developed within this diploma thesis and the corresponding analyses, we will explain the underlying backgrounds on mobile phone forensics within this chapter.

Figure 2.1.: Faraday Shield made by Paraben Forensics First of all, we must pay attention that the mobile phone is prevented from establishing a connection neither to its provider nor to another than the chosen computer as not to change any data during analysis. This can be done best with the help of a Faraday shield as shown in Figure 2.1. In Section 2.1 we describe the different ways of creating a memory dump of a mobile phone. The following paragraph exemplarily outlines some of the currently existing software solutions and contrasts its strengths and weaknesses

7

2. Background on Mobile Phone Forensics with respect to forensic aspects. In the last section of this chapter we illustrate the most important differences of the various operating systems of today’s mobile phones.

2.1. Dumping the Memory After preventing the mobile phone from establishing a connection to the network, we can start with the analysis of the smartphone. The first step is to create a dump of the mobile phone’s memory. The existence of different operating systems necessitates varying procedures in order to create a memory dump. In the following sections we present the different procedures for both, older Nokia mobile phones (see Section 2.1.1 for details) and Symbian devices (described in Section 2.1.2). In Section 2.1.3 we describe the possibility of creating a memory dump from a Windows Mobile device; however, we will not discuss this any further within this diploma thesis.

2.1.1. Twister Box

Figure 2.2.: Twister Box with attached Nokia 3510i Twister Box by SarasSoft [17] is a complete kit for removing simlock and servicing such phone series such as Nokia DCT3, Nokia DCT4, WDT2/EPOC, TIKU BT2, DCT-L, Samsung, Sony Ericsson or Motorola and Acer. It allows us to repair all bugs within the software such as bluetooth error, no service, contact provider or illegal software loaded. Of course, it can also be used for removing security code, phone code, change software or language, or upload Java applications. The Box contains an atmega8 chip1 with the system files and a ftdi-232bm2 chip for communication purpose between the mobile phone and the investigator’s computer. The box supports two communication modes, the 1

A 8-bit AVR micro-controller with 8K bytes in-system programmable flash build by ATMEL Corporation. 2 The FTDI 232BM USB to Serial UART interface chip converts USB to serial data (I/O’s at TTL levels). All USB protocols are handled in the chip, so no knowledge of USB is required. The

8

2.1. Dumping the Memory ‘FBUS mode’ for gathering phone information and the ‘flash mode’ for direct communication with the mobile phone flash chips. However, in case of this diploma thesis we use the working technique of the Twister Box to create memory dumps with the help of the flash mode of the attached mobile phones (see Figure 2.2). A memory dump created with this technique is available in PM format. In this case, data are pre-formatted and their hexadecimal representation is saved block by block as a PM file. At the beginning of each block an unambiguous number, framed in square brackets, can be found. Based on this number we are able to draw conclusions about the content of this block. Such a block can incorporate several indexed entries which in each case occupy one line of the file. The ‘real’ entry is separated by ‘=’ from its index and arranged byte-bybyte. We have shown this exemplarily in Figure 2.3. Here a differentiation between the illustration in the device and in the PM file has to be made. Within the device the HEX-Value 0x02 takes exactly one byte whereas the value within the PM file consists of the signs 0 and 2 which count for more than one byte.

Figure 2.3.: Exemplary part of a PM file The entries occur repeatedly and can incorporate a constant structure. The indices shown in this figure originate from one of the test devices which we analyze in Section 4.1. Both, the block number, as well as the indices of each entry constitute additional formatting of the PM format. We explain the exact meaning of the single blocks and the decoding of the contained data more precisely in Section 3.3.

2.1.2. Symbian Software Agent In order to analyze data of a Symbian phone various approaches exist. The most common approach includes the use of command-respond protocols like the AT Command Set [19], OBEX [20] or the FBUS owned by Nokia [21]. Those protocols are already implemented on the Smartphone and allow the investigator an easy use as they are contained in many SDKs and thus are well documented in most cases. Disadvantages of those protocols lie in the fact that on the one hand we have to trust the correct implementation on pages of the Smartphone. Therefore we cannot assure that the ‘answers’ which are sent by the telephone after a request of the investigator are consistent with the contents of the desired storage space. 232BM is entirely state machine based and no firmware is required. Supports baud rates of up to 3 MBit / second [18].

9

2. Background on Mobile Phone Forensics On the other hand, those protocols change data on the phone. Does the investigator, for example, wish to receive the SMS messages from the incoming box of the smartphone, then unread message are sent to the PC of the investigator, but they are afterwards marked as ‘read’ in the incoming box of the smartphone. This procedure is not acceptable according to forensic principles.

Figure 2.4.: The classic client-server workflow [3] A direct improvement of this procedure offers an On-Phone forensic tool [22], also known as Symbian Software Agent. This agent is a small program which has to be installed on the smartphone to be examined. This tool allows data exchange and connection establishment between PC and smartphone with own protocols. This approach uses a client-server architecture, by which the smartphone operates as a server. Here we need not trust the connectivity services which are provided by the manufacturer. A disadvantages of this procedure is that the tool has to be installed on the device, here data become changed. Those data changes can be narrowed down when using modern agents. Then, the tool is installed on a memory card instead on the internal storage of the device. However, with this approach it is also worked directly on the phone within the whole analysis (see Figure 2.4) and there is no possibility of creating a memory dump.

Figure 2.5.: The MIAT workflow [3] The second approach of a software agent which is currently available is shown in Figure 2.5. Here, the agent functions as a tool for creating a memory dump of specific, for the analysis important, files of the internal storage of a smartphone. This approach has been implemented in the tool MIAT of the University of Rome [22; 3]. For this purpose we copied MIAT to a memory card which we afterwards inserted into the phone. After the installation of the agent we can now create an exact dump of private data on the phone. Within this process the security

10

2.1. Dumping the Memory restrictions are circumvented as far as possible3 in order to gain private data. The backup we created in this way is stored on the memory card in order to guarantee that no other data have been overwritten on the phone. After a successful completion of the backup process we can remove the memory card and we can conduct the complete analysis on the memory dump. In order to prove the integrity of saved data afterwards, we formed hash-sums from the single files. Those are stored in a log file then. Again, we have to mention the disadvantage that changes are done to certain parts of the phone due to the installation of MIAT. Moreover, the analysis as well as the processing of data and data formats are completely put into the responsibility of the investigator which implies the need for a certain level of knowledge of the latter.

2.1.3. Windows CE The two main classes of data extraction techniques on Windows CE running devices4 are either logical extraction, or physical extraction. A logical extraction technique focuses on the visible content at the file system level only, i.e., data pertaining to files, databases and registry along with other file system data. MIAT-WM5 [23] is a promising logical data extraction tool for WinCE running on PDAs and smart phones. A physical extraction technique, on the other hand, is attractive because it can recover all data stored on an electronic device. In most cases, however, only the flash ROM and the RAM content are recovered by using a special operating mode of the device, or by communicating with the operating system. According to Breeuwsma et al. [24], three techniques may be used to obtain a complete copy of flash memory: (i) using flasher tools, (ii) using JTAG test access ports, and (iii) using forensic de-soldering. Flasher tools are designed to copy the memory of certain families of electronic devices. They employ APIs that interact with the addressable memory. Generally, these tools originate from manufacturers, who use them for debugging purposes, or they come from the hacker community, which creates the tools to modify the functionality of handheld devices. An important advantage of this technique is that flash memory can be imaged without de-soldering the chip. However, many flasher tools do not make complete forensic copies of flash memory, mostly because of the limited functionality of the API provided by the embedded device. To state an example of flasher tools we point out to the Twister Box. The second physical extraction method involves the use of JTAG test access ports of embedded devices. JTAG ports in most devices are designed for debugging purposes, but they can also be used to access the flash memory [25]. The 3

Unfortunately, this circumvention of security restrictions does only work with older software versions of Symbian. Currently MIAT exists only for Symbian 2nd edition smartphones. 4 These devices include, amongst others, smartphones such as the phones of the O2 XDA series, T-mobile MDA series or HTC.

11

2. Background on Mobile Phone Forensics JTAG extraction technique is complex and time consuming; however, it is possible to guarantee that no data are written to memory during the data recovery phase. The third physical extraction technique is to de-solder the memory chip and use a chip programmer or reader to extract the data. This method is expensive, time consuming and the most invasive but it can be used to recover data from damaged devices, too.

2.1.4. OS X iPhone An Apple Support knowledge base document [26] describes the various procedures and limitations of a backup of data on an iPhone. Due to the OS based implementation of Digital Rights Management (DRM), we can only save certain data in the way it has been described by Apple. While limited portions of personal data can be viewed and saved this way, more hidden and ostensibly deleted data are available by examining the raw disk dump. Those information stored by the iPhone includes, according to Zdziarski [27]: • Keyboard caches containing usernames, passwords, search terms - nearly everything typed into the iPhone’s keyboard is stored in this cache. • Screenshots are preserved of the last state of an application, taken whenever the home button is pressed or an application is exited. • Deleted data like voicemail recordings, address book entries or images taken by the camera or even out of the browsing cache. • Call history with about 100 entries can be restored through the call database including deleted calls. • Google Maps searches and images including GPS coordinates can be recovered also. • Browser cache and deleted browser objects. • Messages like email, SMS and other communication can be recovered including timestamps and flags. • Pairing records establishing trusted relationships between the iPhone and one or more desktop computers or other handhelds can be recovered. According to Varsalone [28], three possibilities to create a memory dump of an iPhone exist. We explain these in the following: • Viewing the iTunes Sync on a host computer: it is possible to obtain a logical copy of iPhone data with the help of an iTunes Sync Tool. However, within this memory dump are only non-DRM-protected data contained, as long as the Sync is not conducted with the host computer of the suspected. Admitttedly, even then it is not possible to dump deleted or hidden data.

12

2.2. Selection of Existing Tools • Hacking into the iPhone: it is possible to hack the iPhone with the help of jailbreaking5 in order to use UNIX tools like dd and ssh afterwards as to conduct a complete bit-by-bit-copy via the WiFi-connection. A disadvantage of this technique is constituted by the fact that when dealing with iPhones in many cases6 the firmware has to be changed in order to install the jailbreak software (e.g. Pwnage) which in effect leads to changed data on the phone. After we have successfully installed Cydia, a UNIX toolkit for the Apple iPhone, we are able to dump the complete user data partition byte-by-byte on a host computer with the command shown in Listing 2.1 1

dd i f =/dev / d i s k 0 s 2 conv=sync , n o e r r o r bs=4k | nc−w1 26000

Listing 2.1: Command for dumping the iPhone memory The dd-file we created this way can be altered to a dmg-file on a Mac OS X computer and simultaneously mounted to a read-only file. Afterwards it can be worked on it in the same way as on a hard disk. With the help of tools like X-Ways [29] or BlackBag [30] we can conduct a data analysis in a forensic sense. • Disassembling the iPhone: this procedure is very similar to the method described at the end of section 2.1.3. All ROM chips must be de-soldered from the iPhone. Then the data contained must be saved with the help of a NAND dump. Here it holds also true that this method is expensive, time consuming and the most invasive one.

2.2. Selection of Existing Tools When the creation of the memory dump has been completed, we can now analyze this dump with the help of some commonly used software solutions. In this section, we discuss these tools as well as solutions for analyzing the mobile phone’s data directly. Some more forensic software solutions are discussed in Baggili et al. [31], Williamson et al. [32] and Ayers et al. [15].

2.2.1. Gammu The first tool we present within this section is called Gammu [33]. This tool had been previously known as MyGnokii2. It is available as open-source and is the only tested tool which operates platform-independent. Offered are many 5

The term ‘jailbreaking’ originates from a UNIX practice of putting services in a restricted set of directories called a ‘jail’. [27] 6 Many iPhones used in Germany have already installed a jailbreak firmware as to use those phones also in mobile phone networks other than T-D1. In this cases the changed data through the investigator is very small.

13

2. Background on Mobile Phone Forensics extensions to the tool, e.g., a graphical interface like ‘GammUI’ or ‘Wammu’. Moreover, thanks to a Python module, the possibility exists to develop new extensions for Gammu on one’s own account in order to implement new functions, or to adapt the tool to one’s personal needs, as well. Amongst many Linux distributions Gammu and Wammu are already included within the repository to facilitate installation.

Figure 2.6.: Wammu phone configuration wizard To ease the configuration of the mobile phone extension the user can make use of an assistant within the graphical interface (see Figure 2.6), which recognizes the mobile phone connection, either manually, or fully automated. Thereafter the configuration file of Gammu is adapted. However, we have to mention that a high degree of professional knowledge is needed. The investigator is forced to open and use the assistant when opening Wammu (see Figure 2.7). The tool offers support for a broad range of mobile phones and due to the huge developer community the list of supported mobile phones is constantly enlarged. A disadvantage of this tool constitutes the fact that it directly operates on the mobile phones rather than on the memory dump. It uses the communication via F-/M-Bus when dealing with Nokia phones, and via AT-commands [34] when dealing with other manufacturers. Moreover, it actively supports changing data on the mobile phone which does not allow for a sustainable line of argument.

14

2.2. Selection of Existing Tools

Figure 2.7.: Wammu missing configuration at first start

During the conducted tests it became obvious that Gammu found many data stored on mobile phones like ‘saved SMS’ and directory entries. Though, unfortunately no ‘cached SMS’ or pictures were detected. As a last point we would like to outline that the above described tool is not suitable for forensic investigation of mobile phones as data integrity cannot be assured.

2.2.2. Oxygen Forensic Suite

As a further possibility to analyze data on smart phones Oxygen Forensic Suite has to be mentioned [35]. This tool enables communication with the smart phone via bluetooth, infrared or via USB-data-cable of the manufacturer. However, the fact that it is almost impossible to obtain a data cable for older mobile phones from the manufacturer constitutes a major disadvantage.

15

2. Background on Mobile Phone Forensics

Figure 2.8.: Oxygen Forensic Suite Assistant for analysis selection Oxygen Forensic Suite offers a huge number of supported mobile phones which brings relief to the investigator as he need not adapt the interface beforehand. The tool itself is clearly designed and guides the investigator through the complete analysis without requiring special expert knowledge. This has been achieved by various assistants available to the investigator (Figure 2.8 shows the assistant helping with the selection of the smartphones’ content to be examined).

Figure 2.9.: Oxygen Forensic Suite overview on found address book entries The analysis of found data is presented in a very neat form within Oxygen Forensic Suite as shown in Figure 2.9 and Figure 2.10. The reporting is offered

16

2.2. Selection of Existing Tools in PDF-format, as an Microsoft Excel file or as formatted rich text (rtf). Here, major emphasis is put on the hash-values of each single entry, however storage addresses are neglected.

Figure 2.10.: Oxygen Forensic Suite overview on found calendar entries

The tool, used in a demo version, finds only ten entries in each category, however we can already conclude that neither ‘cached SMS’ nor the ‘call history’ could be restored. In our eyes, this can be explained by the fact that the Suite accesses the operating system of the smartphone. This implies that only those data are analyzed which are shown to the user on the mobile phone, as well.

The above mentioned aspect is considered to be a huge disadvantage, as operating directly on the mobile phone violates forensic principles. Data integrity cannot be guaranteed after the conduct of an analysis with the help of Oxygen Forensic Suite. Moreover, full confidence has to be put on the mobile phones’ operating system and deleted data cannot be shown with this method, as well. As an last aspect it has to be noted that subsequent reproduction of analyses is not possible as no memory dump is created.

Finally it can be stated that this tool should not be used for forensic purposes due to the above mentioned reasons. This includes primarily the missing possibility of gapless reasoning and the non-guarantee of data integrity.

17

2. Background on Mobile Phone Forensics

2.2.3. Cell Phone Analyzer

Figure 2.11.: CPA [4] select phone and file typ for analysis

We present a third option, the Cell Phone Analyzer (CPA) from BK-Forensics [4] in the following. This tool offers a clear and easy-to-use interface, allowing also unexperienced investigators to conduct a mobile phone analysis. This fact becomes evident in Figure 2.11 when selecting the device to be examined and the image type. CPA offers a huge selection of supported mobile phones. Moreover, in contrast to many other tools, it does not operate directly on the device but rather on the dumps of Twister Box. This method of operation guarantees data integrity which is a major concern from a forensic point of view.

In addition, CPA offers a detailed report function which can be adapted to the needs of each individual investigator with the help of the Report Wizard. To state some examples, the investigator’s name, date, company or a reference number can be deposited which then appear in both, the report and the analysis file. The actual report can be created in various formats (e.g. HTML, text or rich-text). Moreover, the report directly shows the offsets of found and decoded data in order to make the procedure more transparent.

18

2.3. Differences in the Operation Systems of Mobile Phones

Figure 2.12.: Excerpt of the CPA [4] report for SMS After we have done a detailed analysis of the report, it becomes evident that the tool has found many data on the mobile phone (e.g. as shown in Figure 2.13 SMS, cached SMS, the register, the call history and general smartphone information as depicted in Figure 2.12). However, we must also point out that the tool does not find any stored pictures although those exist on the phone as shown in Chapter 4.1. Due to the fact that within this diploma thesis only the demo-version had been available the report contains random dots. However, there are no restrictions concerning the functionality of the tool as compared to the full version.

Figure 2.13.: Excerpt of the CPA [4] report for mobile phone information

2.3. Differences in the Operation Systems of Mobile Phones At the end of this chapter we present the differences and particularities of currently used mobile phone operating systems within the following sections. In Section 2.3.1 we describe the manufacturer-owned system of Nokia (Series40), followed by the currently mostly used operating system Symbian in Section 2.3.2. Afterwards, we deal with two more systems which are commonly known. With respect to those, we explain Windows CE in Section 2.3.3 and OS X, which is the newest available operating system for smartphones, is depicted in Section 2.3.3.

19

2. Background on Mobile Phone Forensics

2.3.1. Nokia Series40

According to Nokia [36] the Series40 platform has been developed over the last 8 years and the devices range from mass-market devices that provide many mobile consumers with their first experience of the Internet, to devices for specific market segments, such as music or fashion. This platform offers Java technology, Flash Lite from Adobe, web technology and mobile media content.

For Java developers, there is MIDP and CLDC technology, with an array of JSRs that provide additional location, communication, messaging, media, and graphics capabilities. Media developers can deliver web, messaging, and Flash Lite content, as well as streaming video and audio. All this is supported by Open Mobile Alliance (OMA) and digital rights management (DRM) to protect developers’ property. OMA Client Provisioning (CP) and OMA Device Management (DM) to enable remote device configuration are also provided.

The device architecture, following to the Nokia white paper [5], consists of the hardware (the device hardware, CPU, memory) and the operating system, which provides fundamental services to the platform, which consists of:

• Series40 applications: functionality provided to the user, including communication applications (such as telephone and messaging), media applications (such as image viewer, camera and music player) and personal information manager (PIM) with calendar, tasks, and contacts applications.

• Series40 Java technology services: the Java technology implemented within the platform.

• User interface style: resolution and input methods - a common set of UI components with defined behaviour used in one of a range of different screen orientations.

We provide a summary of the Java technology features supported by the different Series40 platforms in Figure 2.14. The mobile phones which we will examine in Chapter 4 are built on the first edition of this platform.

20

2.3. Differences in the Operation Systems of Mobile Phones

Figure 2.14.: Summary of the Java technology supported by the Series40 platform [5]

2.3.2. Symbian OS Symbian OS has been created from scratch, especially for mobile communication devices. While other operating systems, e.g., WinCE for smart phones, had emanated from already existing operating systems, Symbian OS evolved from a contrary approach. The earlier version EPOC, for example, could be executed on devices with less than two megabyte of storage space [37]. Figure 2.15 shows the differences of the Series40 and the Symbian platform. Symbian supports not only different programming languages like Python and C++, and leads to a correlated significant increase in the availability of APIs, but moreover is build modularly. The operating system functionality is provided by the use of different components and not by a monolithic entity. Data access is executed by a ‘file server’ while user input and soft copies are displayed by the ‘windows server’, for instance.

21

2. Background on Mobile Phone Forensics

Figure 2.15.: Comparison of the different platforms [5] It is difficult to develop an operating system which possesses common core capabilities on the one hand, and simultaneously features an uniform programming environment for all smart phones, on the other hand. Today’s smart phones exist in different sizes, forms, screen sizes and input options. The user interface has to adapt to the respective conditions in order to cope with those requirements. Due to that reason Symbian is featured with a flexible architecture which allows the different user interfaces to use the core functionality of Symbian OS as a basis. With respect to mobile phone manufacturers, Symbian decided to develop some reference platforms as to give them a starting point [38]. Those reference platforms include the Symbian OS core functionality together with a user interface which represents a basis-smartphone-typ of a component assembly (screen size and input options). We state the two mostly used reference platforms in the following as an example: • Nokia S60 [39]: this also as Series60 known version already exists in the fourth version since 2001. Its key characteristics can be described as limited input options, a numerical keypad for text entry and a small screen size (typically 240 x 320 pixel). • UIQ: has been developed for pen-based (e.g. touch-screens) smartphones which is contrary to the S60. Mobile devices which are based on this platform often do not incorporate a keypad. However this disadvantage can be compensated by a virtual keypad and handwriting recognition. Screen size varies depending on the model but it can be stated that 240 x 320 pixel are also typical for this type. An important point concerning Symbian is the Platform Security Architecture (PSA) [40]. It had been developed in order to control which operations a process is allowed to conduct, and which not. A process can execute its function

22

2.3. Differences in the Operation Systems of Mobile Phones only if it owns the corresponding privileges. If a program does not own the necessary privileges, this process will be prevented from executing the operation due to the fact that it has been classified as untrustworthy. The processes’ access to APIs is administered by so-called ‘capabilities’. Symbian OS constitutes a ‘Trusted Computing Platform’ which consists, according to Symbian [6], of three trust tiers: • Trusted Computing Base (TCB): This contains the most trusted parts of the OS. Its responsibility lies in the maintenance of the system’s integrity and it is also the part that is least restricted (i.e., it has access to the full range of capabilities available). The Trusted Computing Base consists of the Symbian OS kernel, the file system, and the software installer and how it provides a path for applications to enter the trust tiers. • Trusted Computing Environment (TCE): This is the next tier of trust. Its code has access to only a subset of capabilities. The Trusted Computing Environment largely consists of system servers (i.e., processes that manage and control access to system resources), such as the window server process that controls access to the screen hardware. Each server is only given the capabilities it needs in order to perform its function. So, for example, the window server does not have access to any capabilities that are used for communications or for the reading and writing of user data. In this way it is not possible for a misbehaving system server to compromise the security of another server since it does not have access to the same APIs. • Application: Code running outside of the Trusted Computing Environment has access only to those APIs that are unlikely to pose a security risk. The APIs available in the application tier are grouped by capabilities that relate to user-level features or actions, that is, those that a user can understand. These capabilities are often known as ‘user’ capabilities or ‘application’ capabilities. Untrusted applications must request permission from the user before accessing these APIs. The single capabilities of the correspondent trust tiers are shown in Figure 2.16. With the help of signed software it is possible to add and/or modify components in the TCB or TCE. Anyhow, this holds only true if both, the software had been signed by a trustworthy certificate authority, and the authority is qualified to grant the necessary privileges [41]. A major implication of this is that signed software within the TCE is more trustworthy than software outside the TCE. In case that either unsigned software is used, or software which had not been signed by a trustworthy authority, the system has no basis on which the trustworthiness can be determined. This is why the software then is treated as not trustable.

23

2. Background on Mobile Phone Forensics

Figure 2.16.: The capabilities available in each trust tier [6]

2.3.3. Windows CE Windows CE [42], often referred to as WinCE, is a modular operating system, which serves as the foundation for several classes of embedded devices. WinCE is optimized for devices with minimal storage and small scale factors. For example, its kernel requires less than 1 MB of memory. The devices are often configured without any disk storage and may be configured as closed systems, with the operating system burned on the ROM. WinCE is compliant to the definition of a real-time operating system with deterministic interrupt latency. It supports 256 priority levels and uses priority inheritance to deal with priority inversion. Furthermore, it is a multitasking operating system, where the fundamental unit of execution is a thread. Since the first edition of WinCE (Pegasus), the operating system has evolved to support platforms others than handheld devices. To manage and allocate program memory, the WinCE kernel uses a paged virtual memory system. This system provides contiguous blocks of memory, between 1 KB and 4 KB within 64 KB regions, so that applications do not have to deal with memory allocation. In a WinCE device, the operating system and the applications bundled with the operating system, are stored in ROM. The entire operating system is mapped to a binary ROM image, logically divided into two types of modules. The first type corresponds to executable in place (XIP) modules. The second type includes compressed modules, which are decompressed by the operating system and paged into RAM before execution. In WinCE devices, the RAM is divided into two regions, ‘object store’ and ‘program memory’. The object store resembles a permanent, virtual RAM disk. Data

24

2.3. Differences in the Operation Systems of Mobile Phones in the object store is retained when the system is suspended or when a soft reset operation is performed. Normally, devices have a backup power supply for the RAM to preserve data when the main power supply is interrupted. When operations resume, the system searches for a previously-created object store in RAM and uses it. The remaining portion of the RAM on a WinCE device is designated to program memory. This space holds various stacks and heaps belonging to executing applications. WinCE has a virtual memory address space of 4 GB. The operating system is able to manage at most 32 processes by assigning a slot corresponding to 32 MB of virtual address space to each process. This is partly due to the fact that Windows CE keeps the address spaces of all processes available at all times, even when the processes are not running. Thus, the lower portion of the address space is split into 32 MB slots. The address space is, according to Savoldi and Gubian [7], divided as followed: • Slot 0 is assigned the memory locations in the range 0x00000000 to 0x01FFFFFF. • Slot 1 is assigned the memory locations in the range 0x02000000 to 0x03FFFFFF. • Slot 31 (last slot) ends at memory location 0x41FFFFFF. • Memory locations in the range 0x42000000 to 0x7FFFFFFF mostly correspond to the ‘shared area’ used for VirtualAlloc functions and memorymapped files. • Memory locations above 0x80000000 are reserved for the kernel. The kernel and the DLLs that load into the kernel execute from this memory space.

Figure 2.17.: Virtual address space managed by Windows CE [7] Figure 2.17 shows the layout of the virtual memory managed by WinCE. Note that the kernel and user space each have 2 GB of addressable memory. The Remote Application Program Interface (RAPI) protocol [43] is often used by tools to extract the ROM and RAM contents of WinCE devices. The RAPI library enables applications running on a desktop computer to perform actions

25

2. Background on Mobile Phone Forensics on a remote WinCE device. RAPI interfaces can be used to create and modify databases, either in the object store, or in mounted database volumes. RAPI applications can also query and modify registry keys as well as launch applications and invoke methods on the remote device.

2.3.4. OS X iPhone The iPhone has a solid state NAND flash included which is divided into two partitions by default. The root partition has, depending on the iPhone’s generation, a size of 300MB up to 500MB and contains pre-installed software which is intended to remain on the phone over its complete lifetime. Due to that reason the partition has a read-only status and is directly mounted under /. The residual storage space is mounted as a media partition under /private/var/ and serves for the storage of all user data including music, contacts, and pictures. According to Zdziarski [44] this exhibits the best possibility for Apple to load a new operating system onto the phone without changing any user data. The actual device nodes for the disk are as seen in Listing 2.2. 1 2 3

brw−r−−− 1 r o o t o p e r a t o r 14 , 0 Apr 7 07:46 / dev / d i s k 0 Disk brw−r−−− 1 r o o t o p e r a t o r 14 , 1 Apr 7 07:46 / dev / d i s k 0 s 1 System brw−r−−− 1 r o o t o p e r a t o r 14 , 2 Apr 7 07:46 / dev / d i s k 0 s 2 Media

Listing 2.2: Device nodes for iPhone disks Both partitions make use of the by Apple developed HFSX file system which is shown together with the partition type (pmParType) ‘Apple HFSX’. The above mentioned file system constitutes an advancement of HFS+ which is casesensitive when dealing with file names and which has activated the journaling function of HFSJ by default. According to Apple [45] case-sensitive names do not ignore Unicode ‘ignorable’ characters. This means that a single directory may have several names which would be considered equivalent using Unicode comparison rules, but which are considered distinct on a case-sensitive HFSX volume. Those volumes can be identified by the signature 0x4858 in the signature field of the volume header. The following version field specifies the in the volume used HFSX-version7 . HFS+ is a 32-bit file system with an universal Unicode character set and an up to 255 characters long file name. It is able to administer up to four billions of blocks which may contain files and/or folders. This is not only dependent on the size of the medium used, but also on the files and the blocks itself. The preferable block size is 4 KB.

2.4. Summary As we depicted within this chapter in detail, there exist various possibilities to create an accurate memory dump, which is used in mobile phones. This 7

The only value currently defined is 5.

26

2.4. Summary can be done with the help of additional hardware, like the Twister Box, or by using specific tools which have been developed for this purpose. Here the tool MIAT can be stated as an example. The disadvantage of this method is that it cannot be used for every type of device and that different approaches have to be considered depending on the kind of smartphone used. An alternative exists, i.e., the de-soldering of the memory chip with a subsequent direct analysis, however this approach is not chosen very frequently due to its time and effort caused. Moreover, we observed that currently only few tools are offered which fulfill the forensic requirements and therefore the results of an analysis may be used as evidence in court. Many of the existing tools resort to the manufacturer interfaces without verifying their function in advance. Furthermore, sometimes also data are modified on the device, anticipating a reproduction afterwards. As described within the last sections, many operating systems can be found when dealing with mobile phones. All of them contain distinct storage structures or file systems. As an example, we refer to the iPhone which is similar to an Unix-System as well as to a proprietary, manufacturer-owned system from Nokia. Those different underlying operating systems necessitate varying approaches for analysis. Moreover they require an investigator with a high degree of expertise.

27

2. Background on Mobile Phone Forensics

28

3 Mobile Phone Forensic Toolkit

As we have seen in Chapter 2.2, there are almost no tools existent which conduct a correct forensic analysis of smartphones on their memory dump. Due to this fact, we developed a tool within this diploma thesis which conducts such an analysis for Nokia Series40 phones on the created memory dump. The memory dump has been created with the help of Twister Box. We illustrate in the following chapter the implementation of the developed tool in detail. After we depicted the design goals in Section 3.1, we give a rough overview of the whole system in Section 3.2. In Section 3.3 we explain the single main components. Within this context also the characteristics of the decryption are outlined. In Section 3.4 we present the software agent which has been created for the generation and analysis of relevant storage areas.

3.1. Design Goals After providing a review of advantages and disadvantages of selected approaches in Section 2.2, the following section presents the design goals of the newly developed system: Usability: The handling of the mobile forensic toolkit should be as simple as possible in order to ensure that both, not only IT professionals but also inexperienced users can use this tool. Ideally, the complete examination of the memory dump runs in an autonomous way so that the user does not gain any notice from the internal processes. However, the system is supposed to create a detailed report in an easily legible form with all decoded data included. Extendability: In order to ensure continuous future actuality of the system it is of great importance that the reporting, as well as the analysis function can be easily complemented by further mobile phones. For this purpose the analysis function will be constructed modularly and the reporting function will

29

3. Mobile Phone Forensic Toolkit be implemented as an independent part. By adding single functions it is then possible to increase the number of mobile phones used without adjusting the reporting function. Forensic respectability: The entire tool is supposed to treat data in a forensically correct way. This goal is reached by the fact that work does not take place directly on the phone but rather on a memory map of the phone. Thus it is ensured that neither by the investigator nor by the operating system of the mobile phone data can be changed. For being able to prove the forensic correctness of decoded data by hindsight, hash values will be calculated prior and after each analysis and all storage positions will be indicated within the report.

3.2. System Overview

Figure 3.1.: Schematic system overview The developed system is divided into several sub-units. Hereby we distinguish between older and newer mobile phones. Whereas a complete memory dump is generated with the help of Twister Box and the use of SarasSoft Toolbox when dealing with older mobile phones, the process with newer ones is different. With respect to newer Symbian phones this process only leads to a partial

30

3.3. Implementation of the Wrapper Class memory dump of the phone. Here the remaining part of the memory dump is created with the help of a software agent directly on the phone. This procedure is forensically questionable as data become changed during the installation of the software agent. However, due to the fact that the software agent possesses only a small file size, only few data become changed. Moreover, currently no other technically realizable solution exists in order to get to the relevant data from the internal storage device, which is why we consider this procedure acceptable. Note that we recommend to install the software agent on a memory chip instead on the internal storage of the mobile phone in order to minimize the amount of changed data. In the case of Series40 phones, the analysis takes place with the help of a wrapper-class which was programmed in Python and which is started via the command line. The report is generated as HTML-file and is shown to the investigator in his standard browser. By creating the XMLfiles the reporting function can be extended at any time. The reason for choosing Python lies in its platform independence and the high performance when processing strings and byte-streams. Those characteristics play a vital role for the memory dumps used in this case. We show the procedure of data processing and the creation of memory dumps (see Chapter A) in Figure 3.1 and is delineated hereafter.

3.3. Implementation of the Wrapper Class Within the scope of this diploma thesis, a tool for forensic analysis of Twister Box dumps for Nokia smartphones has been developed. The tool contains several scripts which are written in Python [46]. The various scripts correspond to modules which are responsible for certain telephone functions (address book, SMS, call history, etc.). Those are accessed via a global script. The global script runDecoding.py accepts the Twister Box dump file, the mobile phone type and the reporting type as an argument. This is shown in Listing 3.1. 1

$ . / runDecoding . py < r e p o r t i n g type>

Listing 3.1: Arguments and cue of the decoding tool After starting the tool, data processing is initiated as shown in Figure 3.2. Moreover, the necessary folder structure is generated. While the tool takes over the automatic processing of raw data, the investigator receives continuously information on the current status, as well as on the device type. The first step of the tool to be undertaken is to calculate the md5 and sha1 checksum of the Twister Box dump files *.pm. This step is important as to guarantee data integrity. In a next step the dump file in splitted into several sections. To do so, the single blocks are separated and the index is isolated (see also Listing 3.2). Those steps ease the further process of analysis.

31

3. Mobile Phone Forensic Toolkit

Figure 3.2.: Terminal view while script runs the decoding

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

# c u t o r i g i n a l dump f i l e i n p i e c e s and s a v e t h i s p i e c e s f o r l i n e in f o b j : i f ” [ ” in l i n e : line2 = line . s p l i t () filenameNew = l i n e 2 [ 0 ] filenameNew = s t r ( filenameNew ) i f ” [ ” not in l i n e : filename2 = filename . s p l i t ( ” . ” ) filenameOld = filename2 [0] filenameOld = s t r ( filenameOld ) hexPath = path + ” / c u t t e d P i e c e s H E X / ” f o b j 2 = open ( hexPath + filenameNew + ” . hex ” , ” a ” ) l i n e 3 = l i n e . s p l i t ( ”=” ) o u t p u t l i n e = l i n e 3 [1] outputline = str ( outputline ) f o b j 2 . write ( o u t p u t l i n e + ” \n ” ) fobj2 . close ()

Listing 3.2: Cutting the original memory dump file After a successful split-up the individual modules are called up, conducting the decoding of data. Within this process the smartphone type is always handed over as well, in order to call up the correct subroutines. This guarantees a fast adaption of the tool to new mobile phones as only the subroutines have to be

32

3.3. Implementation of the Wrapper Class amended or adjusted respectively. In this case, it is not necessary to change neither the whole process, nor the reporting. Within the following section the individual modules and their respective decoding functions are presented in detail.

3.3.1. Gathering Information about the Handheld Here, the module decode handheldInfo.py is depicted. This module is responsible for decoding general information as the serial number, the international mobile equipment identity (IMEI) or the security code, which are kept in the storage of the mobile phone. When dealing with Series40 smartphones those information are kept in the blocks 4, 5, 13 and 35 of the dump files. When decoding the HEX values of block 4 one can find the values of ‘serial number’, ‘product code’, ‘product basic code’, ‘module code’ and ‘hardware number’ in the lines 3 to 7. Block 5 contains the ‘IMEI’ of the device and in block 13 the ‘startup message’ which has been inserted by the user and is displayed when the device is switched on, can be found. The ‘security code’ of the smartphones (12345 in the following example) can be decoded from its HEX value in block 35 of the Twister Box dump files (see Listing 3.3). 1 2

[35] 0=31323334350000000000

Listing 3.3: Block 35 of the dump file

3.3.2. Gathering Information about the Lastly Inserted SIM In addition, the smartphone stores information on the lastly inserted SIM card. This information serves the purpose of a clear identification of the SIM card. Moreover, it is used for various security mechanisms in Series40 phones. To illustrate this, the following example can be given: when inserting another than the lastly used SIM card, the address book on the phone is deleted and the display of saved SMS and the call history is removed for the user. The latter data are not deleted and therefore can still be found ex post by analyzing the memory dump. However, this is only the case if those data have not been overwritten by new entries. Data being deposited in the memory of the smartphone are the international mobile subscriber identity (IMSI) and the serial number (ICCID) of the SIM card. The IMSI is located at the beginning of block 94 filled up with 0x00. In contrast, the ICCID in block 117 can be found at the beginning of the 5. entry. Here the control character at the end has to be cut when decoding the information. Both, the extraction, as well as the decoding from the memory dump is done by the module decode SIM.py.

33

3. Mobile Phone Forensic Toolkit

3.3.3. Decoding Call History The module decode calllogs.py decoded the three call histories stored on the smartphone: ‘received calls’, ‘outgoing calls’ and ‘missed calls’. Those three lists are stored within the blocks 59 to 61 when dealing with Series40 phones. Here it has to be mentioned that block 59 contains the ‘outgoing calls’, block 60 contains the ‘missed calls’ and block 61 exhibits the ‘received calls’. We present the exact depiction of the content of the single storage entries in Figure 3.3.

Figure 3.3.: Callhistory in a Series40 memory dump The date contained within those blocks is translated into a readable format with the help of the in Listing 3.4 shown function of GSM Standard [47]. 1 2 3

# c o n v e r t s a g i v e n d a t e from GSM t o DEC d e c S t r i n g = encodedDate . decode ( ’ hex ’ ) d e c S t r i n g = s t r u c t . unpack from ( ’>H5B ’ , d e c S t r i n g )

Listing 3.4: Convert date from GSM to DEC

3.3.4. Decoding SMS We decoded the SMS messages which have been stored within block 140 in a Series40 smartphone with the help of the module decode sms.py. The layout of the storage area is depicted in Figure 3.4. As one can see in Figure 3.4 the date is shown in the format YYMMDDHHMMSS [47] in the denoted storage area. When decoding this, it has to be taken care that the single characters are shifted byte by byte. If doing so, the value 0x90 is 0x09 after shifting. This method of byte-shifting needs to be done as well, when dealing with the sender- and SMSC-number in order to gain the correct data. In this context the SMSC-number reflects the number of the service center by which SMS are sent.

34

3.3. Implementation of the Wrapper Class

Figure 3.4.: SMS message in a Series40 memory dump The module decode sms.py calls the sub-module decode pdu.py for decoding the SMS contents. This sub-module conducts the byte-operations shown in Listing 3.5 and sends back the decoded string to the main module. Within the main module the corresponding sender- and receiver identifications, as well as the date are decoded as an addition to the above described string. 1 2 3 4 5

6 7 8

def pduSMS( smsMessage , path ) : smsMessageHex = smsMessage . decode ( ’ hex ’ ) a s c i i S m s = main ( smsMessageHex ) # makes t h e s t r i n g r e a d a b l e a s c i i S m s = f i l t e r ( lambda x : ( x in s t r i n g . p r i n t a b l e or x in ” \x20\ x d f \ x f c \ x f 6 \ xe4 \ xdc \xd6\ xc4 ” ) and ( x != ” \n ” ) and ( x != ” \ t ” ) , a s c i i S m s ) asciiSms = asciiSms . replace ( ”˜” , ”\ xfc ” ) asciiSms = asciiSms . replace ( ” | ” , ” \ xf6 ” ) return a s c i i S m s

9 10 11 12 13 14 15 16 17 18

def decode ( encoded ) : carry = 0 f o r i , b y t e in enumerate ( encoded ) : shift = i % 7 y i e l d ( ( b y t e > (7 − s h i f t ) i f s h i f t == 6 : yield carry carry = 0

19 20 21 22 23

def main ( encoded ) : decoded = ’ ’ . j o i n (map( chr , decode (map( ord , encoded ) ) ) ) a s s e r t l e n ( decoded ) == l e n ( encoded ) + l e n ( encoded ) // 7 return decoded

Listing 3.5: Decoding PDU encoded SMS

35

3. Mobile Phone Forensic Toolkit The byte-operations conducted within this listing are based on the described decodings for SMS messages in two papers of the European Telecommunications Standards Institute (ETSI) [48; 49]. With respect to this, a 7-bit ASCII alphabet has been chosen for decoding when a 127-bit GSM alphabet is the basis. Those 7-bit are then transformed to a an 8-bit ASCII by separating bits on one Septet and adding those to another Septet. The HEX values of this 8-bit ASCII alphabet are afterwards stored in the memory of the Smartphone. We illustrated this process exemplarily in the character chain ‘hellohello’ in Table 3.1 [50]. With the help of the above described decoding procedure it is possible to decode the following values of the in Listing 3.6 shown extract of a memory dump: • Date: 21-04-09 09:37:22 • Sender: +491705489447 • SMSC: +491710760000 • Message: Dies ist die Antwort auf die Test-SMS !! 0204000201010050240000 904012907322 8000000003820C01080C91 947 150844974 820C02080791 947101670000 80282429 C474790E4ACFE9207 2BA0C0ABAE9F7B79C0E0AD7CD2072BA0CA296E7F4D6B43905854021

Listing 3.6: Memory excerpt of a saved SMS Message

3.3.5. Decoding Address Book The module presented within this section decode addressBook.py is responsible for the decoding of the address book on a Series40 smartphone. The address book is located in block 58 of the memory dump and exhibits the in Figure 3.5 shown format.

Figure 3.5.: Address Book Entries in a Series40 memory dump

36

Text Dec 7-bit ASCII 7-bit ASCII 8-bit ASCII HEX

h 104 1101000 1101000 1 1101000 E8

e 101 1100101 110010 1 00 110010 32

l 108 1101100 1101 100 1111 1101 FD

o 111 1101111 110 1111 01000 110 46

h 104 1101000 11 01000 100101 11 97

Table 3.1.: Coding 7-bit data into octets

l 108 1101100 11011 00 100 11011 9B

e 101 1100101 1 100101 1101100 1 D9

l 108 1101100 1101100

l 108 1101100 1101100 1 1101100 EC

o 111 1101111 110111 1 110111 37

3.3. Implementation of the Wrapper Class

37

3. Mobile Phone Forensic Toolkit

3.3.6. Decoding Calendar The calendar is stored in block 51 of the internal memory on a Series40 smartphone. The layout of the storage content is outlined in Figure 3.6. Here it has to be noted that the date is decoded again as shown in Listing 3.4. For the decoding of this storage address the module decode callendar.py is used which has been developed within the scope of this diploma thesis.

Figure 3.6.: Callendar Entries in a Series40 memory dump

3.3.7. Decoding Stored Files Stored files are deposited in block 158 when dealing with Series40 smartphones. Each entry matches with a file which can be identified by means of its unique header. A GIF-picture can be recognized by its unique header 0x47 0x49 0x46 0x38 0x39 0x61, to mention an example. By reading out the header, the file is recovered by the action that the respective line in binary format is saved as a new file with the corresponding ending. With respect to this, it has to be noted that each line of the block ends with a control character which is not part of the real file. This character has to be removed before storage. 1 2

3 4 5 6

7 8 9 10

11 12 13

i f l i n e [ : 6 ] == ” \ x f f \xd8\ x f f \ xe0 \x00\x10 ” : m e d i a f o b j = open ( path + ” / media / p i c t u r e ” + s t r ( number ) + ” . j p g ” , ” ab ” ) m e d i a f o b j . write ( l i n e ) media fobj . close () i f l i n e [ : 6 ] == ” \x47\x49\x46\x38\x39\x61 ” : m e d i a f o b j = open ( path + ” / media / p i c t u r e ” + s t r ( number ) + ” . g i f ” , ” ab ” ) m e d i a f o b j . write ( l i n e ) media fobj . close () i f l i n e [ : 4 ] == ” \x4d\x54\x68\x64 ” : m e d i a f o b j = open ( path + ” / media / a u d i o f i l e ” + s t r ( number ) + ” . midi ” , ” ab ” ) m e d i a f o b j . write ( l i n e ) media fobj . close () i f l i n e [ : 4 ] == ” \x50\ x4b \x03\x04 ” :

38

3.3. Implementation of the Wrapper Class

14

15 16 17 18

19 20 21 22

23 24

m e d i a f o b j = open ( path + ” / media / j a r f i l e ” + s t r ( number ) + ” . j a r ” , ” ab ” ) m e d i a f o b j . write ( l i n e ) media fobj . close () i f l i n e [ : 4 ] == ” \x4d\x69\x63\x72 ” : m e d i a f o b j = open ( path + ” / media / C L D C f i l e ” + s t r ( number ) + ” . t x t ” , ” ab ” ) m e d i a f o b j . write ( l i n e ) media fobj . close () i f l i n e [ 7 2 : 8 0 ] == ” \x6d\x69\x64\x70\x2d\x72\x6d\x73 ” : m e d i a f o b j = open ( path + ” / media / MIDP RMSfile ” + s t r ( number ) + ” . db ” , ” ab ” ) m e d i a f o b j . write ( l i n e ) media fobj . close ()

Listing 3.7: Decoding stored files based on their file headers The CLDC and MIDP RMS1 files found within this block belong to the installed JAR2 files and contain the database as well as the configuration file of it.

3.3.8. Report Function The reporting is carried out fully automated, as well. With the help of the Python plug-in HTMLgen [52] the analyses of the single modules are transformed into an HTML-file and afterwards opened in the standard browser of the investigator. This is done with the help of the in Listing 3.8 shown function. 1 2 3 4 5

# o p e n i n g r e p o r t i n webbrowser htmlPath = os . path . a b s pa t h ( path ) i f os . path . i s f i l e ( htmlPath + ” / r e p o r t . html ” ) : p r i n t ”−−> opening r e p o r t i n f a v o u r i t e webbrowser . . . . ” webbrowser . open new ( ” f i l e : / / l o c a l h o s t / ” + htmlPath + ” / r e p o r t . html ” )

Listing 3.8: Script for opening the report in favourite browser In addition, all results of the analysis are stored in a sub-folder of the tool as a XML-file. In Listing 3.9 such a file is presented for a saved SMS message which has been found previously. The related XML-schema3 is shown in Listing 3.10. This folder is labeled with the unique IMEI of the investigated device. This 1

The Connected Limited Device Configuration (CLDC) defines the base set of application programming interfaces and a virtual machine for resource-constrained devices like mobile phones, pagers, and mainstream personal digital assistants. When coupled with a profile such as the Mobile Information Device Profile (MIDP), it provides a solid Java platform for developing applications to run on devices with limited memory, processing power, and graphical capabilities [51]. 2 The JavaTM Archive (JAR) file format enables you to bundle multiple files into a single archive file. Typically a JAR file contains the class files and auxiliary resources associated with applets and applications. 3 All used XML-schemata are printed in Section A.

39

3. Mobile Phone Forensic Toolkit procedure eases the documentation and increases the facility of inspection if the investigator is analyzing various mobile phones at a time. 1 2 3 4 5 6 7 8

00001 2009−04−21 09 : 3 7 : 2 2 +491705489447 +491710760000 D i e s i s t d i e Antwort a u f d i e Test −SMS ! !

Listing 3.9: XML-file of a saved SMS after decoding 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

SMS messages

Listing 3.10: XML-schema for a saved SMS

3.4. Implementation of the Symbian Software Agent In this case we have to use another approach as it is not possible to create a memory dump with the help of Flasher-tools like Twister Box when dealing with smartphones running with Symbian OS. The single solution which is currently realizable, apart from de-soldering the memory element, is constituted by the solution with the help of a software agent. This agent is installed on the mobile device and creates a dump of saved files from this location. We decided to develop this software agent in Python; we named it Panoptes4 . This tool can either be started as script within the PyS60 interpreter, or it can 4

Panoptes, also called Argos, is derived from the Greek mythology and signifies the one who sees everything. He had been a tremendous ogre with a hundred eyes all over the body, which allowed him to look in all directions, thereby noticing everything suspicious.

40

3.4. Implementation of the Symbian Software Agent be installed as a stand-alone version with the help of SIS-files. Both versions have advantages, as well as disadvantages. When using the script version, the Python interpreter has to be installed on the device beforehand. Thus Panoptes does not need any further installation, and the update function is kept. In contrast, when using the SIS version, no further software (interpreter) is needed; however the updating of an already installed version of Panoptes becomes significantly difficult. The SIS-file can be created at anytime with the help of the tool ensymble.py [53] and the call which is depicted in Listing 3.11. 1

$ python2 . 5 ensymble . py p y 2 s i s panoptes . py −n Panoptes −u 0 xe46e586a −r 1 . 1 . 0 −l EN −c ” Symbian Memory Backup ” −f E

Listing 3.11: Creating a Panoptes SIS-file Listing 3.12 shows the process of backing up the file structure which is important for the investigator. In this case the folders cache stand for the Browser Cache of the smartphones and DATA with its subfolders normally contains all recorded videos, pictures, or audio files (within this folder all user files are saved by the operating system by default). The folders System and SYS contain all extensions, driver, and modules, which are needed for the programs installed on the smartphone. Here we can easily identify which software has been installed on the device. Shared, non-sensitive data are saved within the folder RESOURCE. Finally, we save the folder PRIVATE which contains all sensitive data from the single programs, as well as from the user. Within this folder we can also find the calendar, saved SMS and the address book. We only use folders from the device C: as this represents the internal memory of our device. The devices D: and Z: represent the ROM and RAM and do not contain any relevant data for the analysis. 1 2 3

4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

# c r e a t e s the target f o l d e r os . mkdir ( ” E : \ \ BACKUP” ) f o l d e r l i s t = [ ’ C : \ \ cache ’ , ’ C : \ \DATA ’ , ’ C : \ \ System ’ , ’ C : \ \ SYS ’ , ’ C : \ \ PRIVATE ’ , ’ C : \ \RESOURCE ’ ] f o r f o l d e r in f o l d e r l i s t : # c h e c k s i f f i l e i s a empty d i r e c t o r y i f not os . l i s t d i r ( f o l d e r ) : os . mkdir ( ” E : \ \ BACKUP” + f o l d e r . s p l i t ( ” : ” ) [ 1 ] ) continue else : # l i s t a l l f i l e s i n s i d e the f o l d e r f i l e s = os . l i s t d i r ( f o l d e r ) # creates subfolder os . mkdir ( ” E : \ \ BACKUP” + f o l d e r . s p l i t ( ” : ” ) [ 1 ] ) # target directory t a r g e t = ” E : \ \ BACKUP” + f o l d e r . s p l i t ( ” : ” ) [ 1 ] # c o u n t s how much f i l e s you have i n t h e f o l d e r count = l e n ( f i l e s ) appuifw . note ( u ” P l e a s e w a i t . . . ” , ” i n f o ” ) f o r i in range ( count ) : t f i l e = f o l d e r + ” \\ ” + f i l e s [ i ] # checks i f f i l e i s directory

41

3. Mobile Phone Forensic Toolkit

i f os . path . i s d i r ( t f i l e ) : # appends t h e found d i r e c t o r y t o t h e f o l d e r l i s t f o l d e r l i s t . append ( t f i l e ) else : # copies the f i l e e32 . f i l e c o p y ( t a r g e t , t f i l e ) appuifw . note ( u ” Backup o f ” + f o l d e r + u ” with ” + s t r ( count ) + u ” f i l e s completed . . . ” , ” i n f o ” )

22 23 24 25 26 27 28

Listing 3.12: Backup function of Panoptes As we have shown in the last section, many folders which need to be saved contain sensitive and secured data. Since Symbian and its new Platform Security does not allow access to those data without the necessary capabilities, we would need the capability ‘AllFiles’ in order to certify the tool Panoptes. This capability grants read only access for the desired folders. Due to the fact that this capability belongs to the so-called ‘Manufacturer-approved’5 capabilities, we are not able to get the necessary rights in this way. For this reason a tool6 is applied which allows us for a short period of time to circumvent those security restrictions. This procedure is contrary to forensic principles. Here, interventions are made on the firmware of a device, thereby data become changed permanently. Unfortunately, currently no forensically correct solution exists which allows us to get the required rights if the certification by the manufacturer for the device to be analyzed fails. When all steps are executed successfully, we can now start Panoptes and begin the backup process. The backup of all files and sub-folders within the folders mentioned above can last up to two hours, depending on the amount of data. Of course, a log is created within this process, in order to facilitate the analysis afterwards. We have shown the source code of the log-function in an abbreviated version in Listing 3.13. With the help of the functions imei(), sw version() and os version() important data are read out and are written into the log. The IMEI read out in this way identifies the smartphone uniquely and can be compared to the IMEI beneath the battery to determine whether the owner of the mobile device has tried to manipulate it. The software and OS version primarily serve the investigator who can gain an overview about which data of the created memory dump belong to the real system, and which data have been added by the user afterwards. 1 2 3

4 5

f o b j = open ( ” E : \ \ BACKUP\\ l o g . t x t ” , ” a ” ) f o b j . write ( ” Panoptes − Symbian Memory Backup ” + ” \n ” f o b j . write ( ”−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−” + ” \n ” + ” −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−” + ” \n ” ) f o b j . write ( ” IMEI : ” + s t r ( s y s i n f o . i m e i ( ) ) + ” \n ” ) f o b j . write ( ”−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−” + ” \n ” ) 5

These are highly sensitive capabilities that can only be obtained from the device manufacturer, even if it is just for experimenting on your own phone. Getting these capabilities requires you to justify why you need them, and to have an ACS Publisher ID from Verisign [54] 6 We have used CrackCertificate for our tests, but HelloOX2 or Open4All are successful, as well.

42

3.5. Summary

6

7 8 9 10

11 12

f o b j . write ( ” S o f t w a r e V e r s i o n : ” + s t r ( s y s i n f o . s w v e r s i o n ( ) ) + ” \n ” ) f o b j . write ( ”OS V e r s i o n : ” + s t r ( s y s i n f o . o s v e r s i o n ( ) ) + ” \n ” ) f o b j . write ( ”−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−” + ” \n ” ) f o b j . write ( ” F i l e was not c o p i e d : ” + t f i l e + ” \n ” ) f o b j . write ( ”−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−” + ” \n ” + ” −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−” + ” \n ” ) f o b j . write ( ” Backup completed ” + ” \n ” ) f o b j . close ()

Listing 3.13: Creation of the Panoptes log file In the following, all files and folders which Panoptes was not able to save, are recorded in the so created log. Those files mostly belong to programs which are currently used. Due to the use, those programs are not marked with a lock of the system. Therefore, the investigator should pay attention that he notes prior to the start of Panoptes which programs are still opened in order to eliminate the possibility that important data may be missing in the later analysis. By means of the unique UID it is possible to find out which programs are concerned, even within the later analysis. When the backup process is terminated, the memory chip can be further analyzed in the computer of the investigator. During this step the investigator has to cope with it by oneself since almost every backup of a mobile phone has a different structure and the needed data can be found on different locations of the file system. This can be traced back to the fact that those files are contained in the sub-folders of the corresponding programs in the folder PRIVATE. Because those programs are represented by their UID in the file system, and those become changed with every new version of a program, here it is not possible to conduct an automated analysis. In addition, it has to be stated that currently no option exists which allows to recover deleted data in this way.

3.5. Summary As we depicted at the beginning of this chapter, we have put much emphasis on the following aspects when designing and implementing the tool for analyzing the Twister Box’ dumps: extendability, a later option for amplifying the tool with new functions or new devices, as well as the forensic respectability, i.e., a forensically correct operation on the memory dump as well as the generation of hash values. Moreover, we have not neglected the usability of the tool when considering the above mentioned characteristics. We have to separate the operation mode of the tool, depicted within this chapter, in two distinct ways of procedure. When dealing with Series40 phones the memory dump of the Twister Box is loaded into the wrapper-class for analysis; in contrast, when dealing with Symbian phones, a copy of relevant data is created directly on the phone with the help of a software agent (Panoptes). Within the wrapper-class, the decoding of data of single modules is undertaken, at the

43

3. Mobile Phone Forensic Toolkit end of the process a report is generated. Optionally, this report is either shown directly as a HTML-file within the browser, or it is stored as a separate XML-file in a sub-directory. We describe the software agent within the last section of this chapter in great detail. Panoptes provides aid for copying relevant data from a protected telephone memory onto a memory chip. This process is needed in order to conduct the analysis of those data not directly on the phone. In the course of this chapter we also discussed the forensic questionableness of this procedure, and we exposed why this is the currently best available solution for doing so. In order to keep the amount of data changed as little as possible, a memory chip which is already inserted in the mobile device should be copied byte-wise to a significantly larger one. In addition, the installation files of Panoptes, as well as further required tools, should be copied to the so created memory chip. When installing Panoptes and the tools for avoiding security restrictions one should chose the device E: as target directory. Only by doing so, changed data can be kept minimal. For the application of this tool within the criminal prosecution, we should consider the certification by the device manufacturer instead of using tools like HelloOX2 or CrackCertificate (see Chapter B).

44

4 Analyzing Mobile Phones

In the following sections we conduct the analysis of the provided smartphones with the help of the tools we developed in Chapter 3. The mobile devices which will be analyzed have been purchased especially for this purpose, to a large extent by auction on eBay by the professorship. The Symbian OS smartphones come from the pool of test devices from T-Mobile. They were kindly provided to us by T-Mobile for the purposes of this diploma thesis. Due to data privacy protection issues it became necessary to remove the following sections from the published version of this diploma thesis.

45

4.1. Summary

4.1. Summary Within this chapter the tool, which we developed within this diploma thesis, has been tested on various mobile phones. At the beginning we analyzed several Nokia 3510i from Series40. In this context we noticed that in many cases the telephone book, as well as the saved SMS could not be restored. We assume that the reason for this lies in the fact that during the many years having passed after the lastly found use, another SIM card had been inserted into the phone. This has led to an over-writing of the former entries by new blank ones. In addition, it attracted our attention that in many cases incomplete entries have been found when dealing with the call logs. In this case, various reasons can be imagined. We think that the reason is the volatility of the memory, as the mobile phones had not been activated for 3-4 years on average. This implies that also no power supply took place. Within a further Chapter we have tested a Nokia 6800. The speciality of this phone lies in the existence of a fully-fledged QWERTZ keyboard in addition to the standard mobile phone keyboard. When dealing with this phone we were able to recover many data, however the phenomena of incomplete call logs could have been found here, as well. We analyzed a Nokia E61 in the last Section of this chapter. This mobile phone constitutes the only Symbian OS smartphone which has been analyzed in the scope of this diploma thesis. Moreover, this was the single case where we created the memory dump with the help of the software agent as a creation with Twister Box is not possible when dealing with Symbian OS smartphones. For an overview of the results of the analysis please refer to Table 4.1.

83

84 Handheld Inform. all part.a part.c part.d part.e part.f

SMS (saved) 6 0 0 0 4 2

SMS (cached) 43 42 40 39 15 —

Phone book Entries 20 0 0 0 18 12

b

Call Logs out. / rec. / mis. 19 / 10 / 8 19 / 9 / 9 20 / 10 / 9 16 / 7 / 8 17 / 7 / 6 —/—/—

Files jpg / Java / midi 17 / 9 / 2 0/3/0 0/3/0 15 / 9 / 0 22 / 5 / 39 1 / xg / —

Table 4.1.: Summary of the analysis of the mobile phones of Chapter 4

351476809025999 351354809256353 351476800630193 353787001185003 351476809025999 351476809025999

IMEI

We could not recover the startup message. We could only recover the ICCID partially. c We could not recover the startup message. d We could not recover the startup message. e We could not recover the startup message. f We could only recover the IMEI and the software version. g Many program files could be found in ‘C:/SYS/bin’. h We could recover these information by using the Twister Box dump and the wrapper class.

a

Smartphone Type Nokia 3501i Nokia 3501i Nokia 3501i Nokia 3501i Nokia 6800 Nokia E61

Calendar Entries 13 1 15 9 29 5

SIM Inform. all part.b all all all allh

4. Analyzing Mobile Phones

5 Secure Deletion

In the following chapter we outline the possibilities and problems of ‘secure deletion’. ‘Secure deletion’ refers to the deletion of data on a smartphone in such a way so that those data cannot be restored during a later investigation. In order to guarantee the complete deletion of data it would be necessary to use a tool which enables the user to access the memory chip directly in order to overwrite the address space of existing data with 0xFF. However, this approach is not possible when dealing with smartphones due to several reasons. One the one hand, the user’s activities are restricted by measures of safety on the device which implies that those far-reaching system interventions cannot be conducted. On the other hand, writing on a specific physical address is hindered due to the use of flash chips ‘wear levelling’ [55; 56] which are intended to optimize durability. In Section 5.1 we explain the different wear levelling techniques and the implied consequences for our approach. First, we will outline general approaches of wear levelling followed by a technique which is used in more recent Nokia smartphones. This is followed by the implementation of our own secure deletion tool for Symbian phones in Section 5.2. In the last section of this chapter we try to verify our tool by means of a Nokia E90 communicator.

5.1. Wear Levelling For wear levelling, a memory controller provides interchanging such banks over the lifetime of the memory1 at times when it is detected that they are receiving 1

At some point, after one hundred thousand or more cycles, so much voltage or time is required to either program or erase the cell, or both, that it becomes impractical to use it any further. The lifetime of that cell has at this point ended.

85

5. Secure Deletion significantly uneven use. The exact procedure of those operations is described in the following. In Figure 5.1 we schematically depict the memory operation techniques. Here, the storage space is separated into single blocks whereby those blocks again consist of several blocks. If the user sends now data which are attached to a logical address, this logical address is converted in an address translation table into a physical memory address, i.e. in a block within the bank.

Figure 5.1.: Schematical illustration of ways in which the solid state memory may be operated [8] This address translation table can be reprogrammed by a processing unit in order to change the physical address of the block in which data are intended to be stored. The process of reprogramming is used to lade the whole memory equally often with writing operations. In order to do such reprogramming, information on storage characteristics and storage occupancy are collected. Therefore, the number of writing operations on each storage block is stored. If it is the case that this number exceeds the average value of the other blocks by a certain amount, the wear levelling process will be started. When wear levelling is accomplished, two main events occur. First of all, data of the heavily used blocks are swapped with the data of those blocks which are least used. In a second step the address translation table is modified in a way so that the new physical addresses are connected to the old logical ones.

86

5.1. Wear Levelling Consequently, a data block having the same logical address as prior to wear levelling is now written on another physical address than beforehand. In Figure 5.2 we show the process of wear levelling by means of a process flow diagram. In this diagram the process of wear levelling is initialized by the system. This initialization can either be started by a system service or by a memory controller. The further process is mostly identical to the already described one, except for the point that here it is worked with a spare bank. Data of the least used bank are written on the spare bank and data of the heavy used bank are now written on the least used bank which in turn is now empty. In another step the heavy used bank is converted to the new spare bank. The following process is now again identical to the previously described one.

Figure 5.2.: Flow diagram showing a preferred operation of the memory system [8] Those two figures make clear that there exist various approaches for the execution of wear levelling. However, all approaches have the intention of regular wear of the storage spaces. Regarding to Symbian OS Internals [57] and Sam-

87

5. Secure Deletion sung [58] Nokia uses in its current device series (e.g.: N-Series) Samsung OneNAND [59] storage with a modification of the already described wear levelling techniques. In this case no swapping of data on the blocks is conducted due to time reasons; instead, a delete- and write-operation is saved. This happens by the storage of the erase-count of each block. If we would now like to write on a block, having a higher count than one of the non-used blocks, the block which has not been used up to now is deleted and the write operation is done on that block. The real selected block is now marked as non-used and shifted to the so-called ‘garbage queue’ which is ordered downwards after the erasecount. If at a later point in time a block for writing is needed, its erase-count is compared to the block on first position of the queue, and the block with the lowest erase-count is chosen for the writing operation. There are two methods of deleting data stored on blocks within the garbage queue. The first approach is, that data will be deleted when the block is inserted into the queue, when using the other approach data will be deleted as soon as the block leaves this queue and is then re-used for storing new data. Samsung does not want to tell us which approach they use in their OneNAND chip.

Despite the tremendous effort for keeping the flash storage in good order consistently, a large number of advantages can be found when compared to an other memory chip as for example hard disks. Those advantages include their non-volatility, speed, ease of erasure and reprogramming, small physical size and the fact that there are no mechanical moving parts like in hard disks.

5.2. Secure Deletion on Symbian Phones

In order to develop a tool for securely deleting data on a smartphone we have resorted to the programming language Python within the context of this diploma thesis. Concretely, we used Python for S60 [60] (also known as pyS60) available in Version 1.4.5. The Python for S60 platform simplifies application development and provides a scripting solution for the Symbian C++ APIs.

Within this diploma thesis we have developed a tool named ‘SecDel’ which currently possesses the ability to delete SMS messages, telephone directories as well as calendar entries (see Figure 5.3). Moreover, it contains an updatefunction which allows the user to load modules which are developed in the future via the Internet later on.

88

5.2. Secure Deletion on Symbian Phones

Figure 5.3.: SecDel overview In the following we depict the secure deletion of telephone book entries exemplarily and in detail. When deleting calendar entries and SMS messages we have only focused on specialities in contrast, as the remaining procedure is very similar. The contacts module offers an API to address book services allowing the creation of contact information databases. The contacts module represents a Symbian contact database as a dictionary-like ‘ContactDB’ object, which contains ‘Contact’ objects and which is indexed using the unique IDs of those objects [54]. As we show in Listing 5.1 the ‘ContactDB’ is opened and the unique ID and the entry title is read out of all entries with the help of a loop after the flash of an information message. Both parts are then consolidated into one list element. 1 2 3 4 5 6 7 8 9 10

11 12 13 14 15

16

def s e a r c h C o n t a c t s ( ) : appuifw . note ( u ” s e a r c h i n g C o n t a c t s . . . ” , ” i n f o ” ) db = c o n t a c t s . open ( ) l i s t 3 = [] f o r d b i d in db : i d = s t r ( db [ d b i d ] . i d ) t i t l e = db [ d b i d ] . t i t l e element = ( i d + ” − ” + t i t l e ) l i s t . append ( element ) s e l e c t i o n = appuifw . m u l t i s e l e c t i o n l i s t ( l i s t , ’ checkbox ’ , 1) f o r k in s e l e c t i o n : c o n t a c t i d = l i s t [ k ] . s p l i t ( ” ” ) [0] contact id = int ( contact id ) # change v a l u e kind = [ ’ c i t y ’ , ’ company name ’ , ’ c o u n t r y ’ , ’ d a t e ’ , ’ d t m f s t r i n g ’ , ’ e m a i l a d d r e s s ’ , ’ fax number ’ , ’ j o b t i t l e ’ , ’ note ’ , ’ pager number ’ , ’ phone number ’ , ’ po box ’ , ’ p o s t a l a d d r e s s ’ , ’ p o s t a l −code ’ , ’ s t a t e ’ , ’ s t r e e t a d d r e s s ’ , ’ u r l ’ , ’ video number ’ , ’ p i c t u r e ’ , ’ second name ’ , ’ v o i p ’ , ’ s i p i d ’ , ’ personal ringtone ’ , ’ share view ’ , ’ p r e f i x ’ , ’ s u f f i x ’ , ’ push to talk ’ , ’ locationid indication ’ , ’ l a s t n a m e ’ , ’ f i r s t n a m e ’ , ’ mobile number ’ ] f o r t y p e in kind :

89

5. Secure Deletion

f o r i in range ( 0 , 1 0 ) : try : i f db [ c o n t a c t i d ] . f i n d ( t y p e ) [ i ] . v a l u e : db [ c o n t a c t i d ] . f i n d ( t y p e ) [ i ] . v a l u e = u ” XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX ” except : continue # delete contact db . d e l i t e m ( c o n t a c t i d ) appuifw . note ( u ” C o n t a c t d e l e t e d ! ” , ” c o n f ” )

17 18 19 20

21 22 23 24 25

Listing 5.1: Secure deletion of contacts used in SecDel After such a list element has been created of each of the telephone book entries, it is saved in a list. Then a ‘Multi-Selection-Listbox’ is created with the help of this list. This listbox (see Figure 5.4) enables the search for entries and the marking of several entries in order to delete those all at once.

Figure 5.4.: SecDel select contacts which should be deleted Within the next step the script separates the ID of the selected list entries from the title in order to search the whole entries in the database again. If the corresponding entry is found, all existing objects within this entry, no matter how often they occur, are overwritten with a sign chain, consisting of 59 times ‘X’. We have chosen the length of 59 due to the fact that this is the maximal allowed length of characters which is available for the longest of the available objects. We conduct this step in order to make sure that none of the characters of the initially entry is still available afterwards. (In Figure 5.5 we depict an entry of the telephone’s address book which has been overwritten in the above described way.) After a successful overwriting of the objects of all previously chosen entries those are deleted from the database with the command in line 24 (Listing 5.1). This is communicated to the user in another message. A particularity exists when we deal with calendar entries or notes. Here the stored dates and times as well as the point of time of reminders are either

90

5.2. Secure Deletion on Symbian Phones

Figure 5.5.: SecDel contact entry after renaming it deleted completely or reset to the 01.01.1970, 00:00 o’clock by the in Listing 5.2 shown code fragment. In addition, repeated events are converted to unique events before they are deleted from the database, too. 1 2 3 4 5 6 7

db2 [ c a l e n d a r i d ] . s e t r e p e a t ( None ) i f ( db2 [ c a l e n d a r i d ] . t y p e == ” note ” ) : # c l e a r d a t e and t i m e db2 [ c a l e n d a r i d ] . s e t t i m e ( None ) else : # s e t d a t e t o 01.01.1970 db2 [ c a l e n d a r i d ] . s e t t i m e ( 0 , 0)

Listing 5.2: Code excerpt of SecDel which changes the date and time values As a further module, we have included an update-function (see Listing 5.3) by which it is possible to load future modules and extensions via an Internet connection belatedly. In order to determine whether a new version of the tool is available, a connection to the server is established. Then, the version number of the currently installed tool is compared to the version number in the third line of the script. If the version number of the script on the server is higher than the one on the smartphone, the complete script is read character-by-character and the currently used one is overwritten by the new one. The user is informed by a message whether the update has been successful. 1 2 3 4 5 6 7 8 9 10

11

def update ( ) : # i n i t i a l values FOLDER = u ”C : \ \ Python \\ ” CODE = ” s e c d e l . py ” # c h e c k i f new v e r s o n i s a v a i l a b l e f c u r r e n t = f i l e ( u ”C : \ \ Python \\ s e c d e l . py ” , ” r ” ) c u r r e n t v e r s i o n = f c u r r e n t . r e a d l i n e s ( ) [ 3 ] . s p l i t ( ”#” ) [ 1 ] f c u r r e n t . close () current version = int ( current version ) n e w v e r s i o n = u r l l i b . u r l o p e n (URL + CODE) . r e a d l i n e s ( ) [ 3 ] . s p l i t ( ”#” ) [ 1 ] new version = i n t ( new version )

91

5. Secure Deletion

i f ( new version > c u r r e n t v e r s i o n ) : code = u r l l i b . u r l o p e n (URL + CODE) . read ( ) f = f i l e (FOLDER + CODE, ”w” ) f . write ( code ) f . close () appuifw . note ( u ” Updated s u c c e s s f u l l y ! ” , ” c o n f ” ) p r i n t ” SecDel updated s u c c e s s f u l l y ! ” else : appuifw . note ( u ”No update a v a i l a b l e ! ” , ” c o n f ” ) p r i n t ” SecDel i s a l l r e a d y t h e newest v e r s i o n ! ”

12 13 14 15 16 17 18 19 20 21

Listing 5.3: Build-in update functionality of SecDel As a last additional update we have included a remote service function. It happens sometimes that one loses his smartphone, or that it becomes stolen. Until now most often one could only hope that the important data stored on the phone are not used by the finder or thief. For this case, we have developed this function. If SecDel is kept active in the background it analyzes every SMS message in the inbox regarding a certain sequence. If the phone now receives a SMS message with the sequence ‘run secdel’, the tool will start with the immediate deletion of all data described above. This is done with the help of a callback function which has been implemented in PyS60. The inbox object’s bind() function binds a callback function to an event that is generated by an incoming message. In our case, the function msg rec() is called up as soon as a new SMS is received on the smartphone (see Listing 5.4). 1 2

box = inbox . Inbox ( ) box . bind ( msg rec )

3 4 5 6 7

def msg rec ( msg id ) : box = inbox . Inbox ( ) i f box . c o n t e n t ( msg id ) == ” r u n s e c d e l ” : appuifw . note ( u ” remote SecDel orderd v i a SMS” )

Listing 5.4: Excerpt of build-in remote deletion functionality

5.3. Verification The operations we have mentioned in Section 5.2 have been tested on a Nokia E90 (see Figure 5.6) with the Symbian OS version 9.2 installed. For the verification of secure deletion on this generation of smartphones, currently only few technological possibilities exist. The reason lies in the fact that Symbian has introduced security restrictions (also called Capabilities [6] which disable any foreign access to all important private files. In order to get to those storage spaces, we need an ‘All Files’ capability by which our software agent becomes certified (compare [41]). The ‘All files’ capability is one of the Manufacturerapproved capabilities which are highly sensitive capabilities that can only be

92

5.4. Summary

Figure 5.6.: Nokia E90 obtained from the device manufacturer, even if it is just for experimenting on your own phone. Getting these capabilities requires you to justify why you need them, and to have an ACS Publisher ID from Verisign [54]. Due to the reasons stated above we had to resort to a smartphone using an older Symbian version for the purpose of verification. When using older Symbian versions, the stated security restrictions had not been implemented yet. For this purpose we used a Nokia N70 and the tool MIAT which we have already mentioned in Section 2.1.2. After comprehensive tests, we received notice that the tool is not able to restore any deleted data, as well. Within the data, which had been saved with the help of MIAT, we could neither find data which had been deleted by the Symbian interface, nor were data detectable which had been deleted by the tool SecDel. In addition, the tool Panoptes which has been developed within this diploma thesis does not give any further results concerning this aspect. Without any doubt, the most perfect solution for the verification of the in Section 5.2 depicted operations and the thereby used wear levelling technic of the memory element, would be the de-soldering of the flash-storage and the subsequent direct analysis of this element. Unfortunately, we were not given the possibility to do so which is why we resorted to the approaches presented beforehand. However, those approaches are questionable from a forensic perspective.

5.4. Summary Within this chapter we presented the various influences which are related to secure deletion. At the beginning we explained the different kinds of wear levelling, used for flash-storages, within Section 5.1. In general, wear levelling describes the possibility of extending the economic life-time of a flash-storage by exchanging blocks on which data are used very frequently with those on which data are used less frequently. By this process it is tried to equally burden

93

5. Secure Deletion the whole storage element with writing operations in order to prevent deficiencies within single sections. In this context, various approaches exist. In most cases, those differ only in the handling of data which are stored on the blocks which should be swapped. When dealing with current Nokia smartphones, those blocks are deleted completely before it is written on those again. This leads to the problem that reading out file fragments in the so-called slack space2 , as it is known from Windows, cannot be done. Subsequently, we presented a tool which tries to delete personal data on the smartphone securely. This means that data are deleted in such a way, that restoring them is not possible, but can not be guaranteed either. In addition, the tool offers, thanks to a remote plugin, the option to delete private data (saved SMS messages, calendar entries, or the telephone book) if the phone is lost or thieved. To do so, one can send a simple SMS message from another phone to the lost one, in order to get private data deleted. Unfortunately, we were not able to verify the depicted deleting operations in a forensically correct way due to the fact that we did not possess the needed means. We could only prove with the help of the tools MIAT and Panoptes that deleted data are not contained in the files intended for storage any longer. Due to this reasons the tool does not constitute a tool for ‘secure deletion’ but rather for ‘more secure deletion’. The combination of overwriting of the data and the subsequent deletion of them on the operating system level on the one hand, as done by SecDel, and the wear levelling process on the memory level on the other hand, as done by the build in flash modules, significantly increase the difficulty to restore these data.

2

The unused space in a disk cluster. Some file systems use fixed-size clusters. Even if the actual data being stored requires less storage than the cluster size, an entire cluster is reserved for the file. The unused space is called the slack space.

94

6 Analyzing the SIM

According to Smith [61] a subscriber identity module (SIM) is a smart card that is designed to fit into mobile phones. It provides the identification of a user to a network, allowing him or her to access such services as telephony, email, internet, and text messaging. According to the ISO standard 7816 [62] the SIM card contains a microcomputer as well as a certain amount of memory to process commands (RAM), and to store user files on an electrically erasable programmable read only memory (EEPROM). The SIM also contains an amount of read only memory (ROM) which stores the cards’ operating system. When the SIM card is activated, the microcomputer loads the operating system from the ROM into the RAM of the card and processes commands as requested by the mobile equipment or card access device. Within Section 6.1 we will, first of all, describe the functionality of a SIM card within a GSM network, the SIM card’s structure as well as the contained data in detail. Afterwards, we deal with the technics which can be used for analyzing such a SIM card in Section 6.2. For that purpose two tools which are currently available on the market will be taken into consideration. The tools we apply are SIMspy [1] and SIMbrush [63] which offer different approaches for analysis.

6.1. GSM and the SIM The global system for mobile communications (GSM) network offers authentication of subscriber identity to the network, file access conditions and data confidentiality of the whole data transfer process. In order to guarantee this, the network and the mobile phone own a secret key ki. This key has a length of 128bit and is saved on the user’s SIM card. While registering at the GSM network, the mobile phone receives a random number, known as challenge, from which the mobile phone calculates an authentication-token SRES with the help of ki. Afterwards, this is sent back to

95

6. Analyzing the SIM the network. Following, the network compares the received SRES with a value calculated on its own beforehand. In the mean time a value kc is calculated which is afterwards used for the encryption of subsequent traffic. The micro-computer located on the SIM card administers the access control on the secured area [11]. This area is overwritten by 0xFF during deletion. Using this procedure, it is guaranteed that also the slack-space does not contain any old data. Due to this fact the forensic examination is strongly limited as only currently existent data can be read out. Only data like the location information (LOCI), which are not shown to the user, can give further information about the last residence of the suspected to the investigator. file/data Phase SST ICCID LP SPN MSISDN AND FDN LND EXT1 EXT2 GID1 GID2 SMS SMSP SMSS CBMI PUCT ACM ACMmax HLPMNSP PLMNsel FPLMN CCP ACC IMSI LOCI BCCH Ki AD

decription Phase ID SIM Service Table Serial Number Prefered Language Service Provider Name Mobile Subscriber International ISDN Number Short Dial Numbers Fixed Numbers Last Dialed Numbers Dialling Extension 1 Dialling Extension 2 Groups 1 Groups 2 SMS Text Messages SMS Text Message Parameters SMS Text Message Status Preferred Network Message Charges Per Unit Charge Counter Charge Limit HPLMN Search Period PLMN Sector Forbidden PLMN’s Capability Configuration Parameters Access Control Class International Mobile Subscriber Identity Location Information Broadcast Control Channels subscriber-specific symmetric cyphering key Administration Data

length in bytes 1 5 10 var 17 var var var var var var var var n * 176 var var var 5 3 3 var var 12 14 2 9 11 16 128 var

Table 6.1.: Content of the SIM [11] In the above printed Table 6.1 we show the data which are normally saved on

96

6.2. Data Acquisition the SIM. We explain some data which have a major importance to the investigator in the following: • IMSI: subscriber id used for (GSM internal) international unique identification of subscriber which consists of ‘mobile country code’, ‘mobile network code’ and ‘mobile subscriber identification number’ • MSISDN: subscriber phone number associated with SIM which consists of ‘country code’,‘national destination code’ and ‘subscriber number’. The ‘national destination code’ identifies network provider and home location register (HLR). • LND: for the last dialed numbers up to 10 slots are reserved on the SIM. The length of each entry is variable. Modern smartphones store the LND local on the phone and do not use this memory area. • LOCI: sums up to 11 byte whereby the bytes five to nine show the location area identifier (LAI). Most times this area is larger than one cell which is why it can only indicate the rough location of the user. The most recently used cell cannot be detected on the SIM. • SMS: for SMS 12 slots are reserved on the SIM. The first byte specifies the status1 . The following bytes 2 to 175 contain the actual message coded with TPDU2 . Modern smartphones normally store the SMS messages local on the phone or on a memory card and do not use this memory area on the SIM card.

6.2. Data Acquisition In order to read out the data which we have mentioned in the previous section from the SIM, we need a smartcard reader which is supported by Microsofts’ Smart Card API (application program interface) [64] (for the use with Windows OS) or one which is supported by the PCSC-light package [65] (for the use with Linux OS). For our purpose, we will make use of a ASEDrive IIIe as seen in Figure 6.1. Moreover, a corresponding tool which carries out the decoding of stored data must be at hand. For the latter some solutions exist in the scope of open source. With two of them, SIMspy [1] and SIMbrush [63], we deal below. 1

0 = mobile terminated message unused or deleted; 1 = mobile terminated message read; 11 = mobile terminated message not read; 101 = mobile originated message sent; 111 = mobile originated message not sent 2 TPDU component consisting of: ISDN of the service center, ISDN of the sender, date and time of the service center, ISDN or directory entry of receiver and the message coded in PDU)

97

6. Analyzing the SIM

Figure 6.1.: ASEDrive IIIe USB V2 Smartcard reader [9]

SIMspy enables the user after the correct enter of the PIN to view and decode all stored data. The user is offered a logging function which records all data in binary form including the date and time. We have depicted this subsequently in extracts in Listing 6.1.

1 2 3 4 5 6 7 8

2009−07−31−19:49 SendPduToCard | S t a r t S e n d | SELECT FILE A0A40000023F00 2009−07−31−19:49 SendPduToCard | R e s u l t | 2 5 b y t e s o f r e s p o n s e data a v a i l a b l e 2009−07−31−19:49 SendPduToCard | S t a r t S e n d | GET RESPONSE A0C0000019 2009−07−31−19:49 SendPduToCard | R e s u l t | 0 0 00 03 0F 3F 00 01 00 00 FF FF 01 0C 11 04 07 06 00 83 8A 83 8A 00 80 8A 90 00

Listing 6.1: Logging function of SIMspy

With respect to the above mentioned program we should not forget that this program has not been developed for a forensic use. Due to that reason neither a reporting function nor another possibility to export or save results is existent. Moreover, the tool operates directly on the SIM which can lead to the fact that data become changed during analysis. In contrast, a major focus has been put on a clear depiction of results and the direct decoding of data. We have shown the excerpts for data like location information and service provider, as well as SIM specific data In Figure 6.2 exemplarily. The decoded directory entries which are stored on the SIM can be viewed in Figure 6.3.

98

6.2. Data Acquisition

Figure 6.2.: Extract from the SIM data with the help of SIMspy [1]

Figure 6.3.: Extract from the SIM register with the help of SIMspy [1]

99

6. Analyzing the SIM A Perl-Script is offered as an extension (see Listing A.1) which converts the on the SIM stored ‘HomeZone’ data from Gauss-Krueger-coordinates into GPScoordinates in order to provide an exact localization of this area. As a further alternative the tool SIMBrush, which is developed by Antonio Savoldi and Paolo Gubian, can be used for analyzing the SIM. This tool works best under a Linux OS and offers a forensic analysis of data stored on the SIM. For an analysis with the help of SIMbrush it is necessary that we have profound knowledge about the structure of a SIM card. The SIM card incorporates a file system which possesses a hierarchical structure. The root is referred to as master file (MF). Within the subjacent levels two different kinds of data are included. Those are on the one hand the directories which are known as dedicated files (DF) , and on the other hand the real files which are named elementary files (EF). The major difference of the two data types is constituted by the fact that DF only contain a header, whereby EF include a header and a body, as well. The headers contain all security information as well as meta information (e.g. length of a record, number of direct children). In contrast, the body contains information related to the application. Now we can start the tool SIMbrush in order to conduct an analysis of a SIM card. After a successful request of SIMbrush, we receive an information output on the terminal showing the initialization sequence. This sequence ends with the SIM card sending an answer to Reset (ATR) (see Figure 6.4). Its primary purpose is to indicate the status of the smart card power-up sequence. It also conveys information which the reader requires in order to optimize the speed of communication between the reader and the card. The total length of the ATR sequence is limited to 33 bytes (The ATR must adhere to the structure specified by ISO 7816-3 [62]). Within our tests the card status has unfortunately never been recognized but has been reported as ‘unknwon state: 20034’.

Figure 6.4.: SIM card status and ATR In a following step we are asked about the authentication mode. We can choose whether we would like to analyze a small part of saved data or the complete SIM card. We start this process by entering the valid PIN. Simultaneously, the authentication status of the single security codes is depicted as shown in Figure 6.5. Our further results of the analysis are all based on the variant with successful authentication.

100

6.2. Data Acquisition

Figure 6.5.: Authentication status of the SIM card Consecutively, we are asked which memory dump depiction we would like to receive (see Figure 6.6). If we choose the ‘FULL acquisition’ resulting in a XML file (this file contains all data in raw format), all standard as well as non-standard files, which can be found on the SIM card, will be included. In contrast, if we choose the ‘PARTIAL acquisition’, only the files according to ETSI 100-977 standard [66]will be included in the resulting XML file.

Figure 6.6.: Possible acquisition modes for SIMbrush At the end of the dumping process, we will receive a short summary (see Figure 6.7. Therein, also the time needed for the creation of a complete memory dump is stated (123 minutes). This time period tremendously differs from the time needed to create a partial dump which is only 8 seconds.

Figure 6.7.: Summary of the acquisition After a successful completion of the memory dump we receive a file named ‘image.xml’, containing raw data from the complete SIM card in XML format. The

101

6. Analyzing the SIM subsequent step for us is to translate this image with the wrapper tools, in order to convert the extracted data in an intelligible form. There are two wrapper tools which deal with the interpretation part: the first tool, wrapper simple.pl, is able to convert the primary image, that is the XML file which is the result of the binary copy of the SIM’s contents, into a comprehensible format. Only the Standard Elementary Files will be converted by this tool. The second tool wrapper dom.pl translates all standard data and non standard data. For the latter, only the header is translated, being unknown the coding for nonstandard elementary files. The second tool also generates a file named fat file in.txt, representing the ‘file allocation table’ related with the SIM card. 1 2

3 4 5 6

EFICCID ’ 2FE2 ’ ( ICC I d e n t i f i c a t i o n ) : T h i s EF p r o v i d e s a unique i d e n t i f i c a t i o n number f o r t h e SIM . 89 49 22 20 85 16 15 09 92 5F ###Germany

Listing 6.2: Excerpt of the generated XML file We depict the ICCID of the SIM card in Listing 6.2 to give an example of the, with the help of wrapper dom.pl generated, XML file. We can translate this into ‘2085161509925’. In Listing 6.3 we show an excerpt from the file allocation table3 . Within this excerpt the hex value 0x2F 0xE2 represents the storage address of the ICCID on the SIM card, the 10 at the end of the line represents the size in byte. The values ALW, NEV und ADM describe the security restrictions of this storage address in the following order: SELECT, GET RESPONSE, READ BINARY, READ RECORD, CHANGE. They have, according to Savoldi [63], the following meanings4 : • ALW: the command is always executable on the file; • NEV: the command is never executable on the file; • ADM: allocation of these levels is a responsibility of the administrative authority which has issued the card: the card provider or the telephone provider which gives the card to its subscriber;

1

8 & 2FE2 & ICCID & EF & ALW, NEV , NEV ,ADM,ADM & t r a n s p a r e n t & 10

Listing 6.3: Excerpt of the file allocation table

3 4

The complete file allocation table can be viewed in Section A A detailed description of all occurring values is stated in the paper of Antonio Savoldi and Paolo Gubian [63].

102

6.3. Summary

6.3. Summary Within this chapter we described the structure of a SIM card according to the ISO 7816 standard with the three storages areas: ROM, RAM, and EEPROM, whereby the last one is used to store data. Afterwards, we dealt with the major functions of the SIM card within a GSM network. This included authentication of subscriber identity to the network, file access conditions, as well as data confidentiality of the whole data transfer process. Following, we have outlined the data, which are stored on a SIM card, and we have presented those data which are of major importance to the investigator in detail; this included for example the IMSI (subscriber ID used for international unique identification of subscriber) or the LOCI (location information). Within the last section we have explained two tools which allow to analyze SIM cards. In this context, we think that SIMspy is a well structured and easy-touse tool which unfortunately directly operates on the memory card and which does not allow for a creation of a report concerning found data. In contrast, we were able to identify the forensic background clearly when dealing with SIMbrush. This tool compiles a complete, or partial, dump of the SIM card and does a translation of all found data afterwards. We consider the most important advantage in the fact that the complete analysis is done on a memory dump and not on the SIM card itself. Moreover, depending on the purpose, we are allowed to read out non-typical storage spaces, as well. This prevents hiding data on the SIM card. The results are presented as a XML file. This guarantees a simple processing of all reports, no matter of which kind they are. We considered the high degree of knowledge needed for evaluating the analysis results, when compared to SIMspy, the only disadvantage of SIMbrush.

103

6. Analyzing the SIM

104

7 Conclusion and Future Work

In this final chapter we conclude this work, starting with a short summary in Section 7.1 to recapitulate what we have learned from the last chapters. In Section 7.2 we discuss some limitations and drawbacks of our analysis system and our developed software agent. Section 7.3 highlights remaining improvements that could be the scope of future work at this project. In Section 7.4 we draw our final conclusion.

7.1. Summary Within this diploma thesis we have developed a wrapper class which automatically analyzes memory dumps of Series40 phones which have been created with the help of Twister Box beforehand. In addition, we developed a software agent for Symbian smartphones which allows us to dump secured data from a Symbian smartphone and analyze them later subsequently. This step has become necessary due to the fact that the Twister Box is not able to create complete memory dumps when dealing with Symbian OS mobile phones. Further, we developed SecDel, a Python script solution, which is intended to securely delete data on Symbian phones. First of all, this approach overwrites existent data with many ‘X’ ; afterwards those entries are deleted. In addition, an option to start this tool remotely is included, which allows to delete private or business data on a phone by sending a special SMS message to the smartphone. Within subsequent chapters we tested software solutions being currently available on the market, with respect to their strengths and weaknesses. Those tools are intended for both, the analysis of SIM cards, as well as the analysis of mobile phones. In this context we recognized that many of those tools are not intended for a forensic purpose due to their procedures in securing data and handling the internal memory of the analyzed smartphones.

105

7. Conclusion and Future Work

7.2. Limitations The wrapper class, which has been developed within Section 3.3, is modularly build, thereby offering the possibility to adapt to further mobile phones. We tested it with phones of the first generation of Series40, therefore the wrapper class is adapted to those in particular. Due to this reason problems may occur when analyzing newer Series40 phones, if saved data are stored in different blocks. We developed the software agent described in Section 3.4 for the current Symbian version 9.2 3rd edition. Nevertheless, it can be used for smartphones of older Symbian versions, if differing certificates are used. In this case it is only necessary that the corresponding Python interpreter is changed. Due to the reasons we explained in Chapter 5.1, the tool we present within this section does not constitute a real ‘secure deletion’ as it cannot be guaranteed that the storage controller writes back to the desired locations from which it has read beforehand. Therewith it might be possible to restore the data partly or even completely by dismantling and analyzing the memory block. However, the latter depends largely on the used wear levelling method on the flash memory chip assembled in the smartphone.

7.3. Future Work It has to be pointed out, that after the finish of this diploma thesis, still some points of research and development should receive some further investigation. In this context we have identified the following aspects: The currently limited scope of operation of the wrapper class should be continuously amended by further Series40 phones in order to keep the developed tool up-to-date. This approach ensures the lasting attractiveness of the tool. When further developing the software agent Panoptes, we should emphasize the integration of capability deactivation or evasion. This makes sure that it can be used for future Symbian versions without resorting to extensions from third party developers. Moreover, the development should be done from a forensic perspective, in order to make sure that the software agent does not change any data or storage areas on the mobile device. In this context, a possible solution would be, for example, the direct installation on a memory chip and the subsequent start of the agent if the memory chip is inserted into the device. Here, the agent should be ‘invisible’ for the operating system. The anaylsis of the data found with the help of Panoptes could become simplified or partly automated, as well. This would ease the investigator’s work, thereby allowing also less trained investigators to conduct analyses. With respect to the secure deletion tools, which we have developed within Section 5.2, further research could be done in the field of the verification of those. Here, one could de-solder the flash memory chip with the help of adequate

106

7.4. Conclusion hardware, and afterwards read it out directly in order to assess the way by which the system overwrites data and conducts wear levelling.

7.4. Conclusion The field of mobile phone forensic is still unexplored. From this results the fact that only few appropriate tools for forensic analysis are yet available. Therefore we decided to take on the task of developing a tool, which facilitates the automatic analysis of Nokia Series40 phones memory dumps. Simultaneously, we developed a solution to backup secured data from current Symbian phones despite the existing security restrictions. The reason for this is that we do not want to further use the devices during analysis as to guarantee data integrity.In order to verify the scope of operation of our tool, we conducted the analysis which are described in Chapter 4. Those show that our approaches are fully operational, and, as far as it is technically realizable, operate in a forensically correct manner. After we discovered during our analyses that many data on the phones can be restored despite its obvious deletion, we went on to develop a solution which securely deletes data on the device. The resulting tool SecDel provides as an extension the function to delete data from a smartphone remote, as well. Nowadays, this constitutes an important function for business people, although this aspect has been neglected by many mobile phone manufacturers. Unfortunately, we were not able to verify this tool up to the storage level, due to technical circumstances.

107

7. Conclusion and Future Work

108

A Appendix

Dumping a Nokia Series40 Phone • After having connected the Twister Box with the mobile device, we open the HWK Software from SarasSoft • As a first step within this Software (see Figure A.1) we confirm the connection establishment to the Twister Box by pressing the button ‘Connect’ • Following we chose the Register ‘DCT4’ if we are dealing with a Series40 mobile phone • Then, we chose the corresponding device typ within the dropdown list ‘Product’ (for Nokia phones, a label with the identification can be found underneath the battery) • With the help of the button ‘Rd PM’ we read out the Permanent Memory from the phone and create thereby our own memory dump for further analysis • In a last step we chose the storage spaces which should be read out for the dump. In our tests we found out that the area from 0 to 255 is the maximum span which can be read out.

109

A. Appendix

Figure A.1.: TwisterBox DCT4 flash window 110

Converter for Gauss - Krueger Coordinates 1 2 3 4 5 6

7 8 9 10 11 12 13 14 15 16

#! / u s r / b i n / p e r l # # C o n v e r t e r f o r Gauss − K r u e g e r c o o r d i n a t e s . # # The f o r m u l a s a r e b a s e d on a s i m i l a r windows−program . # Thanks t o N o r b e r t H o e t t i s c h f o r s e n d i n g me t h e n e c c e s s a r y information . # # T h i s program i s l i c e n s e d under t h e GPL . # # ( c ) 2000 A n d re a s A c h t z e h n ( achtzehn@linux −s o c i e t y . de ) # N o b e r t H o e t t i s c h ( nobbi@nobbi . com ) $s=@ARGV[ 0 ] ; i f ( $s eq ”−−h e l p ” ) { print ” −− Gauss−C o n v e r t e r −− T h i s program c o n v e r t s Gauss−Krueger c o o r d i n a t e s i n t o l o n g i t u d e and l a t i t u d e .

17 18 19

Usage : g a u s s . p l c o o r d i n a t e [map | maplwp ] g a u s s . p l −−h e l p : t h i s h e l p s i t e

20 21 22 23 24

map : Download map o f t h e a r e a u s i n g wget maplwp : Download map u s i n g t h e LWP : : UserAgent I recommend t o use \” maplwp \ ” . I f your p e r l doesn ‘ t s u p p o r t i t , t r y :

25 26 27

˜ p e r l −MCPAN −e s h e l l cpan> i n s t a l l LWP : : UserAgent

28 29

30

31

32

33

The c o o r d i n a t e can be e i t h e r a v a l i d Gauss−Krueger c o o r d i n a t e (14 c h a r a c t e r s ) or a VIAG c o o r d i n a t e (12 c h a r a c t e r s ) t r a n s m i t t e d on CB 221 within the German Viag Interkom network . For f u r t h e r d e t a i l s on t h i s transmission o f Gauss−Krueger−c o o r d i n a t e s i n t h e German Viag Interkom network s e e h t t p : / /www. h e i s e . de / c t / Redaktion / bo / mobilfunk .

34 35

36

37 38 39 40 41 42

( c ) 2000 Andreas Achtzehn ( achtzehn \ @linux−s o c i e t y . de −−> 333665574946) Thanks t o Nobert H o e t t i s c h ( nobbi \@nobbi . com) f o r t h e sourcecode o f h i s window\$−program . \ n ”; e x i t (0) ; } i f ( l e n g t h ( $s )==12) { $ s r=s u b s t r ( $s , 0 , 6 ) ∗10;

111

A. Appendix

43 44 45 46 47 48 49 50 51 52 53 54 55 56

57 58 59 60 61 62 63 64

65 66 67 68 69 70

71 72

73 74

75

76 77 78 79 80 81 82 83 84 85 86 87 88 89

$sx=s u b s t r ( $s , 6 , 6 ) ∗10; p r i n t ”−− VIAG c o o r d i n a t e −−\n ” ; p r i n t ” l a t i t u d e p a r t : $ s r \n ” ; p r i n t ” l o n g i t u d e p a r t : $sx \n ” ; } i f ( l e n g t h ( $s )==14) { $ s r=s u b s t r ( $s , 0 , 7 ) ; $sx=s u b s t r ( $s , 7 , 7 ) ; p r i n t ”−− Gauss−Krueger c o o r d i n a t e −−\n ” ; p r i n t ” l a t i t u d e p a r t : $ s r \n ” ; p r i n t ” l o n g i t u d e p a r t : $sx \n ” ; } i f ( ! ( l e n g t h ( $s )==14) && ! ( l e n g t h ( $s )==12)) { p r i n t ” I n v a l i d c o o r d i n a t e . C o o r d i n a t e must be e i t h e r 12 ( VIAG ) or 14 (GAUSS) c h a r a c t e r s . \ n ” ; p r i n t ” See . / g a u s s . p l −−h e l p f o r d e t a i l s . \ n\n ” ; e x i t (0) ; } &potsdam ; &modolensky ; i f (@ARGV[ 1 ] eq ”map” ) {&download ; } i f (@ARGV[ 1 ] eq ” maplwp ” ) {&downloadlwp ; } i f (@ARGV[ 1 ] eq ” ” ) { p r i n t ” \n\n−− Map has not been downloaded . See g a u s s . p l −−h e l p f o r d e t a i l s . −−\n ” ; } sub potsdam { # E r r e c h n e n d e r P o s i t i o n nach Potsdam−K o o r d i n a t e n s y s t e m $bm = i n t ( $ s r /1000000) ; $y = $sr −($bm∗1000000+500000) ; $ s i = $sx /111120.6196; $px = $ s i +0.143885358∗ s i n (2∗ $ s i ∗0.017453292) +0.00021079∗ s i n (4∗ $ s i ∗0.017453292) +0.000000423∗ s i n (6∗ $ s i ∗0.017453292) ; $t = ( s i n ( $px ∗0.017453292) ) / ( cos ( $px ∗0.017453292) ) ; $v = s q r t (1+0.006719219∗ cos ( $px ∗0.017453292) ∗ cos ( $px ∗0.017453292) ) ; $ys = ( $y∗ $v ) /6398786.85; $ l a t = $px−$ys ∗ $ys ∗57.29577∗ $ t ∗ $v∗ $v ∗(0.5 − $ys ∗ $ys ∗(4.97 −3∗ $ t ∗ $ t ) /24) ; $d l = $ys ∗57.29577/ cos ( $px ∗0.017453292) ∗ (1−$ys ∗ $ys /6∗( $v ∗$v +2∗$ t ∗ $t−$ys ∗ $ys ∗(0.6+1.1∗ $ t ∗ $ t ) ∗(0.6+1.1∗ $ t ∗ $ t ) ) ) ; $lon = $bm∗3+$dl ; $ph =i n t ( $ l a t ) ; $pz =( $ l a t −$ph ) ∗60; $pm =i n t ( $pz ) ; $ps =($pz−$pm) ∗60; $l h =i n t ( $lon ) ; $ l z =($lon−$ lh ) ∗60; $lm =i n t ( $ l z ) ; $ l s =($lz −$lm ) ∗60; p r i n t ”−− C o o r d i n a t e i n German Potsdam System −−\n ” ; p r i n t ” L a t i t u d e : $ph ◦ $pm ’ $ps \” ” ; p r i n t ” ( $ l a t ) \n ” ; p r i n t ” L o n g i t u d e : $ lh ◦ $lm ’ $ l s \” ” ; p r i n t ” ( $lon ) \n ” ;

112

90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111

112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134

135

} sub modolensky { $ p o t s d a = 6377397.155; $wgs84 a = 6378137.0; $ p o t s d f = 1/299.152812838; $wgs84 f = 1/298.257223563; $ p o t s d e s = 2∗ $ p o t s d f − $ p o t s d f ∗ $ p o t s d f ; $potsd dx = 606.0; $potsd dy = 23.0; $potsd dz = 413.0; $ p i = 3.141592654; $ l a t r = $ l a t /180∗ $ p i ; $ l o n r = $lon /180∗ $ p i ; $sa = s i n ( $ l a t r ) ; $ca = cos ( $ l a t r ) ; $so = s i n ( $ l o n r ) ; $co = cos ( $ l o n r ) ; $bda = 1−$ p o t s d f ; $ d e l t a a = $wgs84 a − $ p o t s d a ; $ d e l t a f = $wgs84 f − $ p o t s d f ; $rn = $ p o t s d a / s q r t (1− $ p o t s d e s ∗ s i n ( $ l a t r ) ∗ s i n ( $ l a t r ) ) ; $rm = $ p o t s d a ∗ ((1− $ p o t s d e s ) / s q r t (1− $ p o t s d e s ∗ s i n ( $ l a t r ) ∗ s i n ( $ l a t r )∗1− $ p o t s d e s ∗ s i n ( $ l a t r ) ∗ s i n ( $ l a t r )∗1− $ p o t s d e s ∗ sin ( $ l a t r )∗ sin ( $ l a t r ) ) ) ; $ t a = (− $ p o t s d d x ∗ $sa ∗ $co − $ p o t s d d y ∗ $sa ∗ $so )+$ p o t s d d z ∗ $ca ; $tb = $ d e l t a a ∗ ( ( $rn ∗ $ p o t s d e s ∗ $sa ∗ $ca ) / $ p o t s d a ) ; $ t c = $ d e l t a f ∗($rm/ $bda+$rn ∗$bda ) ∗ $sa ∗ $ca ; $ d l a t = ( $ t a+$tb+$ t c ) /$rm ; $dlon = (− $ p o t s d d x ∗ $so + $ p o t s d d y ∗ $co ) / ( $rn ∗ $ca ) ; $wgs84lat = ( $ l a t r + $ d l a t ) ∗180/ $ p i ; $wgs84lon = ( $ l o n r + $dlon ) ∗180/ $ p i ; $ph=i n t ( $wgs84lat ) ; $pz=($wgs84lat−$ph ) ∗60; $pm=i n t ( $pz ) ; $ps=i n t ( ( $pz−$pm) ∗60) ; $ lh=i n t ( $wgs84lon ) ; $ l z =($wgs84lon−$l h ) ∗60; $lm=i n t ( $ l z ) ; $ l s=i n t ( ( $lz −$lm ) ∗60) ; p r i n t ” \n\n−− C o o r d i n a t e i n WGS84 system −−\n ” ; p r i n t ” L a t i t u d e : $ph ◦ $pm ’ $ps \” ” ; p r i n t ” ( $wgs84lat ) \n ” ; p r i n t ” L o n g i t u d e : $ lh ◦ $lm ’ $ l s \” ” ; p r i n t ” ( $wgs84lon ) \n ” ; } sub download { i f ( $wgs84lat > 10) { $wgs84lat = s u b s t r ( $wgs84lat , 0 , 6 ) ; } e l s e { $wgs84lat = s u b s t r ( $wgs84lat , 0 , 5 ) ; } i f ( $wgs84lon > 10) { $wgs84lon = s u b s t r ( $wgs84lon , 0 , 6 ) ; } e l s e { $wgs84lon = s u b s t r ( $wgs84lon , 0 , 5 ) ; }

136

113

A. Appendix

$bef = ” wget −q \” h t t p : / /www. mapblast . com/ g i f ?&CT= $wgs84lat : $wgs84lon :20000& IC=$wgs84lat : $wgs84lon : 8 : &W=456&H=259&FAM=m y b l a s t&LB=\”; mv g i f ∗ map . g i f ” ; system ( $bef ) ; p r i n t ” \n\n−− Map downloaded and saved t o map . g i f −−\n ”

137

138 139

140 141 142

143

144 145 146

147 148 149

150

} sub downloadlwp { i f ( $wgs84lat > 10) { $wgs84lat = s u b s t r ( $wgs84lat , 0 , 6 ) ; } e l s e { $wgs84lat = s u b s t r ( $wgs84lat , 0 , 5 ) ; } i f ( $wgs84lon > 10) { $wgs84lon = s u b s t r ( $wgs84lon , 0 , 6 ) ; } e l s e { $wgs84lon = s u b s t r ( $wgs84lon , 0 , 5 ) ; } r e q u i r e LWP : : UserAgent ; $ua = new LWP : : UserAgent ; $ a n f r a g e = ” h t t p : / /www. mapblast . com/ g i f ?&CT=” . $wgs84lat . ” : ” . $wgs84lon . ” :20000& IC=” . $wgs84lat . ” : ” . $wgs84lon . ” : 8 : &W=456&H=259&FAM=m y b l a s t&LB=” ; $ r e q u e s t = new HTTP : : Request ( ’ GET ’ , $ a n f r a g e ) ; $ r e s p o n s e = $ua−>r e q u e s t ( $ r e q u e s t , ’ map . g i f ’ ) ; p r i n t ” \n\n−− Map downloaded and saved t o map . g i f −−\n ” }

Listing A.1: PERL script to convert Gauss-Krueger coordinates [1]

114

File Allocation Table of Analyzed SIM Card ID 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48

Memory Position 3F00 0000 0002 0003 0005 0007 2FD1 2FE2 7F10 6F3A 6F3B 6F3C 6F3D 6F40 6F42 6F43 6F44 6F4A 6F4B 7F20 0001 6F05 6F07 6F11 6F12 6F13 6F14 6F15 6F16 6F17 6F18 6F20 6F30 6F31 6F37 6F38 6F39 6F41 6F45 6F46 6F52 6F53 6F74 6F78 6F7B 6F7E 6FAD 6FAE

Name MF NS NS NS NS NS NS ICCID DFTELECOM ADN FDN SMS CCP MSISDN SMSP SMSS LND EXT1 EXT2 DFGSM NS LP IMSI NS NS NS NS NS NS NS NS KC PLMNsel HPLMN ACMmax SST ACM PUCT CBMI SPN KcGPRS LOCIGPRS BCCH ACC FPLMN LOCI AD PHASE

File Type MF EF EF EF EF EF EF EF DF EF EF EF EF EF EF EF EF EF EF DF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF

Privileges

Structure

— NEV,NEV,NEV,NEV,NEV ALW,NEV,NEV,NEV,NEV ALW,NEV,NEV,NEV,NEV ALW,NEV,NEV,NEV,NEV NEV,NEV,NEV,NEV,NEV ADM,ADM,NEV,ADM,ADM ALW,NEV,NEV,ADM,ADM — CHV1,CHV1,NEV,CHV2,CHV2 CHV1,CHV2,NEV,ADM,ADM CHV1,CHV1,NEV,ADM,ADM CHV1,CHV1,NEV,ADM,ADM CHV1,CHV1,NEV,ADM,ADM CHV1,CHV1,NEV,ADM,ADM CHV1,CHV1,NEV,ADM,ADM CHV1,CHV1,NEV,ADM,ADM CHV1,CHV1,NEV,ADM,ADM CHV1,CHV2,NEV,ADM,ADM — NEV,NEV,NEV,NEV,NEV ALW,CHV1,NEV,NEV,NEV CHV1,ADM,NEV,CHV1,ADM CHV1,CHV1,NEV,NEV,NEV CHV1,CHV1,NEV,NEV,NEV CHV1,CHV1,NEV,NEV,NEV CHV1,ADM,NEV,NEV,NEV CHV1,CHV1,NEV,NEV,NEV CHV1,ADM,NEV,NEV,NEV CHV1,CHV1,NEV,NEV,NEV CHV1,ADM,NEV,NEV,NEV CHV1,CHV1,NEV,ADM,ADM CHV1,CHV1,NEV,ADM,ADM CHV1,ADM,NEV,ADM,ADM CHV1,CHV2,NEV,ADM,ADM CHV1,ADM,NEV,ADM,ADM CHV1,CHV2,CHV1,ADM,ADM CHV1,CHV2,NEV,ADM,ADM CHV1,CHV1,NEV,ADM,ADM ALW,ADM,NEV,ADM,ADM CHV1,CHV1,NEV,ADM,ADM CHV1,CHV1,NEV,ADM,ADM CHV1,CHV1,NEV,ADM,ADM CHV1,ADM,NEV,ADM,ADM CHV1,CHV1,NEV,ADM,ADM CHV1,CHV1,NEV,CHV1,ADM ALW,ADM,NEV,ADM,ADM ALW,ADM,NEV,ADM,ADM

— transparent transparent transparent transparent transparent linear fixed transparent — linear fixed linear fixed linear fixed linear fixed linear fixed linear fixed transparent cyclic linear fixed linear fixed — transparent transparent transparent transparent linear fixed transparent transparent transparent transparent linear fixed transparent transparent transparent transparent transparent transparent cyclic transparent transparent transparent transparent transparent transparent transparent transparent transparent transparent transparent

115

Size (byte) — 72 3 16 16 25 86 10 — 6000 300 4400 42 150 132 2 300 65 13 — 16 4 9 1 93 1 8 18 2 120 10 9 192 1 3 10 30 5 20 17 9 14 16 2 12 11 3 1

A. Appendix

49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83

7F21 0001 6F05 6F07 6F11 6F12 6F13 6F14 6F15 6F16 6F17 6F18 6F20 6F30 6F31 6F37 6F38 6F39 6F41 6F45 6F46 6F52 6F53 6F74 6F78 6F7B 6F7E 6FAD 6FAE 7F43 6F60 6F61 6F62 6F63 6F64

NS NS LP IMSI NS NS NS NS NS NS NS NS KC PLMNsel HPLMN ACMmax SST ACM PUCT CBMI SPN KcGPRS LOCIGPRS BCCH ACC FPLMN LOCI AD PHASE NS PLMNwACT OPLMNwACT HPLMNwACT CPBCCH INVSCAN

DF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF DF EF EF EF EF EF

— NEV,NEV,NEV,NEV,NEV ALW,CHV1,NEV,NEV,NEV CHV1,ADM,NEV,CHV1,ADM CHV1,CHV1,NEV,NEV,NEV CHV1,CHV1,NEV,NEV,NEV CHV1,CHV1,NEV,NEV,NEV CHV1,ADM,NEV,NEV,NEV CHV1,CHV1,NEV,NEV,NEV CHV1,ADM,NEV,NEV,NEV CHV1,CHV1,NEV,NEV,NEV CHV1,ADM,NEV,NEV,NEV CHV1,CHV1,NEV,ADM,ADM CHV1,CHV1,NEV,ADM,ADM CHV1,ADM,NEV,ADM,ADM CHV1,CHV2,NEV,ADM,ADM CHV1,ADM,NEV,ADM,ADM CHV1,CHV2,CHV1,ADM,ADM CHV1,CHV2,NEV,ADM,ADM CHV1,CHV1,NEV,ADM,ADM ALW,ADM,NEV,ADM,ADM CHV1,CHV1,NEV,ADM,ADM CHV1,CHV1,NEV,ADM,ADM CHV1,CHV1,NEV,ADM,ADM CHV1,ADM,NEV,ADM,ADM CHV1,CHV1,NEV,ADM,ADM CHV1,CHV1,NEV,CHV1,ADM ALW,ADM,NEV,ADM,ADM ALW,ADM,NEV,ADM,ADM — CHV1,ADM,ADM,ADM,ADM CHV1,CHV1,ADM,ADM,ADM CHV1,CHV1,ADM,ADM,ADM CHV1,CHV1,ADM,ADM,ADM CHV1,CHV1,ADM,ADM,ADM

— transparent transparent transparent transparent linear fixed transparent transparent transparent transparent linear fixed transparent transparent transparent transparent transparent transparent cyclic transparent transparent transparent transparent transparent transparent transparent transparent transparent transparent transparent — transparent linear fixed linear fixed linear fixed linear fixed

Table A.1.: SIMbrush generated file allocation table of analyzed SIM card

116

— 16 4 9 1 93 1 8 18 2 120 10 9 192 1 3 10 30 5 20 17 9 14 16 2 12 11 3 1 — 123 84 84 84 84

XML Report Schemata 1 2 3 4 5

6 7 8 9 10 11 12 13 14

Cached SMS messages

Listing A.2: XML-schemata for cached SMS messages 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

Calendar e n t r i e s

Listing A.3: XML-schemata for calendar entries 1 2 3 4 5 6 7 8 9 10 11

C a l l l o g e n t r i e s

117

A. Appendix

12

13

14

15 16 17 18



Listing A.4: XML-schemata for call logs 1 2 3 4 5 6 7 8 9 10

11 12

13

14

15 16 17 18

Saved c o n t a c t s

Listing A.5: XML-schemata for saved contacts 1 2 3 4 5

6 7 8 9 10 11 12 13

Handheld and SIM c a r d i n f o r m a t i o n s

118

14 15



Listing A.6: XML-schemata for handheld and SIM card infos 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

SMS messages

Listing A.7: XML-schemata for saved SMS messages 1 2 3 4 5 6 7 8 9 10 11

12 13 14 15

URL e n t r i e s

Listing A.8: XML-schemata for URL entries

119

A. Appendix

120

B Source Code

The complete source code of the implementation and all needed packages are provided on the CD delivered with this document.

121

B Bibliography

1 N. H¨ uttisch, “SIMspy II,” http://www.nobbi.com/download.html#simspy, 2009. ¨ berwachungsmaß2 Bundesnetzargentur, “Statistik der strafprozessualen u nahmen der telekommunikation,” http://www.bundesnetzagentur.de/, 2008. 3 A. Distefano and G. Me, “An overall assessment of mobile internal acquisition tool,” Digital Investigation, vol. 5, pp. 121–127, 2008. 4 Provider of cell phone forensic solutions to law enforcement and the security professionals. [Online]. Available: http://www.bkforensics.com/ 5 Series 40 Platform: Introductory White Paper, 3rd ed., Nokia, November 2008. 6 Symbian Press, “Plattform security.” 7 A. Savoldi and P. Gubian, “Data recovery from Windows CE based handheld devices,” in Advances in digital forensics, vol. IV, 2008, pp. 219–230. 8 K. M. Lofgren, R. D. Norman, G. B. Thelin, and A. Gupta, “Wear leveling techniques for flash EEPROM systems,” United States Patent, April 2008. 9 Athena Smartcard Solutions. (2009, April) ASEDrive IIIe USB V2 Smart Card Reader. [Online]. Available: http://www.athena-scs.com/product. asp?pid=1 10 Bundeskriminalamt, “statistical data of telephone and SIM-card analysis conducted by the german BKA,” Personal Communication, July 2009.

123

Bibliography 11 Digital cellular telecommunications system (Phase 2+); Specification of the Subscriber Identity Module - Mobile Equipment (SIM-ME) interface (3GPP TS 51.011 version 4.15.0 Release 4), European Telecommunications Standards Institute (ETSI), 2005. 12 (2009, February) mobile telephone market increases 2009 up to 6.6 percent. [Online]. Available: http://www.zdnet.de/news/ wirtschaft unternehmen business bitkom mobilfunkmarkt waechst 2009 um 6 6 prozent story-39001020-41000202-1.htm 13 J. H. Schiller, Mobile Communications. Edition.

Addison-Wesley, 2003, vol. Second

14 G. Palmer, “A road map for digital forensic research,” First Digital Forensic Research Workshop, Tech. Rep., August 2001. 15 R. Ayers, W. Jansen, N. Cilleros, and R. Daniellou, “Cell phone forensic tools: An overview and analysis,” National Institute of Standards and Technology NIST, Tech. Rep., October 2005. 16 P. Copeland, “Phone-forensics,” http://www.phone-forensics.com/, 2009. 17 “The official sarasbox webside,” http://www.sarasbox.com/, 2009. 18 (2009, September) Ftdi 232 bm usb to serial chip. [Online]. Available: http://www.vanguard-co.com/contents/product/accessories portal/ integrated circuit/ftdi232.htm 19 Digital cellular telecommunications system (Phase 2+); at command set for GSM mobile equipment (me)., European Telecommunications Standards Institute (ETSI), 1999. 20 P. Megowan, D. Suvak, and D. Kogan, “Irda object exchange (OBEX) protocol,” Infrared Data Association, Tech. Rep., 1999. 21 Kot and Zoltan. (2009, http://gnokii.org/

July) gnokii project. [Online]. Available:

22 P. M. Mokhonoana and M. S. Olivier, “Acquisition of a symbian smart phone’s content with an on-phone forensic tool,” Information and Computer Security Architectures Research Group, Tech. Rep., 2007. 23 F. Dellutri, V. Ottaviani, and G. Me, “MIAT-WM5: Forensic acquisition for windows mobile pocketpc,” Universita degli Studi di Roma, Tech. Rep., 2008. 24 M. Breeuwsma, M. de Jongh, C. Klaver, R. van der Knijff, and M. Roeloffs, “Forensic data recovery from flash memory,” SMALL SCALE DIGITAL DEVICE FORENSICS JOURNAL, vol. 1, no. 1, June 2007. 25 M. Breeuwsma, “Forensic imaging of embedded systems using JTAG,” Digital Investigation, vol. 3, no. 1, pp. 32–42, 2006.

124

Bibliography 26 Apple iPhone and iPod touch: About backups. [Online]. Available: http://support.apple.com/kb/HT1766 27 J. A. Zdziarski, iPhone Forensics: Recovering Evidence, Personal Data and Corporate Assets. O’Reilly Media, September 2008, vol. 1. 28 J. Varsalone, Macintosh OS X, iPod, and iPhone Forensic Analysis DVD Toolkit. Syngress Media, 2009. 29 (2009, August) X-ways software technology ag. [Online]. Available: http://www.winhex.com/security/ 30 (2009, August) Blackbag technologies inc. [Online]. Available: //www.blackbagtech.com/

http:

31 I. M. Baggili, R. Mislan, and M. Rogers, “Mobile phone forensics tool testing: A database driven approach,” International Journal of Digital Evidence, vol. 6, no. 2, 2007. 32 B. Williamson, P. Apeldoorn, B. Cheam, and M. McDonald, “Forensic analysis of the contents of nokia mobile phones,” School of Computer and Information Science Edith Cowan University, Tech. Rep., 2006. 33 MyGnokii - Gammu - Free tools and software for cellular devices and phones. [Online]. Available: http://www.gammu.org/ 34 Digital cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications System (UMTS); AT command set for User Equipment (UE) (3GPP TS 27.007 version 8.5.0 Release 8), European Telecommunications Standards Institute (ETSI), 2008. 35 Oxygen forensic suite 2 by oxygen software. [Online]. Available: http://www.oxygen-forensic.com/ 36 Nokia Series 40 Platform. [Online]. Available: http://www.forum.nokia. com/Technology Topics/Device Platforms/Series 40/ 37 T. Badura, “Security analysis of symbian os platform security architecture(psa),” Master’s thesis, Universit¨ at Mannheim, September 2008. 38 S. Babin and S. McNabb, Developing Software for Symbian OS: A Beginner’s Guide to Creating Symbian OS V9 Smartphone Applications in C++. Wiley and Sons, 2007, vol. 2. 39 Symbian Press, “S60 developers guide.” 40 C. Heath, A. Harker, and G. Preston, Symbian OS Platform Security: Software Development Using the Symbian OS Security Architecture. Wiley and Sons, 2006. 41 Symbian Press, “A guide to symbian signed.”

125

Bibliography 42 Microsoft Corporation. Windows CE overview. [Online]. Available: msdn2.microsoft.com/en-us/library/ms899235.aspx 43 ——. Remote API 2 (RAPI2). [Online]. Available: msdn2.microsoft.com/ en-us/library/aa920150.aspx 44 J. A. Zdziarski, “iphone forensics demonstration,” http://www.oreillynet. com/pub/e/949, 2009. 45 Technical note TN1150 - HFS+ volume format. [Online]. Available: http://developer.apple.com/technotes/tn/tn1150.html 46 M. Lutz, Programming Python.

O’Reilly, September 2001.

47 3rd Generation Partnership Project; Technical Specification Group Terminals; Technical realization of the Short Message Service (SMS); (Release 6), European Telecommunications Standards Institute (ETSI), 2004. 48 Digital cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications System (UMTS); Use of Data Terminal Equipment - Data Circuit terminating Equipment (DTE-DCE) interface for Short Message Service (SMS) and Cell Broadcast Service (CBS) (3GPP TS 27.005 version 8.0.0 Release 8), European Telecommunications Standards Institute (ETSI), 2008. 49 Digital cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications System (UMTS); LTE; Technical realization of Short Message Service (SMS) (3GPP TS 23.040 version 8.4.0 Release 8), European Telecommunications Standards Institute (ETSI), 2009. 50 “Online pdu encoder and decoder,” http://twit88.com/home/utility/ sms-pdu-encode-decode, 2009. 51 (2009, April) Java me. [Online]. Available: http://java.sun.com/products/ cldc/ 52 M. Hamilton, “Python htmlgen,” http://www.linuxjournal.com/article/ 2986, 2009. 53 J. Ylanen. (2009, September) ensymble - tools to make pys60 applications for symbian s60 phones. [Online]. Available: http: //code.google.com/p/ensymble/ 54 J. Scheible and V. Tuulos, Mobile Python: Rapid Prototyping of Applications on the Mobile Plattform. Wiley, October 2007, vol. 1st. 55 M. Assar, S. Nemazie, and P. Estakhri, “Flash memory mass storage architecture incorporation wear leveling techniques,” United States Patent, December 1995. 56 S.-W. Han, “Flash memory wear leveling system and method,” United States Patent, January 2000.

126

Bibliography 57 (2009, September) Symbian OS internals. [Online]. Available: //developer.symbian.org/wiki/index.php/Symbian OS Internals/

http:

58 Flash Software Group, “XSR1.5 wear leveling,” Samsung Electronics Co., Ltd, Tech. Rep., 2007. 59 (2009, September) SAMSUNG OneNANDTM . [Online]. Available: http://www.samsung.com/global/business/semiconductor/ products/fusionmemory/Products OneNAND.html 60 PyS60 Library Reference, 1st ed., Nokia, Dezember 2008. 61 G. Smith, “General characteristics of the subscriber identity module file system,” 2008, published in Phone-Forensics Forum. 62 CardWerk. (2009, April) Identification cards - integrated circuit cards with contacts. [Online]. Available: http://www.cardwerk.com/smartcards/ smartcard standard ISO7816.aspx 63 A. Savoldi and P. Gubian, “SIM and USIM filesystem: a forensics perspective,” University of Brescia, Tech. Rep., 2007. 64 Microsoft Developer Network. (2009, September) Smart card api. [Online]. Available: http://msdn.microsoft.com/en-us/library/dd627646(VS. 85).aspx 65 ALioth debian. (2009, September) Middleware to access a smart card using scard api (pc/sc). [Online]. Available: https://alioth.debian.org/projects/ pcsclite/ 66 Specification of the Subscriber Identity Module - Mobile Equipment (SIM - ME) interface. (ETSI TS 100-977 v8.3.0), European Telecommunications Standards Institute (ETSI). 67 C. Adams, A. Whitledge, and S. Shenoi, “Legal issues pertaining to the use of cell phone data,” in Advances in digital forensics, vol. IV, 2008, pp. 231– 243.

127