Copy Link
Add to Bookmark
Report
SET 031 0x02
-[ 0x02 ]--------------------------------------------------------------------
-[ DOS GSM ]-----------------------------------------------------------------
-[ by FCA00000 ]-----------------------------------------------------SET-31--
DoS en GSM
La información de este artículo 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 quizás todo lo contrario.
No pretendo demostrar que soy más 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 intención.
Para los que hayan seguido la serie de artículos que he escrito sobre móviles,
esta nueva entrega es una continuación más profunda de conocimientos.
Para los demás, supondrá un acercamiento a las redes GSM de telefonía
móvil, 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 móvil o a tu red de telefonía, quizás puedas adaptarlo
a tus necesidades. Sé que hay mucha gente con Nokia que les gustaría que
escribiera estos artículos para su querido móvil. 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 Denegación de Servicio.
La mayoría de los casos son errores de programación, bien porque los
parámetros 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 paradigmático 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 ocasión voy a explicar hasta qué extremo uno es capaz de tirar
una parte de la red de telefonía GSM.
Las redes GSM se componen de muchas entidades encadenadas:
-Una tarjeta SIM con datos que la red necesita para identificar al usuario.
-Lo más cercano al usuario es el MS-Mobile Station, es decir, el móvil.
-Este se conecta a través de ondas de radio con la BS-Base Station
La BS tiene 1-16 transceptores, cada uno con un BTS : conexión radio
Es lo que normalmente se conoce como antena.
-BSC: Base Station Controller = conexión con la red central
-Un grupo de varias BSC están gobernadas por el MSC-Mobile Switching Center
-Estos se agrupan según 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, sería muy divertido.
En artículos anteriores ya expliqué cómo modificar el SIM con herramientas
simples. Estos conocimientos los necesitaré ahora brevemente.
Para los usuarios 'de a pie' la configuración 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, todavía hace falta mucho más poder
tecnológico, fuera del alcance de los simples mortales. Mi enhorabuena a
los 'kumpels' del CCC que están trabajando duramente en ello.
Modificar el móvil no consiste en cambiar los colores de los menús, sino
conocimientos más profundos de ensamblador de su micro.
Afortunadamente esto ya no es obstáculo 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 gustaría dar un enfoque más detallado.
Primero necesito un poco de teoría:
Un móvil es un emisor/receptor de radio. Las frecuencias reservadas al GSM son
-De base a móvil: Fu(n)=935.2+0.2*n MHz (0<=n<=123)
-De móvil 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 físico que usa el móvil 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 lógico LAPDm.
En cada uno de los slots se meten 156.25 bits (?alguien ha usado alguna
vez 1/4 de bit?) pero en realidad sólo 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
sólo 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 información sobre la red: cobertura, nivel de señal, ...
Normalmente son muchos más, pero la documentación obliga sólo a uno.
Una BS tiene que transmitir como mínimo en una frecuencia, aunque casi siempre
transmiten en varias. Esto permite dar cobertura a 124 grupos de 8 usuarios.
Según esto, una BS sólo puede tener 8*124-1 = 991 usuarios hablando a la vez.
Para permitir más usuarios, se usan celdas mas pequeñas. Explico esto después.
Además, algunas de la frecuencias y canales ya están usados para ajustes
de potencia, velocidad, y sincronización, por lo que no se pueden usar
para transmisión 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 información, ademas del código de redundancia
1 bit de Stealing, indicando si la información es de tráfico o señalización
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 sólo se pueden
usar 57+57 bits para datos. 14 bytes no parece mucho, ?verdad?
-de acceso aleatorio, para mantener la sincronización estricta de tiempos
8 Trial bits
41 de sincronización
36 datos
68.25 es decir 252 microsegundos de espera. Ya incluye 8.25 bits de separación
-paquete de corrección de frecuencia: paquetes F
3 Trial bits
142 bits de valor 0
3 Trial bits
8.25 de relleno
-paquete de sincronización S, para encontrar la frecuencia exacta de la BTS
Estos canales físicos sirven como base para los canales lógicos, en los
cuales se agrupa la información de voz y datos.
Te habrás dado cuenta de lo importante que es todo el protocolo externo a la
comunicación 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 físico A-bis, que
va a 64Kb o 2Mb. Usa TDMA, LAPDm, y RR
-el BSC se conecta con el MSC usando protocolo físico 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 más de 20 documentos de 200 páginas. Demasiado para mí.
Aunque esto no tenga mucho que ver con el tema que me ocupa, me gustaría
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 móvil+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 móvil.
Aun así, el VLR habla mucho con el HLR, ya que la información sólo
se almacena temporalmente en el VLR.
Si, por ejemplo, el móvil desea comenzar una llamada, el VLR le pregunta
al HLR si dicho móvil tiene derecho a iniciar llamadas.
Análogamente, cuando se intenta llamar a un móvil, el HLR transmite toda
la información al VLR adecuado.
Pero el HLR es el único que mantiene los datos de seguridad usados para
el cifrado y la autentificación.
Como se ha visto antes, las ondas de radio son el interface físico de
la primera capa de comunicación Um.
Al viajar por el aire, están afectadas por las condiciones ambientales.
Entre los fenómenos que modifican la calidad de las ondas se encuentran:
-reflexión
-refracción
-dispersión
motivados por el terreno, distancia, obstáculos, rebotes, potencia del móvil.
Todos estos condicionantes son estudiados en detalle por los técnicos del
operador telefónico encargados de decidir la ubicación y potencia de las BSs.
Y no es una tarea fácil. (Gracias, Johannes, por la información)
Cada BS emite periódicamente información sobre su ubicación, potencia
de emisión, y distancia hasta la que puede admitir "clientes".
Para esto usa los canales de broadcast. Pretendo escribir
otro artículo sobre ello.
Si un móvil no tiene una conexión activa, está en modo no-dedicado, y se
dedica a recibir la información 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, situación, ...
Puede haber más de 6 BS, por ejemplo en el aeropuerto, o a la puerta
del edificio de Telefónica I+D.
Y en otros puntos no hay más 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 móvil, 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 más.
Por el contrario, un MS también puede estar en modo dedicado, es decir, hay
una conexión activa y el usuario está hablando o escuchando.
Entonces obviamente está usando un canal en una cierta frecuencia.
En esta situación el móvil constantemente calcula la potencia usada.
Si este valor cae por debajo de un límite, escanea la red para ver si hay
otra BS de mejores características.
Esto suele suceder cuando el usuario se mueve y la distancia a la BS aumenta.
El MS entonces recopila la información 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 telefonía
-entre un VLR y otro, de distintos operadores, incluso de distintos países
Notar que la decisión de conmutar a otra BS no la toma el MS, sino el BSC.
El valor límite para pasar de una BS a otra es enviado primero por
la BS al móvil, y luego del MS al BS en caso de que la calidad disminuya.
La comunicación 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 sólo me interesa entre dos celdas del mismo BSC, pero tener
una visión completa proporciona más 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 mayúsculas (ej. BSSMAP HANDOVER REQUIRED,
RR HANDOVER COMPLETE) son comandos que se envían entre las
entidades, según el protocolo establecido entre ellas.
Estos valores ocupan 1 byte, y están 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 señal: buena MEASUREMENT
REPORT------------>*
Calidad señal: buena
*-El usuario se mueve
|
RR
MEASUREMENT
REPORT------------------------------------->*
Calidad señal: mala |
RR
MEASUREMENT
REPORT------------>*
Calidad señal: mala |
BSSMAP
HANDOVER
REQUIRED--->*
(T7) |
BSSMAP
HANDOVER
*<-----------------------------------------REQUEST
| (T101)
Reserva canal
de tráfico
|
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 móvil le pide al SABM (Set asynchronous balanced mode) que
establezca la información de señalización.
RR HANDOVER COMPLETE: El móvil usa esta nueva señalización para
indicar que el handover se ha completado.
Esto es la respuesta al comando RR UNBLOCK-ACK: Confirmación de que
el recurso está desbloqueado.
De acuerdo con las especificaciones de GSM:
RR HANDOVER COMMAND tiene valor 83, y también se le conoce como HAND-COM
RR HANDOVER COMPLETE tiene valor 84, y también se le conoce como HAND-COMP
RR UNBLOCK-ACK tiene valor 43
Según 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 señalización.
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 Gestión de movilidad para servicios no-GPRS
0 1 1 0 Mensajes de gestión de recursos de radio. Este es nuestro caso
1 0 0 0 Gestión de movilidad para servicios GPRS
1 0 1 0 Mensajes de gestión de sesión
El segundo dato Skip Indicator vale 0000, según cuenta 10.3.1
El tercer dato Message Type vale 0x2C=00101100=HANDOVER COMPLETE, según
la tabla 10.1 del GSM 04.08 . Hay otros 256 comandos, dependiendo de la
dirección del tráfico y el significado que necesites.
El cuarto dato RR Cause indica la razón por la cual se ha enviado el comando.
En situaciones normales vale 00000000 , según 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 triangulación bastante eficaz para ubicar un móvil.
Así que el mensaje de HANDOVER COMPLETE satisfactorio es como mínimo
0110 0000 00101100 00000000 = 602C00 , en hexadecimal
Recapitulando: cuando el móvil tiene mala recepción, le dice a la red la
lista de antenas y sus potencias , quien quizás decide provocar el handover.
Tras reservar un nuevo canal, la información se transmite por el antiguo canal
al móvil, 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 móvil 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 liberación "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 móvil no ha hecho el handover.
Entonces libera el nuevo canal, puesto que no está usado.
?Y que pasa en este caso con el móvil? Pues que usará erroneamente
el nuevo canal. Cuando se dé cuenta de que no hay nadie escuchándole
buscará otra frecuencia para empezar de nuevo.
Ahora suponer que el móvil 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á todavía liberado
-se reserva un nuevo canal para intentar el handover
Repitiendo este proceso N veces, se reservarán un total de N+1 canales.
Si la velocidad de petición de canales es superior a T102, llegará
un momento en que se ocupen todos los canales.
Entonces ningún usuario más podrá usar ninguna de los BSC que dan soporte
a esa celda.
Obviamente otras celdas todavía tendrán soporte si hay otras BSs alrededor.
Ahora bien, las celdas de tamaño mínimo, llamadas pico-celdas, tienen un
radio típico de 100 metros, así que como mínimo seguro que nadie más
puede hacer un handover en un radio de 100 metros.
Recordar que una misma frecuencia no puede usarse en dos celdas adyacentes.
Notar también que los usuarios con una conexión activa no la pierden, pero
no son capaces de realizar un handover para conseguir mejor calidad.
Para completar la información, decir que también existen:
-microceldas, con un máximo de 1 Km.
-macroceldas, con un máximo de 10 Km.
-celdas paraguas, con más de 10 Km de cobertura
Lo normal es que haya celdas de corta distancia cubriendo edificios con mucha
actividad, y otras celdas mucho más grandes que cubren los huecos entre
las picoceldas. Por supuesto, 2 celdas no pueden tener la misma frecuencia
usada por más de una BS. Este problema de solapamiento de frecuencias
también 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 móvil Siemens S45, con particular atención a aquellas encargadas de
la transmisión y recepción de los datos de radio.
Los datos van codificados cuando se envían por el aire para evitar que
elementos indeseables escuchen la comunicación, pero tanto el móvil
como el BS saben cómo descodificarlos. Si no, ?cómo demonios van a usarlos?
Además debe haber un cierto punto en el que el paquete recibido de 148 bits
está completamente en memoria.
El móvil contiene un interface de radio que en el proceso de recepción 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 móvil debe leer ese puerto (periódicamente o
mediante una interrupción, eso no lo sé) y guardarlo en una posición de memoria.
Cada cierto tiempo mira si tiene todos los bits. En teoría deberían 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 información secreta:
esto se produce en la rutina 0xFA2524 y en r14:13 están 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 petición de cambiar de BS.
Hay un pequeño 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, debería también 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 petición 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 también quedará reservada.
Tras un máximo de 124*8-1 peticiones, todos los canales están 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 petición de nuevos canales continúa.
En cuanto se produzca el fin del algún timer T102/T8 , el BS liberará el
canal, pero yo estaré allí para solicitarlo de nuevo.
Como he comentado antes, este proceso de handover sólo se realiza cuando
tengo una llamada activa.
Esto me fuerza a hacer una llamada antes de poder anular los demás 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 número de teléfono de servicio gratuito que no me cuelgue al cabo del tiempo.
La solución que he aplicado es llamar al teléfono de atención al cliente
de mi operador. Entonces el sistema automático IVR me indica que pulse el
número '1' para saber mi tarifa, '2' para mi factura, '3' para el buzón, ...
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 conexión.
Claro que no puedo estar pulsando teclas cada 5 segundos.
Pero es fácil 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. Sólo 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 fácil de hacer con los múltiples parches existentes en la
red para este teléfono, por ejemplo NAM hecho por lalo.lerry o el de NTCN.
Algo más sencillo es hacer que el móvil no envíe 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 envío 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 notificación 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 móvil y se puede cambiar, aunque no
veo razón 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 estación base el tiempo suficiente, y por lo tanto el BS envía una
y otra vez sus inútiles intentos de handover. Notar que es simplemente
una variación del caso anterior.
En una red ethernet esto se conoce como ataque ACK_SYN, creo recordar.
He explicado que la duración de una trama de 8 canales dura 4.615 milisegundos.
Así que en teoría 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 petición de canales es superior
a la de liberación de los no usados, por lo que efectivamente puedo llegar a
ocuparlos todos.
Pero aquí estoy dando la solución 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 móvil usa la frecuencia 890.4
-El usuario se mueve rápidamente 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 móvil 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 sólo
se puede hacer cuando positivamente la respuesta se ha perdido.
Como "confirmación" de esta hipótesis 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 compañías involucradas: Alcatel, Nokia, Siemens,
Lucent, Vodafone, Orange, Movistar, T-mobile, UMC, Ericsson, y Telia.
Otra posibilidad interesante es activar este DoS con varios teléfonos para
conseguir un DDoS. No lo he probado.
La utilidad de este artículo es evidente: hay sitios en los que la gente
no debería tener los móviles encendidos: en el cine, los museos, la
iglesia, los restaurantes, ... y lo que mas me disgusta: en el autobús que
va de Santander a Vigo. Parece que todo el mundo se empeña en hablar entonces !
Activa estos trucos y ya nadie a tu alrededor podrá recibir llamadas ni SMS.
Pero también debes ser una persona responsable y no activarlo en las
cercanías de hospitales, bomberos , o la policía.
De todos modos esto es ilegal, así que yo no me arriesgaría.
Además, el consumo de batería es realmente alto.
Si vas paseando tranquilamente y tu móvil deja de tener cobertura, mira a tu
alrededor: quizás algún 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 móviles 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 artículo, 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*
