Tarjetas de Timofónica

Desde hace unos cuantos años hasta ahora, nuestra querida Telefónica nos a venido sorprendiendo con unos nuevos telefonines públicos (cabinas), equipados con lector de tarjetas. Dichas tarjetas, como todos sabréis, están equipadas de un chip, una memoria PROM, imposible de borrar una vez escrita. Por lo que la idea de hacer un "recargador" de tarjetas fue rechazada de cuajo. Sin embargo, hace ya unos años, surgió la idea de emular la susodicha memoria PROM, y de este modo disponer de una tarjeta válida, y con la posibilidad de puesta a cero en cada llamada. Surgieron varios circuitos con este fin, unos antes, otros después, otros mejores, otros peores. Pero desde hace un tiempo (año y medio aproximadamente), los inventos dejaron de funcionar, las cosas empeoraron y surgió la controversia, de tal forma que construir un emulador actualmente se ha convertido en una cosa muy chunga . Y aquí está este documento, con la idea de aclarar ideas más que exponerlas, en el difícil mundo del phreaking en España. Desde CPNE esperamos aclara tus dudas.

Recientemente, si el phreaker intrépido lee los diversos documentos referentes a tarjetas telefónicas( Bausson, TPROM.DOC, Ingenieros Cabreados, Lector por _J-R_ y SpeedFire, Emulador de Minotauro/DAN), se dará cuenta que no existe coherencia entre ellos. Eso es así porque cada DOC. llama a los pines de una manera distinta, e incluso se le otorgan distintas funciones. ¿Cuál elegir? Porque evidentemente, alguien dirá la verdad. Voy a tratar de explicar quien y quien no tiene la razón y por qué. NOTA: puede que yo también me equivoque.

Fíjate bien, porque esa es la numeración de pines que seguiré en este documento. Ojo, porque puede no coincidir con los otros autores. La tabla 1 expone el patillaje y las funciones de los pines según JM García y su TPROM.DOC. GND y Vcc corresponden a la alimentación. Vpp se usa para programar una dirección de la memoria. Dout es la salida de datos de la posición de memoria actual. Din es la entrada de datos. Cuando Vpp == 21V, el estado de Din quedará grabado en la posición apuntada por el contador interno. Recordemos que sólo se pueden grabar unos. CLK sirve para cambiar de dirección el contador interno, de tal manera que recorre cíclicamente los 256 bits de manera secuencial. RST sirve para poner a cero el contador interno y que este apunte a la dirección 0 (como en C, la primera dirección es la 0, no la 1). La figura 2 muestra el diagrama de tiempos según el TRPOM.DOC también. Como se ve, la tarjeta tiene 3 posibles estados: Lectura, Reset y Escritura. Comencemos con el ciclo de reset. Considerando que el contador esté en la posición n, si ponemos RST a nivel bajo y DAMOS UN PULSO DE RELOJ, el contador apuntará a la posición cero, y por lo tanto, por Dout saldrá el dato grabado en la posición 0. Hay que decir que si no damos el pulso de Reloj, no se producirá el RESET. Estando leyendo una posición Dn, si aplicamos un pulso de reloj, el contador avanzará una dirección, y por Dout saldrá el dato que esté grabado en Dn+1. El ciclo de escritura es el más complejo: Estando el contador en Dn, pondremos en Vpp 21v y Din a uno( recuerdo que sólo se pueden grabar unos), y aplicaremos un pulso de reloj y retiraremos Din y Vpp a 5V. El contador NO AVANZARÁ y quedará grabado en Dn un 1. Para poder leer la siguiente posición, habremos de aplicar otro pulso de reloj. Es importante dejar claro que JM expone que el estado de Dout es irrelevante en las operaciones de escritura. Vpp deberá estar conectado a +5v siempre, menos en las operaciones de programación cuando esté a 21v. En ningún momento debe estar a 0v.

Explicaremos ahora lo que dice el señor Bausson en su Doc. sobre las smartcards. Para el señor Bausson, los pines tienen idéntica función, salvo los siguientes: Dout (pin nº 3) es llamado I/O, es decir, entrada y salida de datos. Esto es importante, pues por este pin saldrán los datos que leamos, pero TAMBIÉN ENTRARÁN los que queramos grabar. Din (pin nº 7) es llamado por Bausson, R/W, es decir, estando a nivel bajo, la tarjeta estará en modo de lectura y estando a nivel alto, en modo de escritura. La figura 3 muestra el diagrama de tiempos propuesto por Bausson. Señalo que hay contradicciones en el documento de Bausson: dice que el pin 3 es de I/O. Si sólo se pueden grabar unos, en un ciclo de programación deberá estar a uno. Sin embargo, en su diagrama de tiempos pone que su estado es irrelevante (o sea, que da lo mismo como esté para que se produzca la grabación). Aquí coincide con JM García. Otro dato importante es que mientras JM expone que durante la grabación el contador no avanza, según Bausson si. Resumiendo-> de la doc de Bausson se saca que coincide con JM García, salvo en lo del contador que se incrementa en la grabación. Lo demás es lo mismo, pero con distinto nombre. Esto es haciendo caso a los diagramas de tiempo.

