Investigation USIM EFs and Service Table

There has been so much going on over the past year and with research and testing I haven't posted as much as I would like. The growth areas in the variety of methods and tools for logical data and physical data extraction, harvesting and examination; impact that apps and malware might have on evidence; wireless options available on smartphones and tablets changing the way traditional cell site analysis can be conducted; and the generally the explosion in mobile information and standards needing to be absorbed and understood has been mind-blowing to say the least. These and other matters have consumed my time and the casualty has been fewer posts at the blog. However, from all the work and research I will endeavour to post here, hopefully, useful examination and investigative information on areas that may have either become outdated or evolved such that particular methods applied or tools used could be out-of-date or updated.

USIM (UICC) Cards memory storage and network/user files have seen a massive increase since 2010. Just have a look back at a post in 2010 I made here at trewmte.blogspot and compare the EFUST (elementary files usim service table) in TS 31.102 back then 3g-usim-2g-sim-service-numbers.html compared to the latest releases 12 ( 31_series/31.102/31102-ca0.zip ) and 13 ( 31.102/31102-d20.zip )

The first thing an examiner might wish do first thing in the morning at work is check whether the USIM reader tool is up-to-date. Have a look at the EFUST list and list of elementary files below and check that your reader has the capability to detect, extract and harvest data from these files. Then ask yourself do you actually understand when they are allocated and activated in a USIM what use is made of them? What evidence maybe harvested from them? How would the acquired data assist investigations in the following categories as they would apply to the use of mobile communications?

i)                    Contract Law

ii)                  Tort Law

iii)                Intellectual Property Law

iv)                Criminal (including the new Cybercrime) Law

v)                  Data Protection Law

vi)                Taxation Law

vii)              Computer Law

viii)            Communications Law

ix)                Internet Law

x)                  Etc.

EFUST
Service n°1: Local Phone Book
Service n°2: Fixed Dialling Numbers (FDN)
Service n°3: Extension 2
Service n°4: Service Dialling Numbers (SDN)
Service n°5: Extension3
Service n°6: Barred Dialling Numbers (BDN)
Service n°7: Extension4
Service n°8: Outgoing Call Information (OCI and OCT)
Service n°9: Incoming Call Information (ICI and ICT)
Service n°10: Short Message Storage (SMS)
Service n°11: Short Message Status Reports (SMSR)
Service n°12: Short Message Service Parameters (SMSP)
Service n°13: Advice of Charge (AoC)
Service n°14: Capability Configuration Parameters 2 (CCP2)
Service n°15: Cell Broadcast Message Identifier
Service n°16: Cell Broadcast Message Identifier Ranges
Service n°17: Group Identifier Level 1
Service n°18: Group Identifier Level 2
Service n°19: Service Provider Name
Service n°20: User controlled PLMN selector with Access Technology
Service n°21: MSISDN
Service n°22: Image (IMG)
Service n°23: Support of Localised Service Areas (SoLSA)
Service n°24: Enhanced Multi Level Precedence and Pre emption Service
Service n°25: Automatic Answer for eMLPP
Service n°26: RFU
Service n°27: GSM Access
Service n°28: Data download via SMS-PP
Service n°29: Data download via SMS CB
Service n°30: Call Control by USIM
Service n°31: MO-SMS Control by USIM
Service n°32: RUN AT COMMAND command
Service n°33: shall be set to '1'
Service n°34: Enabled Services Table
Service n°35: APN Control List (ACL)
Service n°36: Depersonalisation Control Keys
Service n°37: Co-operative Network List
Service n°38: GSM security context
Service n°39: CPBCCH Information
Service n°40: Investigation Scan
Service n°41: MexE
Service n°42: Operator controlled PLMN selector with Access Technology
Service n°43: HPLMN selector with Access Technology
Service n°44: Extension 5
Service n°45: PLMN Network Name
Service n°46: Operator PLMN List
Service n°47: Mailbox Dialling Numbers
Service n°48: Message Waiting Indication Status
Service n°49: Call Forwarding Indication Status
Service n°50: Reserved and shall be ignored
Service n°51: Service Provider Display Information
Service n°52 Multimedia Messaging Service (MMS)
Service n°53 Extension 8
Service n°54 Call control on GPRS by USIM
Service n°55 MMS User Connectivity Parameters
Service n°56 Network's indication of alerting in the MS (NIA)
Service n°57 VGCS Group Identifier List (EFVGCS and EFVGCSS)
Service n°58 VBS Group Identifier List (EFVBS and EFVBSS)
Service n°59 Pseudonym
Service n°60 User Controlled PLMN selector for I-WLAN access
Service n°61 Operator Controlled PLMN selector for I-WLAN access
Service n°62 User controlled WSID list
Service n°63 Operator controlled WSID list
Service n°64 VGCS security
Service n°65 VBS security
Service n°66 WLAN Reauthentication Identity
Service n°67 Multimedia Messages Storage
Service n°68 Generic Bootstrapping Architecture (GBA)
Service n°69 MBMS security
Service n°70 Data download via USSD and USSD application mode
Service n°71 Equivalent HPLMN
Service n°72 Additional TERMINAL PROFILE after UICC activation
Service n°73 Equivalent HPLMN Presentation Indication
Service n°74 Last RPLMN Selection Indication
Service n°75 OMA BCAST Smart Card Profile
Service n°76 GBA-based Local Key Establishment Mechanism
Service n°77 Terminal Applications
Service n°78 Service Provider Name Icon
Service n°79 PLMN Network Name Icon
Service n°80 Connectivity Parameters for USIM IP connections
Service n°81 Home I-WLAN Specific Identifier List
Service n°82 I-WLAN Equivalent HPLMN Presentation Indication
Service n°83 I-WLAN HPLMN Priority Indication
Service n°84 I-WLAN Last Registered PLMN
Service n°85 EPS Mobility Management Information
Service n°86 Allowed CSG Lists and corresponding indications
Service n°87 Call control on EPS PDN connection by USIM
Service n°88 HPLMN Direct Access
Service n°89 eCall Data
Service n°90 Operator CSG Lists and corresponding indications
Service n°91 Support for SM-over-IP
Service n°92 Support of CSG Display Control
Service n°93 Communication Control for IMS by USIM
Service n°94 Extended Terminal Applications
Service n°95 Support of UICC access to IMS
Service n°96 Non-Access Stratum configuration by USIM
Service n°97 PWS configuration by USIM
Service n°98 RFU
Service n°99 URI support by UICC
Service n°100 Extended EARFCN support
Service n°101 ProSe
Service n°102 USAT Application Pairing

