Friday, June 23, 2017

Universal Network Investigations

Just started a new LinkedIn group called 'Universal Network Investigations (UNI)'. It is a group only for those involved in the wider area of fixed, mobile and large-scale computer networks. The group exists to assist cyber, forensics and fault-finding investigations: to exchange observations and sharing 'intel' in a closed forum discussing fixed and mobile network investigations - trace data and other forms of evidence (including but not limited to PCAP, CDRs, traffic logs, exchange and switch data, cell details, dumps, etc.) If you are a member of LinkedIn and want to participate in the group here is the link: https://www.linkedin.com/groups/13536130

Sunday, June 18, 2017

Mobile Forensic Metamodel


Previous studies have mostly discussed mobile forensics only in data acquisition terms and only in a problem solving scenario, as a subset to computer forensics. These studies did not take mobile forensics beyond the paradigm that is known as computer forensics. Additionally, they have not addressed the elements of MF comprehensively, and the previous research in the MF domain did not focus on modeling the case domain information involved in investigations.

This paper develops a Mobile Forensic Metamodel (MFM) in order to clarify all the necessary activities required by investigators for conducting their task. In addition, it creates a unified view of mobile forensic in the form of a metamodel that can be seen as a language for this domain. A metamodeling approach is applied to ensure that the metamodel which is the outcome is complete and consistent.

A metamodel for mobile forensics investigation domain
CLICK TO DOWNLOAD .PDF

Thursday, June 15, 2017

WhatsApp network forensics

With many companies allowing employees to use their own smartphones in the workplace it has been noted confidential information maybe being unwitting leaked as users take to using their smartphone cameras to take photos of Whiteboard content, potentially risking disclosure (mentioned by the Information Security Community). Smartphones can also scan data, reducing the need for organisation to require Whiteboard printouts (thus saving money?). Whilst a user might not intentionally leak information, WhatsApp does provide for exchange of information during in-party calls, potentially allowing confidential data to be circulated.

However, let us avoid that scare story of sending confidential information and the story at work with the situation where a WhatsApp user has called another WhatsApp user and discloses Global Organisation X is in talks with World Dominant Corp. B to take them over. Both are on the Stock Exchange and both hold Worldwide Patents used in the medical industry. Such a leak could wrongfully 'influence' the markets. Could a WhatsApp call leak be possible? Maybe, but is that relevant to WhatsApp network forensics and this article? No. Finding out potential avenues where information leakage might take place enables pre-planning, handling risk and helps in designing a rescue plan.

Screen from my desktop using Wireshark

