-[ 0x02 ]--------------------------------------------------------------------
-[ DOS GSM ]-----------------------------------------------------------------
-[ by FCA00000 ]-----------------------------------------------------SET-31--


DoS en GSM

La informacin de este artculo es de lo mas 'IN' , ya que es in-completa,
in-correcta, e in-exacta, tanto in-tencionalmente como in-conscientemente.
No debes creerte todo lo que digo. Mejor: no te creas nada.
O quizs todo lo contrario.

No pretendo demostrar que soy ms k00l que nadie. Tampoco es que no tenga 
amigos con los que relacionarme. Lo cierto es que la curiosidad es mi motor 
(Frase tomada del Aviador Dro). Si a alguien ofendo, no es mi intencin.

Para los que hayan seguido la serie de artculos que he escrito sobre mviles, 
esta nueva entrega es una continuacin ms profunda de conocimientos.
Para los dems, supondr un acercamiento a las redes GSM de telefona
mvil, y algunos de sus problemas.
He intentado explicarlo todo paso por paso para que, aunque lo que cuento no se
adapte a tu modelo de mvil o a tu red de telefona, quizs puedas adaptarlo
a tus necesidades. S que hay mucha gente con Nokia que les gustara que
escribiera estos artculos para su querido mvil. Lamentablemente no tengo
un Nokia para probar.

En el mundo de los ordenadores, existe un ataque bastante explotado
llamado DoS - Denial of Service, en el cual un programa malintencionado
hace una solicitud incorrecta a otro sistema, y consigue colapsarlo o
apagarlo hasta el punto de que resulta inaccesible para otros programas.

Un ejemplo de estos son simples peticiones a un servidor Web , que ste no
es capaz de procesar adecuadamente, y el programa en el servidor termina de
manera incorrecta.
Otros ejemplos -involuntarios- son aquellos programas que bloquean un
recurso, sin permitir que otros programas puedan usarlo a la vez.
En el fondo, cualquier programa que use algo (CPU, puertos serie, disco,
impresora...) es un potencial atacante de una Denegacin de Servicio.
La mayora de los casos son errores de programacin, bien porque los
parmetros de entrada no son esperados en ese formato, o porque se
bloquean recursos que luego no se liberan adecuadamente.

Otra variante son los DDoS - Distributed Denial of Service, en el que
muchos clientes maliciosos se sincronizan para 'tumbar' a un servidor.
Un ejemplo paradigmtico se produjo cuando un virus, previamente
propagado por Internet, se activ en miles de ordenadores para
sofocar a los servidores Web de Yahoo.

En esta ocasin voy a explicar hasta qu extremo uno es capaz de tirar
una parte de la red de telefona GSM.

Las redes GSM se componen de muchas entidades encadenadas:
-Una tarjeta SIM con datos que la red necesita para identificar al usuario.
-Lo ms cercano al usuario es el MS-Mobile Station, es decir, el mvil. 
-Este se conecta a travs de ondas de radio con la BS-Base Station
 La BS tiene 1-16 transceptores, cada uno con un BTS : conexin radio
 Es lo que normalmente se conoce como antena.
-BSC: Base Station Controller = conexin con la red central
-Un grupo de varias BSC estn gobernadas por el MSC-Mobile Switching Center
-Estos se agrupan segn VLR-Visitor Location Register
-Toda la red de una operadora converge en un HLR-Home Location Register

Los nicos puntos que puedo tocar son el SIM y el MS.
Claro que si me dieran un MSC para jugar con l, sera muy divertido.

En artculos anteriores ya expliqu cmo modificar el SIM con herramientas
simples. Estos conocimientos los necesitar ahora brevemente.
Para los usuarios 'de a pie' la configuracin del SIM esta vetada por
claves de seguridad que no han podido ser rotas.
S, ya s que hay gente que ha conseguido clonar un SIM, pero de ah a
hacerse pasar por otro usuario hay una gran diferencia.
Y para modificar internamente el SIM, todava hace falta mucho ms poder
tecnolgico, fuera del alcance de los simples mortales. Mi enhorabuena a
los 'kumpels' del CCC que estn trabajando duramente en ello.

Modificar el mvil no consiste en cambiar los colores de los mens, sino
conocimientos ms profundos de ensamblador de su micro.
Afortunadamente esto ya no es obstculo para los lectores de SET30, ?no?

