-[ 0x02 ]--------------------------------------------------------------------
-[ GSM_sniff ]---------------------------------------------------------------
-[ by FCA00000 ]-----------------------------------------------------SET-32--

Esta vez voy a seguir con el tema de la red GSM.

Antes de empezar voy a decir una inconsistencia:
Todo cuerpo sumergido en un lquido experimenta un empuje ascendente
igual a la cantidad de lquido desplazado, expecto en Lunes, que es el doble.

Dicho esto, queda claro que este artculo contiene contradiciones y errores.
Por eso, no debes creerte todo lo que digo. Experimenta por tu cuenta y
aprende.

Al parecer, el artculo anterior sobre DOS en GSM fue interesante para al
menos 4 personas, as que voy a continuar contando ms cosas, en esta caso
sobre el protocolo de comunicacin UM, equivalente a algo que se conoce con
el nombre de layer L3.

Como viene siendo habitual para esta serie de artculos, el elemento principal 
es un mvil Siemens S45, con la versin de software S45i_v56.

De todos modos he comprobado que funciona de manera muy similar en otros
modelos Siemens que usan el procesador C166, as que no debera ser difcil
adaptarlo. Dar unas indicaciones para ello.

Al final de cada prrafo recomiendo un libro. No tienes que leerlo
necesariamente en este momento, pero aumentar tu cultura.

********* En busca del byte perdido **************
En el tema anterior titulado DOS_GSM cont que haba encontrado la rutina
que est involucrada en el proceso de enviar los mensajes a la red GSM.
Analizando esos mensajes y estudiando la documentacin GSM se llega a la
conclusin de que los mensajes deben enviarse en bloques de 14 bytes.

Si hay menos de 14 datos, es necesario rellenarlos con caracteres extra.
Este carcter es 0x2B.
As que gracias al traceador que hice, coloco mltiples breakpoints a lo largo
de todo el cdigo del sistema operativo del S45.
Lo que har es buscar varias veces repetido el dato 0x2B.
Pero claro no puedo mirar toda la memoria cada vez. Lo que har es mirar slo
un trozo de 8 bytes.
?Porqu 8 bytes? En principio, no s cual es el mensaje mas pequeo, pero
supongo que es menor de 6 bytes. Entonces debe rellenarse con 8 veces el
valor 0x2B para conseguir que ocupe 14 bytes.

No me cansar de repetirlo: el C166 usa un sistema de direccionamiento de la
memoria en segmentos de 16 Kb, indexados con otro registro cualquiera.
Para leer la memoria 0x123456 se divide entre 0x4000, que resulta 0x48, con
resto (llamado offset) 0x3456.
La manera de leer el dato y meterlo en r12 es:
mov r15, #48h
mov r14, #03456h
extp r15, #1
mov r12, [r14]

?Donde empiezo a buscar? En cualquier sitio. Es decir, tomo un valor aleatorio.
Una buena manera de obtener un valor aleatorio es usar el registro T6, que se
incrementa cada 8 instrucciones.
Con esto obtengo el valor aleatorio del offset. Para elegir un segmento
aleatorio, lo que hago es usar el valor actual de DPP0 o DPP1 o DPP2 o DPP3
dependiendo del primer y el ltimo bit de T6.
?Porqu estos bits?
Uso el bit ltimo porque es suficientemente aleatorio.
Uso el bit primero porque la direccin r14 debe ser menor que 0x4000, para conseguir
sto hay que desechar el bit 15.

Algo as (en pseudo-cdigo):
char lee_mem(x)
{
a=x & 0x8001 ;
switch (a):
 case 0x0000: r15=DPP0;
 case 0x0001: r15=DPP1;
 case 0x8000: r15=DPP2;
 case 0x8001: r15=DPP3;
r14=x & 0x3FFF ;
r12=*(r15:r14) ;
return r12;
}



Esto me sirve para leer un dato. Para leer 8 bytes a partir de T6 y comprobar
que hay varios 0x2B seguidos hago:

inicio=T6;
contador=0;
for(i=0;i<8;i++)
 if(lee_mem(inicio+i)==0x2B)
  contador++;
if(contador==8)
 encontrado_en(inicio);


Cuando encuentro 8 veces el byte de relleno, lo que hago es guardar la
direccin de memoria (inicio) y la rutina desde la que vengo, que est
guardada en la pila.
No slo eso, sino que decido guardar tambin la rutina anterior, y la
anterior de la anterior.
Con esto, necesito 2+2*3=8 bytes para almacenar cada ocurrencia.

?Dnde guardo todos esos valores? En la memoria a partir de 0x0EA000=003A:2000
que parece que no la usa ningn otro programa:

encontrado_en(x)
{
static ultima_direccion=0x0EA000; // al ser static, se inicializa la primera vez
*(ultima_direccion++)=x%0x4000;
*(ultima_direccion++)=x/0x4000;
puntero=puntero_pila; // esto es, el registro SP
for(i=0;i<=2;i++)
 {
 *(ultima_direccion++)=*(puntero++);
 *(ultima_direccion++)=*(puntero++);
 }
}

Por supuesto para que no se salga de los lmites (0x3FF0) hay hay que poner una
condicin del tipo:

if(ultima_direccion>0x0EA000+0x3FF0)
 return;

Bueno, con esto consigo un montn de direcciones que tendra que investigar.

Thomas Mann: Muerte en Venecia
******** Busqueda y captura ***************
Antes que esto, una consideracin: si lo que pretendo es analizar el trfico
de la red, primero necesito generar algo de trfico, ?no?
Lo normal sera efectuar una llamada, o enviar un SMS. Pero esto cuesta
dinero, y no estoy dispuesto a malgastarlo. Adems estos mensajes son pesados
y cabe la posibilidad d que no necesiten relleno.
Estudiando sobre GSM he aprendido que la red de vez en cuando manda mensajes
al mvil, para decirle dnde est, y para que el telfono pueda calcular el
nivel de recepcin de la seal por si quiere pasarse a otra celda.
Estos mensajes se mandan, como mnimo, cada 60 segundos. No es mucho, pero a
ver si me apao con esto. Confo en que alguno sea un simple ACK que
indique que el anterior mensaje ha sido recibido.

Lo bueno es que, como tengo muchas rutinas interceptadas, en cuanto se pongan
los datos a 0x2B, creo que los localizar bastante pronto.

Pongo mi programa en funcionamiento y veo que algunas direcciones aparecen una
y otra vez.
Claro, es porque he usado un planteamiento errneo.
Supongamos que la rutina xxx1 est interceptada, y encuentra la secuencia
en la direccin de memoria yyy1.
Ms tarde, la rutina xxx2 tambin est interceptada, pero quiere la
casualidad que ahora T2 no nos lleva a ninguna direccin con datos 0x2B.
Unas rutinas mas tarde, xxx8 encuentra los datos, pero resultan estar en yyy1.
El fallo est en que esta direccin aparecer 2 veces en mi informe.

