PDA

Просмотр полной версии : Экспертиза эмуляторов SIM (U-SIM, R-UIM...)



abvg
19.03.2005, 13:07
Цель данного треда – перевести уровень обсуждения наших проблем, связанных с эксплуатацией SIM эмуляторов совместно с ME (Mobile Equipment) на более высокий уровень - технический.

Задача – помочь с выбором конкретной прошивки и с написанием последующих прошивок.

Я начну, а в зависимости от активности и интереса уважаемых коллег, пойдем дальше и глубже (или не пойдем).

На первом этапе анализировались широко известные прошивки:
TWINSIM, DejanGold, SIM_EMU_6.01, Kismi1, Kismi8.

Задачи: посмотреть, что и как сделано


a) Эмулируемые ATR (ничего интересного – одни исторические байты. Как видим, указание класса TA2 по питанию A,B,C,D – отсутствует. Только через STATUS!):

TWINSIM 3F 2F 00 80 69 AF 02 04 01 36 00 02 0A 0E 83 3E 9F 16
Dejan 3F 2F 00 80 69 AF 02 04 01 31 00 00 00 0E 83 3E 9F 16
SIM_EMU_6.01
Kismi1 3F 2F 00 80 69 AF 02 04 01 36 00 02 0A 0E 83 3E 9F 16
Kismi8 3F 2F 00 80 69 AF 02 04 01 31 00 00 00 0E 83 3E 9F 16

Здесь:
3F – Inverse convention
2F – TB1 only & 15 исторических байтов
00 – TB1 = VPP is not connected
Остальное – ерунда (главное применение – увековечить свой nick!)

б) Реальные ATR(кусочек для сравнения:

Gemplus GemXplore 3F 2F 00 80 59 AF 02 01 01 30 00 00 0A 0E 83 06 9F 12
e-plus (1800MHz) 3F 2F 00 80 69 AE 02 02 01 36 00 00 0A 0E 83 3E 9F 16
D2 CallYa (900MHz) 3F 2F 00 80 69 AF 02 04 01 36 00 02 0A 0E 83 3E 9F 16
GemXplore 98 V1 16K 3F 2F 00 80 69 AF 03 07 03 52 00 00 0A 0E 83 3E 9F 16
DebitelD2 (900MHz) 3F 2F 00 80 69 AF 03 07 03 52 00 0D 0A 0E 83 3E 9F 16
Virgin Mobile (Gemplus) 3F 2F 00 80 69 AF 03 07 03 5A 00 15 0A 0E 83 3E 9F 16
French GSM (900MHz) 3F 69 00 00 24 AF 01 70 01 01 FF 90 00
BEN (1800MHz) 3B 0A 20 62 0C 01 4F 53 45 99 14 AA
Sonera(from 1998) 3B 0F 80 6A 16 32 46 49 53 45 53 8C E0 FF 07 90 00
Etc...

в) Класс команд – A0! (Кстати, мало кто из эмуляторов его проверяет?!)

г) Эмулируемые команды:

A4 SELECT Twin Dejan 6.01 Kismi1 Kismi8
B0 READ BINARY Twin Dejan 6.01 Kismi1 Kismi8
B2 READ RECORD Twin Dejan 6.01 Kismi1 Kismi8
DC UPDATE RECORD Twin Dejan 6.01 Kismi1 Kismi8
C0 GET RESPONSE Twin Dejan 6.01 Kismi1 Kismi8
F2 STATUS Twin Dejan 6.01 Kismi1 Kismi8
D6 UPDATE BINARY Twin Dejan 6.01 Kismi1 Kismi8
88 RUN GSM ALGORITHM Twin Dejan 6.01 Kismi1 Kismi8
20 VERIFY CHV(PIN) Twin Dejan 6.01 Kismi1 Kismi8
24 CHANGE CHV(PIN) Twin 6.01 Kismi1 Kismi8
26 DISABLE CHV(PIN) Twin 6.01 Kismi1 Kismi8
28 ENABLE CHV(PIN) Twin 6.01 Kismi1 Kismi8
2C UNBLOCK CHV(PIN) Twin 6.01 Kismi1
04 INVALIDATE 6.01 Kismi1
10 TERMINAL PROFILE 6.01
12 FETCH 6.01
14 TERMINAL RESPONSE 6.01
32 INCREASE 6.01
44 REHABILITATE 6.01
A2 SEEK 6.01
C2 ENVELOPE 6.01
FA SLEEP Dejan 6.01 Kismi8