(uso el punto '.' para separar las unidades y los decimales ; por eso 2/10=0.2)
Lo que voy a contar ahora ya lo explic eljaker all por el numero 15 de SET
pero me gustara dar un enfoque ms detallado.

Primero necesito un poco de teora:
Un mvil es un emisor/receptor de radio. Las frecuencias reservadas al GSM son 
-De base a mvil: Fu(n)=935.2+0.2*n  MHz (0<=n<=123)
-De mvil a base: Fd(n)=890.2+0.2*n  MHz (0<=n<=123)
Donde  n  es el canal de radio-frecuencia.
Esto da un rango de 25MHz para subida, y otros 25MHz de bajada.

Este canal fsico que usa el mvil para comunicar con el BTS se denomina Um.

Estos 124 canales de 0.2 Mhz = 200Khz se llaman canales FDMA - Frequency
Division Multiple Access , y dura 4.615 milisegundos
Cada FDMA se organiza en 8 slots que obviamente duran 0.577 milisegundos.
Esto se conoce como TDMA - Time Division Multiple Access.
Este canal de enlace usa protocolo lgico LAPDm.


En cada uno de los slots se meten 156.25 bits (?alguien ha usado alguna
vez 1/4 de bit?) pero en realidad slo se usan 148 bits.
Por eso cada bit dura 3.69 microsegundos.
Cada slot pertenece a un usuario que hace una llamada, con lo que
slo 8 usuarios pueden hablar a la vez en una frecuencia dada en una celda.
Al menos uno de los slots de los canales de bajada tiene que estar libre para
permitir transmitir informacin sobre la red: cobertura, nivel de seal, ...
Normalmente son muchos ms, pero la documentacin obliga slo a uno.

Una BS tiene que transmitir como mnimo en una frecuencia, aunque casi siempre
transmiten en varias. Esto permite dar cobertura a 124 grupos de 8 usuarios.

Segn esto, una BS slo puede tener 8*124-1 = 991 usuarios hablando a la vez.
Para permitir ms usuarios, se usan celdas mas pequeas. Explico esto despus.
Adems, algunas de la frecuencias y canales ya estn usados para ajustes
de potencia, velocidad, y sincronizacin, por lo que no se pueden usar
para transmisin de datos ni voz.

Los 148 bits duran 546.12 microsegundos, y componen un paquete (burst), que
puede ser de varios tipos:
-normal:
3  Trial bits, de valor 0
57 bits de datos, con la informacin, ademas del cdigo de redundancia
1  bit de Stealing, indicando si la informacin es de trfico o sealizacin
26 de Entrenamiento, para que el MS pueda reajustar la velocidad
1  bit de Stealing
57 bits de datos
3  Trial bits , de valor 0
Luego siguen 8.25 bits . O, lo que es lo mismo, 30.4 microsegundos, para
esperar entre un paquete y otro. O sea, que en realidad slo se pueden
usar 57+57 bits para datos. 14 bytes no parece mucho, ?verdad?

-de acceso aleatorio, para mantener la sincronizacin estricta de tiempos
8  Trial bits
41 de sincronizacin
36 datos
68.25 es decir 252 microsegundos de espera. Ya incluye 8.25 bits de separacin

-paquete de correccin de frecuencia: paquetes F
3   Trial bits
142 bits de valor 0
3   Trial bits
8.25 de relleno

-paquete de sincronizacin S, para encontrar la frecuencia exacta de la BTS

Estos canales fsicos sirven como base para los canales lgicos, en los
cuales se agrupa la informacin de voz y datos.

Te habrs dado cuenta de lo importante que es todo el protocolo externo a la
comunicacin de datos: menos del 30% de los paquetes se usan para tranmitir
datos de voz. (Fuente: Nokia)

Para completar, decir que subiendo en la escalera hasta otras entidades:
-el BTS se conecta con el BSC mediante el protocolo fsico A-bis, que
 va a 64Kb o 2Mb. Usa TDMA, LAPDm, y RR
-el BSC se conecta con el MSC usando protocolo fsico A, sobre el cual
 van protocolos en capas: MTP, SCCP, BSSMAP, MM y CM.
Todo esto esta explicado en las especificaciones GSM y 3GPP, distribuidas
a lo largo de ms de 20 documentos de 200 pginas. Demasiado para m.


