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

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 

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

SIM PIN Challenge 2

SIM PIN Challenge 2

.
A reminder that this challenge ends on the 15th February 2009:
.
http://trewmte.blogspot.com/2009/01/sim-pin-challenge.html
.
No pressure here guys, but we have had the first written response to the SIM PIN Challenge from a Challenge Entrant who has just started in mobile telephone forensics. This Challenge should therefore be a walk in the park for all you mobile phone and computer forensic examiners who have given evidence about SIM Cards in Court.
.
As a brief history about SIM Cards, the requirement for *Personal Identity Number (PIN) to be available in a SIM Card is defined by way of the GSM Standard GSM11.11. Moreover, GSM11.11 v3 1995 standard and onwards can be downloaded free of charge. So at least we know there is over 13 years of technical knowledge about SIM Card PIN that is traceable. Furthermore, there are other standards that are used to test for allocation and activation of PIN and the mandated execution of the function between the mobile phone and SIM Card.
.
*Do remember that PIN is only used because it is comon language now, but has been made obsolete from the standards and replaced by CHV (Card Holder Verification).
.
Finally, many ten of thousands of SIM Cards have been examined and their evidence, along with examiners' testimonies/experts' opinions, have been presented in criminal proceedings at Court for well over a decade. A large number of the SIM Cards presented for examination had PIN enabled, thus understanding the fundamental operation of PIN is vital to forensic investigation understanding and the evidence presented about it.
.
I have sent copies of this Challenge and MOBILE FORENSICS AND EVIDENCE DEGREES/CHALLENGE (see weblink at the end of this discussion) to the following who have the responsibility for: innovation, universities and skills; and regulation of forensic sciences:
.

Rt Hon John Denham Secretary of State for the

Department of Innovation, Universities and Skills (DIUS)

.

Mr Andrew Rennison UK Forensic Science Regulator

.
MOBILE FORENSICS AND EVIDENCE DEGREES/CHALLENGE

http://trewmte.blogspot.com/2009/01/mobile-forensics-and-evidence-degrees.html

SIM PIN Challenge 2

SIM PIN Challenge 2

.
A reminder that this challenge ends on the 15th February 2012:
.
http://trewmte.blogspot.com/2009/01/sim-pin-challenge.html
.
No pressure here guys, but we have had the first written response to the SIM PIN Challenge from a Challenge Entrant who has just started in mobile telephone forensics. This Challenge should therefore be a walk in the park for all you mobile phone and computer forensic examiners who have given evidence about SIM Cards in Court.
.
As a brief history about SIM Cards, the requirement for *Personal Identity Number (PIN) to be available in a SIM Card is defined by way of the GSM Standard GSM11.11. Moreover, GSM11.11 v3 1995 standard and onwards can be downloaded free of charge. So at least we know there is over 13 years of technical knowledge about SIM Card PIN that is traceable. Furthermore, there are other standards that are used to test for allocation and activation of PIN and the mandated execution of the function between the mobile phone and SIM Card.
.
*Do remember that PIN is only used because it is comon language now, but has been made obsolete from the standards and replaced by CHV (Card Holder Verification).
.
Finally, many ten of thousands of SIM Cards have been examined and their evidence, along with examiners' testimonies/experts' opinions, have been presented in criminal proceedings at Court for well over a decade. A large number of the SIM Cards presented for examination had PIN enabled, thus understanding the fundamental operation of PIN is vital to forensic investigation understanding and the evidence presented about it.
.
I have sent copies of this Challenge and MOBILE FORENSICS AND EVIDENCE DEGREES/CHALLENGE (see weblink at the end of this discussion) to the following who have the responsibility for: innovation, universities and skills; and regulation of forensic sciences:
.

Rt Hon John Denham Secretary of State for the

Department of Innovation, Universities and Skills (DIUS)

.

Mr Andrew Rennison UK Forensic Science Regulator

.
MOBILE FORENSICS AND EVIDENCE DEGREES/CHALLENGE

http://trewmte.blogspot.com/2009/01/mobile-forensics-and-evidence-degrees.html