д) In addition the following codes are reserved:

- GSM operational phase: 16 18 1A 1C 1E

- Administrative management phase: 2A D0 D2 C4 C6 C8 CA B4 B6 B8 BA BC

е) НЕПРАВИЛЬНЫЕ (несуществующие) команды

AA ????????? Twin Kismi1
BB ????????? Twin Kismi1
FE ????????? Dejan Kismi8

ж) Дополнения до ПОЛНОГО списка команд (на всякий случай - для тех, кому интересно).

1) ANSI-41-based Security Commands

82 CONFIRM SSD Confirm_SSD (Shared Secret Data)
84 UPDATE SSD Update_SSD
86 AKEY-validation 51.011
88 RUN CAVE Internal_Authentificate
8A BASE STATION CHALENGE Ask_Random
8C CMEA_encrypt
8E GENERATE KEY/VPM

2) OTASP/OTAPA Commands

50 GENERATE PUBLIC KEY
52 KEY GENERATION REQUEST
54 CONFIGURATION REQUEST
56 DOWNLOAD REQUEST
CC COMMIT
CE VALIDATE
EA SSPR CONFIGURATION REQUEST
EC SSPR DOWNLOAD REQUEST
EE OTAPA REQUEST

3) ESN Management Command

DE STORE ESN_ME

з) Запрещенные команды во всех классах:
- 6Х;
- 9Х;
- нечетные.



Результаты.

При осуществлении операций в GSM сети крайне важен интерфейс GSM-ME в виде:
- пар GSM-команд и ответов;
- GSM процедур состоящих их одной или нескольких таких пар, выполняющих всю или некоторую часть прикладной задачи. (Важно – ME предполагает, что процедура НЕ прервется где-то внутри своего исполнения, вернее, что не существуют недокументированных прерываний.)
- GSM сессий.

Если посмотреть на сессии и процедуры для различных ME, то легко видеть, что используются ВСЕ команды – лишних НЕТ. Проектировщики ОС для МЕ используют ВСЁ пространство команд. Урезанные EMU сильно рискуют. И только дело случая...
Занятно, что в одной программе Kismi, в разных режимах РАЗНЫЕ подмножества команд(?!)

Что же касается P1, P2, Lc – полный бардак! НИКТО НИЧЕГО в эмуляторах не проверяет. Даже класса команд! Не факт, что все приложения ОС ME корректно работают.
Плохо написаны драйверы(только Dejan – молодец), отсутствует PTS, обработка ошибок приема/передачи. Как мелкий пример – в драйвере работы с DATA EEPROM в 6.01 при записи забыли про запрет прерываний. И т.п., и т.д....
Вот оно и глючит.
Какой эмулятор выбрать – решайте сами.

abvg
24.03.2005, 12:34
Данный пост продолжает тему и отвечает на вопрос поднятый в треде Gold card ???




Итак, рассмотрим начало содержимого EEPROM, которое генерирует
преусловутоя программа TwinSim.


:10 0000 00 31313131FFFFFFFF39383738FFFFFFFF 00
:10 0010 00 33333333333333333333333333333333 F0
:10 0020 00 3FF2FF4F24F234F1CC23C23CF1324FCD E0
:10 0030 00 0977777777777777777709F1CC23C23C D0
:10 0040 00 F1324FCD096D3CFF7C54ADD00001040A C0
:10 0050 00 010302097DD6D0A2F14FEC000004FFFF B0
:10 0060 00 FFFF010A0300000004CF3FCF0F03FFFF A0
:10 0070 00 FF05FFFFFF00000213FF140032008CFF 90
:10 0080 00 FFFFFF0034FFFFFFFFFFFFFFFFFFFF10 80
................................................