Aunque esto no tenga mucho que ver con el tema que me ocupa, me gustara
aqu hacer un inciso para explicar que cada SIM est dado de alta en una
base de datos almacenada en el HLR-Home Location Register.
Cuando un mvil+SIM se mueve a un area que est fuera del HLR entonces
est (temporalmente) en un VLR-Visitor Location Register, por lo que
el VLR debe notificarle al HLR que dicha VLR tiene controlado al mvil.
Aun as, el VLR habla mucho con el HLR, ya que la informacin slo
se almacena temporalmente en el VLR.
Si, por ejemplo, el mvil desea comenzar una llamada, el VLR le pregunta
al HLR si dicho mvil tiene derecho a iniciar llamadas.
Anlogamente, cuando se intenta llamar a un mvil, el HLR transmite toda
la informacin al VLR adecuado.
Pero el HLR es el nico que mantiene los datos de seguridad usados para
el cifrado y la autentificacin.


Como se ha visto antes, las ondas de radio son el interface fsico de
la primera capa de comunicacin Um.
Al viajar por el aire, estn afectadas por las condiciones ambientales.
Entre los fenmenos que modifican la calidad de las ondas se encuentran:
-reflexin
-refraccin
-dispersin
motivados por el terreno, distancia, obstculos, rebotes, potencia del mvil.
Todos estos condicionantes son estudiados en detalle por los tcnicos del
operador telefnico encargados de decidir la ubicacin y potencia de las BSs.
Y no es una tarea fcil. (Gracias, Johannes, por la informacin)

Cada BS emite peridicamente informacin sobre su ubicacin, potencia
de emisin, y distancia hasta la que puede admitir "clientes".
Para esto usa los canales de broadcast. Pretendo escribir
otro artculo sobre ello.

Si un mvil no tiene una conexin activa, est en modo no-dedicado, y se
dedica a recibir la informacin de todas las BSs alrededor suyo.
En general suelen ser entre 0 y 6 BSs. En el Siemens S45 es posible ver el
identificador de estas celdas, junto con su potencia, situacin, ...
Puede haber ms de 6 BS, por ejemplo en el aeropuerto, o a la puerta
del edificio de Telefnica I+D.
Y en otros puntos no hay ms que una antena. Por ejemplo, en la hermosa
sierra de Teruel, o en la isla Peregil.

Con los datos de cada una de las BS, el MS decide cual es la que le da mayor
potencia con menor consumo para el mvil, y la define como BS preferida.
Al cabo de un tiempo (5 segundos?), escanea de nuevo la red para
ver si hay otra frecuencia+canal que le convenga ms.

Por el contrario, un MS tambin puede estar en modo dedicado, es decir, hay
una conexin activa y el usuario est hablando o escuchando.
Entonces obviamente est usando un canal en una cierta frecuencia.
En esta situacin el mvil constantemente calcula la potencia usada.
Si este valor cae por debajo de un lmite, escanea la red para ver si hay
otra BS de mejores caractersticas.
Esto suele suceder cuando el usuario se mueve y la distancia a la BS aumenta.
El MS entonces recopila la informacin de todas las antenas que puede
escuchar, y transmite los datos al BSC , que le dice a cual BS debe
intentar conmutar. Este fenomeno se llama handover o handoff.

El handover se puede producir:
-por cambio de canal, dentro de la misma BS
-por cambio de frecuencia, dentro de la misma BS
-entre una BS y otra, dentro de la misma BSC
-entre una BSC y otra, dentro de la misma MSC
-entre una BSC y otra, perteneciente a distintas MSC
-entre un VLR y otro, pertenecientes al mismo operador de telefona
-entre un VLR y otro, de distintos operadores, incluso de distintos pases

Notar que la decisin de conmutar a otra BS no la toma el MS, sino el BSC.
El valor lmite para pasar de una BS a otra es enviado primero por
la BS al mvil, y luego del MS al BS en caso de que la calidad disminuya.

La comunicacin pertinente al proceso de Handover est compuesta
por varios mensajes enviados entre las entidades involucradas.

Este es el diagrama de tiempos entre una celda de un BSC y otra celda
de un BSC diferente, pero ambos del mismo MSC.
En realidad slo me interesa entre dos celdas del mismo BSC, pero tener
una visin completa proporciona ms claridad.

