Contaminating Evidence THREE

Parts ONE and TWO can be found here for those who haven't followed the discussion so far:

Contaminating Evidence ONE  - http://trewmte.blogspot.co.uk/2017/04/contaminating-evidence-one.html

Contaminating Evidence TWO - http://trewmte.blogspot.co.uk/2017/04/contaminating-evidence-two.html

I have received enquiries asking for references how to test a damaged SIM card is working or not? This is not a case of simply sticking the damaged SIM cards into a SIM reader and using software to see what content is returned from various data files.

Lab Managers, Section Leaders and Examiners need to define the aims and objectives for testing damaged SIM cards. This should be on the basis of the Test A Damaged SIM Card SOP. The use of general statements in these discussions are not aimed to tell you what to do or how to write your examination processes and procedures. It offers, hopefully, helpful suggestions on basic materials needed to develop and evolve SOP. The following materials could serve as a foundation template with which to prepare and guide the preparation of headings and descriptions; themselves used to define how tests should be conducted.

Avoiding a discussion about how to top and tail a SOP document, nor discuss the merits of aims and ambitions, Do's and Don't (so to speak) and so on, the focus will highlight the relevance of "interface". The first question to ask is who's interface? There are a few to deal with when examining a damaged SIM card:

1) The hardware interface of the damaged SIM card
2) The software interface of the damaged SIM card
3) The probes of hardware of the examining tool
4) The software of the examining tool

Because there are many internal communications entities on a SIM card it can be thought of in terms as having it own mini-network. Here is an image of communications network where at certain points interception is required to deal with e.g. cyber attacks.




We can see network elements as being defined as entities of the network and we need to get to those entities to discover what is inside (content). We therefore require defining the object identifiers for 'path-to-content', so perhaps creating an identifier tree that illustrates the reference points of interest can help you do that?

Unlike a full communications network, which it is not realistic to attempt to obtain an image compared to a device; the SIM card's mini-network in a device can be imaged. Identifying elements and entities in the SIM card's mini-network examiners can look to the following standards:

ISO/IEC 7816-1
GSM 11.11; 11.12; 11.14; 11.17; 11.18
3GPP 31.120;31.121
ETSI TS.102230

To illustrate how the standards can be used to create a standard operating procedure (SOP) in the photo below I have identified physical, electrical, electronic and logical elements to be considered by combing the details taking the test reference identifiers in GSM 11.17 and overlaid them to GSM 11.11 reference points.  These are known as the SIM test groups.

Germane and relevant is the interface processes and procedures chosen have a 'forensic' requirement that the device's content should not be altered by our actions (so to speak). "Human Intervention and Tools (HIT) need to demonstrate that their interaction with the device does not change any data. All tests carried out using an examination tool should also be carried out on the basis of understanding any limitations of the tool."

So when it comes to testing the damaged SIM card we have background knowledge, but does that mean we have to create new software utilities and hardware for testing to see if the card can be imaged using a SIM card reading software? There is a huge range of physical hardware readers out there that are compliant with the Standard's physical, etc. interface requirements. To support that proposition examiners can use hardware such as SCR331 etc. Moreover, there is the utility PC/SC diagnostic tool. I chose this utility because it was available back in 2002-2003 and a popular tool for testing GSM SIM cards.

The purpose of using a test utility on the damaged SIM card is that you do not want to run a fully blown image process on the damaged card because you do not know the extent of the damage inside to its micro-computer electronic circuits (do you think that should be stated in your SOP?). PC/SC diagnostic tool enables testing only the boot-up of the card and to return its ATR (answer-to-reset) and other system parameters.  As the test does not penetrate the Master File (MF) and elementary files (EF) the tool only works with the shell and wont read and return content such as the EFICCID or EFIMSI and so on.

When conducting a test read of the damaged card the results returned will need to be saved. PC/SC diagnostic tool provides for saving the test report. Identifying the name of the report is optional, but when training it is perhaps a good idea to get into the practice of identifying the report from the SIM Serial Number (SSN) recorded on the face of the card. In the photo below I have simply used filename ICCID so as not to identify a test card or a case exhibit.

The initial report that is saved will be a plaintext .txt file. To prevent loss or alteration of that file convert the .txt file to a working document (.pdf).

Examiners essentially need to be aware how the test tool works. It writes APDU (application protocol data unit) - the communications unit between the SIM card reader and the SIM card. The APDU are set out in the Standards.

When preparing your damaged SIM card SOP some key information to have considered and confirmed are:

a) Does the tool permanently write to the card?
b) If so, and working at the shell, where would that be discovered, if at all?
c) Can a write blocker be used?
d) What can be learned from the ATR and parameters?    

If the test results obtained are good this detail can be used in the decision-making process whether or not to create a cloned test card. Remember to enter a caveat in the SOP and to the client that internal damage cannot be seen and therefore any image extracted thereafter might only be on a one-shot basis.

Remember: photographs and well documented contemporaneous notes are essential here. Make the effort to record details so that you don't have to struggle trying to remember what the device was like or what you did.