Напомню фрагмент описания формата HEX (конечно, исключительно для тех, кто подзабыл - уверен, что пригодится еще не раз...)

General Record Format

| RECORD | LOAD | | | INFO | |
| MARK | RECLEN | OFFSET | RECTYP | or | CHKSUM |
| ':' | | | | DATA | |
1-byte 1-byte 2-bytes 1-byte n-bytes 1-byte

Each record begins with a RECORD MARK field containing 03AH, the ASCII code for the colon (':') character.

Each record has a RECLEN field which specifies the number of bytes of information or data which follows the RECTYP field of the record. Note that one data byte is represented by two ASCII characters. The maximum value of the RECLEN field is hexadecimal 'FF' or 255.

Each record has a LOAD OFFSET field which specifies the 16-bit starting load offset of the data bytes, therefore this field is only used for Data Records. In other records where this field is not used, it should be coded as four ASCII zero characters ('0000' or 030303030H).

Each record has a RECTYP field which specifies the record type of this record. The RECTYP field is used to interpret the remaining information within the record. The encoding for all the current record types are:

'00' Data Record
'01' End of File Record
'02' Extended Segment Address Record
'03' Start Segment Address Record
'04' Extended Linear Address Record
'05' Start Linear Address Record

Each record has a variable length INFO/DATA field, it consists of zero or more bytes encoded as pairs of hexadecimal digits. The interpretation of this field depends on the RECTYP field.

Each record ends with a CHKSUM field that contains the ASCII hexadecimal representation of the two's complement of the 8-bit bytes that result from converting each pair of ASCII hexadecimal digits to one byte of binary, from and including the RECLEN field to and including the last byte of the INFO/DATA field.

Therefore, the sum of all the ASCII pairs in a record after converting to binary, from the RECLEN field to and including the CHKSUM field, is zero.



Как хорошо видно, автор TwinSim’a не позаботился о подсчете КС(CHKSUM), и, как следствие этого, НИ ОДИН программатор работающий с данными в HEX формате ЭТО зашивать и не ДОЛЖЕН!

Чтобы долго не возится, я обычно конвертирую такое фуфло в BIN с помощью любимого WinHex 11.9 ... и всё!

З.Ы. Кстати, обратите внимание на то, как в одну кучу свалены PIN1, PIN2, KI1, KI2, IMSI1, IMSI2,... Никакой структуры нет и в помине – ВОТ ОНО иногда :) И НЕ РАБОТАЕТ!

piir
24.03.2005, 16:03
Конечно все это интересно но я давно HEX BINом пользуюсь.
В дополнении к экспертизе TwinSim cNOKIA 6100 6610 SamsungA800 работает но примерно до 8 перезагрузок.После чего прочитал СИМ сравнил PIC он без изменений.ЕЕ прочитать не смог т.к. режим СР. с МОТОРОЛАМИ Т190и ему подобными пашет,а вот с Е365 нет.Только вручном режиме и только с одним оператором.
Вот так.
Суважением Палыч.

abvg
25.03.2005, 11:45
Автор оригинала piir
1. ...но я давно HEX BINом пользуюсь.
2. ...прочитал СИМ сравнил PIC он без изменений.
3. ...ЕЕ прочитать не смог т.к. режим СР.


1 Существует ГИГАНТСКАЯ разница между этими программами! Используя WinHex Вы получаете власть над целым миром, а в Н2В только над форматом.

2. Можно было не париться :)
В микроконтроллерах семейства PIC 16F84 отсутсвует возможность
программной записи в программную память, а в
16F87X такая возможность есть (и существенно используется в 6.01)

3. Режим СР - зависит только от твоего желания :confused: