ESCANERFRECUENCIAS

Hola a todos, me llamo Jesús Tormo, soy estudiante de ingeniería informática y comparto con ustedes esta afición por la radio, la electrónica y la tecnología.

Como todos hemos comentado alguna vez en este foro el futuro son las comunicaciones digitales, poco a poco nuestros queridos scanners que con tanto esfuerzo adquirimos un dia, van perdiendo utilidad y de ellos no obtenemos sino chirriantes e imcomprensibles pitidos.

El mercado no nos ha dado o no ha querido darnos una respuesta a nuestras demandas de evolución tecnológica y las soluciones comerciales, de haberlas, valen un ojo de la cara y parte del otro o sencillamente nos las niegan. Nos las niegan porque la información es poder y a nadie le interesa que ese poder esté en manos del pueblo, a los políticos solo les interesa su poltrola y prohibir, prohibir y prohibir, que nos conformemos con el fútbol y el gran hermano, telebasura y payperview. Aún no pueden conducir por nosotros, pero el día que puedan... agarraos los machos, nos van a decir a donde tenemos que ir, cuando y cómo y a quien tenemos que llevar en nuestro coche, que por supuesto conducirán ellos porque nosotros no somos capaces, ellos saben lo que nos comviene mejor que nosotros mismos, prohibido fumar, prohibido beber, prohibido tener otra casa cerrada en la playa, que si te quitamos los puntos del carnet, que si te subimos los impuestos, trabaja miserable, mil euros al mes y te quitamos el 30% para para mantener a los que te prohiben.

Pues bien, mientras no prohiban la constitución, que creo que les falta poco, tal y como va el gobierno, y bajo su amparo y el derecho a la libertad de aprender y enseñar cualquier conocimiento, me he propuesto escribir una serie de artículos en los que voy a describir la implementación de un sencillo receptor para comunicaciones digitales basado en componentes de bajo coste como los sintonizadores de tv o los de satélite,
la salida de este receptor será digital y nos servirá como base para el desarrollo del software necesario para recibir los distintos tipos de comunicaciones digitales.

No voy a empezar la casa por el tejado, lo que me propongo es edificar unos sólidos cimientos a partir de los cuales desarrolladores independientes puedan implementar el software necesario para lograr un scanner digital multimodo.

Mi idea no es nueva, Matt Ettus ha hecho algo parecido, la diferencia es que yo voy a utilizar componentes baratos de uso común, de forma que uno pueda implementarse su propio receptor por menos de 300 euros, frente a los más de $900 que cuesta un sistema básico de software radio Ettus.

Hola amigos, recientemente he mantenido correspondencia con un compañero del foro sobre la posibilidad de desarrollar un receptor específico para la tecnología DECT (teléfonos inalámbricos digitales). Pienso ampliar el tema con un artículo más detallado, pero aquí os dejo una copia de la carta que le envié a este compañero.

Por supuesto, cualquier sujerencia o aportación será bienvenida.


Si tomamos como postulado que DECT no hace salto de canales con frecuencia y que seguramente no va encriptado o una encriptación básica como el XOR con la clave, necesitariamos un receptor con un ancho de banda de 1,278 MHz en frecuencia intermedia, que yo conozca solo los AOR AR-3000A y AR-5000 disponen de esa característica, ya que su ancho de banda pasante en F.I. es de 10 MHz, el AR-5000 incorpora una salida directa de F.I. mientras que el 3000A (importante la A) necesita una pequeña modificación descrita en la página de AOR.

http://www.coit.es/publicac/publbit/bit103/quees.htm

Una vez que disponemos de la salida de F.I. en 10,7 MHz necesitamos reducirla en frecuencia a su valor mínimo (esto es para utilizar un ADC lo màs barato posible y no sobrecargar el pc de datos inútiles). Puesto que el ancho de banda de DECT es de 1,278 MHz, filtraremos la señal de F.I. ya sea mediante un filtro de cristal (más caro) o diseñando un paso banda LC (Chevyshev o Butterworth) y la convertiremos mediante un pequeño chip mezclador/oscilador de cristal, el ne602

http://users.tpg.com.au/users/ldbutler/ ... verter.htm