La solucion es fcil: si el dato ya est localizado, no lo marco de nuevo:
antes de encontrado_en(x) , miro si ya estaba:
busca(x) {
for(i=0x0EA000=0;i<=ultima_direccion;i+=2*4)
 if(*(i)=x%0x4000 && *(i+1)=x/0x4000 )
  return(1);
return(0);
}

Con esto recopilo un montn ms reducido de direcciones.
Reseteo el mvil, y repito el experimento unas cuantas veces.
Muchas de ellas no se vuelven a repetir, pero otras aparecen una y otra vez.
Lo sorprendente es que las rutinas alrededor de la direccin C91F00=0324:1F00
aparecen una y otra vez.
Las investigo, y parece que leen y copian, usando un conjunto de direcciones
alrededor de 00E8D8=0003:28D8
Creo que esas direcciones es la DMA, la Direct Memory Access, que permite que
el procesador C166 y el procesador de comunicaciones de radio DSP puedan
intercambiar datos.

Una rutina tpica:
C91F54: mov   r14, #0Ch  ; numero de bytes a copiar = 12, incluyendo L2, que
C91F56: mov   [-r0], r14 ; explicar ms adelante
C91F58: mov   r15, r12   ; r1:r2 contiene los datos a copiar
C91F5A: mov   r1, r13
C91F5C: mov   r12, #28BCh
C91F60: mov   r13, #3      ; direccin destino = 0003:28BC
C91F64: mov   r14, r15
C91F66: mov   r15, r1      ; direccin origen es ahora = r15:r14
C91F68: calls 0FF8D44h     ; rutina que copia bytes

Eso lo menciono con un propsito muy claro: en otros modelos de Siemens que
usan el C166 las rutinas son exactamente iguales, puesto que el DMA para
el DSP est en la misma direccin de memoria.
Si tienes otro Siemens, slo hay que buscar ese mismo trozo de cdigo para
aprender dnde est la rutina que los envia por la red GSM.

Esta rutina y sus compaeras se llaman desde diversos puntos del sistema
operativo. De hecho, hay 2 tipos de rutinas: las que meten en el DMA, y las
que sacan datos del DMA.
Lo que no tengo tan claro es porqu hay ms de 2 zonas de DMA. Al fin y al
cabo, slo hay 1 interface de radio.
Creo que es porque actan sobre un doble buffer antes de mandarlo a la red, tal
como se detalla en el procedimiento de acceso de tramas L2.

Como s que hay gente que sigue estos artculos, dir que las rutinas son:
C91F94, C91EEA, C91EC2, C91ED6 y C91F54
Los datos se metern o sacarn de:
0003:28D8 (2 veces), 0003:2940, 0003:28BC, y 0003:28F2 .

Lo que hago a continuacin es parchear las rutinas para que metan los datos
en otra zona de memoria, ademas del DMA.
Eso me permite ver los datos que se envan y reciben.

Decido crear una estructura en C:
struct mi_trama {
 int32 direccion_datos;
 int32 rutina_interceptada;
 int32 rutina_llamante_1;
 int32 rutina_llamante_2;
 char[14] datos_trama;
};

copia_datos_desde(x)
{
static numero_tramas=0;
mi_trama[numero_tramas].direccion_datos=x;
mi_trama[numero_tramas].rutina_interceptada=dato[pila];
mi_trama[numero_tramas].rutina_llamante_1=dato[pila+2];
mi_trama[numero_tramas].rutina_llamante_2=dato[pila+4];
for(i=0;i<14;i++)
 mi_trama[numero_tramas].datos_trama[i]=dato[x+i];

numero_tramas++;
}

Virginia Wolf: Al faro
******** Mi primera trama...chispas ***************
As empiezo a capturar trama, una de las cuales es:

06 13 2B 2B 2B 2B 2B 2B 2B 2B 2B 2B 2B 2B

De acuerdo con la documentacin 3GPP TS 24.007 
cada trama L3 se compone de varios bytes, donde el primero tiene 3 partes:
-origen/skip, que ocupa 1 bit
-indice de la transaccin, que ocupa 3 bits
-discriminador de protocolo, los restantes 4 bits

El segundo byte indica el tipo de mensaje.
Los restantes bytes contienen datos, llamados elementos, cuyo significado
depende del tipo de mensaje.


Para verlo ms grficamnte:
+------+-----------------+---------------------------+
|---8--|---7----6----5---|-----4-----3----2-----1----|
|-Skip-|--TransactionID--|---Protocol discriminator--|  octet 1
|--------------------Message type--------------------|  octet 2
|--------Other information elements as required------|   etc.
|....................................................|  details about elements
+----------------------------------------------------+


El bit origen/skip vale 0 si la trama se interpreta como "llega desde..." o
vale 1 si significa "va hacia..."
El TransactionID es un nmero secuencial, que va desde 0 hasta 7.
El discriminador de protocolo est definido en 3GPP TS 24.007 y puede valer:

0000: Group Call Control -GCC
0001: Broadcast Call Control -BCC
0010: Reserved: was allocated in earlier phases of the protocol
0011: Call control and call related SS messages  CC
0100: GPRS Transparent Transport Protocol -GTTP
0101: mobile management messages non GPRS -MM
0110: radio resource management messages -RR
0111: Unknown
1000: GPRS mobile management messages -GMM
1001: SMS messages                      -SMS
1010: GPRS Session Management messages   -SM
1011: non call related SS messages    -SS
1100: Location Services               -LS


En el caso de la trama
06 13 2B 2B 2B 2B 2B 2B 2B 2B 2B 2B 2B 2B
se interpreta como:
06  0-------  direccin "desde"
    -000----  TransactionID = 0
    ----0110  Protocol Discrim.   : RR - radio resource management messages

Vamos ahora con el segundo byte: 0x13
Como el protocolo es RR, hay que consultar el documento
3GPP TS 44.018 - Mobile radio interface layer 3 specification

donde dice que 
13  00010011  MESSAGE TYPE : CLASSMARK ENQUIRY 
que est definido en la seccin 10.5.2.7c, y en este caso no contiene
elementos, ya que es de tipo "pregunta", y se la hace la red al mvil.

Muy fcil, ?eh? Esto es porque este mensaje es muy simple.


Analizo ahora otro mensaje:
06 21 00 01 00 2B 2B 2B 2B 2B 2B 2B 2B 2B

06  0-------  direccin "desde"
    -000----  TransactionID : 0
    ----0110  Protocol Discrim.   : radio resource management messages
21  00100001  MESSAGE TYPE        : PAGING REQUEST TYPE 1 , definido en 9.1.22
00  ----00--  spare bits          : 0
    ------00  Page Mode           : Normal paging
    --00----  Channel Needed      : (first) Any Channel
    00------  Channel Needed      : (second) Any Channel