Los puntos Txxx (por ejemplo T8, T3124) son 'timers' que pone dicha entidad.
Si la respuesta no vuelve en el tiempo adecuado, el proceso se cancela.
Todos los pasos con letras maysculas (ej. BSSMAP HANDOVER REQUIRED,
 RR HANDOVER COMPLETE) son comandos que se envan entre las
entidades, segn el protocolo establecido entre ellas.
Estos valores ocupan 1 byte, y estn en GSM 08-08 parte3: MSC to BSS -Layer 3


+-------+---------------+--------------+-----------------+--------------+-----+
| MS    |  celda-fuente |  BSC-fuente  |  celda-destino  |  BSC-destino | MSC |
+-------+---------------+--------------+-----------------+--------------+-----+
 *-RR
  MEASUREMENT
    REPORT------------------------------------->RR 
   Calidad seal: buena                     MEASUREMENT
                                              REPORT------------>*
                                           Calidad seal: buena
 *-El usuario se mueve
    |
   RR
  MEASUREMENT
    REPORT------------------------------------->*
  Calidad seal: mala                           |
                                                RR 
                                            MEASUREMENT
                                              REPORT------------>*
                                         Calidad seal: mala     |
                                                               BSSMAP
                                                              HANDOVER
                                                               REQUIRED--->*
                                                                 (T7)      |
                                                                         BSSMAP
                                                                       HANDOVER
                             *<-----------------------------------------REQUEST
                             |                                          (T101)
                        Reserva canal
                        de trfico
                             |
                       Construye mensaje
                      RR HANDOVER COMMAND
                             +----BSSMAP HANDOVER REQUEST ACKNOWLEDGE------->*
                                                                             |
                                                                       fin T101
                                                                             | 
                                                                         BSSMAP
                                                                  *<---HANDOVER
                                                                  |     COMMAND
                                                                  |
                                                               (fin T7)
                                                                  |
    *<---------------RR HANDOVER COMMAND--------------------------+
    |                                                            (T8)
    |
 Conecta
 a nuevo
 canal
    |
RR HANDOVER
  ACCEPT----->*
 (T3124)      |
           RR HANDOVER
             ACCEPT-------->*
                            |
                       BSSMAP HANDOVER
                          DETECTED----------------------------------------->*
                            |
                       RR PHYSICAL
                       INFORMATION
                            |
              *<------------+
              |          (T3105/T3103)
          RR PHYSICAL
          INFORMATION
              |
    *<--------+
    |
(fin T3124)
    |
  RR SABM------------------>*
                            |
                       (fin T3105/T3103)
                            |
    *<--------------------RR UNBLOCK-ACK
    |
RR HANDOVER
COMPLETADO----------------->*
                            |
                      BSSMAP HANDOVER
                         COMPLETADO----------------------------------------->*
                                                                             |
                                                                     (fin T102)
                                                                             |
                                                                         BSSMAP
                                                                   *<-----CLEAR
                                                                   |
                                                                 (fin T8)
                                                                   |
                                                             BSSMAP CLEAR
                                                              COMPLETADO--->FIN

Espero que lo entiendas bien, porque me ha costado un buen rato dibujarlo.

Los puntos mas importantes, desde el punto de vista del MS, son:
RR SABM: El mvil le pide al SABM (Set asynchronous balanced mode) que
         establezca la informacin de sealizacin.
RR HANDOVER COMPLETE: El mvil usa esta nueva sealizacin para
         indicar que el handover se ha completado.
Esto es la respuesta al comando RR UNBLOCK-ACK: Confirmacin de que
el recurso est desbloqueado.

De acuerdo con las especificaciones de GSM:
RR HANDOVER COMMAND tiene valor 83, y tambin se le conoce como HAND-COM
RR HANDOVER COMPLETE tiene valor 84, y tambin se le conoce como HAND-COMP
RR UNBLOCK-ACK tiene valor 43


Segn las especificaciones 3GPP TS 04.08 de la capa 3 interface radio:

9.1.16	HANDOVER COMPLETE
Este mensaje se manda desde el MS hacia la red para indicar que el MS ha
establecido satisfactoriamente el enlace de sealizacin.

Los elementos son: Tabla 9.16/GSM 04.08
--------------------------+-------------------+-----------+---------+-------+
IEI Information element   | Type / Reference  | Presencia | Formato | Long. |
--------------------------+-------------------+-----------+---------+-------+
   *RR management         |  Protocol Discrim.| Mandatoria| V       | 1/2   |
    Protocol Discriminator|  10.2             |           |         |       |