la mínima frecuencia que podemos utilizar es la propia frecuencia del ancho de banda dividido por dos, si bien es mejor sumarle siempre 50 o 100 KHz para evitar que la frecuencia llegue a cero en los extremos, así que en principio 750 kHz sería adecuado, ya que con un ancho de banda de 1278 kHz tendriamos 750 +- 639 (esto es 1278/2).

Ahora solo necesitamos un cristal que oscile a 10,7 MHz + 0,750 MHz para que la mezcla entre la F.I. del receptor y nuestro oscilador NE602 den como resultado los 750 KHz requeridos. Después del paso mezclador, necesitamos un filtro paso bajo calado a 1389 kHz que es la máxima frecuencia que debe salir del mezclador (750 + 1278/2).

Una vez que tenemos la señal DECT en un formato manejable por una computadora, necesitamos pasarla a formato digital, para ello emplearemos un ADC barato. Según el teorema de Nyquist
http://es.wikipedia.org/wiki/Teorema_de ... st-Shannon

necesitamos como mínimo muestrear al doble de la máxima frecuencia que alcanzará nuestra señal, esto es 1389 kHz x 2 = 2778 kS/s (kilo Samples por segundo).
El chip ADS5120CZHK es un ADC de 8 canales que puede muestrear hasta 40 MS/s a una resolución de 10 bit y es relativamente fácil de encontrar en ebay por unos $30.

Una vez que tenemos la señal en digital, tan solo nos queda introducirla en el PC, para ello hay múltiples opciones, la más barata es utilizar una bahía pcmcia que dispone de 32 lineas digitales I/O y escribir un módulo de control en linux .
Otra opción de complejidad y costo intermedio es utilizar un microcontrolador PIC con bus usb como interface PIC18F4550 muy barato en ebay.

La solución más cara pero la más sencilla es utilizar una tarjeta I/O de alta velocidad, unos 200 euros aproximadamente, con la ventaja de que ya nos da el software de recolección de datos hecho.

Una vez que tenemos la señal DECT al alcace de nuestra computadora, mira las maravillas que se pueden hacer con linux y software standard, imaginate si lo programas expresamente para ello:

http://www.domenech.org/homebrew-sdr/receptor-1.htm

Como todo el mundo no se puede permitir un receptor AOR, te comentaré que estoy implementando una gama de receptores para DECT, GSM y sistemas digitales basados en sintonizadores de satélite y tv baratos.

Veamos como solucionariamos los problemas del DECT con poco presupuesto:

Un sintonizador de TV por satélite digital que podemos encontrar en cualquier decodificador digital sintoniza en el rango de 900 a 2150 MHz con un ancho de banda pasante típico de 25 MHz, con una salida de F.I. en 479,5 MHz. Pues ya no necesitamos el AOR, extraeremos la F.I. de un viejo sintonizador de satélite recauchutado y tan solo tendremos que cambiar dos cosas de nuestro diseño anterior para el AOR, primero el filtro paso banda, que habrá que adecuarlo a la nueva frecuencia intermedia y segundo el cristal de cuarzo, todo lo demás es perfectamente válido.

Bien ahora vamos a tratar el tema de salto de canal, tenemos dos opciones:

a) puesto que el ne602 y sus componentes asociados son muy baratos, podemos construir 10 bloques de F.I. sintonizando cada uno a un canal dentro del amplio ancho de banda de la frecuencia intermedia. No olvidemos que el ADC que hemos utilizado es de 8 canales, por lo que necesitariamos dos para cubrir los 10 canales.

b) ponerle un PLL al ne602 como se describe en uno de los enlaces que te dejo al final, ese PLL puede gobernarse mediante un microcontrolador PIC o directamente a la puerta centronics (puerto paralelo) del PC, y sería el software el encargado de conmutar de canal DECT.

Como podrá ver, mi querido amigo, no hace falta mucho presupuesto para investigar, tan solo imaginación y bueno, tal vez sacrificar algunas salidas de fin de semana, jaja.

Sat tunner datasheet:
http://www.datasheetcatalog.com/datashe ... 8G06.shtml

Como operar con sintonizadores digitales con PLL:
http://hem.passagen.se/communication/sprec.html

Saludos.

Jesús.

Magnífica documentación; aunque es una lastima lo del Linux: no lo domino.
Por lo demás, la iniciativa me parece muy positiva.
Saludos.