: Mobile Identity 1
01  00000001  length of Mob.ident.: 1               
00  0000----  Identity Digit 1    : hex value ( 0xF, en caso de ser TMSI/P-TMSI)
    ----0---  No. of ID digits    : even 
    -----000  Type of identity    : No Identity

En pocas palabras, esto le dice informacin al mvil sobre los canales que
tiene que usar para comunicar.
Esta informacin consiste en "usa cualquier canal que est disponible".
?Porqu se dice una informacin tan tonta? Porque el mvil antes haba
preguntado cules canales debera usar.

La documentacin para el protocolo RR ocupa unas 300 pginas.
La informacin sobre todos los protocolos ocupa mas de 3000 pginas, y a
menudo se refiere a otra documentacin ETSI.

Se pueden encontrar unas series de tramas y su explicacin detallada en
http://www.informatik.hu-berlin.de/~goeller
aunque la explicacin est en alemn, la mayora de los datos estn en ingls.
Por cierto que Herr Doktor-Ing. Goeller es un experto en el tema.
Su libro "Die GSM-Dm-Kanaele im Dialog" es muy instructivo (y caro).

Caldern de la Barca: La vida es sueo
******** Menudos elementos ***************
Por ejemplo el mensaje de CLIR (Caller Line Identification Restriction - para
indicar que deseas ocultar el nmero desde el que llamas) ocupa 7 tramas.
Excluyendo las tramas de autentificacin, la trama mas importante es:

03 05 04 04 60 02 00 81 5E 08 91 94 33 57 12 80 51 F6 A2 

03  0-------  direction from      : originating site
    -000----  TransactionID       : 0
    ----0011  Protocol Discrim.   : Call control and call related SS messages

05  00------  SendSequenceNumber  : 0
    --000101  MESSAGE TYPE        : SETUP

04  00000100  INFORMATION ELEMENT : Bearer capability
04  00000100  length              : 4
60  0-------  Extension           : 0												
    -11-----  Radio Channel Req.  : dual rate support MS/full rate preferred
    ---0----  Coding Standard     : GSM standard coding
    ----0---  Transfer Mode       : Circuit Mode
    -----000  Info Transfer Cap.  : speech
02  0-------  Extension           : 0
    -0------  Coding              : extension of info. transfer capabilities
    --00----  Spare               : 00	
    ----0010  speech Vers. indic. : GSM full rate speech version 2
00  0-------  Extension           : 0
    -0------  Coding              : extension of info. transfer capabilities
    --00----  Spare               : 00	
    ----0000  speech Vers. indic. : GSM full rate speech version 1
81  1-------  Extension           : 1
    -0------  Coding              : extension of info. transfer capabilities
    --00----  Spare               : 00	
    ----0001  speech Vers. indic. : GSM half rate speech version 1

5E  01011110  INFORMATION ELEMENT : CalledPartyBCDNumber
08  00001000  length              : 8
91  1-------  Extension           : 1			
    -001----  Type of number      : international number
    ----0001  Numb. plan id.      : ISDN/teleph. numb. plan (Rec. E.164/E.163)
94..F6        number              : +4933752108156

A2  10100010  INFORMATION ELEMENT : CLIR Invocation <****


El dato de ocultar la informacin es el ltimo  A2  que est definido
en 3GPP TS 04.08 prrafo 10.5.4.11b

Alguno se habr dado cuenta de que los datos "number"
94 33 57 12 80 51 F6
se invierten de 2 en 2, para resultar
49 33 75 21 08 15 6F
que es justamente el nmero de telfono al que llamas: +49 337 52108156.

Obviamente sta es una trama enviada desde el mvil llamante hasta la red.

La trama usa 19 bytes. En realidad se manda en 2 tramas de 14 (la segunda con
caracteres de relleno) pero as es ms fcil de entender, creo yo.

Como ves, el campo "Other information elements as required" se compone de 3
elementos: 
"Bearer capability" de 4 bytes, ms 1 con el cdigo (04) y otro
   con la longitud (04)
"CalledPartyBCDNumber" de 8 bytes, ms 1 con el cdigo (5E) y otro
   con la longitud (08)
"CLIR Invocation", de 1 byte con cdigo A2. En este caso no es necesario
   especificar la longitud, pues siempre es 0.

HP Lovecraft: En las montaas de la locura
********* Todos los negritos **************
Para aquellos que quieran ver todos los tipos de discriminadores de protocolos
aqu hay una recopilacin, con algunos ejemplos
Si no doy ejemplos, es porque mi mvil jams ha enviado ni recibido
ninguno de esos protocolos. No hay tampoco ninguno de GPRS porque los reservo
para un futuro artculo.

===================
    ----0000  Protocol Discrim.  : Group Call Control -GCC
===================
    ----0001  Protocol Discrim.  : Broadcast Call Control -BCC
===================
    ----0010  Protocol Discrim.  : Reserved: was allocated in earlier
                                                        phases of the protocol
===================
03 05 04 04 60 02 00 81 5E 08 91 94 33 57 12 80 51 F6 A2 
03  0-------  direction from     : originating site
    -000----  TransactionID      : 0
    ----0011  Protocol Discrim.  : Call control and call related SS messages-CC
05  00------  SendSequenceNumber : 0
===================
    ----0100  Protocol Discrim.  : GPRS Transparent Transport Protocol -GTTP
===================
05 24 01 03 23 19 01 05 f4 31 e0 9f 55 
05  0-------  direction from     : originating site
    -000----  TransactionID      : 0
    ----0101  Protocol Discrim.  : mobile management messages non GPRS -MM
===================
06 1b aa b2 62 f2 10 31 04 58 04 3c 55 65 08 9d 00 00 3e ab 
06  0-------  direction from     : originating site
    -000----  TransactionID      : 0
    ----0110  Protocol Discrim.  : radio resource management messages -RR
1b  00011011  MESSAGE TYPE       : SYSTEM INFORMATION TYP 3
===================
    ----0111  Protocol Discrim.  : Unknown
===================
08 02 01 49 04 62 f2 70 4f 25 01 17 16 18 05 f4 c7 98 75 86 
08  0-------  direction from     : originating site
    -000----  TransactionID      : 0
    ----1000  Protocol Discrim.  : GPRS mobile management messages -GMM
02  00000010  MESSAGE TYPE       : ATTACH ACCEPT
===================
19 01 ab 01 00 07 91 94 71 01 67 05 00 00 9f 44 0c 91 94 71 21 26 ....
19  0-------  direction from     : originating site
    -001----  TransactionID      : 1
    ----1001  Protocol Discrim.  : SMS messages                      -SMS
01  00000001  MESSAGE TYPE       : RP_DATA 
===================
    ----1010  Protocol Discrim.  : GPRS Session Management messages   -SM
