Smart Cards
Smartcard Contact Pads

After a long (14 year) hiatus, I recently dug out an old Towitoko ChipDrive smartcard reader and resumed writing code for it.

Towitoko was acquired by SCM Microsystems in 2002. Later that year they changed their name to Tx Systems, Inc. You can see their website here.


C1 Supply voltage Between 4.5 and 5.5 volts. Consumption not to exceed 10 milliamps at any acceptable frequency.
C2 Reset signal  
C3 Clock signal 1 to 5 MHz, provided externally.
Duty cycle of 40% to 60% of the period.
C4 Reserved No connection.
C5 Ground  
C6 Programming voltage Not typically provided on plug-in SIMs.
C7 Input/Output A 20 kilo-ohm resistor is recommeded on the interface device.
Baudrate is (clock frequency) / 372.
C8 Reserved No connection.
ISO/IEC 7816-3 pins and their GSM values.


Global System for Mobiles (GSM) uses a personalized smartcard, called a Subscriber Identity Module (SIM) to provide storage and authentication functions for the customer.

Interesting information can be extracted from the SIM.


The mobile equipment communicates with the SIM using standard ISO 7816-3 Operating Procedures (a copy of parts 1, 2, and 3 can be found here).

This transmission protocol uses Application Protocol Data Units (APDU), which can be either commands or responses. These are sent across the electrical interface between the SIM and the mobile equipment, or the SIM-ME interface for short.

CLA INS P1 P2 P3 Data
Command APDU format.

There are five fields in an APDU command. The class of instruction (CLA) is always A0 for GSM. The instruction code (INS) indicates the particular command to be performed. P1, P2, and P3 are parameters for the command, with P3 containing the length of the Data segment, if any.

Data SW1 SW2
Response APDU format.

The response to a command is returned in three fields. The Data portion, if any, contains information requested in the command. SW1 and SW2 are status words indicating the success or failure of the command.

A number of commands are defined for GSM SIM cards, including functions to read and write data, confirm security features, and run the GSM authentication algorithm. Completing an entire GSM procedure may require a series of APDU command/response pairs.

SELECT A4 00 00 02
STATUS F2 00 00 length
READ BINARY B0 offset (high) offset (low) length
UPDATE BINARY D6 offset (high) offset (low) length
READ RECORD B2 record number mode length
UPDATE RECORD DC record number mode length
SEEK A2 00 type/mode length
INCREASE 32 00 00 03
VERIFY CHV 20 00 CHV number 08
CHANGE CHV 24 00 CHV number 10
DISABLE CHV 26 00 01 08
ENABLE CHV 28 00 01 08
UNBLOCK CHV 2C 00 00 (for CHV1)
02 (for CHV2)
INVALIDATE 04 00 00 00
REHABILITATE 44 00 00 00
SLEEP FA 00 00 00
GET RESPONSE C0 00 00 length
SIM command coding.


The SIM maintains information in a series of "files" that are organized hierarchically, much like the operating system of a personal computer. These files may be for administrative purposes or be specific to the GSM user application. Data in these files are accessed through APDU commands sent to the operating system.

A file is composed of a header and a body. The header contains structure and attribute information and is managed by the operating system. The body, which is optional, contains the actual data. Files are uniquely identified by a two-byte hexadecimal number.

First Byte GSM file type
3F Master File
7F Dedicated File
2F Elementary File under the Master File
6F Elementary File under a Dedicated File
GSM file type identifiers (first byte).

There are three different types of files on a SIM: a master file (MF), dedicated files (DF), and elementary files (EF). There is one master file on a SIM, which holds all the other files in a tree-like structure. Dedicated files are headers that hold hierarchical trees of elementary files, but don't have data of their own. GSM defines two dedicated files immediately under the MF, DFGSM containing GSM application files and DFTELECOM containing the application service features.

Elementary files (EF) have both a header and a body, and come in three flavors. The first, called transparent, is a binary file that can store information of varying length in any location. This is a raw, unstructured, random access file. The second is called linear fixed and stores data records that all have the same fixed length. The third is termed cyclic and is designed to store records in chronological order. It also uses fixed-length records, but when the last entry is full the next record overwrites the oldest entry.