SIM PIN Challenge

SIM PIN Challenge

.

Back in 2005 I was at a presentation by a SIM manufacturer when the presentation turned to CHV (Card Holder Verification), the correct technical term for PIN used for SIM Cards.

.

The presentation had reached the part "Verifying the CHV" and went on to record:

.

~ To verify PIN, the verifyCHV APDU is used....

.

A0 20 00 CHVNum 08 PINValue

.

~ The message sent from the phone to the SIM in order to check your PIN number 1111, is:

.

A0 20 00 01 08 313131FFFFFFFF

.

This all seemed normal until three slides later when the presentation started to discuss "File Structure after personalization" and displayed the graphics starting with the Master File (MF) and under which there were five Elementary Files (EF). The graphics displayed in the presentation were text book style when discussing MF and EFs, except for this presentation the manufacturer had gone as far as to identify two particular CHV EFs; one of which was 3F00 - EF_CHV1 0000.

.

.
So does that mean a particular EF under the MF in SIM with a logical address 3F00 0000 is always going to be the CHV1 file and would the raw data from that EF reveal a user's PIN number?
.
Below are raw data extracts from three phases of SIM cards - Phase 1, Phase 2 and Phase 3 (2+) and harvested from the Master File (MF) 3F00 and an unnamed EF immediately under the MF with an address 3F00 0000.
.
Your challenge, if you are interested, is to examine the raw data and corroborate whether the data reveals a user's CHV1 (PIN number) or not.
.
To help, you may want to check the GSM SIM card standard GSM 11.11 to comprehend file structure, formatting and coding etc for elementary files and to learn what the standard has to say about CHV/PIN.
.
As forensic investigators you shouldn't need the 'carrot and stick' approach to get you to undertake this challenge because I know how much you all love your work and can't get enough of it and that should be reward enough :-). However, the first person who posts the correct answer at Forensic Focus , I am sure we can sort out some sort of prize:
.
http://www.forensicfocus.com/index.php?name=Forums&file=viewtopic&t=3349
.
However, there are some rules (there is always something like this):
.
1) In your answer it should contain identification to a document or weblink that supports the answer (the document/weblink must be traceable and not based on "something somebody told you"). This will be checked before any prize is awarded.
2) Challenge closes 15th February 2009.
3) I wont be giving the answer, because I do not want everyone just to sit back and think they can wait for my reply.
.
GOOD LUCK
.
PHASE 1 SIM Card
3F00
--------------------------------------------------------------------------------
Response: 00 00 1A 47 3F 00 00 00 F1 F4 44 13 15 83 02 03 04 00 82 8A 00 00 00 00 00 00 00 00 00 00 00 00 00 00
----------------------------------------
Allocated memory :1A47File ID :3F00
Type of file :MFNumber of DF : 2
Number of EF : 3 Number of CHV's : 4
CHV1(PIN1) :Disabled
CHV1(PIN1) Status :2 Tries left
CHV1(PIN1) Status :10 Tries left
CHV1(PIN1) Status :0 Tries left
CHV1(PIN1) Status :0 Tries left
--------------------------------------------------------------------------------
.
3F00:0000
--------------------------------------------------------------------------------
Response: 00 00 00 18 00 00 00 00 FF FF FF 13 06 00 00 02 01 00 00 0A FF
----------------------------------------
File ID :0000
Type of file :RFU
Structure of file :Transparent
File Size :0018
Read Access :CHV (PIN) 15
Write Access :CHV (PIN) 15
Increase Access :CHV (PIN) 15
Rehabilitate :CHV (PIN) 15
Invalidate Access :CHV (PIN) 15
File Status :Not Invalidated
--------------------------------------------------------------------------------
.
Phase 2 SIM Card
3F00
--------------------------------------------------------------------------------
Response: 00 00 63 9C 3F 00 01 FF FF FF FF 01 0E 93 02 07 02 00 83 8A 00 00 00 00 83 00 FF
----------------------------------------
Allocated memory :639C
File ID :3F00
Type of file :MF
Number of DF : 2
Number of EF : 7
Number of CHV's : 2
CHV1(PIN1) :Disabled
CHV1(PIN1) Status :3 Tries left
CHV1(PIN1) Status :10 Tries left
CHV1(PIN1) Status :0 Tries left
CHV1(PIN1) Status :0 Tries left
--------------------------------------------------------------------------------
.
3F00:0000
--------------------------------------------------------------------------------
Response: 00 00 00 12 00 00 04 00 FA FF FF 01 02 00 00
----------------------------------------
File ID :0000
Type of file :EF
Structure of file :Transparent
File Size :0012
Read Access :CHV (PIN) 15
Write Access :CHV (PIN) 10
Increase Access :CHV (PIN) 15
Rehabilitate :CHV (PIN) 15
Invalidate Access :CHV (PIN) 15
File Status :Not Invalidated
--------------------------------------------------------------------------------
.
Phase 3 (2+) SIM Card
3F00
--------------------------------------------------------------------------------
Response: 00 00 00 01 3F 00 01 00 00 00 00 00 09 81 04 12 0A 00 83 8A 83 8A
----------------------------------------
Allocated memory :0001
File ID :3F00
Type of file :MF
Number of DF : 4
Number of EF : 18
Number of CHV's : 10
CHV1(PIN1) :Disabled
CHV1(PIN1) Status :3 Tries left
CHV1(PIN1) Status :10 Tries left
CHV1(PIN1) Status :3 Tries left
CHV1(PIN1) Status :10 Tries left
--------------------------------------------------------------------------------
.
3F00:0000
--------------------------------------------------------------------------------
Response: 00 00 00 17 00 00 04 00 FB FF FF 01 02 00 00
----------------------------------------
File ID :0000
Type of file :EF
Structure of file :Transparent
File Size :0017
Read Access :CHV (PIN) 15
Write Access :CHV (PIN) 11
Increase Access :CHV (PIN) 15
Rehabilitate :CHV (PIN) 15
Invalidate Access :CHV (PIN) 15
File Status :Not Invalidated
--------------------------------------------------------------------------------