===================
0b 3b 1c 19 A1 17 02 01 01 02 01 0A 30 0F 04 01 21 83 01 11 84 07 81 30 73...
0b  0-------  direction from     : originating site
    -000----  TransactionID      : 0
    ----1011  Protocol Discrim.  : non call related SS messages    -SS
3b  00------  SendSequenceNumber : 0
    --111011  MESSAGE TYPE       : FACILITY REGISTER
===================
    ----1100  Protocol Discrim.  : Location Services               -LS

Jos Saramago: Todos los nombres
******* ?Dnde dices que estoy? ****************
Analizo otro mensaje, que manda la red para informarle al mvil cul es la
celda en la que est ubicado:
06 1E CD 3A 62 F2 10 31 04 55 08 2B 2B 2B

06  0-------  direction from      : originating site
    -000----  TransactionID       : 0
    ----0110  Protocol Discrim.   : radio resource management messages
1E  00011110  MESSAGE TYPE        : SYSTEM INFORMATION TYPE 6
: Cell Identity
CD  11001101  Cell identity value1, Hex Wert
3A  00111010  Cell identity value2, Hex Wert  
: Location Area Identification                        
62  ----0010  MCC digit 1         : 2
    0110----  MCC digit 2         : 6
F2  ----0010  MCC digit 3         : 2
    1111----  MNC digit 3         : 15 = no usado
10  ----0000  MNC digit 1         : 0
    0001----  MNC digit 2         : 1
31  00110001  Location area code (LAI), Number of MSC: 31
04  00000100  Location area code (LAI), Number of BSC: 04
: Cell Options (SACH)
55  0-------  1 spare bit         : 0
    -1------  Power control indic.: is set
    --01----  MSs shall use uplink discont.transmission
    ----0101  Radio Link Timeout  : 24
: NCC Permitted
08  ----1---  BCCH carrier with NCC = 3 is permitted for monitoring;

En otras palabras:
-la celda CI es CD3A=52538
-el MCC=Mobile Country Code es 262 (Alemania. Espaa es 214)
-el MNC=Mobile Network Code es 01 (T-Mobile. Movistar=07, Amena=14)
-el MSC=Mobile Switching Center es 0x31
-el BSC=Base Station Code es 04, lo cual significa:
 -el BCC (Bradcast Color Code) es 000 (bits 5-4-3). Identifica el canal.
 -el NCC (National Color Code) es 4 (bits 2-1-0). Identifica el canal.
Para ver una descripcin de estos parmetros, consulta
www.nobbi.com o www.paginasmoviles.com o cualquier glosario GSM.

Katherine Mansfield: Fiesta en el jardn
******** ?Se puede tocar? ***************
Voy a analizar poco a poco otro mensaje, que se manda desde el mvil
cuando pulso una tecla en medio de una conversacin o para mandar un
comando DTMF a un sistema de IVR-Interactive Voice Response:

03 75 2C 32 2B 2B 2B 2B 2B 2B 2B 

03  0-------  direction from    : originating site
    -000----  TransactionID     : 0
    ----0011  Protocol Discrim. : Call control and call related SS messages CC
75  01------  SendSequenceNumber: 1
    --11----  Message types     : Miscellaneous messages, en GSM 04.08 - 10.3
    ----0101  Message sub-type  : START DTMF
2C  00101100  Type              : Keypad facility, definido en 9.3.24
32  0------   Spare             : no usado
    -0110010  Keypad information (IA5 character) : definido en 10.5.4.17 .
                                     En mi caso, 0x32="2", o sea, la tecla "2"


Volviendo al sistema del mvil, la rutina en C91F5C toma los datos de una
direccin variable de memoria y los pone en 0003:28BC para enviarlos a la red.
El dato que ir a parar a 0003:28BC ser "03", y el dato en 0003:28BC+3
ser "32"
Supongamos que quiero causarle un estropicio a la red provocando que el mvil
mande la tecla "x" en vez de "2". La red no espera ese carcter "x" porque
ningun mvil puede mandar ese cdigo DTMF.
No tengo ms que interceptar esa rutina para que en vez de
escribir "32" escriba "78", que es el cdigo de "x".

Algo as:
org C91F5C:
jmps cambia_DTMF_32_por_78

cambia_DTMF_32_por_78
{
if(*(0003:28BC+0)==0x03 &&
   *(0003:28BC+1)==0x75 &&
   *(0003:28BC+2)==0x2C &&
   *(0003:28BC+3)==0x32  ) then
            *(0003:28BC+3)==0x78;
jmps original_C91F5C;
}

La manera de probarlo es muy sencillo. S que mi compaa de telfono me
dice la factura si llamo al IVR y pulso el "2".
Aplico el parche, pulso el "2", pero no me dice la factura, sino que me
indica que la tecla pulsada no es correcta.

Bueno, sta es la manera de modificar las tramas antes de mandarlas.
Un procedimiento anlogo se usara para engaar al mvil y hacerle creer
que ha recibido una trama cuando en realidad ha recibido otra.

William Faulkner: Los Rateros
******** Primera modificacin ***************
?Cmo se puede usar esto?
Este mensaje se manda desde el mvil hacia la red:
06 16 03 33 19 81 20 02 60 14 
tiene
06  0-------  direction from      : originating site
    -000----  TransactionID       : 0
    ----0110  Protocol Discrim.   : radio resource management messages
y
16  00010110  MESSAGE TYPE        : CLASSMARK CHANGE
con elemento
: Mobile Station Classmark 2                 
03  00000011  length              : 3

33  0-------  1 spare             : 0
    -01-----  Revision Level      : Used by phase 2 mobile stations
    ---1----  "Controlled Early Classmark Sending" option is implemented in MS
    ----0---  Encryp.Algor. A5_1  : available  <-******
    -----011  RF power capability : Class 4, handheld
....................

Si modifico el bit 3 (Encryp.Algor. A5_1) para que se convierta en "1", le
estoy diciendo a la red que el mvil no soporta el protocolo de
autentificacin A5_1.
En este caso, la red no querr cifrar la comunicacin, por lo que toda la
transferencia de datos se har sin cifrar. Por supuesto esto permite que
otros "snifen" mis datos, pero eso no me preocupa porque en GSM hay unas
radiofrecuencias usadas para la direccin  mvil->red y otras distintas
para red->mvil. Un mvil es incapaz de escuchar a otro.

A cambio consigo que los mensajes no estn cifrdos, con lo que me resultan
ms fciles de analizar.
En GSM, el algoritmo A5/1 se usa para las comunicaciones de datos; la voz
se cifra con otro algoritmo.

Herman Hesse: Demian
******** Escuela de daos ***************
Otra posibilidad que se presenta es provocar caos en la red mediante el
envo de tramas imposibles y construidas errneamente.

