Tprom Ii

Descargar como doc, pdf o txt
Descargar como doc, pdf o txt
Está en la página 1de 7

TPROM_II

TARJETAS TELEFONICAS MEXICANAS (T2G)


PROPUESTA DE EMULADOR
Illan_ivanovich
Zzyro

El presente trabajo es una recopilacion de experiencias propias y de algunas personas


que estan muy adentradas en el tema. Este trabajo esta basado en los principios de
funcionamiento de las tarjetas telefónicas sugeridas por Manuel Garcia, Bausson, el
Narco, Darkman (Los maestros), pero adaptados de cierta forma para ser validos en
México.
Primero que nada vamos a identificar los pines de nuestra tarjeta

No me voy a adentrar mucho en esto ya que existe demasiada información al


respecto, solo quiero que tengan presente la forma de conexión al momento de
realizar experimentos sobre la misma. Si nos damos cuenta, solo vamos a prestar
atención a tres pines de nuestra tarjeta: rst, clk y I/O, si lo vemos de manera práctica
nos daremos cuenta que las señales generadas o aplicadas a estos pines son los que
harán funcionar nuestra tarjeta. Mucha gente se preguntará que tan difícil sería
manipular estas señales de tal forma que pudieramos emular su funcionamiento, la
cosa es simple y muy compleja si no se tienen las herramientas suficientes. Para tener
mas claro el funcionamiento de nuestra tarjeta, les recomiendo leer los textos de los
autores que mencioné al principio ya que no tendría caso que en este documento me
pusiera a copiar y pegar información, creo que sus textos son lo suficientemente
ilustrativos.

Que es lo que hace la cabina telefónica cuando le introduces tu tarjeta?

Primero que nada ejecuta ciertas rutinas de seguridad clásicas, algunas cabinas
ejecutan algunas y otras no, realmente no podría identificar cual las hace y cual no
porque solo e sacado un log de una sola cabina, entonces no tengo la suficiente
información al respecto. Pero por que me atrevo a decir que no todas las cabinas
funcionan de la misma forma? La verdad es que experimentando e implementando
estas rutinas he logrado hacer funcionar un emulador en algunas cabinas y en otras
no hasta que se corrige el codigo y se incluyen mas rutinas de seguridad . Como
funciona esto? La cabina al ejecutar la rutina de seguridad espera ciertas respuestas
desde la tarjeta, algunas rutinas de seguridad son las siguientes:

-Funcionamiento normal:
Aplicar pulsos de clk cuando Vcc=1, el pin I/O Nos da lectura de la tarjeta
-Rutina clásica:
Aplicar pulsos de clk cuando Vcc=1 y Rst=1, el pin I/O se mantiene en cero mientras
RST siga siendo uno.

-Rutina clasica de write en primer byte


Aplicar rutina de Write en el primer byte (Sube rst, baja rst, sube clk, baja clk) Esta
rutina implica un incremento en el contador de direcciones y se obtiene el siguiente bit
por I/O.

Y algunas otras por ejemplo write en los bytes 2-7, write en el bit 109, 108, 110, etc.

Podemos resumir lo anterior como sigue:


1.-Cuando la cabina quiere escribir en los bits 0-8 simplemente aumenta el contador
de direcciones y manda el dato correspondiente a I/O.

2.-Si la cabina manda write’s desde los bits 0-8 aumenta el contador hasta el bit 8 y si
se siguen dando write’s la tarjeta no hace nada.

3.-En los bytes 2-7 cuando hay un write, la tarjeta se bloquea hasta que se realiza un
reset

4.- En el byte 13, en los ultimos 4 bits si la cabina manda un write la tarjeta se
bloquea.

NOTA: En el bit 110 tenemos el bit de activación del chalenge/response que en México
(Por fortuna) no se ha implementado, por lo que se evadirá el tema, de cualquier
forma si alguien requiere más información al respecto ya saben:
[email protected]

EXPERIENCIA CON EMULADORES

Aquí voy a exponer algunos detalles encontrados en algunos emuladores.