--------------------------+-------------------+-----------+---------+-------+
   *Skip Indicator        |  Skip Indicator   | Mandatoria| V       | 1/2   |
                          |  10.3.1           |           |         |       |
--------------------------+-------------------+-----------+---------+-------+
   *Handover Complete     |  Message Type     | Mandatoria| V       |   1   |
    Message Type          |  10.4             |           |         |       |
--------------------------+-------------------+-----------+---------+-------+
   *RR Cause              |  RR Cause         | Mandatoria| V       |   1   |
                          |  10.5.2.31        |           |         |       |
--------------------------+-------------------+-----------+---------+-------+
77  *Mobile Observed Time |  Mobile Time Diff.|  Opcional | TLV     |   5   |
    Difference            |  10.5.2.21a       |           |         |       |
--------------------------+-------------------+-----------+---------+-------+

El primer dato Protocol Discriminator ocupa 4 bits con el siguiente significado:
bits 4 3 2 1
     0 0 1 1   Control de llamada: mensajes relativos a llamadas
     0 1 0 1   Gestin de movilidad para servicios no-GPRS
     0 1 1 0   Mensajes de gestin de recursos de radio. Este es nuestro caso
     1 0 0 0   Gestin de movilidad para servicios GPRS
     1 0 1 0   Mensajes de gestin de sesin

El segundo dato Skip Indicator vale 0000, segn cuenta 10.3.1

El tercer dato Message Type vale 0x2C=00101100=HANDOVER COMPLETE, segn
la tabla 10.1 del GSM 04.08 . Hay otros 256 comandos, dependiendo de la
direccin del trfico y el significado que necesites.

El cuarto dato RR Cause indica la razn por la cual se ha enviado el comando.
En situaciones normales vale 00000000 , segn especificado en la
tabla 10.5.70 del apartado 10.5.2.31 del GSM 04.08
Otros valores son:
00000010 Fallo: canal inaceptable
00001010 Frecuencia no implementada

El quinto dato Mobile Time Difference es opcional. En mis pruebas he visto
que siempre se transmite, pero en otras redes puede ser que no.
Si no se usa, los datos van con valor 0.
En todo caso la trama completa ocupa 1/2 + 1/2 + 1 + 1 + 5 = 8 bytes que
caben perfectamente dentro de 1 burst.
Por cierto, que es un dato realmente curioso. Demuestra que GSM es capaz de
hacer una triangulacin bastante eficaz para ubicar un mvil.

As que el mensaje de HANDOVER COMPLETE satisfactorio es como mnimo
0110 0000 00101100 00000000 = 602C00 , en hexadecimal

Recapitulando: cuando el mvil tiene mala recepcin, le dice a la red la
lista de antenas y sus potencias , quien quizs decide provocar el handover.
Tras reservar un nuevo canal, la informacin se transmite por el antiguo canal
al mvil, quien usa la nueva frecuencia y celda, y notifica a la red que la
antigua est libre, mediante el comando 602C00 .

?Pero que pasa si el mvil no recibe el comando  "RR PHYSICAL INFORMATION" ?
Entonces el timer T3124 caduca y el MS comienza de nuevo el proceso
de HANDOVER, usando el antiguo canal.

?Y si el comando perdido es "RR UNBLOCK-ACK" ?
En este caso el MS nunca liberar el canal antiguo, y la red lo liberar
por su cuenta.

?Y si el MS no notifica la liberacin "RR HANDOVER COMPLETADO"?
Pues que la red espera el tiempo especificado en T102 y T8 para asumir que
el dato se ha perdido, y asume que el mvil no ha hecho el handover.
Entonces libera el nuevo canal, puesto que no est usado.
?Y que pasa en este caso con el mvil? Pues que usar erroneamente
el nuevo canal. Cuando se d cuenta de que no hay nadie escuchndole
buscar otra frecuencia para empezar de nuevo.