Hace tiempo que recib un mensaje de gente de TTD que quera hacer algo
relacionado con esto. Espero que sigan en ello y publiquen sus resultados.

La trama
05 1B 2B 2B 2B 2B ...
significa:
05  0-------  direction from      : originating site
    -000----  TransactionID       : 0
    ----0101  Protocol Discrim.   : mobile management messages non GPRS
1B  00------  SendSequenceNumber  : 0
    --011011  MESSAGE TYPE        : TMSI REALLOCATION COMPLETE

y se enva desde el mvil durante el proceso de autentificacin.
Lo importante es que el dato 1B tiene los bits 7-6 con valor 0, indicando
que sta es la secuencia 0. A esta trama le podra seguir otra con secuencia 1.

?Pero qu sucedera si lo altero para que sta sea la secuencia 1? Pues
o bien la red la rechaza, o bien espera a que llegue la trama 0, y las reordena.
Vamos a verlo: en la rutina que enva datos 
org C91F5C:
jmps cambia_trama_0_por_trama_1

cambia_trama_0_por_trama_1
{
if(*(0003:28BC+0)==0x05 &&
   *(0003:28BC+1)==0x1B &&
   *(0003:28BC+2)==0x2B  ) then
            *(0003:28BC+1)==0x1B | 0x40 ;
jmps original_C91F5C;
}

y compruebo que ahora el mvil no es capaz de autentificarse. Esto demuestra
que la red slo admite tramas que estn bien ordenadas, lo cual elimina
cualquier ataque out-of-order. 1 punto para los que han diseado la red.

Robert Howard: Gusanos de la tierra
******** A ver si cabe ***************
La trama 
03 25 02 E0 90 
significa
03  0-------  direction from    : originating site
    -000----  TransactionID     : 0
    ----0011  Protocol Discrim. : Call control and call related SS messages
25  00------  SendSequenceNumber: 0
    --100101  MESSAGE TYPE      : DISCONNECT
02  00000010  LENGTH OF IE CAUSE: 2
E0  1-------  Extension Bit     : 1
    -11-----  Coding stand.     : Standard defined for the GSM-PLMNS 
    ---0----  spare             : 0
    ----0000  location          : user 
90  1-------  Extension Bit     : 1
    -0010000  cause             : Normal call clearing , en 10.5.123/GSM 04.08

y se produce cuando el receptor corta voluntariamente la llamada.
El cdigo con la causa de la finalizacin es nicamente los bits 6-0 del
ltimo dato 0x90.
Por eso 0x90 se interpreta como 0x90 & 0x7F = 0x10= 16 en decimal.
Otras "causas de finalizacin de llamada" son (en decimal):
16=Normal call clearing
21=Call rejected
17=User busy
38=Network out of order

Por ejemplo, resulta gracioso hacer que todas las llamadas parezca que se
han finalizado porque la red ha fallado. El interlocutor se quedar extraado,
adems de que recibe un aviso sonoro bastante desconcertante.

Pero ms interesante es el dato
02  00000010  LENGTH OF IE CAUSE: 2

Vamos con detalle:
Segn 9.3.18.2 - Release (mobile station to network direction)
la trama contiene los datos:
03    =Call control protocol discriminator			
       Transaction identifier
25    =Release Message type
xx    =length of cause. Vale 02 en el caso anterior.
y1-yN =Cause, 4<=N<=32 bytes . Definido en 10.5.4.11. Vale E0,90 en mi caso
z1-zM =Second cause, 4<=M<=32  bytes . Definido en 10.5.4.11. Vacio en mi caso
1C    =Facility. Definido en 10.5.4.15. Tambin est vacio
7E    =User-user. Definido en 10.5.4.25. Tampoco se usa
7F    =SS version. Definido en 10.5.4.24. En blanco

En 10.5.4.11 Cause
me encuentro:
    8     7     6     5     4     3     2     1
+-----------------------------------------------+
|     |           Cause IEI                     | octet 1
+-----------------------------------------------|
|           Length of cause contents            | octet 2
+-----------------------------------------------|
| 0/1 |  coding   |  0  |                       |
| ext | standard  |spare|       location        | octet 3
+-----+-----------------------------------------|
| 1ext|          recommendation                 | octet 3a* 
+-----+-----------------------------------------|
| 1ext|          cause value                    | octet 4
+-----------------------------------------------|
|            diagnostic(s) if any               | octet 5*
:                                               :
:                                               : octet N*
+-----------------------------------------------+

O sea, que puedo incluir mucha informacin, y el octeto 2 indica la longitud
de los datos. Esta longitud est especificada como byte, por lo que caben un
total de 255 datos.
As, los bytes y1-yN=Cause podran ser:
0x02 0xE0 0x90 como en el ejemplo dado
pero tambin
0x09 0xE0 0x90 0xAA 0xAA 0xAA 0xAA 0xAA 0xAA 0xAA
o incluso
0xFF 0xE0 0x90 0xAA 0xAA ...250 veces 0xAA ... 0xAA
Pero este mensaje tiene N>32 bytes. Vamos a ver qu sucede:
Parcheo el mvil para que sustituya la trama
03 25 02 E0 90 
por
03 25 FF E0 90 0xAA 0xAA ...250 veces 0xAA ... 0xAA
es decir, incluyo ms bytes de los permitidos.
Sorprendentemente, funciona sin problemas.

El mvil que inici la llamada recibe una indicacin de que se ha cortado
por causa
03 25 FF 20 90 0xAA 0xAA ...27 veces 0xAA ... 0xAA

Es decir, que la red ha acortado la trama, y ajustado el valor de N.

En este caso, el ataque de buffer overflow ha fallado. Otro punto para los
ingenieros de Lucent.

Mario Benedetti: El porvenir de mi pasado
********** Viajando de gorra *************
Otro caso. Presta atencin a la diferencia entre el llamante y el llamado.
El mensaje
9.3.1.2 Alerting (mobile station to network direction)
lo emite el mvil llamado para indicar que el usuario est recibiendo la
notificacin de que le estn llamando.
En circunstancias normales el mensaje se emite cuando el timbre empieza a sonar.

Tras esto, la red manda un mensaje
9.3.1.1 Alerting (network to mobile station direction)
hacia el mvil llamante para informarle de que el timbre est sonando al
otro lado. Esto se refleja en que el llamante oye otro timbre muy suave,
aproximadamente cada 1 segundo.

En este caso, las tramas contienen los elementos:
03  =Call control protocol discriminator
     Transaction identifier
01  =Alerting Message type
1C  =Facility. Elemento opcional.
1E  =Progress indicator (slo en 9.3.1.1).  Elemento opcional.
7E  =User-user, definido en 10.5.4.25.   Elemento opcional.	

Este ltimo elemento User-user es informacin que se manda entre los usuarios.
Se transmite transparentemente (sin sufrir modificaciones) y en el caso de un
mensaje ALERTING tiene un mximo de 131 bytes.
Otros mensajes, por ejemplo DISCONNECT, slo admiten 31 bytes.