Pero… ¿cuál tiene razón?. Pues ninguno de los dos. Leyendo en Bausson el mapa de memoria, las tarjetas españolas son fabricadas por: Gemplus, Oberthur y G+D. Gemplus es una importante compañía, pero que no da información. G+D me es desconocida (al menos por ese nombre). Oberthur es una división de KirkPlastic, y en su web encontré que las tarjetas que fabrican incorporan el chip ST1200. ST es de SGS-THOMSON, importante empresa de semiconductores. El chip ST1200 se corresponde efectivamente con una memoria EPROM de 8 pines, de 256 bits, con todo lo expuesto en orden. Todas los pines coinciden, salvo el pin 5 ( Reset) y el 7 (Din según JM y R/W según Bausson). En el datasheet, el pin 5 es B y el 7 es A, mientras que CLK es un reloj que valida los códigos de función que ingresemos por A y B. Es decir, que cuando demos un pulso de Reloj, dependiendo de los cuatro estados posibles de A y B ( porque son 2 bits, 4 combinaciones), se producirá: o una lectura, incrementando el contador, o una escritura ( luego explico si incrementando el contador o no), o un reset. Es lo mismo, pero con otro nombre. La tabla 2 muestra estos códigos. Como se ve, el pin B ( nº 5) bien puede corresponderse con un reset, activo a nivel bajo. Y el pin A puede corresponderse con un R/W. El chip asume que sólo se escriben unos. En el datasheet, el pin 3 ( Dout según JM y I/O según Bausson) es Dout, con lo que Bausson está confundido. De todas formas, el diagrama de Bausson está bien en este aspecto. Y vamos con lo más escabroso-> ¿avanza el contador de direcciones en un ciclo de programación? Según el datasheet, NO, no avanza. Luego la razón la tiene JM García, pero ojo, sólo para las tarjetas que lleven el chip ST1200, que son las de Oberthur. Es posible que las de Gemplus también los lleven. Las de G+D NO lo llevan ( asique no se te ocurra intentar emularla con estos datos). Las ilustraciones de la página siguiente muestran los diagramas de tiempos de el ST1200. Para poder leerlos, adjunto todo lo necesario. Espero que ahora las cosas estén un poco más claras. Y estos son los pines que propongo: todos iguales que JM García ( GND, Vpp, Dout, RST, CLK y Vcc) salvo Din, que llamaremos R/W, como Bausson. En cuanto a diagrama de tiempos, el de JM García y los del ST1200 son los únicos válidos.

Por el bien de todos los phreakers, no divulguéis más información falsa. Es conveniente usar todos la misma terminología.

Hace ya unos cinco años que apareció el primer emulador de tarjetas PROM ( o EPROM, mejor). Fue el TPROM.DOC de Don JM García. El emulador funcionaba a la perfección ( yo no lo he probado) hasta hace año y medio ( estando ahora a Septiembre del 97). Muchos son los que se han aventurado a predecir las causas de esto, pero una cosa está clara: tiene que haber forma de hacerlo funcionar.

El usuario que se ponga a construir el susodicho emulador, se encontrará que ciertos componentes (concretamente la memoria, una CMOS 4537, y el transistor, el BF320) se han quedado obsoletos y ya no se fabrican. Además, como ya he dicho, el emulador NO FUNCIONA en las actuales cabinas (y me refiero a las azules de toda la vida). El propio autor propuso que se debía a cortes en la alimentación, pero de ser así, bajaría el pestillo, jodiéndose el invento a media llamada. Pero según las últimas informaciones, el pestillo ni siquiera se baja, con lo que esa no es la causa(o por lo menos, no esa sola). Por lo que he oído, el teléfono, modernamente, sólo alimenta la tarjeta(o el emulador) cuando descuenta dinero(quema fusibles). Sin embargo, al principio, la alimenta hasta que la lee y baja el pestillo. Debería bajarse el pestillo. Y no se baja. Pensando mucho, después de ver el convertidor de tarjetas de 1000 a 2000 ptas. de Cyberhack Magazine(seguid así muchachos), y si es verdad que funciona, deduzco que el fallo está a partir de la dirección 96. Pregunta ->¿qué tiene una tarjeta real después del bit 96 que no tenga el emulador(cualquiera de ellos, el de JM y el de ingenieros, del que hablaré más adelante)? Pues si. Los DIEZ FUSIBLES FUNDIDOS de fábrica. Haré pruebas para confirmarlo, aunque creo que esa es la causa de que el emulador falle. Esto es así porque es fácil para Timofónica desarrollar un nuevo software para su módulo lector de tarjetas que compruebe que las diez siguientes direcciones a la 96 están a 0 (debiendo estar a 1). Ni siquiera tiene que cambiar el lector. Sólo el software( y por lo que he oído, lo puede cambiar a distancia por el módem que incorporan los TMs). En fin, alguien debería actualizar este emulador, poniendo memorias actuales ( 6116, 6264) y a base de puertas, no transistores, respetando el diagrama de tiempos(no como los ingenieros cabreados) y corrigiendo el fallo de los diez fusibles. Si piensas construirlo, despídete, pues aunque consigas todos los componentes, NO FUNCIONA tal y como está ahora en el TPROM.DOC.