In the following examples, the Towitoko-specific bytes sent from the computer are also included. These bytes are necessary in order to get the Towitoko reader to interact with the SIM card. Other types of readers will not need these bytes but may have different control sequences.

To access the Master File, we perform two steps. First, issue a "SELECT" instruction. If it is successful, we issue a "GET RESPONSE" instruction to retrieve the response data from the "SELECT" instruction.

  1. Send the APDU to "SELECT" the Master File (which has the identifier 3F 00):

    To Towitoko (9 bytes): 6F 05 05 62 A0 A4 00 00 02
    From Towitoko (1 byte): A4
    To Towitoko (6 bytes): 6F 02 05 7E 3F 00
    From Towitoko (2 bytes): 9F 1A

  2. Now send the APDU to GET RESPONSE from the previous SELECT instruction, using the length information (1A from the 9F status). Note that we actually get back three additional bytes on top of the indicated 26 bytes:

    To Towitoko (9 bytes): 6F 05 05 62 A0 C0 00 00 1A
    From Towitoko (29): C0 00 00 AC FF 3F 00 01 00 00 00 00 00 0D 13 02 04 04 00 83 8A 83 8A 00 01 AC FF 90 00

This 29-byte response has three parts:

[MF/DF] RFU: 00 00
  Free Memory: AC FF
  File ID:     3F 00 (MF)
  File Type:   01 (Master File)
  RFU:         00 00 00 00 00
  Length Following: 0D
  File characteristics:    13
    Clock stop:     Allowed, no preferred level
    Required speed: 13/4
    CHV:            Enabled
  Child DFs:               02
  Child EFs:               04
  CHVs, Unblock CHVs, etc: 04
  RFU:                     00
  CHV1 Status:             83 (Initialized, 3 remaining)
  Unblock CHV1 Status:     8A (Initialized, 10 remaining)
  CHV2 Status:             83 (Initialized, 3 remaining)
  Unblock CHV2 Status:     8A (Initialized, 10 remaining)
  RFU:                     00

To read an Elementary File, perform the following steps:

  1. Send the APDU to SELECT the desired Elementary File. The proper Master File or Directory File must have been selected previously. In this example we read the ICCID file (identifier 2F E2).

    To Towitoko (9 bytes): 6F 05 05 62 A0 A4 00 00 02
    From Towitoko (1 byte): A4
    To Towitoko (6 bytes): 6F 02 05 7E 2D E2
    From Towitoko (2 bytes): 9F 0F

  2. Now send the APDU to GET RESPONSE from the previous SELECT instruction, using the length information (0F from the 9F status):

    To Towitoko (9 bytes): 6F 05 05 62 A0 C0 00 00 0F
    From Towitoko (18): C0 00 00 00 0A 2F E2 04 00 04 00 44 01 01 00 00 90 00

    [EF] RFU:    00 00
      File Size:   00 0A
      File ID:     2F E2 (EF-ICCID)
      File Type:   04 (Elementary File)
      RFU:         00
      Access:      04 00 44
        Read/Seek:    Always
        Update:       Admin 4
        Increase:     Always
        RFU:          Always
        Rehabilitate: Admin 4
        Invalidate:   Admin 4
      Status:      01 (Not Invalidated)
      Length:      01
      EF Structure:  00 (Transparent)

  3. Now we read the contents of the file. This is a transparent type of data file, so we can perform a binary read. We request the 10 bytes (the 00 0A file size) as given in the file information:

    To Towitoko (9 bytes): 6F 05 05 62 A0 B0 00 00 0A
    From Towitoko (13 bytes): B0 98 88 61 39 52 00 10 81 51 F4 90 00

    Again we discard the first byte (B0, the original "READ BINARY" instruction) and the last two bytes (90 00, the two status words that indicate success). The remaining ten bytes are interpreted this way:

      Identification Number: 8 9 8 8 1 6 9 3 2 5 0 0 0 1 1 8 1 5 4
      Luhn is 4, computed is 4.
      MII: 89 (Telecommunications), Country ID: 881 (Global Mobile Satellite System), Issuer ID: 6 (Iridium)

Hacker Glider Send mail to Dan Veeneman
Last revised February 5, 2013