El formato es:
   8     7     6     5     4     3     2     1
+-----------------------------------------------+
|     |            User-user IEI  =  0x7E       | octet 1
+-----------------------------------------------|
|          Length of user-user contents         | octet 2
+-----------------------------------------------|
|        User-user protocol discriminator       | octet 3
+-----------------------------------------------|
|               User-user information           | octet 4* 
:                                               :
:                                               :
|                                               | octet N*
+-----------------------------------------------+

El octeto 3 se pone a valor 0x00 para "User specific protocol", segn
dice 10.5.131/GSM 04.08
Otros valors peden ser:
0x1=OSI high layer protocols
0x2=X.244
0x4=IA5 characters

As, la trama
03 01 7E 09 00 46 43 41 30 30 30 30 30
significa:
03  0-------  direction from    : originating site
    -000----  TransactionID     : 0
    ----0011  Protocol Discrim. : Call control and call related SS messages
01  00------  SendSequenceNumber: 0
    --000001  MESSAGE TYPE      : Alerting Message type
7E  00000010  ELEMENT           : User-user
09  00001001  length            : 9, incluyendo el discriminator (octeto 3)
00  00000000  User-user prot. discrim: 0x00=User specific protocol
46..30       User-user information: "FCA00000"

Que hace que, cuando llamo, esa informacin se transmite al mvil llamado.
Lo que sucede en el otro extremo depende de las caractersticas del mvil
receptor. Con el Siemens S45 no pasa nada, aunque es posible que en otros
mviles aparezca el texto en la pantalla.

Pero lo importante no es esto. Lo mejor de todo es que he conseguido transmitir
la palabra "FCA00000" desde un mvil al otro incluso antes de que se haya
aceptado la llamada, lo que implica un coste de 0 euros.

Si recuerdas lo que he dicho 45 lineas ms arriba, el tamao de este elemento
es 131 bytes, lo cual deja bastante espacio para mandar datos gratuitamente.
Esto es mucho mejor que mandar SMS, ?no te parece?
Claro que necesitas parchear ambos mviles, pero bueno, un punto para m.

Esto da una pista de porqu nunca habr un Sistema Operativo para mviles
que tenga cdigo fuente disponible: seran muy sencillos de usar para
cometer fraudes.
Si has odo hablar de instalar Linux en un mvil, ninguno de estos proyectos
aspiran a desarrollar la parte que permite realizar llamadas.
Incluso si lo consiguieran, las compaas telefnicas se las ingeniaran
para vetarlos en sus redes.
Los mviles que vienen instalados con Linux no hacen pblico el cdigo que
usan para conectarse a la red GSM, tambin conocidas como ETel.
De todos modos aqu hay una lista de tales telfonos:
http://www.linuxdevices.com/articles/AT9423084269.html

Antoine de Saint Expery: El Principito
******* Baile de mscaras ****************
Algunas de las tramas enviadas por la red pueden provocar que el mvil
incluya su IMEI (International Equipment Mobile Identity) en la respuesta.
Este cdigo de 15 cifras es nico para cada mvil, y suele estar escrito
en una pegatina dentro del mvil.
Se usa para que los operadores de red puedan impedir acceso desde un mvil
que se ha denunciado que ha sido robado.

En notacin ETSI, el IMEI se denomina IMEISV, pues incluye el dgito de
checksum, para completar un total de 16 cifras..

Este cdigo tambin se usa para buscarlo en otra base de datos de
fabricantes, y saber las caractersticas. As, pueden evitar enviar EMS
a un mvil que saben que no los va a poder mostrar.
Tambin se usa para mandar configuraciones distintas. Por ejemplo, el
modelo Siemens S45 soporta GPRS, as que es recomendable que el operador
de red le mande un mensaje para configurar el punto de acceso con los APN.

Una trama que se usa desde el mvil para enviar esta informacin es:
06 32 17 09 33 23 81 81 32 07 31 09 F0 

06  0-------  direction from      : originating site
    -000----  TransactionID       : 0
    ----0110  Protocol Discrim.   : radio resource management messages
32  00110010  MESSAGE TYPE        : CIPHERING MODE COMPLETE

17  00010111  INFORMATIONS ELEMENT: Mobile Identity

09  00001001  length of Mob.ident.3: 9 , incluyendo 1 para la cabecera.  
                                     en total, el IMEISV ocupa (9-1)*2=16
33  ----0---  No. of ID digits     : even 
    -----011  Type of identity     : IMEISV
    0011----  Identity Digit 1     : 3
23..09 F0     Identity Digits 2-17 :  321818237013900F

Es sencillo alterar esta trama para imilar unIMEI diferente, lo cual, por
cierto, es ilegal.

Juan Lpez: Superlpez- La caja de Pandora
********* Aqu cabe de todo **************
Una caracterstica del protocolo GSM layer 3 es que no usa tcnicas de
compresin. Al ser las tramas tan pequeas, los algoritmos usados en
herramientas como ZIP o gzip no obtendran ningn beneficio estimable.

En cambio, aprovecha al mximo todos los bits empaquetndolos y
distribuyndolos entre todos los bytes.

Por ejemplo, el mensaje
83 01 1E 02 EA 88 
que significa:
83  1-------  direction to        : originating site
    -000----  TransactionID       : 0
    ----0011  Protocol Discrim.   : Call control and call related SS messages
01  00------  SendSequenceNumber  : 0
    --000001  MESSAGE TYPE        : ALERTING
1E  00011110  INFORMATION ELEMENT: Progress indicator
02  00000010  L. OF IE PROG.IND. : 2
EA  1-------  Extension         : 1
    -11-----  Coding standard   : Stand. Def. for the GSM-PLMNS as descry.
    ---0----  Spare             : 0
    ----1010  Location         : Network beyond interworking point
88  1-------  Extension        : 1
    -0001000  Progress descript: In-band inform. or appr. pattern now available 

Es decir, que el bytes 0xEA contiene un total de 4 elementos de informacin.
Y el elemento Progress description con valor 88, es capaz de indicar 64
combinaciones del estado de la alerta.
Esto se traduce en que casi todos los mensajes son vlidos, en el sentido de
que incluso una combinacin aleatoria de bytes tambin puede representar una
trama.
Bueno, quizs me he pasado con esta afirmacin.
En el dato 0xEA anterior, el nibble bajo 0x0A=1010 indica el "Location" que
est definido en 10.5.127/GSM 04.08: Progress indicator information element
con valores
0x00=0000  User
0x01=0001  Private network serving the local user
0x02=0010  Public network serving the local user
0x04=0100  Public network serving the remote user
0x05=0101  Private network serving the remote user
0x0A=1010  Network beyond interworking point
    All other values are reserved