Ahora suponer que el mvil solicita un tercer canal antes de que T102 caduque:
-el canal inicial est en uso
-el canal que se intent usar para el handover no est todava liberado
-se reserva un nuevo canal para intentar el handover
Repitiendo este proceso N veces, se reservarn un total de N+1 canales.
Si la velocidad de peticin de canales es superior a T102, llegar
un momento en que se ocupen todos los canales.
Entonces ningn usuario ms podr usar ninguna de los BSC que dan soporte
a esa celda.
Obviamente otras celdas todava tendrn soporte si hay otras BSs alrededor.
Ahora bien, las celdas de tamao mnimo, llamadas pico-celdas, tienen un
radio tpico de 100 metros, as que como mnimo seguro que nadie ms
puede hacer un handover en un radio de 100 metros.
Recordar que una misma frecuencia no puede usarse en dos celdas adyacentes.

Notar tambin que los usuarios con una conexin activa no la pierden, pero
no son capaces de realizar un handover para conseguir mejor calidad.

Para completar la informacin, decir que tambin existen:
-microceldas, con un mximo de 1 Km.
-macroceldas, con un mximo de 10 Km.
-celdas paraguas, con ms de 10 Km de cobertura

Lo normal es que haya celdas de corta distancia cubriendo edificios con mucha
actividad, y otras celdas mucho ms grandes que cubren los huecos entre
las picoceldas. Por supuesto, 2 celdas no pueden tener la misma frecuencia
usada por ms de una BS. Este problema de solapamiento de frecuencias
tambin es complejo de planificar.

Todo este rollo para decir que el mensaje HANDOVER COMPLETE es 602C00

Tras mucho trabajo he conseguido encontrar y desensamblar algunas rutinas
de mi mvil Siemens S45, con particular atencin a aquellas encargadas de
la transmisin y recepcin de los datos de radio.
Los datos van codificados cuando se envan por el aire para evitar que
elementos indeseables escuchen la comunicacin, pero tanto el mvil
como el BS saben cmo descodificarlos. Si no, ?cmo demonios van a usarlos?
Adems debe haber un cierto punto en el que el paquete recibido de 148 bits
est completamente en memoria.

El mvil contiene un interface de radio que en el proceso de recepcin va
recogiendo bit a bit los datos y cuando tiene 8, los pone en un puerto
de comunicaciones, y sigue recogiendo datos.
El Sistema Operativo del mvil debe leer ese puerto (peridicamente o
mediante una interrupcin, eso no lo s) y guardarlo en una posicin de memoria.
Cada cierto tiempo mira si tiene todos los bits. En teora deberan ser
148 bits = 18.5 bytes, pero yo he visto que no se guardan los 3 bits de Trial
del principio y el final, as que el proceso comienza cuando se tienen 18 bytes.
Recordar que los datos estan en 2 trozos de 57 bits en el paquete.
Los 3 bytes del HANDOVER COMPLETE caben en el primer trozo, pues 57/8=7 < 3

Ahora es cuando viene la informacin secreta:
esto se produce en la rutina 0xFA2524 y en r14:13 estn los datos.
Para saber si el mensaje es "RR PHYSICAL INFORMATION" , miro el tercer dato
(segundo byte) Message Type que debe valer 0x2D=00101101=PHYSICAL INFORMATION
Si coincide, cancelo el proceso sin enviar el comando.

