MagicSIM » History » Version 7
tnt, 02/19/2016 10:48 PM
1 | 7 | tnt | {{>toc}} |
---|---|---|---|
2 | 2 | laforge | |
3 | 7 | tnt | When you want to use [[OpenBSC]] with actual cryptographic authentication, then the secret Ki of the SIM needs to be known. |
4 | 1 | laforge | |
5 | Extracting the Ki of regular SIM cards issued by GSM operators is typically not possible. |
||
6 | |||
7 | Therefore, we need some alternative solution: A SIM with a known A3/A8 algorithm, where we can program the actual Ki. |
||
8 | |||
9 | |||
10 | 7 | tnt | h2. Magic SIM / Super SIM 16-in-1 |
11 | |||
12 | |||
13 | Various stores around the world seem to be selling cheap so-called _16-in-1_ SIM cards. They are intended for COMP128v1 based cloning, |
||
14 | 1 | laforge | and enable the user to aggregate up to 16 SIM card identities on one card. They include a SIM toolkit (STK) application for switching |
15 | the currently active identity from the Phone UI. |
||
16 | |||
17 | Unfortunately those cards come without any documentation and only with a proprietary Windows-based tool for programming. |
||
18 | |||
19 | We've spent some time reverse engineering those cards. Here is some information on how you can program them. |
||
20 | |||
21 | Please note, this information assumes that you are generally familiar with ISO 7816-4 smart cards, as well as the GSM 11.11 specification. |
||
22 | |||
23 | 7 | tnt | The traces have been generated using "but any tool that allows you to send and receive APDUs will work. |
24 | 1 | laforge | |
25 | |||
26 | 7 | tnt | h3. DF.ADMIN |
27 | 1 | laforge | |
28 | 7 | tnt | |
29 | DF.ADMIN is a dedicated file (directory) with the File ID *7f 4d*. It contains EF's with the user-modifiable IMSI, Ki and other values. |
||
30 | |||
31 | You can change to DF.ADMIN using the SELECT sequence *a0 a4 00 00 02 7f 4d* |
||
32 | <pre> |
||
33 | 1 | laforge | (GSM, ISO 7816-4) > a0 a4 00 00 02 7f 4d |
34 | 7 | tnt | 0000: 00 00 60 33 7f 4d 02 00 00 00 00 00 0a 91 08 18 ..@3.M.......... |
35 | 1 | laforge | 0010: 06 00 83 8a 83 8a 00 ....... |
36 | Normal execution (SW 9000) |
||
37 | 7 | tnt | </pre> |
38 | 1 | laforge | |
39 | |||
40 | 7 | tnt | h4. EF.OPN Operator Name |
41 | 1 | laforge | |
42 | 7 | tnt | |
43 | EF.OPN is a record-oriented file with the File ID *8f 0c* and a record-length of 0x12. |
||
44 | |||
45 | 1 | laforge | Records are numbered 0x02..0x11, one for each of the 16 identities that you can store on the SIM. |
46 | |||
47 | You can select and read the records in this file using the following example APDU sequence: |
||
48 | 7 | tnt | <pre> |
49 | 1 | laforge | (GSM, ISO 7816-4) > a0 a4 00 00 02 8f 0c |
50 | 0000: 00 00 01 44 8f 0c 04 00 00 f0 44 01 02 01 12 ...D......D.... |
||
51 | Normal execution (SW 9000) |
||
52 | |||
53 | (GSM, ISO 7816-4) > a0 b2 02 04 12 |
||
54 | 0000: 4f 70 65 72 61 74 6f 72 31 ff ff ff ff ff ff ff Operator1....... |
||
55 | 0010: 09 01 .. |
||
56 | Normal execution (SW 9000) |
||
57 | 7 | tnt | </pre> |
58 | 1 | laforge | In this example, the record 0x02 (i.e. the first record) is called "Operator1" |
59 | |||
60 | |||
61 | |||
62 | 7 | tnt | h4. EF 8f 0d: Ki, IMSI, ICCID |
63 | |||
64 | |||
65 | 1 | laforge | This EF contains the Ki (secret A3/A8 key), the IMSI (subscriber identity number) and the ICCID (card serial number). |
66 | It is a record-oriented file with a record length of 0x4a bytes. There is one record for each of the identities that |
||
67 | the card supports. They are numbered from 0x01 up to 0x10. |
||
68 | |||
69 | The following sequence reads the contents of this EF: |
||
70 | 7 | tnt | <pre> |
71 | 1 | laforge | (GSM, ISO 7816-4) > a0 a4 00 00 02 8f 0d |
72 | 0000: 00 00 04 a0 8f 0d 04 00 00 f0 44 01 02 01 4a ..........D...J |
||
73 | Normal execution (SW 9000) |
||
74 | |||
75 | (GSM, ISO 7816-4) > a0 b2 01 04 4a |
||
76 | 0000: 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 """""""""""""""" |
||
77 | 0010: 3f 00 2f e2 0a 44 44 44 44 44 44 44 44 44 44 7f ?./..DDDDDDDDDD. |
||
78 | 0020: 20 6f 07 09 11 11 11 11 11 11 11 11 11 6f 30 18 o...........o0. |
||
79 | 0030: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ |
||
80 | 0040: ff ff ff ff ff ff ff ff ff ff .......... |
||
81 | Normal execution (SW 9000) |
||
82 | 7 | tnt | </pre> |
83 | 1 | laforge | |
84 | In this example, the following numbers have been added for illustration purpose: |
||
85 | 7 | tnt | * 22 = Ki, to be used for RUN GSM ALGORITHM (COMP128v1) |
86 | * 44 = ICCID, exported through EF.ICCID |
||
87 | * 11 = IMSI, exported through EF.IMSI |
||
88 | * ff = PLMN selector, exported through EF.PLMNsel |
||
89 | 1 | laforge | |
90 | As you can also see, each of the file contents (except Ki) is prefixed with the file name + path |
||
91 | and the length. |
||
92 | 7 | tnt | <pre> |
93 | 1 | laforge | DF DF EF EF LEN File content |
94 | 3f 00 2f e2 0a 44 44 44 44 44 44 44 44 44 44 |
||
95 | 7f 20 6f 07 09 11 11 11 11 11 11 11 11 11 |
||
96 | 6f 30 18 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |
||
97 | 7 | tnt | </pre> |
98 | 1 | laforge | it is thus likely that you can generate arbitrary files+content, as long as the format is correct. |
99 | |||
100 | 5 | tnt | |
101 | 7 | tnt | h4. EF 8f 0e: SMS parameters |
102 | |||
103 | |||
104 | The content of records in EF *8f 0e* is used to generate the EF.SMSP (short message service parameters). |
||
105 | 1 | laforge | It is a record-based file with a record length of 32 bytes. Records are numbered from 0x01 through 0x10 |
106 | |||
107 | Reading this file works as follows: |
||
108 | 7 | tnt | <pre> |
109 | 1 | laforge | (GSM, ISO 7816-4) > a0 a4 00 00 02 8f 0e |
110 | 0000: 00 00 03 20 8f 0e 04 00 00 f0 44 01 02 01 32 ... ......D...2 |
||
111 | Normal execution (SW 9000) |
||
112 | (GSM, ISO 7816-4) > a0 b2 01 04 32 |
||
113 | 0000: 3f 00 7f 10 6f 42 01 28 ff ff ff ff ff ff ff ff ?...oB.(........ |
||
114 | 0010: ff ff ff ff fd ff ff ff ff ff ff ff ff ff ff ff ................ |
||
115 | 0020: ff 08 91 33 33 33 33 33 33 33 33 33 33 ff ff ff ...3333333333... |
||
116 | 0030: ff ff .. |
||
117 | Normal execution (SW 9000) |
||
118 | 7 | tnt | </pre> |
119 | 1 | laforge | |
120 | 6 | tnt | The content seems to be similar to the previous file but targeted at record based EFs: |
121 | 7 | tnt | * 3f 00 is the MF |
122 | * 7f 10 is DF.telecom |
||
123 | * 6f 42 is EF.SMSP |
||
124 | * 01 is the record number |
||
125 | * 28 is the record length |
||
126 | 2 | laforge | |
127 | |||
128 | |||
129 | 7 | tnt | h3. The included USB Reader |
130 | |||
131 | |||
132 | 2 | laforge | The 16-in-1 cards include a small USB-key SIM card reader in a transparent plastic case. |
133 | |||
134 | 7 | tnt | This reader follows a so-called _Phoenix_ design, in which a 3.579 MHz crystal is used in combination with two inverters of a 74HC08 to clock the card, while two other inverters and a transistor are used to connect the data line to a RS232 port. The schematics are probably very close to [http://www.circuitsarchive.org/index.php/SmartCard_PC_Serial_Reader_/_Writer_%28Phoenix%29":http://svn.ploetzli.ch/cyberflex-shell/], |
135 | 2 | laforge | |
136 | 4 | tnt | The reader included with the 16-in-1 SIM card also accomodates a Prolific PL-2303 USB to RS232 converter. It will thus show up as a regular serial port on any operating system. |
137 | |||
138 | There's a small switch on the side of the key, it select between two crytal frequencies: |
||
139 | 7 | tnt | * 3.579 MHz leading to a 9600 baudrate when the switch is _away_ from the USB plug (i.e. the switch needs to be closer to the SIM than to the USB plug) |
140 | * 7.2 MHz leading to a 19200 baudrate when the switch is _towards' the USB plug. |
||
141 | 2 | laforge | |
142 | For best compatibility both with existing software and with 'slow' cards, select the 9600 baudrate. |
||
143 | |||
144 | You can use the following open source tools for using the reader: |
||
145 | 7 | tnt | * "(MacOS out of the box, hacking /dev/ttyUSB0 into the source makes it work on Linux, too) |
146 | * [http://www.opensc-project.org/openct/wiki/smph":http://freshmeat.net/projects/sctk/] commandline tools |