Lo que quiere decir que no puede tener valor 0x03. Siendo ms exacto, la trama
83 01 1E 02 >E3< 88 
No es vlida.

Si la red recibe este dato, es posible que lo admita o que lo rechace.
Yo he comprobado que lo rechaza, dejando la conexin en un estado inestable.
Al cabo de un tiempo, el canal se libera automticamente, dejando al mvil
totalmente confuso, pues espera respuestas que nunca le llegan.

Bill Bryson: A Short History of Nearly Everything
********** Y lo que falta, se inventa *************
El otro aspecto se refleja en el mvil que recibe esta trama. Por supuesto
que en una red convenientemente programada nunca va a suceder, pero es
necesario que los fabricantes de mviles prueben sus modelos en todas
las circunstancias.
En particular, si engao al S45 para hacerle creer que ha recibido la trama
anterior, decide considerarla como valor 0x00=User y funciona bien.

Es muy interesante el proyecto en el que trabaja el grupo HispaPhreak quienes
han conseguido (no quiero saber cmo) el cdigo fuente del mvil TSM.
Busca el proyecto plabs en www.sourceforge.net
Lamentablemente yo slo he tenido valor de ver las rutinas de comunicacin
GSM , que estn en el directorio
MCU\Layer1\
y
MCU\Protocol\

con algunas definiciones en
MCU\inc\cdg\

Las estructuras de tramas estn bien definidas en
spy_decoding.ini

Por ejemplo, ah he aprendido que el mvil TSM
soporta para "Progress indicator information element" estos valores:
LOC_USER                  0x0 /* user */
LOC_PRIV_NET_LOCAL_USER   0x1 /* private network serving the local user */
LOC_PUB_NET_LOCAL_USER    0x2 /* public network serving the local user */
LOC_TRANSIT_NET           0x3 /* transit network */
LOC_PUB_NET_REMOTE_USER   0x4 /* public network serving the remote user */
LOC_PRIV_NET_REMOTE_USER  0x5 /* private network serving the remote user */
LOC_INTERNATIONAL_NET     0x7 /* international network */
LOC_BEYOND_POINT          0xA /* network beyond interworking point */
LOC_GNOLZ_1               0x1 /* reserved */

Lo cual quiere decir que s admite el valor 0x3 , y lo tratar con el
significado de "transit network", aunque luego el programa en
MCU\Protocol\CC\Src\CC_FFK.C
la maneja como si fuera lo mismo que LOC_PUB_NET_LOCAL_USER.

Este es tambin el comportamiento de mi Siemens: transforma LOC_TRANSIT_NET
en LOC_USER.

Como ya digo, parece muy interesante, pero hay que dedicarle mucho tiempo.

Otra cosa que he aprendido leyendo estos fuentes es que es tpico que varias
empresas participen en la elaboracin de un mvil, supongo que cada una se
especializa en un tema.
En este apecto Siemens lo tiene ms fcil, ya que ellos hacen los elementos
de red, los mviles, los controladores de radio; los microprocesadores C166 se
los compra a Infineon, que es de su mismo grupo. Todo ello sin salir de Munich.

Toms Moro: Utopa
********** El futuro que nos persigue *************
En general los nuevos modelos de telfonos incluyen mucha ms funcionalidad
que los antiguos, aunque la gestin de tramas L3 est desarrollada desde
el primer modelo, y apenas cambia, a no ser que sea para:
-incluir nuevos cdigos definidos por la ETSI, ej. LOC_TRANSIT_NET=0x3
-corregir errores
-servicios privados, ej. multi-SMS, slo disponibles en Nokia
-nuevos servicios comunes, ej. EMS
-nuevos protocolos, ej. GPRS

La nueva revolucin viene debida al sistema 3G y la telefona UMTS.
Esto introduce un cambio radical en el sistema de asignacin de frecuencias.
Lo bueno es que el protocolo que va por encima sigue siendo layer L3, con lo
que las tramas son las mismas, excepto las de gestin de Radio Recursos -RR.
El protocolo de autentificacin ha sido rediseado completamente, y la
conexin con redes TCP/IP se ha integrado como un nuevo tipo de mensajes.

Por supuesto, tambin se han revisado todos los INFORMATION ELEMENT para
aumentar su significado all donde se haba quedado corto, o eliminar
elementos que no se usaban.
La nueva documentacin incluyendo UMTS ocupa aproximadamente el doble de la
anterior, y an as sigue referenciando a muchos de los documentos anteriores.

Pero para estudiar cmo funciona el protocolo bsico, lo mejor es elegir un
modelo de mvil antiguo, tal como el Siemens C35 o S45i.

Existen otros protocolos que se usan entre los otros elementos de red:
BTS<--Abis-->BSC<--A-->MSC<--C-->HLR
pero no tengo acceso a estos dispositivos, as que no puedo contar nada.

Francisco de Quevedo: El buscn
********* Cosas raras **************:
Voy a detallar otra trama
Mi operador de red proporciona un nmero de telfono mediante el cual
me notifica el saldo. Este nmero es *104#
En realidad no es una llamada de telfono, sino ms bien un servicio.

Tras unas tramas iniciales:
tipo 0x24=CM SERVICE REQUEST / Mobile identity
tipo 0x41=RECEIVER READY
tipo 0x16=CLASSMARK CHANGE
tipo 0x32=CIPHERING MODE COMPLETE
tipo 0x15=MEASUREMENT REPORT
que sirven para comenzar la conversacin, el mvil envia esta trama:
01 24 53 0B 7B 1C 14 A1 12 02 01 01 02 01 3B 30 0A 04 01 0F 04 05 AA 2B
El grupo 7B=FACILITY REGISTER
incluye el elemento
3B=processUnstructuredSS-Request
 30=SEQUENCE
 0A=long=10 (en nibbles)
 04 01 0F 04 05 son los bytes: 104 , el nmero del servicio
o sea, que en realidad no es una llamada de telfono, sino uno de los
protocolos soportados por la propia red.

Gustavo Adolfo Becquer: El Monte de las nimas
********* Matroshkas **************
Algo que no he explicado anteriomente para no complicar el tema es que las
tramas L3 viajan por la red dentro de otras tramas L2.
Este protocolo L2 se encarga de segmentar las tramas L3 que son muy grandes,
adems de asegurarse que son enviadas fsicamente con xito.
Pero no todos los mensajes lo necesitan.

Lo mejor es verlo con un ejemplo:
03 84 51 13 05 04 01 A0 5C 09 11 81 94 33 57 12 80 51 F6 7D 02 91 81 
significa
03  0-------  Spare               : 0
    -00-----  Link Prot. Disc.    : 1, definido en GSM 04.06
    ---000--  SAPI                : 0, garantiza recepcin de la trama
    ------1-  C/R Flag            : 1, BS side to MS side
    -------1  EA                  : 1, puede segmentarse