Mr. Flowers.- Este emulador tiene una configuración de hardware muy simple, solo
una resistencia entre vcc y pin 16, es muy sencillo de construir, sin embargo, el código
esta implementado para leer y trabajar solamente con 128 bits, pero como se sabe en
México las cabinas leen hasta el bit 512. Por que se implementó de 128 y no de 512??
Bueno, resulta que algunas cabinas solamente leen 128 bits y efectúan una rutina de
reset, es por eso que este emulador nos da lectura en algunas cabinas sin ningún
problema, el problema principal de este emulador es la escritura en eeprom ya que lo
intenta directamente en eeprom. Si hacemos una comparación con el emulador de
cartman nos damos cuenta que este último hace el write y write/carry en registros de
ram y posteriormente los manda a eeprom dando un tiempo crítico para la escritura.

Uno de los principales problemas a que se enfrentan los emuladores con pic es cuando
la cabina corta el Vcc y mantiene el RST alto. Resulta que por características técnicas
del pic cuando una de sus patas se mantiene a 5 volts el micro funciona normalmente
aunque vcc no tenga voltaje. Esto se corrige fácilmente con un diodo 1N4148 a la
entrada de Vcc y Mclr. Y que tiene que ver MCLR con todo esto, pues resulta que
cuando el pic tiene un 1 en alguna de sus patas, el pin de vcc también se energiza y
como la mayoria de los emuladores tienen vcc y mclr juntos pues entonces empieza a
funcionar. Lo que el diodo hace es que aisla la entrada de vcc y mclr de tal forma que
cuando exista un voltaje en cualquiera de los pines del pic y se energice vcc no haya
forma de que mclr se energice y haga funcionar al pic.

PROPUESTA

Pues ahora viene lo bueno. Realmente he experimentado con emuladores ya creados e


incluso he creado algunos códigos funcionales, pero la bronca es la siguiente, una
tarjeta original contiene respuestas que podriamos no conocer, de hecho he logrado
encontrar muchas rutinas de seguridad en las tarjetas, pero estoy seguro de que
existe alguna, o algunas más que no podemos entender. Entonces, como podríamos
hacer un emu que funcione en su totalidad sin problemas de cuelgue y que responda a
esas rutinas de seguridad que manda la cabina? Pues simple: CON UN CHIP
ORIGINAL

Esta propuesta de emulador usaría chips intercambiables y switch de recarga. Si


recuerdan, esta configuración, para los que estan adelantados en el tema es una
versión moderna del tprom de Juan Manuel García. Simplemente del chip original
vamos a tomar los valores que nunca cambian (Bytes 0-7 y 13-64), lo único que nos va
a ocupar es la escritura en los bytes 8-12.

El funcionamiento es muy simple: El pic se encargará de contar los primeros 64 bits y


permanecerá inactivo hasta que llegue a los bytes 8-12 que es donde va hacer los
procesos de write y write carry. El mismo pic se encargará de mandar una señal de
control que inhabilitará al chip o lo pondrá a funcionar dependiendo de la posición en
que se encuentre.

El diseño puede ser mejorado intentando colocar una especie de base para conectar el
chip, de esta forma se podrán intercambiar los chips cada vez que la cabina no los
reconozca o que ya hayan caducado. Este emulador va a tener 30 pesos de saldo y
tendrá la opción de recarga, sin embargo no la estoy implementando ya que esto es
solo con fines de investigación.
Y por supuesto cada vez que se termine el saldo tendrán que reprogramar el pic para
que les dé saldo nuevo, esto lo hago para evitar que cualquier cabrón llegue y
comience hacer tonterias (Que no es el fin de este documento). Pero el que quiera
adentrarse mas, podrá hacer las modificaciones necesarias para poder lograr sus
objetivos. Cualquier duda, pregunta o sugerencia es bién recibida, ya saben
[email protected].

Aqui les dejo el diagrama del circuito que estoy proponiendo, sin embargo se requiere
de poner una resistencia de 10k en la base del transistor BC547 y también se
recomienda la implementación de un diodo 1N4148 a la entrada de vcc y mclr para
evitar posibles cortes en el vcc.
La funcion del transistor no es mas que la de conmutar la salida del chip con la salida
del pic, es decir, cuando se tenga una señal alta en la base del transistor entonces se
satura y permite leer el chip original, sin embargo para que exista una lectura
correcta en este momento se debe inhabilitar RA4 (Se debe poner como entrada) para
evitar errores en la lectura. Cuando la base del transistor esta a cero entonces el
transistor se pone en corte y se inhabilitara la salida del chip original y comenzará a
funcionar el pic. Por supuesto, la señal RA3 será la encargada de hacer dicha
conmutación atravez de software.