Para los que quieran probarlo:
org 0FA2542h ; . Originalmente es    calls 0FD943Eh
 jmps 0FEFA00h ; zona de memoria no usada
 mov [-r0], r2
 extp r14, #1
 movb rl2, [r3+#2h]
 cmpb rl2, #2Dh
 jmpr cc_NZ, no_es_2D
si_es_2D:
 mov r2, [r0+]
 rets ; esto hace que el proceso de handover no continue
no_es_2D:
 mov r2, [r0+]
 calls 0FD943Eh ; llamada original
 jmps 0FA2542h+4 ; continua como si no hubiera pasado nada

Entonces en lugar de continuar con el proceso de completar el
handover, simplemente retorno de la rutina.
Con esto lo que consigo es no atender la peticin de cambiar de BS.

Hay un pequeo error aqu: la parte final del procedimiento del handover
anula el timer T3124, ya que el proceso ha tenido xito.
Si yo interrumpo este proceso, debera tambin desactivar el timer
Esto los consigo con estos pasos:
mov r8, #0000h
calls 0F99F5Ch
mov r6, #3030h
mov [-r0], r6
mov r5, r6
mov r4, #0000h
calls 0CA97ACh

Ahora no se procesa la peticin de handover. Pero el canal que el BS intent
darme sigue estando reservado.
Como no he aceptado el handover, vuelvo a pedir una nueva frecuencia+canal.
Que, por cierto, tampoco aceptar, y tambin quedar reservada.
Tras un mximo de 124*8-1 peticiones, todos los canales estn reservados
y la red en esta celda queda colapsada.
Recordar que cada celda puede tener 124 frecuencias, cada una de 8 canales.
Pero uno de los canales ya lo tengo inicialmente.
Y, como sigo sin aceptar los handovers, la peticin de nuevos canales contina.
En cuanto se produzca el fin del algn timer T102/T8 , el BS liberar el
canal, pero yo estar all para solicitarlo de nuevo.

Como he comentado antes, este proceso de handover slo se realiza cuando
tengo una llamada activa.
Esto me fuerza a hacer una llamada antes de poder anular los dems canales.
En el momento en que pierda esta llamada, se acab el proceso de solicitar
nuevos canales, o sea que tengo que mantenerla activa.
La mejor manera que se me ocurre de conservar la llamada sin pagar es usando
un nmero de telfono de servicio gratuito que no me cuelgue al cabo del tiempo.
La solucin que he aplicado es llamar al telfono de atencin al cliente
de mi operador. Entonces el sistema automtico IVR me indica que pulse el
nmero '1' para saber mi tarifa, '2' para mi factura, '3' para el buzn, ...
El men '2' de la factura me permite pulsar '0' para volver al men anterior.
Si pulso la tecla '2' de nuevo, me lleva otra vez al men de la factura.
Y as continuamente, sin cortar nunca la conexin.
Claro que no puedo estar pulsando teclas cada 5 segundos.
Pero es fcil de simular:
la rutina 0CCB510h es la que se encarga de procesar cada tecla, que est en r4.

La rutina 0C70FECh (acaba en 0C70FF6h) es llamada por el reloj interno
cada 5 segundos. Slo tengo que unirla con la rutina anterior:
org C70FF6h
mov [-r0], r2
mov [-r0], r15
extp #0040h, #1h
mov r2, 0700h ; hueco libre para almacenar la tecla previa
cmp r2, #'0'
jmpr cc_NZ, no_0
si_0:
 mov r2, #'2'
 jmpr cc_UC, sigue
no_0:
 mov r2, #'0'
sigue:
 extp #0040h, #1h
 mov 0700h, r2 ; almacena la nueva tecla simulada
 mov r4, r2
 calls 0CCB510h ; procesa la tecla
 reti

Ahora me falta un ltimo paso para activar/desactivar esta funcionalidad,
pero eso es fcil de hacer con los mltiples parches existentes en la
red para este telfono, por ejemplo NAM hecho por lalo.lerry o el de NTCN.

Algo ms sencillo es hacer que el mvil no enve nunca el
comando 0x2C=00101100=HANDOVER COMPLETE .
Simplemente hay que modificar la rutina que prepara y manda los datos de
potencia de las BS adyacentes, y enviar otro comando con significado distinto.
Por ejemplo, yo usar
0x08=00001000=RR-CELL CHANGE ORDER
que no tiene sentido cuando el MS se lo manda al BS.
As que en la rutina de envo en 0E0FE14h miro si el segundo byte es 0x2C.
En este caso lo cambio por 0x08 , y aunque permuto de canal, el BS no recibe
la notificacin correcta, por lo que no libera el anterior.
Pero me permite usar el nuevo canal !
Me pregunto qu cara pone el BS cuando recibe este tipo de mensaje, similar
al dicho "como s que te gusta el arroz con leche, por debajo de la puerta
te meto un ladrillo".

Cuando pasa un tiempo T102/T8, el BS libera el canal que no est usado.
En mis pruebas este tiempo parece estar en torno a los 700 milisegundos, es
decir, 0.7 segundos.

Las recomendaciones del 3GPP dicen que el timer T3124 debe ponerse a 675
milisegundos si el canal es de tipo SDCCH+SACCH, o un poco menos de la
mitad (320) en caso contrario.
Este es un dato que est dentro del mvil y se puede cambiar, aunque no
veo razn para ello.
De todos modos, y para que nadie se queje de que dejo cosas en el
tintero, este dato se encuentra en la rutina E89C64:
E89C64: mov r12, #2A3h ; es decir, 675
......
E89C6A: mov r12, #140h ; es decir, 320

Las mismas recomendaciones sugieren que el T102 se ponga en el BSC al
mismo valor. Esto es consistente con mi medida de 700 milisegundos.

Si reduzco este valor hasta un valor menor que 25h, el MS no escucha
a la estacin base el tiempo suficiente, y por lo tanto el BS enva una
y otra vez sus intiles intentos de handover. Notar que es simplemente
una variacin del caso anterior.

En una red ethernet esto se conoce como ataque ACK_SYN, creo recordar.

He explicado que la duracin de una trama de 8 canales dura 4.615 milisegundos.
As que en teora puedo recorrer las 124 frecuencias en 572 milisegundos.

Aunque no haya ninguna BS emitiendo en cada frecuencia, debo escanearlas todas.
Aun as, 572<700 , o sea que la velocidad de peticin de canales es superior
a la de liberacin de los no usados, por lo que efectivamente puedo llegar a
ocuparlos todos.

Pero aqu estoy dando la solucin para los operadores: simplemente
hay que reducir ese timer hasta un valor menor de 572.
?Es eso posible? Yo creo que no, pues me parece entender que T102/T8 siempre
tiene que ser mayor que un ciclo completo de frecuencias.
Esto es as para solucionar el siguiente escenario:
-Un mvil usa la frecuencia 890.4
-El usuario se mueve rpidamente a otra celda
-El MS toma medidas de las potencias de las BS de alrededor
-Se notifican estos datos al BSC-1. Esto tarda 4.6 ms
-El MSC solicita al mvil un handover hacia la frecuencia 890.2. Tarda 4.6
-el comando RR HANDOVER COMMAND se pierde pues el MS ya abandon la celda
-el MS tiene que buscar una frecuencia para reconectarse
-escanea todas las frecuencias. Tarda 572 ms
-notifica este dato a un BSC-2.
-se intenta un nuevo handover
-el MSC le dice al BSC-1 que libere 890.2 de la celda inicial. Esto slo
 se puede hacer cuando positivamente la respuesta se ha perdido.

Como "confirmacin" de esta hiptesis dir que esto creo que es lo que notas
cuando de repente pierdes la cobertura y se recupera al cabo de medio segundo.
Todo ese tiempo se intenta encontrar una nueva celda, sin que la BS de la celda
anterior pueda ayudar porque ya est fuera de alcance.

De todos modos, y para depurar parte de responsabilidad, he notificado de
esto a algunas de las compaas involucradas: Alcatel, Nokia, Siemens,
Lucent, Vodafone, Orange, Movistar, T-mobile, UMC, Ericsson, y Telia.

Otra posibilidad interesante es activar este DoS con varios telfonos para
conseguir un DDoS. No lo he probado.

La utilidad de este artculo es evidente: hay sitios en los que la gente
no debera tener los mviles encendidos: en el cine, los museos, la
iglesia, los restaurantes, ... y lo que mas me disgusta: en el autobs que
va de Santander a Vigo. Parece que todo el mundo se empea en hablar entonces !

Activa estos trucos y ya nadie a tu alrededor podr recibir llamadas ni SMS.
Pero tambin debes ser una persona responsable y no activarlo en las
cercanas de hospitales, bomberos , o la polica.
De todos modos esto es ilegal, as que yo no me arriesgara.

Adems, el consumo de batera es realmente alto.

Si vas paseando tranquilamente y tu mvil deja de tener cobertura, mira a tu
alrededor: quizs algn lector de SET est cerca.
(Y si alguien te regala flores, eso es Impulso.)

Como nota curiosa, hace tiempo le que cuando Gadafi acudi a una
conferencia en Europa, los mviles dejaban de funcionar en las zonas por la
que pasaba su comitiva. Vamos, como el caballo de Atila.
Al igual que el resto de este artculo, puede ser cierto o no.


Referencias:
http://ccnga.uwaterloo.ca/~jscouria/GSM/gsmreport.html
www.etsi.fr    Documentos de la ETSI y 3GPP, en especial 04.07 y 04.07
http://www.soberit.hu.fi/tik-76.115/95-96/palautukset/Mobiili/pt/manual.html
http://www.ee.surrey.ac.uk
www.gsm-forum.com
www.EventHelix.com
http://www.protocols.com/pbook/telephony.htm

*EOF*