What is relevant is that for those conducting network forensics, accordingly to F. Karpisek, I. Baggili, F. Breitinger (ISSN 1742-2876, http://dx.doi.org/10.1016/j.diin.2015.09.002) they were able to "...decrypt the network traffic and obtain forensic artifacts that relate to this new calling feature which included the: a) WhatsApp phone numbers, b) WhatsApp server IPs, c) WhatsApp audio codec (Opus), d) WhatsApp call duration, and e) WhatsApp's call termination." From a network investigators point of view essential information producing evidential artifacts of identifying network activity. Taking this further, PenTesters might even find this information useful, also. Even where security flaws get updated, doesn't stop modified attacks occurring creating further vulnerabilities; so learning is the name of the game. 
 
Often we read from articles/reports about vulnerabilities etc. but only the content in the articles/reports are available. What is extremely helpful here F. Karpisek, I. Baggili, F. Breitinger have made available 'trace data' so that when combined with the tools referred to in 'WhatsApp network forensics: Decrypting and understanding the WhatsApp call signaling messages', enables Investigators and PenTesters to gain experience and refine testing approaches. Access to the trace information is here: https://www.dropbox.com/s/szrk5f3axwt5bi7/reference_files_WhatsApp.zip . You may want to get a copy soon as often with dropbox downloads they get deleted by the dropbox user after a time.

Wednesday, June 14, 2017

iPhone - TDEL034 Tool Testing


Many discussions take place during training which unearth useful guidance for practices and procedures. Also, tips and tricks are also revealed. From the MTEB Tool Testing training papers 2015 - iPhone TDEL034 (test device entry level) strategies and pre-planning - it is used to illustrate potential stages for obtaining images that produce a baseline test data to enable repeated testing to identify possible changes in the working operation of forensic tool suites importing a pre-existing test image.

However, TDEL034 is, as stated above, for strategies and pre-planning. Acquisition tools and Analysis (reader/reveal) tools are dealt with later in the training. What is uncovered during discussions are peoples perceptions given their involvement within the examination process. 

It is in these sessions during training the reality dawns as to the time and expense it takes just to deal with one brand-name 'Make' of smartphone and then adding into the equation the various models that have been created and may be created in the future. If that isn't enough, there is then the various versions of OS implemented in various models (https://en.wikipedia.org/wiki/IOS_version_history).

The discovery doesn't end there. Tasks involving removal of barriers and revelation equally may impact when discussing discovery (https://en.wikipedia.org/wiki/IOS_jailbreaking).

Digital forensics is a reality and not a junk science. This field of endeavour is unlike traditional sciences incl. many forensic sciences. How many traditional sciences can you identify evolve and update rapidly e.g. every 6mths-12mths? It is against this backdrop that digital forensics is expected to function and operate across a digital arena of many makes/models of devices and services. Understanding the fantastic job that people do working in digital forensics and battling with constant change illustrates how digital forensics is highly unique.

Generic standards do not work as well with digital forensics as would 'specific' standards. That is because with generic standards they are tantamount to informing everyone this is what has been created and it is your responsibility to make it work. This is analogous to an organisation purchasing a SATNAV and Driving Route System which when operational fails to inform the driver of 'No Entry' roads, dead end roads, instructing a driver to take the action even when the sign states 'No Left Turn' or using as-the-crow-flies navigation so the driver is placed at a point e.g. x-miles from true destination, because the system doesn't understand vehicles cannot drive through people houses, gardens or buildings to get to the other side. The organisation then expects the driver to workout the problems so that when reaching the destination it looks like the SATNAV and Driving Route System was working correctly.

This is why training is essential not just at the tool level, but also at the conceptual level to assist in the design of an examination approach that fits the need of the device and at the same time relieve the pressure placed on the tools that are expected to, alone, get it right. Having the right digital forensic standard should provide the baseline and should define process approach to assist achieve results.

I will return to this subject to offer observations a little later, but for now other matters are now pressing and need attention.

Sunday, June 11, 2017

Do Cyber Events Follow A Philosophy

I was intending to raise this point some months back but due to other pressing issues I had forgotten to do so. It relates to a quote used in a presentation from Nokia 'The known unknowns of SS7 and beyond: Evolution of Telco Attacks'.


 Are cyber events such as DDoS, Malware, SS7 attacks, Dirty/Nasty USSD, dirty data_ark  and so on following some sort of noble objectives to be comprehended from quotes e.g. Sun Tze's philosophy "The supreme art of war is to subdue the enemy without fighting"?



Even if that were correct or true how does it help define which events are isolated and which events are or have characteristics of intended aggregation to bring about a sustained campaign of subjugation?

Tuesday, June 06, 2017

Not Comfortable Fit for Digital Forensics - ISO17025



Within the digital forensics arena there is discomfort amongst labs, academia, businesses and practitioners that ISO/IEC 17025 'General requirements for the competence of testing and calibration laboratories' is not a comfortable fit for digital forensics. Very few digital forensics laboratories and businesses have been accredited so far. To get an understanding of concerns obtained from a pretty good base-data of opinion from replies to UK ISO 17025 Digital Forensics Survey 4/24/2017 created by Professor Peter Sommer, the results have been published and are available here http://goo.gl/KP0HOn .

Not to second guess the Forensic Science Regulator (FSR) there is , of course, the October 2017 deadline looming and the outcomes of that deadline might impact on the way forward. However, I regularly keep an eye on Lab Accreditation and Best Practice Guides (as you can see from some of the pdf tabs open in the above screen shot) in context with digital forensics in order to note the changing approach to digital forensics. The new breeze appears to suggest digital forensics blowing towards ISO standards e.g.

ISO/IEC 27042: 2015. Information Technology - Security Techniques - Guidelines for the Analysis and Interpretation of Digital Evidence.

ISO/IEC 27037: 2012. Information Technology - Security Techniques - Guidelines for Identification, Collection, Acquisition and Preservation of Digital Evidence.

Currently, but this may change, these standards are not substitutes for accreditation. That does not mean though digital forensics may not branch off and have its own unique accreditation and standards. It may well be the British Standards Institute (BSI) may need to produce an equivalent standard for the UK based upon an example of the old BS5750 approach. BS5750 and ISO9000 do enable the UK Government's requirement to be met for "inclusion" of single-person organisations and SMEs to play apart in the economy and not be excluded from it due to globalism or restraint of trade practices or over-burdensome control measures.

Previously, I drew attention to how in the US, Karin Athanas, Program Manager at the American Association for Laboratory Accreditation (A2LA), produced an article titled "Accreditation for the One-Person Organization - The smallest laboratories can teach us the biggest lessons.". This article defined that smaller business entities could achieve accreditation to ISO/IEC17025: http://trewmte.blogspot.co.uk/2016/10/isoiec-1702517020-one-person.html


The UK ISO 17025 Digital Forensics Survey 4/24/2017 isn't the first time attention has been drawn to ISO/IEC17025 that it should works for all, not the few. If the latter accreditation doesn't work then maybe another route will need to be found.


Sunday, May 28, 2017

Forensic Chip Off - Notes in Progress

Thanks for those who have taken the Survey for Digital Forensics Tool Testing so far. For those who haven't taken the 4-mins survey which only has 15 easy to read questions to answer, please do so ( digital-forensics-tool-testing.html ). The larger the pool of anonymous answers being returned to the Faculty of Computer Science University of Sunderland for Dr. Graeme Horsman to analyse the better the feedback to you and the digital forensics community, as a whole, will be when Graeme publishes the findings.

Below are two youtube videos. Watch them both as they provide an interesting account of removing iPhone 5 ICs. These are general repair services for iPhone and not promoted as forensic chip off.  In particular, pay attention to whether there are any good working practices and whether the operator's manner is acceptable for handling an exhibit?

Three observations I will share are (1) should the operator be wearing anti-static glovers?; (2) how would you keep contemporaneous notes (CN) simultaneously whilst removing a chip?; and (3) should you be testing chip off tools to understand their limitations before using them for chip removal and chip reading?

Please use weblinks
https://www.youtube.com/embed/jePWDxec9J0



https://www.youtube.com/embed/r5pC6zVMgSo 

Wednesday, May 24, 2017

Survey: Digital Forensics Tool Testing

Following on from the post "Study into Carving Validation" - http://trewmte.blogspot.co.uk/2017/05/study-into-carving-validation.html ,Dr Graeme Horsman from the Faculty of Computer Science University of Sunderland has produced a questionnaire designed to acquire industry consensus on the wider vista associated with tool testing in the field of Digital Forensics. Responses are anonymous and the results will form part of research into the design and implementation of tool testing in the field, and will also be used as part of the production, publication and dissemination of research in this area.

As the survey responses are anonymous Dr. Horsman requests any questions or comments you have should be posted at the LinkedIn Group "Institute for Digital Forensics" - https://www.linkedin.com/groups/2436720 as all questions and comments made are under Chatham House Rules  ( https://www.chathamhouse.org/about/chatham-house-rule )

This survey contains 15 questions. Estimated time to complete - 4 minutes.

https://sunduni.eu.qualtrics.com/jfe/form/SV_5uupcHQ8cMYiiO1

Thursday, May 18, 2017

Study into Carving Validation

At the LinkedIn Group "Institute for Digital Forensics" ( https://www.linkedin.com/groups/2436720 ) we are pleased to announce Dr Graeme Horsman PhD, BSc (Hons), MJur (Dur), PGCertHE, SFHEA from the Faculty of Computer Science University of Sunderland has joined the Group and wants to seek assistance from practitioners, in-house test and examination departments and laboratories regarding thoughts on testing in terms of the tools that are used. This is in terms of strategies etc., given the importance (albeit it has always been important) with ISO standards etc. Do IDF members have their own "test data and strategy that they roll out on new software/releases"? This is in relation to potential value of an automated test data generator for known good content from which to evaluate parsing/carving algorithms. This would be with respect to "carving validation" so test data would be geared towards such algorithms. Dr Horsman would appreciate as much feedback as possible and wants to engage in discussions to facilitate this study.

Access to content and discussions is open to LinkedIn members who request and are approved for membership to the Group "Institute for Digital Forensics.

Sunday, May 14, 2017

Contaminating Evidence SIX

The original question (in Part ONE) I believe was asked by someone starting out in mobile forensics. I tend to find it is easier to start with the 2G technology [SIM Application CLA (0xA0) / 2G context], which is still predominant in certain countries; although market research shows 2G falls below 30% globally by 2020.

Furthermore, law enforcement and security still seize and find 2G SIM cards (globally speaking) associated with criminal activity - drug dealing, SIMboxing, trafficking, etc. - so any observations to assist examination may help improve outcomes, assist generate "quality in work" but without expending large quantities of capital.

Equally, with 3G and 4G SIM cards the examiner can still SELECT and ReadBinary etc. re: GSM Access. Also, it is helpful to let examiners see basic script commands and responses as the basic commands can still be issued under [USIM Application CLA (0x00)]:

SelectUSIMApplication
Select 6F07
ReadBinary


To make the following a little more interesting than merely showing a screen image of USIM Application returning the SIM Card's IMSI, does the mobile network IMSI match the network to which the IMSI was last latched?


For privacy and security purposes the IMSI has been obscured, however it is confirmed the IMSI for this discussion is a subscriber to the EE network. As an examiner you may consider looking to the last network and location the subscriber was camped.

SelectUSIMApplication
Select 6F7E (e.g. location area)
ReadBinary




SelectUSIMApplication
Select 6F73 (packet switched location area)
ReadBinary



Observations, at first instance: the LOCI and PSLOCI screens reveal that the subscriber's account has been latched to the T-Mobile network; not EE or Orange network. Who would provide feedback to the investigating office on what that means? Both of these screens show "updated" for location and routing area, yet the P-TMSI Signature Value has been unchanged FFFFFF. What significance, if any, would that import into interpreting the data?

The key point of using commands and getting responses can assist an examiner refine searches made to (U)SIM and the (U)ICC and also respond to "time-is-of-the-essence" requests in cases of device seizure at the point a trafficker is stopped and searched. Combining precise information searches can help examiner's do this.


Moreover, with enhanced scripting and script variables we can do so much more and a matter that will be considered in another blog discussion post/s soon regarding examination, evidence and validation:

==========
ContinueOnBadStatus
Select 3F00
Select 7F20
Select 6F07
If (GoodStatus = True)
{
 ReadBinary
 If (GoodStatus = True)
 Pass
}
Fail
===========
===========
Select 3F00
Select 7F10
Select 6F3A
Set $recNum = 1
While ($recNum <= $totalRecords)
{
 ReadRecord $recNum
 Increment $recNum
}
===========
===========
$count
$recordNumber
$data
$alphatag
$bitmask
===========


The tool USIM Commander is a SIM evaluation and programming tool available from Quantaq Ltd and can be found here: http://www.quantaq.com/products/simtools/

Hope you find this helpful.


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
Contaminating Evidence THREE  - http://trewmte.blogspot.co.uk/2017/04/contaminating-evidence-
three.html
Contaminating Evidence FOUR - http://trewmte.blogspot.co.uk/2017/05/contaminating-evidence-four.html 

Contaminating Evidence FIVE - http://trewmte.blogspot.co.uk/2017/05/contaminating-evidence-five.html

Thursday, May 11, 2017

Contaminating Evidence FIVE

To refresh, these discussions (links at foot of this article) originated because someone asked a question e.g. should I put a seized damaged SIM card into a seized mobile phone (handset), where both items have been found placed into the same Exhibit bag? The discussions have been to highlight helpful observations about what can be involved and learning the lesson to keep a damaged SIM card separate from the handset and conduct tests independently from combined forensic suites; hence the need for Test A Damaged SIM Card SOP.

Yes, you can run a test single APDU (application protocol data unit) command to select particular data from a SIM card, as you can run a script containing multiple test APDU commands. For example, what follows is an example of multiple APDU command to SELECT and GET RESPONSE  from the SIM card requesting the SIM's IMSI (international mobile subscriber identity). Invariably, investigating officers and security may only require just that little piece of information; and whether extracted and harvested from a working SIM or a damaged SIM. Where a damaged SIM Card is involved it wont be clear at the initial examination stage whether (a) the SIM will respond to any test or fully-blown image? and (b) if it does, could there be only chance to retrieve any data from it (the card)?

APDU Commands
We know that the standards identify commands as follows and therefore these would most likely assist the examiner when reading the SOP. Remember in part FOUR it referred to the SOP should assist examiners by identifying the short form title and clause. So here is one exercise you can do now. Go and download ETSI GSM11.11 (Release R1999) and 3GPP TS 31.102 latest release and identify the short form title and clauses relevant to the APDU commands below:

- Select
- VerifyCHV
- ReadBinary
- ReadRecord
- UpdateBinary
- UpdateRecord
- Status

Test APDU - IMSI Request
The next step is to select and chosen the statements needed to issue commands for the SIM card to reveal the IMSI:

- 2GMode
- Select 3F00
- Select 7F20
- Select 6F07
- ReadBinary
 


USIM Commander GUI Image


The IMSI has been doctored in the above image for privacy and security reasons. However, the three windows panes above illustrate how to validate commands issued to a damaged SIM card. The left pane shows the commands. the top right pane shows the status and harvested data of the commands issued. And the bottom right pane confirms the translated APDU trace and the Raw APDU trace. Thus proving the process and procedure the examiner adopted and applied during testing. This information can then be logged into the examiner's Contemporaneous Notes. 

Training and Discovery
Before jumping into conducting the tests, training and exposure to different types of SIM cards and their conditions should be the first priority. Even the best APDU scripters make mistakes. The screen images that follow illustrate mistake and correction (can you find the mistake?) and following that the importance of the learning curve an examiner needs, which is only possible base upon discovery using training SIM cards to see what might be revealed.
 
 
 
Examiner need to be encouraged to extend search investigation beyond the template. The images below, identifies CHV1 and CHV2 discovery might reveal. This discovery helps examiners to uncover if unknown CHV1 and CHV2 can be revealed.




 
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
Contaminating Evidence THREE  - http://trewmte.blogspot.co.uk/2017/04/contaminating-evidence-

three.html
Contaminating Evidence FOUR - http://trewmte.blogspot.co.uk/2017/05/contaminating-evidence-four.html 

Wednesday, May 10, 2017

Contaminating Evidence FOUR

In the last discussion it referred to APDU (application protocol data unit) - the communications unit between the SIM card reader and the SIM card. It also mentioned that APDU are set out in the Standards. There is some more information on this you may find helpful. The Test A Damaged SIM Card SOP could include a removal of doubt (ROD)technique. The purpose of this ROD technique assists the examiner's comprehension from the outset of the 5-Ws rule of thumb:

Who - the examiner
What - testing across the interface
Where - between the DUT and the Test Tool
When - as directed by the laboratory Good Practice Guide (GPG)
Why - to avoid contamination of evidence

To aid that process the SOP could reference the procedure with the inclusion of the relevant standard numbering and title, also directing the reader to a specific clause. It is irrelevant for the purposes of testing to ask an examiner to remember something s/he was taught some time back. A permanent record in a document of direction and advice instructing the examiner is needed. Practices and procedures should not be left to guesswork. As the old adage states " it is not knowledge you need to hold-on to in your head as this is recorded in books; it is the skills and experiences you should remember." A permanent record, then, is a reference book. The skills and experiences developed through use and discovery are those essential requirements to maintain and evolve the SOP, which when recorded then goes on to become knowledge.

ISO/IEC 7816

In Part ONE it referred to ISO/IEC 7816-1. That is because it is the starting point that identifies other 7618-parts. Here we need to look at ISO/IEC7816-3. The above image show the specific section to be discussed. But for the sake of manner and form let us use a page within the SOP identifying Standards and Text applicable to it (the SOP and its procedures and tests therein):

Standard Title:
============
INTERNATIONAL STANDARD ISO/IEC 7816-3 Third edition 2006-11-01
Identification cards — Integrated circuit cards — Part 3: Cards with contacts — Electrical interface and transmission protocols

============

However a short form identity for the relevant Standard and clause/s are required. This is placed at the end of paragraph following the written procedure or test (otherwise any procedure and test would be verbosely overloaded with repetition of a Title like the above).

Short Form Identity:
=============
(ISO7816-3 (cl12.1.1)) 
=============

Note that apart from going to a separate document (e.g. relevant Standard and clause) everything that an examiner should require should be in the SOP. The reasoning behind that has many responses but to highlight: (a) avoids an examiner reading wrong, incorrect or out of date material; (b) excessive amounts of information can confuse; (c) examiners will be testing, but prior to tests and following tests contemporaneous notes should be made which could be excessively lengthy if the SOP references are not used....and so on.

It can also be helpful to produce GUI screen images and samples of APDU so that the examiner is equally guided to know what to look for in any trace file output for validation purposes.

USIM Detective


Dependent upon the (U)SIM/(U)ICC hardware reader and software (system) used it is important that the examiner does not end up using another system to perform the tests. If a different system is used a new SOP should be created for every system in use. If support is needed for that then an example can be given here. The above screen image shows the ADPU commands and responses in the USIM Detective trace file. However, Simspy2 trace file output is different:

Simspy2

  
This might suggest the commands and responses that are output should still be identical? No, not all commands and responses will be identical. Worse still, if the examiner starts quoting one system in a report and the data used is in fact from another system. An example of this is Simspy2 and USIM Detective both issue commands and responses that can acquire different data. Both issue commands to fetch data from memory locations that are not specified in the standards. This does not suggest they are wrong, merely they offer different traced evidence.

Unless each Lab produces its own system then the market forces of commercially or freely available systems will be the pool from which systems are obtained. The more tools the better, but budgets can dictate a system to be used, although in reality obtaining free software should not present a problem. Purchasing a commercial system, it should be possible to fully scrutinised data captured and that the system has the back-up evidence to produce a trace file output containing the commands and responses where validation is needed.

Validation requires confirmed interpretation of commands issued and as mention in previous discussion seeking guidance from the standards can save an awful lot of time and assists avoiding guesswork:

GSM11.11



Lastly, but still relevant to Test A Damaged SIM Card SOP, it should be made clear in the SOP that the standard referred to identifies the "interface" as referenced in the standard. In this discussion ISO7816-3 confirms the "electrical interface" and the transmission protocols used. However, as (U)SIM cards emerge with additional capabilities in the (U)SIM or at the (U)ICC level it is important to record additional interfaces significant to the method and process evidence is captured:



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

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

Sunday, April 23, 2017

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.

Thursday, April 20, 2017

Contaminating Evidence TWO

The goal of these essay discussions is to provide responses to the potential proposition that could arise in the theoretical question.  Part One can be found here: http://trewmte.blogspot.co.uk/2017/04/contaminating-evidence-one.html


“What would you do if presented with an exhibit bag containing a mobile phone (which cannot be fully accessed without a SIM Card) and a SIM Card (which was not inserted and may/may not be associated with the device) separately and what could the affects be if the SIM Card was inserted into the mobile phone?”
The question raises “what could the affects be...?” The follow essay discussion will endeavour to capture some hopefully useful points for readers. It is not exhaustive list but intended to be illustrative of what may happen.

Removing the SIM card and handset from the evidence and exhibit bag, the examiner, following anti-static procedures, should normally inspect the SIM card first for any signs of damage.

 
In this case, the photo shows sustained visible damage to the outer SIM contact pads; as consequence this could mean damage to internal components and connections? It is not unknown for suspects to try and damage their cards with external power sources to make access to SIM memory impossible.
 
Inserting a faulty SIM card into a handset may have an adverse effect on the handset’s SIM controller circuit with respect to the sensitive EMI filter. If the handset has a bad reaction to the inserted SIM card it could be the case the exhibit SIM card caused contamination damage by causing the EMI filter to breakdown, preventing the handset reading this and any other SIM cards until repaired.   
This is good example of a case where photographic records and contemporaneous note taking is very important. The decision not to use this damaged SIM card with the exhibit handset at all would be wise. The SIM card would need to be tested to see if any data can be recovered from it using an external SIM reading software. There may be a chance to create a clone test card from it.
 
The examiner should be following the correct Laboratory SOPs which may direct him/her to make a clone test card from the exhibit SIM card. This clone test card ‘might be used’, subject to approval from the investigating officer, to be inserted into the exhibit handset. This is in cases where extracting and harvesting data in an image file (e.g. .bin or raw file) following the removal of the memory chip or using JTAG points on the handset’s printed circuit board (PCB) are not options available to the examiner.
As mentioned in Contaminating Evidence ONE feedback received from queries raised by the Lab Manager to the client regarding seizure procedure, chain of custody and any other examination/s should hopefully confirm one way or other whether there is any connection between the handset and SIM card. If there is, and subject to authorisation, the examiner might use the cloned test card in the handset.
In the alternative, for whatever reason, should the examiner insert the exhibit SIM card into the exhibit handset this action requires an understanding of the following:
(i)                  handset processes and procedures during power off?
(ii)                inserted SIM card processes and procedures during handset power down?
(iii)               events happening at power on for handset and SIM card?
Depending on make/model of handset, its profiling and initialising processes, on power this can potentially affect data held on the SIM card and data held in the internal memory of the handset.
SIM cards follow a fairly, precise procedure for boot-up until the SIM Toolkit stack initialises and then depending upon make/model of handset dynamic changes can occur with allocated, but not activated services in EFSST. If the SIM card is not connected with the handset then exchanges causing data changes take place between the SIM card and handset. This is, by all means, not the only potential data changes that can occur with SIM cards and analysis should be considered for the following:
(iv)               EFHPLMN (Home PLMN - check for update timer)
(v)                EFLOCI (Location Information)
(vi)               EFBCCH (Broadcast Control Channel)
(vii)             EFKc (GSM Ciphering key Kc)
(viii)           EFKcGPRS (GPRS Ciphering key KcGPRS)
(ix)               Check DF ProSe
(x)                 EFCPBCCH (CPBCCH Information)
(xi)               EFPSLOCI (Packet Switched location information)
(xii)             EFNETPAR (Network Parameters)
(xiii)            EFOPLMNwACT (Operator controlled PLMN selector with Access Technology)
(xiv)            Proactive SIM
(xv)             EFSST (SIM Service Table)
(xvi)            And so on
Also of interest is what is happening to the handset data due to internal functions? For instance, inserting a SIM card that has not been previously used with the handset can block access to phonebooks, messages and so on due to internal security policies. Moreover, when powering on a handset the examiner has no clue whether the handset user as set a policy ‘auto-delete’ messages, which may be triggered.
 
There is also some debate where a handset is switched ON but within a radio-damping field or chamber to prevent connection to the network what happens to data under these circumstances?  The thought that all radio context details is lost on power down may have security requirements but what is retained in the handset is largely left down to the handset manufacturers. Of interest, some UEs having stored some NAS (mobility management) information e.g., old security context, GUTI, IMSI, timer values etc. may still be stored for assist quick speed to link to network as opposed to drawing stored data from the SIM card. This may occur where the user selects Flight Mode and suspends all radio activity, again depending upon make/model of handset. Inserting a SIM card not used in the handset previously, the handset initialisation procedure will call the data from EFNETPAR file and record that into temporary memory. That information wasn’t there previously; that may be considered contamination.
 
SUMMARY TWO
Due to so much activity that is invisible to the examiner when handsets are switched ON with a SIM card inserted requires the examiner (using strict Laboratory SOPS) to follow the SOPS procedures and NOT insert the exhibit SIM card into the exhibit handset using subjective guesswork.