Otro emulador interesante aparecido recientemente es el de Ingenieros en Paro Cabreados. Está realizado por un tal Jack el Destripa-Hardware, y se intenta que sea el sucesor del TPROM.DOC. Está realizado con componentes modernos, que se encuentran en todas las tiendas de electrónica, y su realización práctica es posible. Sin embargo….. NO FUNCIONA. En efecto, no funciona. Y esto es, además de por lo de los diez fusibles que he comentado, porque tiene fallos en el diseño. En una tarjeta real, el Reset, se produce al darle un pulso de CLK con la señal de Reset activada, pero en el emulador el Reset se produce con sólo activar el Reset, sin tener en cuenta el pulso de Reloj. Creo que este error no es crítico(es decir, es error, pero que no impide que el trasto no funcione, pues si se activa el reset, se entiende que el teléfono mandará el correspondiente CLK). De todas formas, uno ya no se puede fiar ni de su sombra, y si queremos un chisme que funcione…. Otro fallo está en la escritura. Hemos quedado que en la tarjeta real, cuando R/W (según mi terminología, no la de Bausson) está a uno y Vpp a 21v, si se produce el pulso de reloj, queda grabado un uno en la posición Dn, y el contador NO AVANZA, por lo que inmediatamente leeremos el Dn, sin necesidad de resetear la tarjeta. El emulador no tiene en cuenta esto, y avanza a la siguiente posición, con lo que el teléfono rechazará la tarjeta(en este caso nuestro invento). Este es un error crítico, que hace que el emulador NO FUNCIONE. No lo hagas, pues NO FUNCIONA. Hay que revisarlo también.

Otro emulador apareció en la revista Minotauro. Está hecho a base de microcontrolador y emula a una tarjeta GASTADA, por lo que habría que cambiar el código del micro. No lo he probado ni lo pienso probar, porque creo que es una tontería(pues encima de usar componentes caros, emula a una tarjeta GASTADA). No lo hagas(aunque aporta ideas muy buenas).

Por último, de los emuladores que conozco, sólo me queda hablar del de Lionel Hutz. Es una quedada, no vale para nada. No hay más que mierda en ese DOC. Ni lo mires. Cualquiera que sepa un poco de electrónica dirá: ¿qué kojones es esto?. En efecto. Una auténtica BOBADA. Si llega a tus manos, bórralo.

En resumen, actualmente (septiembre-1997) no hay emulador que funcione en las cabinas azules.

Despídete de construir nada(por ahora) y no enriquezcas a los dueños de las tiendas de componentes electrónicos. Sin embargo, en la revista CyberHack Magazine ha aparecido un convertidor de 1000 ptas a 2000 o 2100 ptas. Dicen que funciona(todavía no me ha dado tiempo a probarlo). Creo que es factible que funcione. Abre una puerta a la esperanza a los que intentamos hacer un emulador a base de componentes, es decir, sin usar microcontrolador.

Otro proyecto, que se debería intentar por gente experta(mis conocimientos de electrónica son de nivel básico), es un emulador a base de un PIC16C84. Llevaría el PIC, un cristal y un condensador, y cabría en la propia tarjeta. Lo jodido es diseñar el programa del microcontrolador. Yo mismo lo haría, pero no tengo ni puta idea de microcontroladores. Ya sabréis lo que hay que emular, y cómo. Pues hala, hala… Para más datos del chip, id a la web de SGS. Y para el mapa de memoria, lo mejor es recurrir a Bausson. Y EMULAD TARJETAS Oberthur, que son las que sabemos que con seguridad tienen el ST1200. Hay que respetar todos los ciclos del diagrama de tiempos. También sería interesante que el programa del PIC cambiara el nº de serie de la tarjeta cada llamada, poniéndolo al azar, o siguiendo cualquier algoritmo que lo cambiara. Habría que recalcular el checksum también. Esto se puede hacer si el PIC tiene memoria EEPROM(que creo que si). Tendríamos el emulador perfecto.