SIM PIN Challenge

SIM PIN Challenge

.

Back in 2005 I was at a presentation by a SIM manufacturer when the presentation turned to CHV (Card Holder Verification), the correct technical term for PIN used for SIM Cards.

.

The presentation had reached the part "Verifying the CHV" and went on to record:

.

~ To verify PIN, the verifyCHV APDU is used....

.

A0 20 00 CHVNum 08 PINValue

.

~ The message sent from the phone to the SIM in order to check your PIN number 1111, is:

.

A0 20 00 01 08 313131FFFFFFFF

.

This all seemed normal until three slides later when the presentation started to discuss "File Structure after personalization" and displayed the graphics starting with the Master File (MF) and under which there were five Elementary Files (EF). The graphics displayed in the presentation were text book style when discussing MF and EFs, except for this presentation the manufacturer had gone as far as to identify two particular CHV EFs; one of which was 3F00 - EF_CHV1 0000.

.

.So does that mean a particular EF under the MF in SIM with a logical address 3F00 0000 is always going to be the CHV1 file and would the raw data from that EF reveal a user's PIN number?
.
Below are raw data extracts from three phases of SIM cards - Phase 1, Phase 2 and Phase 3 (2+) and harvested from the Master File (MF) 3F00 and an unnamed EF immediately under the MF with an address 3F00 0000.
.
Your challenge, if you are interested, is to examine the raw data and corroborate whether the data reveals a user's CHV1 (PIN number) or not.
.
To help, you may want to check the GSM SIM card standard GSM 11.11 to comprehend file structure, formatting and coding etc for elementary files and to learn what the standard has to say about CHV/PIN.
.
As forensic investigators you shouldn't need the 'carrot and stick' approach to get you to undertake this challenge because I know how much you all love your work and can't get enough of it and that should be reward enough :-). However, the first person who posts the correct answer at Forensic Focus , I am sure we can sort out some sort of prize:
.
http://www.forensicfocus.com/index.php?name=Forums&file=viewtopic&t=3349
.
However, there are some rules (there is always something like this):
.
1) In your answer it should contain identification to a document or weblink that supports the answer (the document/weblink must be traceable and not based on "something somebody told you"). This will be checked before any prize is awarded.
2) Challenge closes 15th February 2012.
3) I wont be giving the answer, because I do not want everyone just to sit back and think they can wait for my reply.
.
GOOD LUCK
.
PHASE 1 SIM Card
3F00
--------------------------------------------------------------------------------
Response: 00 00 1A 47 3F 00 00 00 F1 F4 44 13 15 83 02 03 04 00 82 8A 00 00 00 00 00 00 00 00 00 00 00 00 00 00
----------------------------------------
Allocated memory :1A47File ID :3F00
Type of file :MFNumber of DF : 2
Number of EF : 3 Number of CHV's : 4
CHV1(PIN1) :Disabled
CHV1(PIN1) Status :2 Tries left
CHV1(PIN1) Status :10 Tries left
CHV1(PIN1) Status :0 Tries left
CHV1(PIN1) Status :0 Tries left
--------------------------------------------------------------------------------
.
3F00:0000
--------------------------------------------------------------------------------
Response: 00 00 00 18 00 00 00 00 FF FF FF 13 06 00 00 02 01 00 00 0A FF
----------------------------------------
File ID :0000
Type of file :RFU
Structure of file :Transparent
File Size :0018
Read Access :CHV (PIN) 15
Write Access :CHV (PIN) 15
Increase Access :CHV (PIN) 15
Rehabilitate :CHV (PIN) 15
Invalidate Access :CHV (PIN) 15
File Status :Not Invalidated
--------------------------------------------------------------------------------
.
Phase 2 SIM Card
3F00
--------------------------------------------------------------------------------
Response: 00 00 63 9C 3F 00 01 FF FF FF FF 01 0E 93 02 07 02 00 83 8A 00 00 00 00 83 00 FF
----------------------------------------
Allocated memory :639C
File ID :3F00
Type of file :MF
Number of DF : 2
Number of EF : 7
Number of CHV's : 2
CHV1(PIN1) :Disabled
CHV1(PIN1) Status :3 Tries left
CHV1(PIN1) Status :10 Tries left
CHV1(PIN1) Status :0 Tries left
CHV1(PIN1) Status :0 Tries left
--------------------------------------------------------------------------------
.
3F00:0000
--------------------------------------------------------------------------------
Response: 00 00 00 12 00 00 04 00 FA FF FF 01 02 00 00
----------------------------------------
File ID :0000
Type of file :EF
Structure of file :Transparent
File Size :0012
Read Access :CHV (PIN) 15
Write Access :CHV (PIN) 10
Increase Access :CHV (PIN) 15
Rehabilitate :CHV (PIN) 15
Invalidate Access :CHV (PIN) 15
File Status :Not Invalidated
--------------------------------------------------------------------------------
.
Phase 3 (2+) SIM Card
3F00
--------------------------------------------------------------------------------
Response: 00 00 00 01 3F 00 01 00 00 00 00 00 09 81 04 12 0A 00 83 8A 83 8A
----------------------------------------
Allocated memory :0001
File ID :3F00
Type of file :MF
Number of DF : 4
Number of EF : 18
Number of CHV's : 10
CHV1(PIN1) :Disabled
CHV1(PIN1) Status :3 Tries left
CHV1(PIN1) Status :10 Tries left
CHV1(PIN1) Status :3 Tries left
CHV1(PIN1) Status :10 Tries left
--------------------------------------------------------------------------------
.
3F00:0000
--------------------------------------------------------------------------------
Response: 00 00 00 17 00 00 04 00 FB FF FF 01 02 00 00
----------------------------------------
File ID :0000
Type of file :EF
Structure of file :Transparent
File Size :0017
Read Access :CHV (PIN) 15
Write Access :CHV (PIN) 11
Increase Access :CHV (PIN) 15
Rehabilitate :CHV (PIN) 15
Invalidate Access :CHV (PIN) 15
File Status :Not Invalidated
--------------------------------------------------------------------------------