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