Particular note: when looking at the EFUST service list above this should not be taken as all the services that may be allocated and activated on modules in a UICC. GSM EFSST (sim service table) has particular services unique to GSM SIM (GSM 11.11), such as Service n°29: Proactive SIM which does not appear in the EFUST list. And if Service n°29: Proactive SIM is important to an investigation (and it can be) it is worth the reminder to look at GSM 11.14 (sim application toolkit) that adds services and most importantly "capabilities" between SIM and smartphone. Perhaps you might think, such as, how this can assist an investigation? My responses is consider (a) man-in-the-middle attacks (b) crime (c) cybercrime.

There has been an abundance in the growth of elementary files, too, in USIM Releases 12/13. The increase in access to varying networks by smartphones and tablets has meant the technical, privacy, commercial and monetisation influences how a subscriber latches and attaches to networks. The relevance being recovered message data for instance requires understanding and identifying how the data got there via which particular network access point etc.

3GPP TS 31.102 V12.10.0 (2016-01)
4 Contents of the Files 18
4.1 Contents of the EFs at the MF level 18
4.2 Contents of files at the USIM ADF (Application DF) level 18
4.2.1 EFLI (Language Indication) 18
4.2.2 EFIMSI (IMSI) 19
4.2.3 EFKeys (Ciphering and Integrity Keys) 20
4.2.4 EFKeysPS (Ciphering and Integrity Keys for Packet Switched domain) 21
4.2.5 EFPLMNwAcT (User controlled PLMN selector with Access Technology) 21
4.2.6 EFHPPLMN (Higher Priority PLMN search period) 22
4.2.7 EFACMmax (ACM maximum value) 23
4.2.8 EFUST (USIM Service Table) 25
4.2.9 EFACM (Accumulated Call Meter) 27
4.2.10 EFGID1 (Group Identifier Level 1) 28
4.2.11 EFGID2 (Group Identifier Level 2) 28
4.2.12 EFSPN (Service Provider Name) 28
4.2.13 EFPUCT (Price per Unit and Currency Table) 29
4.2.14 EFCBMI (Cell Broadcast Message identifier selection) 30
4.2.15 EFACC (Access Control Class) 31
4.2.16 EFFPLMN (Forbidden PLMNs) 31
4.2.17 EFLOCI (Location Information) 32
4.2.18 EFAD (Administrative Data) 33
4.2.19 Void 35
4.2.20 EFCBMID (Cell Broadcast Message Identifier for Data Download) 35
4.2.21 EFECC (Emergency Call Codes) 36
4.2.22 EFCBMIR (Cell Broadcast Message Identifier Range selection) 37
4.2.23 EFPSLOCI (Packet Switched location information) 37
4.2.24 EFFDN (Fixed Dialling Numbers) 39
4.2.25 EFSMS (Short messages) 39
4.2.26 EFMSISDN (MSISDN) 41
4.2.27 EFSMSP (Short message service parameters) 41
4.2.28 EFSMSS (SMS status) 43
4.2.29 EFSDN (Service Dialling Numbers) 43
4.2.30 EFEXT2 (Extension2) 44
4.2.31 EFEXT3 (Extension3) 44
4.2.32 EFSMSR (Short message status reports) 45
4.2.33 EFICI (Incoming Call Information) 45
4.2.34 EFOCI (Outgoing Call Information) 49
4.2.35 EFICT (Incoming Call Timer) 50
4.2.36 EFOCT (Outgoing Call Timer) 50
4.2.37 EFEXT5 (Extension5) 51
4.2.38 EFCCP2 (Capability Configuration Parameters 2) 51
4.2.39 EFeMLPP (enhanced Multi Level Precedence and Pre-emption) 52
4.2.40 EFAaeM (Automatic Answer for eMLPP Service) 53
4.2.41 Void 54
4.2.42 EFHiddenkey (Key for hidden phone book entries) 54
4.2.43 Void 54
4.2.44 EFBDN (Barred Dialling Numbers) 54
4.2.45 EFEXT4 (Extension4) 55
4.2.46 EFCMI (Comparison Method Information) 55
4.2.47 EFEST (Enabled Services Table) 56
4.2.48 EFACL (Access Point Name Control List) 56
4.2.49 EFDCK (Depersonalisation Control Keys) 57
4.2.50 EFCNL (Co-operative Network List) 57
4.2.51 EFSTART-HFN (Initialisation values for Hyperframe number) 59
4.2.52 EFTHRESHOLD (Maximum value of START) 59
4.2.53 EFOPLMNwACT (Operator controlled PLMN selector with Access Technology) 59
4.2.54 EFHPLMNwAcT (HPLMN selector with Access Technology) 60
4.2.55 EFARR (Access Rule Reference) 61
4.2.56 Void 62
4.2.57 EFNETPAR (Network Parameters) 62
4.2.58 EFPNN (PLMN Network Name) 64
4.2.59 EFOPL (Operator PLMN List) 65
4.2.60 EFMBDN (Mailbox Dialling Numbers) 66
4.2.61 EFEXT6 (Extension6) 67
4.2.62 EFMBI (Mailbox Identifier) 67
4.2.63 EFMWIS (Message Waiting Indication Status) 67
4.2.64 EFCFIS (Call Forwarding Indication Status) 69
4.2.65 EFEXT7 (Extension7) 70
4.2.66 EFSPDI (Service Provider Display Information) 70
4.2.67 EFMMSN (MMS Notification) 71
4.2.68 EFEXT8 (Extension 8) 73
4.2.69 EFMMSICP (MMS Issuer Connectivity Parameters) 73
4.2.70 EFMMSUP (MMS User Preferences) 76
4.2.71 EFMMSUCP (MMS User Connectivity Parameters) 77
4.2.72 EFNIA (Network's Indication of Alerting) 77
4.2.73 EFVGCS (Voice Group Call Service) 78
4.2.74 EFVGCSS (Voice Group Call Service Status) 80
4.2.75 EFVBS (Voice Broadcast Service) 80
4.2.76 EFVBSS (Voice Broadcast Service Status) 82
4.2.77 EFVGCSCA (Voice Group Call Service Ciphering Algorithm) 83
4.2.78 EFVBSCA (Voice Broadcast Service Ciphering Algorithm) 84
4.2.79 EFGBABP (GBA Bootstrapping parameters) 84
4.2.80 EFMSK (MBMS Service Keys List) 85
4.2.81 EFMUK (MBMS User Key) 86
4.2.82 Void 87
4.2.83 EFGBANL (GBA NAF List) 87
4.2.84 EFEHPLMN (Equivalent HPLMN) 88
4.2.85 EFEHPLMNPI (Equivalent HPLMN Presentation Indication) 88
4.2.86 EFLRPLMNSI (Last RPLMN Selection Indication) 89
4.2.87 EFNAFKCA (NAF Key Centre Address) 89
4.2.88 EFSPNI (Service Provider Name Icon) 90
4.2.89 EFPNNI (PLMN Network Name Icon) 91
4.2.90 EFNCP-IP (Network Connectivity Parameters for USIM IP connections) 91
4.2.91 EFEPSLOCI (EPS location information) 94
4.2.92 EFEPSNSC (EPS NAS Security Context) 96
4.2.93 EFUFC (USAT Facility Control) 97
4.2.94 EFNASCONFIG (Non Access Stratum Configuration) 98
4.2.95 EFUICCIARI (UICC IARI) 102
4.2.96 EFPWS (Public Warning System) 102
4.2.97 EFFDNURI (Fixed Dialling Numbers URI) 103
4.2.98 EFBDNURI (Barred Dialling Numbers URI) 104
4.2.99 EFSDNURI (Service Dialling Numbers URI) 104
4.2.100 EFIWL (IMEI(SV) White Lists) 105
4.2.101 EFIPS (IMEI(SV) Pairing Status) 106
4.2.102 EFIPD (IMEI(SV) of Pairing Device) 107

4.3 DFs at the USIM ADF (Application DF) Level 108
4.4 Contents of DFs at the USIM ADF (Application DF) level 108
4.4.1 Contents of files at the DF SoLSA level 108
4.4.1.1 EFSAI (SoLSA Access Indicator) 109
4.4.1.2 EFSLL (SoLSA LSA List) 109
4.4.1.3 LSA Descriptor files 112

4.4.2 Contents of files at the DF PHONEBOOK level 113
4.4.2.1 EFPBR (Phone Book Reference file) 113
4.4.2.2 EFIAP (Index Administration Phone book) 115
4.4.2.3 EFADN (Abbreviated dialling numbers) 116
4.4.2.4 EFEXT1 (Extension1) 119
4.4.2.5 EFPBC (Phone Book Control) 120
4.4.2.6 EFGRP (Grouping file) 121
4.4.2.7 EFAAS (Additional number Alpha String) 122
4.4.2.8 EFGAS (Grouping information Alpha String) 123
4.4.2.9 EFANR (Additional Number) 123
4.4.2.10 EFSNE (Second Name Entry) 125
4.4.2.11 EFCCP1 (Capability Configuration Parameters 1) 125
4.4.2.12 Phone Book Synchronisation 126
4.4.2.12.1 EFUID (Unique Identifier) 126
4.4.2.12.2 EFPSC (Phone book Synchronisation Counter) 127
4.4.2.12.3 EFCC (Change Counter) 128
4.4.2.12.4 EFPUID (Previous Unique Identifier) 128
4.4.2.13 EFEMAIL (e-mail address) 129
4.4.2.14 Phonebook restrictions 130
4.4.2.15 EFPURI (Phonebook URIs) 130

4.4.3 Contents of files at the DF GSM-ACCESS level  (Files required for GSM Access) 131
4.4.3.1 EFKc (GSM Ciphering key Kc) 131
4.4.3.2 EFKcGPRS (GPRS Ciphering key KcGPRS) 132
4.4.3.3 Void 132
4.4.3.4 EFCPBCCH (CPBCCH Information) 132
4.4.3.5 EFInvScan (Investigation Scan) 133
4.4.4 Contents of files at the MexE level 134
4.4.4.1 EFMexE-ST (MexE Service table) 134
4.4.4.2 EFORPK (Operator Root Public Key) 134
4.4.4.3 EFARPK (Administrator Root Public Key) 136
4.4.4.4 EFTPRPK (Third Party Root Public Key) 137
4.4.4.5 EFTKCDF (Trusted Key/Certificates Data Files) 138

4.4.5 Contents of files at the DF WLAN level 138
4.4.5.1 EFPseudo (Pseudonym) 138
4.4.5.2 EFUPLMNWLAN (User controlled PLMN selector for I-WLAN Access) 139
4.4.5.3 EFOPLMNWLAN (Operator controlled PLMN selector for I-WLAN Access) 139
4.4.5.4 EFUWSIDL (User controlled WLAN Specific Identifier List) 140
4.4.5.5 EFOWSIDL (Operator controlled WLAN Specific IdentifierList) 141
4.4.5.6 EFWRI (WLAN Reauthentication Identity) 141
4.4.5.7 EFHWSIDL (Home I-WLAN Specific Identifier List) 142
4.4.5.8 EFWEHPLMNPI (I-WLAN Equivalent HPLMN Presentation Indication) 143
4.4.5.9 EFWHPI (I-WLAN HPLMN Priority Indication) 143
4.4.5.10 EFWLRPLMN (I-WLAN Last Registered PLMN) 144
4.4.5.11 EFHPLMNDAI (HPLMN Direct Access Indicator) 144

4.4.6 Contents of files at the DF HNB level 145
4.4.6.1 Introduction 145
4.4.6.2 EFACSGL (Allowed CSG Lists) 145
4.4.6.3 EFCSGT (CSG Type) 148
4.4.6.4 EFHNBN (Home NodeB Name) 150
4.4.6.5 EFOCSGL (Operator CSG Lists) 150
4.4.6.6 EFOCSGT (Operator CSG Type) 152
4.4.6.7 EFOHNBN (Operator Home NodeB Name) 153
4.4.7 Void 153

4.4.8 Contents of files at the DF ProSe level 153
4.4.8.1 Introduction 153
4.4.8.2 EFPROSE_MON (ProSe Monitoring Parameters) 153
4.4.8.3 EFPROSE_ANN (ProSe Announcing Parameters) 154
4.4.8.4 EFPROSEFUNC (HPLMN ProSe Function) 155
4.4.8.5 EFPROSE_RADIO_COM (ProSe Direct Communication Radio Parameters) 156
4.4.8.6 EFPROSE_RADIO_MON (ProSe Direct Discovery Monitoring Radio Parameters) 157
4.4.8.7 EFPROSE_RADIO_ANN (ProSe Direct Discovery Announcing Radio Parameters) 158
4.4.8.8 EFPROSE_POLICY (ProSe Policy Parameters) 158
4.4.8.9 EFPROSE_PLMN (ProSe PLMN Parameters) 160
4.4.8.10 EFPROSE_GC (ProSe Group Counter) 161
4.4.8.11 EFPST (ProSe Service Table) 162
4.4.8.12 EFPROSE_UIRC (ProSe UsageInformationReportingConfiguration) 162

4.5 Contents of Efs at the TELECOM level 166
4.5.1 EFADN (Abbreviated dialling numbers) 166
4.5.2 EFEXT1 (Extension1) 166
4.5.3 EFECCP (Extended Capability Configuration Parameter) 166
4.5.4 EFSUME (SetUpMenu Elements) 166
4.5.5 EFARR (Access Rule Reference) 166
4.5.6 EFICE_DN (In Case of Emergency – Dialling Number) 167
4.5.7 EFICE_FF (In Case of Emergency – Free Format) 167
4.5.8 EFRMA (Remote Management Actions) 168
4.5.9 EFPSISMSC (Public Service Identity of the SM-SC) 168

4.6 Contents of DFs at the TELECOM level 168
4.6.1 Contents of files at the DFGRAPHICS level 169
4.6.1.1 EFIMG (Image) 169
4.6.1.2 EFIIDF (Image Instance Data Files) 170
4.6.1.3 EFICE graphics (In Case of Emergency – Graphics) 171
4.6.1.4 EFLAUNCH SCWS 171
4.6.1.5 EFICON 175

4.6.2 Contents of files at the DFPHONEBOOK under the DFTELECOM 176
4.6.3 Contents of files at the DFMULTIMEDIA level 176
4.6.3.1 EFMML (Multimedia Messages List) 176
4.6.3.2 EFMMDF (Multimedia Messages Data File) 179
4.7 Files of USIM 180

I will leave you to conclude whether you may think USIM has little or no relevance to an investigation.

(U)SIM Examination (Physical) Pt1

(U)SIM Examination (Physical) Pt1

We begin with GSM as this is the original starting place where examiners first learned about subscriber identity modules (SIM). There are many ways to learn about SIM: using a SIM reader tool is one way, receiving instruction during training that concentrates on the types of user and network data that can be harvested by examiners. An education and training process can equally include a training module or modules on the physical aspects of a card and identify, for the examiner, material parts of the SIM, the known routes to understanding electrical aspects, processing aspects, storage geometry and memory mapping, so on and so forth. The thinking here is analogous to the way in which there is an expectation that a computer examiner would understand HDD disc geometry, clusters and sectors, BIOS etc even before entering into the search and study of the 'content' that may be recorded on the disc. It is or should be the same for (U)SIM.

The SIM Card can be seen as a composition of at least three constituent parts:

- The physical card (the storage carrier).
- An integrated circuit card micro-processing chip (the operating system and content storage device).
- The subscriber identity module; an area of physical memory allocated at manufacturing for pre-market and post-market recording by the mobile network operator and SIM user.
 -  A fourth constituent part could be a Card with an etched antenna for RFID/NFC for use by (US)SIM (but this part is not included or discussed at this stage).
- etc

To enable test and inspection of these constituent parts GSM approved and adopted GSM11.17 to assist manufacturers, operators and service providers help formalise and uniform the test and inspection procedures rather than have a mish-mash of randomly selected tests for SIM cards submitted for use in GSM. The former is highly desirable as the goal of GSM has always be about interconnection-compatiblity and interconnection backward-compatibility. By way of illustration, a GSM SIM Card Phase 1 should still be able to be inserted into a GSM Phase 2+ mobile device and allow communications to take place, unless the operator or device manufacturer has declared and stated otherwise.

From an examiner's viewpoint we would desire to know how those three constituent parts translate to the work we do? Some examples are set out below

Physical Card
Due to the form factors used in GSM we can make assessment to determine the supply chain and manufacturer of the card itself. We look at the card to see if has been cut down for use and any attempts of anonymity by removal of the SIM Serial Number (SSN) compared to manufacture polarisation techniques. Later 3G/LTE USIM Cards have undergone some changes since GSM's inception; the latter will be dealt at a later date.


 Image courtesy of wikipedia - http://en.wikipedia.org/wiki/Subscriber_Identity_Module

ICC Chip
Manufacturer and technical specification are important to determine a range of potential evidence, including release into the marketplace and technological and electronic capability. Clearly the geometry and memory mapping are important. There are various techniques to deal with a card with a damaged chip. One example is called 'acid-etching' used to gain access to the physical chip itself by removal of the outer protective coverings used in the manufacturing process. 

 
  Image courtesy of wikipedia - http://en.wikipedia.org/wiki/Subscriber_Identity_Module

Physical Memory
Determining geometry and memory mapping forms part of the testing and inspection process set out in GSM1117. We can use these procedures to formulate a forensic analysis programme, similar to the way in which computer forensic examiners seek to determine specifically data discovered and recovered from a particular memory location on the HDD and define the data from its binary and encoded states and any formatting that may be applicable to the data. That being so, would it be out of the question in SIM examination terms for the EFBCCH file to be formatted as .bmp?  Below are a set of powerpoint slides I have prepared so that examiners can comprehend procedures approved and adopted for test and inspection for GSM SIM Cards. Later on when we 3G/LTE (U)SIM this GSM starting point assists formulate how to identify differences between the various (U)SIM/LTE cards but equally identify expansion of technology services and content so the examination limit or avoid omissions during the investigative/evidential process.      

Considering Clone Test SIM Card Tools

Considering Clone Test SIM Card Tools

There have been a few mentions about clone test Sim Cards at this blog raising observations as to possible issues that may be useful to know.  

Yet further observations examiners may find useful to consider are whether it is necessary for a cloned test SIM Card tool to produce identical files, structure and format for every clone test card produced or whether the make/model of handset can influence e.g. the number of files etc necessary to gain access to a handset's memory? Cust_Files pre-generated on a cloned test card should be included or excluded from consideration regarding the number of GSM/3GPP EFs identified on a cloned test card? The importance, if any, of the evolution in a clone test card's development?

Below are two screen dumps, following examination using just one (U)SIM Card Reader, from two different clone test SIM Cards supplied by different manufacturer with their tools that provide a useful visual indicator when placed in context with the above observations. The observations above and the images below are not published to suggest a problem with a particular clone test SIM Card or tool. The observations are for the purpose should two different examiners use two different clone test SIM Cards and tools to generate evidence which one would be more pertinent for use when accessing memory on a particular handset etc?      

Considering Clone Test SIM Card Tools

Considering Clone Test SIM Card Tools

There have been a few mentions about clone test Sim Cards at this blog raising observations as to possible issues that may be useful to know.  

http://trewmte.blogspot.co.uk/2012/10/to-clone-or-not-to-clone.html
http://trewmte.blogspot.co.uk/2008/11/cloning-test-sim-cards.html

Yet further observations examiners may find useful to consider are whether it is necessary for a cloned test SIM Card tool to produce identical files, structure and format for every clone test card produced or whether the make/model of handset can influence e.g. the number of files etc necessary to gain access to a handset's memory? Cust_Files pre-generated on a cloned test card should be included or excluded from consideration regarding the number of GSM/3GPP EFs identified on a cloned test card? The importance, if any, of the evolution in a clone test card's development?

Below are two screen dumps, following examination using just one (U)SIM Card Reader, from two different clone test SIM Cards supplied by different manufacturer with their tools that provide a useful visual indicator when placed in context with the above observations. The observations above and the images below are not published to suggest a problem with a particular clone test SIM Card or tool. The observations are for the purpose should two different examiners use two different clone test SIM Cards and tools to generate evidence which one would be more pertinent for use when accessing memory on a particular handset etc?      

(U)SIM Examination (Physical) Pt1

(U)SIM Examination (Physical) Pt1

We begin with GSM as this is the original starting place where examiners first learned about subscriber identity modules (SIM). There are many ways to learn about SIM: using a SIM reader tool is one way, receiving instruction during training that concentrates on the types of user and network data that can be harvested by examiners. An education and training process can equally include a training module or modules on the physical aspects of a card and identify, for the examiner, material parts of the SIM, the known routes to understanding electrical aspects, processing aspects, storage geometry and memory mapping, so on and so forth. The thinking here is analogous to the way in which there is an expectation that a computer examiner would understand HDD disc geometry, clusters and sectors, BIOS etc even before entering into the search and study of the 'content' that may be recorded on the disc. It is or should be the same for (U)SIM.

The SIM Card can be seen as a composition of at least three constituent parts:

- The physical card (the storage carrier).
- An integrated circuit card micro-processing chip (the operating system and content storage device).
- The subscriber identity module; an area of physical memory allocated at manufacturing for pre-market and post-market recording by the mobile network operator and SIM user.
 -  A fourth constituent part could be a Card with an etched antenna for RFID/NFC for use by (US)SIM (but this part is not included or discussed at this stage).
- etc

To enable test and inspection of these constituent parts GSM approved and adopted GSM11.17 to assist manufacturers, operators and service providers help formalise and uniform the test and inspection procedures rather than have a mish-mash of randomly selected tests for SIM cards submitted for use in GSM. The former is highly desirable as the goal of GSM has always be about interconnection-compatiblity and interconnection backward-compatibility. By way of illustration, a GSM SIM Card Phase 1 should still be able to be inserted into a GSM Phase 2+ mobile device and allow communications to take place, unless the operator or device manufacturer has declared and stated otherwise.

From an examiner's viewpoint we would desire to know how those three constituent parts translate to the work we do? Some examples are set out below

Physical Card
Due to the form factors used in GSM we can make assessment to determine the supply chain and manufacturer of the card itself. We look at the card to see if has been cut down for use and any attempts of anonymity by removal of the SIM Serial Number (SSN) compared to manufacture polarisation techniques. Later 3G/LTE USIM Cards have undergone some changes since GSM's inception; the latter will be dealt at a later date.


 Image courtesy of wikipedia - http://en.wikipedia.org/wiki/Subscriber_Identity_Module

ICC Chip
Manufacturer and technical specification are important to determine a range of potential evidence, including release into the marketplace and technological and electronic capability. Clearly the geometry and memory mapping are important. There are various techniques to deal with a card with a damaged chip. One example is called 'acid-etching' used to gain access to the physical chip itself by removal of the outer protective coverings used in the manufacturing process. 

 
  Image courtesy of wikipedia - http://en.wikipedia.org/wiki/Subscriber_Identity_Module

Physical Memory
Determining geometry and memory mapping forms part of the testing and inspection process set out in GSM1117. We can use these procedures to formulate a forensic analysis programme, similar to the way in which computer forensic examiners seek to determine specifically data discovered and recovered from a particular memory location on the HDD and define the data from its binary and encoded states and any formatting that may be applicable to the data. That being so, would it be out of the question in SIM examination terms for the EFBCCH file to be formatted as .bmp?  Below are a set of powerpoint slides I have prepared so that examiners can comprehend procedures approved and adopted for test and inspection for GSM SIM Cards. Later on when we 3G/LTE (U)SIM this GSM starting point assists formulate how to identify differences between the various (U)SIM/LTE cards but equally identify expansion of technology services and content so the examination limit or avoid omissions during the investigative/evidential process.      

To Clone or NOT to Clone?

To Clone or NOT to Clone?

The purpose of this article is to reiterate the issues surrounding the best practice model of the forensic examination/data harvesting of mobile telephones and the isolation of radio signals. It’s not the intention of the author to critique any persons/methods or vendors of products/services but merely to highlight the issues which are still apparent today considering such methods have been adopted for well over ten years in the field of mobile phone forensics and which in the opinion of the author are yet to be addressed to a satisfactory level.

Best practice advocates the need to isolate the target device from any communication signal in order to prevent changes in existing live/deleted recoverable data. Bearing this in mind the most common practice is to utilise U/SIM cloning tools and to replicate a working copy of the target U/SIM or in some cases creating a working U/SIM for those target devices where the original U/SIM is not available. The majority or most commonly adopted tools/applications for such a method will only permit the examiner to copy the minimal data required to allow successful boot which are the ICCID and IMSI in the main with the addition of other parameters such as the MNC. Although it may be regarded as best practice in the main it’s not without issue. From experience and review/re-examination of cold and live cases the same problems are encountered yet not addressed to a satisfactory level.

There are several vendors of such products and in the main they are adequate to a degree however some vendors of such products do not appear to continue with the product development cycle of such functions as one would expect. We see improvements and development with the core functions of mobile phone forensic applications and that is most welcomed however the basic fundamental process in this case cloning of the target U/SIM are left behind. Thus how is it possible to continue or improve upon a best practice model if the basic fundamental requirements are not addressed?

Examples where failings have been noted are listed below:

1. Misrepresentation of acquired/harvested data:
Quite often through examination it has been noted certain data types are not translated or presented in the correct format. For example contact names may be missing as they are contained within the ADN of the U/SIM card and due to the cloning system have not been transferred through which in turn is replicated to other data sets such as SMS and call list.

2. Inaccessible data
Situations have been encountered where data is not available via the GUI of the target device thus the possibility of missing or non-examination of data exists. An example of this was encountered whilst examining a BlackBerry Bold device where the BBM application was not available without the use of the original target U/SIM, the reason being that the application or some functions were tied to the SIM Application Toolkit.

The above examples are just the tip of the iceberg and in the opinion of the author there are certainly more issues encountered in the use of U/SIM cloning systems when examining mobile telephones and/or devices which utilise the use of U/SIM cards.

So how can we overcome such issues and improve upon the best practice model? One solution is total radio isolation and the use of the original target U/SIM i.e. faraday enclosures/rooms. Unfortunately this option is not a satisfactory way forward due to cost, health & safety issues, practicality and when dealing with volume work.

For a more practical and sustainable solution the author would suggest that the vendors of such products/services review their product development cycle, obtain and work with the necessary feedback from seasoned practitioners with a view to providing far more robust products/services which at best eliminate U/SIM cloning issues or which offers the examiner more flexibility as to the cloning parameters required or at least work towards providing bulletins of known issues and possible solutions for identified issues.

Author: Vinny Parmar
Digital Forensic Practitioner
Accredited MTEB Mobile Phone Trainer