También les estoy incluyendo una propuesta de pcb en la cual por limitaciones
propias del programa que usé no incluyo un conector para el chip sino que estoy
incluyendo un portacircuito integrado de 6 pines el cual va a servir para colocar
nuestro chip, la forma en que se coloque este chip queda a consideración de cada
quién, esta propuesta es, en caso de que quieran adoptarla para que a cada chip que
se vaya a usar le puedan soldar patitas y lo puedan colocar en el porta CI, pero insisto,
cada quien puede hacerlo como mas le convenga. No estoy incluyendo la opción para
recarga, sin embargo, los que saben acerca de emulación sabrán que no es difícil
implementarla, solo bastaría con volver a guardar los valores de un ábaco nuevo o con
poco uso (30, 50, 100), la ventaja de esto es que solamente se requerirán 5 bytes de
eeprom para usar este emulador. Me comentaba un colega (rocco) que posiblemente
un pic 16f84 se salía un poco de nuestros fines ya que no se le sacaría mucho provecho
a todos los recursos que nos brinda dicho chip, sin embargo lo estoy dejando así ya
que la mayoría estamos familiarizados con este pic, además de que podemos hacer
muchas modificaciones y arreglos que podrían abarcarnos un poco mas de espacio en
la memoria de programa.

Este zip contiene ademas un archivo dfx del pcb que pueden abrir con el corel draw,
también se incluye el asm y el hex, las actualizaciones a este documento se iran
haciendo sobre los resultados que se vayan obteniendo.
Los diagramas anteriores se tratan de un hardware basado en el emulador de mr
flowers, ademas el código es tambien basado en dicho emulador. Este emulador debe
ser usado con bateria externa ya que esta implementado solamente en ram, para los
que quieran experimentar con el tambien les sugiero el uso del diodo a la entrada del
vcc y mclr.
Los códigos que deben usar para este emulador son el TPROM2.ASM y
TPROM.HEX.

Pero muchos se preguntarán el porque usar una bateria, es mucho desmadre, pues
bueno, también les incluyo otra propuesta de hardware basada en el ya conocido
emulador de cartman, sin embargo no les incluyo el pcb. Esta segunda versión no
requiere la bateria para trabajar, y se trata del codigo TPROMII.ASM y para los mas
wevones también esta el TPROMII.HEX.

Agradecimientos a Zzyro por su valiosa colaboración para la terminación de este


documento, así como a Cartman por sus aclaraciones hace ya algunos meses, y sobre
todo a los que hacen posible que este doc llegue a sus manos......

Pero para hacer mejor este documento y gracias a la colaboración de Zziro también se
les incluye el pcb del emulador, quizas no se encuentre a tamaño real pero es para que
se den una idea del mismo.

Solo recuerden incluir una resistencia entre la base del transistor y la salida del pic
mas o menos de 10k. Además del uso del diodo para evitar posibles cortes de
alimentación de la cabina (En algunas cabinas este corte no esta implementado por lo
que así como esta el diseño debe funcionar en la mayoria de las cabinas). Por
supuesto, esta propuesta es con fines de investigación y el autor no se hace responsable
del mal uso que se le pueda dar. De hecho, esta propuesta está diseñada de tal forma
en que se pueden hacer modificaciones para que funcione de forma mas óptima
(Incluyendo recarga que es lo que buscan muchos), pero eso ya queda a consideración
de los que se propongan a realizarlo por completo, para cualquier aclaración, dudas y
comentarios son bién recibidos [email protected] espero que este
documento sea de utilidad para todos y que logren sus objetivos.

Tambien agradezco a los que están y no (Zug, Yasser, Bu208, Paco_1585, Beavis,
Rocco, SomeOne y a los del nunca iniciado Foro Privado)

Seguimos en lo mismo.......

BK

También podría gustarte