Se me olvidaba. Un projecto similar al que propones, para GSM y para crackear el A5, es el que está haciendo Steve y compañia (http://wiki.thc.org/), aunque creo que ya estás al tanto, ¿no, Pijus?.
Desgraciadamente, mis conocimientos no son tal altos y, a veces, me pierdo con este proyecto. Creo que el tema está bastante avanzado ....
Saludos.

sastreprim escribió:Se me olvidaba. Un projecto similar al que propones, para GSM y para crackear el A5, es el que está haciendo Steve y compañia (http://wiki.thc.org/), aunque creo que ya estás al tanto, ¿no, Pijus?.
Desgraciadamente, mis conocimientos no son tal altos y, a veces, me pierdo con este proyecto. Creo que el tema está bastante avanzado ....
Saludos.

Las investigaciones de Steve se basan en el ataque por tablas precalculadas al A5 y dado el tamaño de estas tablas (28 Terabytes) es descomunal creo que el gsm está todavía lejos del común de los mortales, creo que tiene que haber una forma más sencilla de romper el A5 basada en la negociación inicial de claves entre célula y terminal.

Saludos.

sastreprim escribió:Creo que el tema está bastante avanzado ....
Saludos.

el tema esta muy poco avanzado precisamente por las dificultades de hardware y la renovacion que implica las comunicaciones digitales a nivel conceptual. Uno de los puntos aun en desarrollo es la codificacion convolucional, ya que parece que el proyecto adolece de gente de telecomunicaciones hay que empezar de nuevo, yo personalmente aun estoy en el codigo Hamming...me falta bastante, pero afortundamente esa gente sabe mas que yo y es mas lista.

el proyecto de jackbauer es interesante pero soy partidario del esfuerzo hardware minimo debido a que el hardware es caro y un error de concepto en ausencia de material de test podria ser catastrofico (dependiendo de la economia de cada quien, la mia es economia de NULL pointer -por darle un matiz gracioso-); y en este sentido le envie una informacion creo que interesante para tener solucionado el problema de la sintonizacion-demodulacion del dect con placas de famitel am10, que estan perfectamente diferenciadas del resto de la pbc y para colmo con punto de soldadura relativamente grandes y su antena pertinente. Quedaria entregar esos datos al ordenador, y el precio de un am10 es de 30 euros, uno de los dos chips que usa dicha parte esta documentado el otro no lo encuentro pero creo que poco importa ya que es un amplificador.

en caso de interesa paso el pdf
animaros por que el costo es minimo: 30 euros y si la cosa no sale por lo menos nos entretenemos, que en los tiempos de hoy ya tiene merito

http://img443.imageshack.us/img443/5051/dectja9.jpg

JackBauer escribió:Las investigaciones de Steve se basan en el ataque por tablas precalculadas al A5 y dado el tamaño de estas tablas (28 Terabytes) es descomunal creo que el gsm está todavía lejos del común de los mortales, creo que tiene que haber una forma más sencilla de romper el A5 basada en la negociación inicial de claves entre célula y terminal.

pues no me parece tanto, con 56 discos duros de 500MB ya esta

https://www.batch-pc.com/batchpc/tienda/articulos05.asp?pg=4&pagesize=9&idfam=443&fam_id_padre=442

ten en cuenta que el GSM lo vale
230*28*4/3~9000 euros
millon y medio de pesetas un regalo, incluso un mileurista lo podria comprar

Ante todo quiero expresar mi agradecimiento al Sr. Joseyvicente, gracias a cuya visión, empeño e instinto hemos podido descubrir las enormes posibilidades que encierra este terminal.

He de decir que la telefonía DECT no es una de mis prioridades, por lo que es posible que pasen meses o incluso años antes de que me ponga a experimentar en serio con estos terminales, pero no he podido resistirme a hacer una incursión dadas las enormes facilidades que ofrecen los AM10, parece como si llevaran pegada una etiqueta que pusiese ‘hackeame por favor’.

En primer lugar, la parte de RF va separada de la de control, con lo que ya nos empieza facilitando las cosas, es más, todo el transceptor (emisor y receptor) va en un único integrado de la casa Philips que está perfectamente documentado, aquí es donde a uno se le disparan las neuronas -¿Quiere esto decir que puedo tomar el control del transceptor y hacerme un receptor para comunicaciones DECT? – Pues sí, eso es exactamente lo que quiere decir, después veremos cómo. Pero refrenemos nuestra excitación, todavía tenemos que superar dos grandes obstáculos, uno es que DECT no sólo es digital, sino que permite el cifrado de las comunicaciones y el otro es el temido channel hopping o salto de canal, es decir que estos bichos no se conforman con una frecuencia fija, sino que saltan de canal cada vez que les da la gana, lo bueno es que sólo hay diez canales, con lo que no pueden ir muy lejos, además, a nuestro favor está que lo más probable es que solo cambien de canal cuando les molesta una interferencia, por lo que, aunque sólo es una suposición basada en el escaneo convencional de varios terminales DECT, entre salto y salto de canal pueden pasar varios minutos, al igual que sucede con el trunking. La segunda buena noticia es que también es muy probable que la mayoría de los terminales DECT baratos no lleven cifrado, ya que este exige más potencia del microcontrolador (mcu) o un procesador extra, lo que encarece el coste final.

Pero lo bueno no se termina aquí, este terminal parece haber sido diseñado por hackers, desde el famoso teléfono móvil de Kevin Mitnick, no había sido tan sencillo reprogramar un terminal móvil, ya que la unidad central de proceso, el microcontrolador que gobierna todo el sistema es una mcu 80C51 de Philips, una mcu también muy documentada, con lo que se disparan las posibilidades.

Recapitulemos, tenemos una placa de RF que es un transmisor receptor que opera en la banda DECT (1880 a 1900 MHz) gobernado por una mcu que podemos reprogramar a nuestro gusto y convertirla en un escaner para teléfonos inalámbricos DECT, con lo que en caso de dar con un Terminal no encriptado, podriamos escuchar perfectamente estos teléfonos, además es un escaner que podemos llevar en el bolsillo a todas partes. Para las comunicaciones encriptadas la cosa se complica un poco más, ya que habría que buscar qué algoritmo de encriptación utiliza y una forma de romperlo mediante una computadora, en este caso esta ‘placa de RF reprogramada’ puede servir a los que quieran experimentar con criptografía. Y no nos olvidemos de la base del teléfono, que aunque no he podido examinarla aún es de suponer que incluya una configuración similar, con lo que ya tendriamos dos transceptores reprogramables sintetizados y microcontrolador por 30 euros.

Pasemos a describir el conjunto; está formado por tan sólo seis integrados que paso a comentar a continuación:

Placa de RF:
AA3590: Amplificador de potencia de RF para transceptores duplex de acceso múltiple por división en frecuencia de amplio espectro.
A3545: Trasceptor DECT totalmente integrado en un chip.

Placa de control:
LV373: Array de 8 buffers tri-estado.
37VF010703CWH: Memoria FLASH de 1Mbit.
24C32ANSU27: 32k serial EEPROM
PDC50953H/E96: 80C51 mcu.

Todos estos integrados están perfectamente documentados y sus hojas de datos están disponibles en Internet, a excepción del AA3590 cuya hoja de datos específica no hemos encontrado, aunque si la de otro miembro de la misma familia, el AA3592 que debe de ser muy similar, en cualquier caso, esto solo nos debería preocupar si tuviésemos intención de utilizarlo como emisor, pues el amplificador de potencia de emisión no pinta nada en recepción.

Algunas ideas finales:

Como podemos ver, el número de posibilidades es infinito, tan sólo limitado por nuestra capacidad imaginativa, con una placa que cuesta tan sólo 30 euros, tenemos un transmisor receptor digital microcontrolado totalmente programable, podemos desde volcar la FLASH y la EEPROM e intentar descompilar el sistema operativo original, hasta tomar el control del transceptor aislándolo de su unidad de control, pasando por la posibilidad de borrar la FLASH (guardando primero un volcado, claro está) y reprogramarla con nuestra propia aplicación de control para la plaquita.

Para ir abriendo boca, os dejo la documentación de la unidad central de proceso:

http://www.nxp.com/acrobat_download/var ... ARCH_1.pdf
http://www.nxp.com/acrobat_download/var ... WARE_1.pdf
http://www.keil.com/dd/docs/datashts/philips/p51_pg.pdf

Si alguien quiere la documentación completa de todos los integrados, que me escriba a mi o a Joseyvicente y se la enviaremos por email.

Podeis escribirme a pulsar75[arroba]gmail.com
Substituid los corchetes completos por el signo de la arroba antes de darle a enviar
Si es una duda general sobre este tema o alguna consulta prefiero que la hagáis en el foro.

Y no olvidéis super vitaminarse y super mineralizarse.

Nota: La propiedad intelectual de este artículo es exclusiva de su autor y su única intención es meramente didáctica, estando amparado por las libertades de cátedra y de expresión, principios recogidos en La vigente Costitución Española de 1978. Queda autorizada su copia y difusión por cualquier medio siempre que se cite la fuente y al autor.

Jesús M. Tormo.

estoy revisando los chips aunque ya sabes que mi conocimiento y posibilidades no estan la mismo nivel que mi obsesion que al reves que tu prioriza el dect al gsm, e incluso otros sistemas de los que hablare algun dia.

solo escribo esto para comentarte que el chip no documentado es un amplificador de rf, viene indicado en el pdf del procesador de banda base o sea que poco nos importa.

Como vimos antes, todo el transceptor DECT está integrado en una sola pastilla, el A3545:
http://www.datasheetcatalog.com/datashe ... 3545.shtml

Según muestra la hoja de datos, se gobierna mediante el típico bus I2C, para el que no lo sepa, este es un bus muy común para comunicaciones entre integrados compuesto de 3 hilos a nivel de lógica TTL. Estas tres señales se denominan ENABLE (pin 6), DATA (pin 4) y CLOCK (pin 8). ENABLE le dice al dispositivo que se prepare para recibir instrucciones, DATA es una cadena de bits cuyo formato varía según el modelo específico de dispositivo, es en esta cadena de bits donde se codifican las órdenes y finalmente, la línea CLOCK indica cuando comienza la transmisión de un bit DATA (CLOCK a estado alto) y cuando finaliza ese bit (CLOCK a estado bajo).

Como podemos ver, será muy fácil hacernos con el control del transceptor, en una primera aproximación podemos utilizar tres líneas del puerto paralelo de un PC para gobernar este integrado, haciendo un pequeño programita en cualquier lenguaje de programación que dominéis, como C, JAVA, PASCAL, Visual Basic, etc. Tan sólo necesitáis acceder a bajo nivel al puerto 0x378 que suele corresponderse con el puerto paralelo del ordenador.

Ya hemos visto la utilidad de las señales Enable y Clock, vamos a ver ahora la más importante, el formato de la señal DATA. Como podéis ver en la hoja de datos, la señal data consta de un stream o hilera de 24 bits, cuyo significado, de bit de mayor peso (msb) a bit de menor peso (lsb) paso a describir:

b23 a b20: son bits de comprobación, siempre deben estar a cero para que la cadena sea válida.

b19: Este es un bit un poco especial, normalmente lo dejaremos a cero para obtener la señal de banda base demodulada en el pin 7 (RDATAP), ver la hoja de datos para más información.

b18 a b17: Estos bits le indican al integrado de qué valor es el cristal de referencia que se utiliza como señal de reloj interno, las posibilidades son:
00 para 3,456 MHz
01 para 13,824 MHz
10 para 6,912 MHz
11 para 10,368 MHz

b16 a b10: bits de control, siempre a cero.

b9 y b7: Cambian el modo de operación (ver hoja de datos para los diferentes modos).
00: modo normal.
01: modo de baja señal.
10: no usado.
11: Modo avanzado de señal.

b8: Fuerza al PLL del sintetizador a estar siempre encendido mientras el VCO lo esté si está a 1.

b6: Este bit parece tener una doble función, por un lado, si está a cero, el chip está en modo receptor, si está a 1 el chip está en modo emisor, pero a la vez es el bit de menor peso del divisor del PLL que sintetiza la frecuencia del canal de operación, lo que parece indicar las frecuencias de transmisión y recepción no coinciden. Hay que experimentar esto.

b5 a b0: divisor principal del PLL que sintetiza la frecuencia del canal de operación, según la siguiente fórmula:

n es el número, pasado a decimal, formado por los bits: b5, b4, b3, b2, b1, b0, b6
divisor = 2176 + n
Frecuencia del canal = 0,864 x (2176 + n)
para n = 00, esto es 0000000 en binario, Fc = 1880,064 MHz
para n = 47, esto es 0101111 en binario, Fc = 1920,672 MHz

Con lo que hemos visto hasta aquí, ya podemos hacernos nuestro primer scanner para DECT, lo primero que tenemos que hacer es separar, desoldando, las tres patillas del bus I2C de la placa de circuito impreso, esto es las patillas 4, 6 y 8, para ello necesitaremos unas pinzas, flux para dispositivos de montaje superficial (smd) y malla de cobre que podemos sacar de un coaxial de buena calidad RG58 o RG213, también podemos comprar tira de cobre para desoldar smd que venden en cualquier tienda de electrónica, en esta página podeis aprender como se desueldan componentes smd:

http://www.servisystem.com.ar/smd1.html

tened en cuenta que sólo teneis que desoldar los tres pines en cuestión, después de aislarlos de la placa del teléfono, soldaremos a estos tres pines unos hilos finos, en las tiendas de electrónica venden un hilo esmaltado muy fino para estos menesteres, pero si no lo encontráis, se puede utilizar hilo para bobinar inductancias que está igualmente esmaltado, hay que quemar un poco la punta con el soldador para remover el esmalte y estañarlo bien para soldarlo a las patillas, otro sistema es cortar con un cutter muy afilado y mucha maña las pistas de circuito impreso que van al chip, para repararlo luego bastara un poquito de estaño que vuelva a unir las pistas.

Una vez que tenemos el bus de control aislado del resto del terminal, partimos por la mitad un zócalo de circuito integrado de 14 pines (de los que tienen los pines circulares, no los planos) dejando dos hileras de 7 pines, soldamos los pequeños hilos de bobina que hemos puesto, a las patillas de una de las hileras de pines, así tenemos un enchufe donde enchufar el cable que vendrá del puerto paralelo y al que soldaremos el otro medio zócalo, para así enchufar un medio zócalo dentro del otro medio y poder conectar y desconectar el cable paralelo fácilmente, este cable debe de tener 5 hilos, los tres de las señales de control, más un cuarto hilo, el pin 25 del conector paralelo, que conectaremos a la masa del teléfono o en su defecto a cualquiera de los siguientes pines del integrado (ahora NO hay que desoldar estos pines de masa) 10, 13, 18, 19 ó 30. Este conector podemos ponerlo en una esquina de la carcasa del teléfono, haciendo una pequeña abertura con el cutter, el quinto hilo será la salida del detector, patilla 7 del integrado A3545.

A partir de aquí podemos comenzar a experimentar enviando comandos de control al chip y ver como reacciona, sería interesante tener un osciloscopio conectado al demodulador (patilla 7) para ver el formato de los datos que recibimos. El altavoz del teléfono lo encenderemos y apagaremos descolgando o simulando que hacemos una llamada, porque en realidad ahora aunque marquemos el teléfono no hará nada, ya que el control del interfaz radio lo tenemos nosotros.

Otra idea que sería muy interesante es monitorear con el puerto paralelo las tres líneas de control del integrado A3545, pero sin llegar a cortarlas, de esa forma, como ya sabemos el significado de los bits de control, podemos hacer un pequeño programa que lea el puerto paralelo del ordenador y nos diga que hace el teléfono en cada uno de los siguientes casos:

a) buscar la base
b) sincronizarse con ella
c) protocolo de handshaking
d) datos que se intercambian
e) hacer una llamada
f) formato en que están los datos al hablar

Todo esto antes de tomar nosotros el control, sería un programa sniffer o husmeador que espiaría como funciona el teléfono, de esto podriamos aprender muchísimo sobre como funciona DECT.

Próximo episodio en su casa.

Happy hacking…

Nota: La propiedad intelectual de este artículo es exclusiva de su autor y su única intención es meramente didáctica, estando amparado por las libertades de cátedra y de expresión, principios recogidos en La vigente Costitución Española de 1978. Queda autorizada su copia y difusión por cualquier medio siempre que se cite la fuente y al autor.

Jesús M. Tormo.