84  10000100  Information Transf. : INFORMATION         N(R)=4, N(S)=2, P=0
51  010100--  length              : 20
    ------0-  M                   : 0
    -------1  EL                  : 1
El resto es la trama L3 en el formato que ya conocemos:
13  0-------  direction from      : originating site
    -001----  TransactionID       : 1
    ----0011  Protocol Discrim.   : Call control and call related SS messages
05  00------  SendSequenceNumber  : 0

    --000101  MESSAGE TYPE        : SETUP
........

Como ves, se incluye un flag EA "puede segmentarse" que hace que se pueda
incluir el elemento length que en este caso es 0x51, significando que
la longitud es 20 bytes

Lo que menos me ha gustado es la explicacin:
"The coding of the L2 pseudo length value field is the binary
representation of the L2 pseudo length of the message
in which the L2 pseudo length information element occurs."

Si no lo entiendes a la primera, no insistas, porque en realidad no dice nada.

Esto complica un poco las cosas cuando pretendo enviar una trama construida
por m, pues tengo que calcular el tamao. Por eso es ms fcil dejar
que sea el propio Sistema Operativo el que las calcule, o limitarse a modificar
las tramas sin cambiar su tamao.

Este es el principal obstculo que me ha impedido hacer un programa lo
suicientemente flexible como para mandar cualquier trama en cualquier momento.
Pero me apao bastante bien modificando las tramas, sin necesidad de crear
otras nuevas.

Antn Chejov: La casa del sotabanco
********** Mtodo vago *************
Tras explicar el mtodo manual de analizar las tramas, voy a decir el mtodo
automtico, que ahorra un poquito de esfuerzo.

La herramienta principal es ethereal, normalmente usada para analizar
trfico TCP/IP en redes ethernet.
Pero adems incluye analizadores para muchsimos otros protocolos, entre
ellos gsm_a y gsm_map .
Debes usar la versin 0.12 o superior, porque son las nicas que admiten
protocolos definidos por el usuario.

Lo primero,
Menu->Edit->preferences->protocols->DLT User A->DLT=147 , Payload=gsm_a_dtap

Luego, debes crear un archivo de texto llamado trama.txt con el contenido
000000 03 25 02 E0 90 

(Ten cuidado de poner un espacio al final)

Por si no te suena, esta es la trama que se enva para terminar una llamada.
Ahora:
text2pcap.exe -d -l 147 trama.txt trama.pcap
tethereal.exe -V -r trama.pcap
o bien lo cargas con ethereal.exe

Lo puedes exportar a un fichero de texto:

Frame 1 (5 bytes on wire, 5 bytes captured)
    Arrival Time: Dec  1, 2005 17:47:42.000000000     <*** no importa
    Time delta from previous packet: 0.000000000 seconds     <*** no importa
    Time since reference or first frame: 0.000000000 seconds  <*** no importa
    Frame Number: 1     <*** efectivamenta, slo hay 1 trama
    Packet Length: 5 bytes   <*** que ocupa 5 bytes
    Capture Length: 5 bytes
    Protocols in frame: user_dlt_a:gsm_a_dtap    <*** segun le dije en DLT=147
GSM A-I/F DTAP - Disconnect                   <*** debido a Payload=gsm_a_dtap
    Protocol Discriminator: Call Control; call related SS messages <*** dato 03
        0... .... :  TI flag: allocated by sender
        .000 .... :  TIO: 0                              <*** TransactionID
        .... 0011 = Protocol discriminator: Call Control;
                                                  call related SS messages (3)
    Message Type Disconnect                             <*** dato 25
    Cause - (16) Normal call clearing
        Length: 2                                     <*** dato 02
        1... .... :  Extension: not extended        <*** dato E0, bit 7
        .11. .... :  Coding standard: Standard defined for the GSM PLMNS
        ...0 .... :  Spare                      <*** dato E0, bit 4
        .... 0000 :  Location: User             <*** dato E0, bit 3-0
        1... .... :  Extension                   <*** dato 90, bit 7
        .001 0000 :  Cause: (16) Normal call clearing   <*** dato 90, bit 6-0

Esta manera es ms cmoda de interpretar los mensajes.
Lo malo es que no dice cules son los bytes que le han llevado a obtener
esta informacin. Y suele mostrar los datos en decimal, mientras que
la documentacin ETSI prefiere usarlos en bits o en hexadecimal.

De todos modos tienes el cdigo fuente a tu disposicin. Puedes modificarlo
como ms te apetezca. Yo lo he hecho y les he re-enviado los cambios, ya
que el anlisis de los protocolos GSM estaba bastante incompleto en lo que
se refiere a interface Um, referido por Ethereal como gsm_a_dtap .
A pesar de todo, no es capaz de analizar todas las tramas, y aproximadamente
el 50% no estn completas.

Yo lo uso para automatizar el anlisis de mis mensajes, y para maquetar
modificaciones, que luego hago que mande el mvil y ver cmo reacciona la red.

Esto muestra la trama de una manera bastante clara.

Puedes obtener ms tramas de la pgina de Goeller, o bien directamente
de tu mvil. Si no, aqu incluyo otras:

LOCATION UPDATING REQUEST / LAI / TMSI  (no sabe analizar los elementos)
06 1B CD 3A 62 F2 10 31 04 40 04 3C 55 65 08 A5 00 00 3C 2B 2B 

RECEIVER READY (esta trama no la sabe analizar)
01 03 01 2B 2B 2B 2B

CIPHERING MODE COMPLETE / IMEISV=350178312456787
06 32 17 09 33 05 71 28 31 54 76 08 F4 2B 2B 

MEASUREMENT REPORT:
03 49 06 15 97 57 01 8E 27 C7 07 E3 4D D1 4A EC 81 F4 38 B8 

TMSI REALLOCATION COMPLETE:
05 5B 2B 2B

La red confirma que ha recibido DTMF "2"
83 36 2C 32 2B 2B 2B

Ibsen: Casa de muecas


********** Esto es todo, amigos  *************
Bueno, esto es todo lo que quera contar sobre el protocolo GSM.

Lo que todava no me acabo de explicar es porqu en Internet hay tantas
pginas web que explican el protocolo TCP/IP, y sin embargo apenas hay
unas pocas que comentan el protocolo GSM.
De ellas, la mayora explica el nivel L2 de los mensajes, pero slo
hay 3 pginas (2 en alemn) que explican el nivel L3 de las tramas.

Espero que con este artculo haya ms gente interesada en los datos GSM que
circulan por el aire, pues superan en 100 veces al volmen de datos TCP/IP
que se envan por la red Internet.

Si vas a dar la excusa de que esto funciona nicamente con mviles Siemens y
no tienes uno, slo tienes que decirme tu direccin: yo tengo 6 en un cajn.
***********************

*EOF*
