Karpoff Spanish Tutor

Programa:

Programas dentro de PLD's


 

PROTECCION:

Hardlock. PLD's, no dongles...

Objetivo:

Leer la función grabada adentro (JA!)

Descripción:

Simplemente lo hago funcionar ...y miro!

Dificultad:

Prohibido para mayores de 4 años (de electrónica).

DOWNLOAD:

PLDS.zip

Herramientas:

Meid bai de iuser (?)+PLDES.COM

CRACKER:

Villano bAjo

  FECHA:

28/04/2001

 

 INTRODUCCION

 

(UN) METODO DE RECUPERACION DE PROGRAMACION DE PLD'S

Aplicado en este caso a un dispositivo 16V8, pero extensible a cualquier tipo de PLD... creo...

Proceso a realizar: verificar todas las lecturas de salida posibles cuando se varia la entrada desde 000 hasta 1FF (nueve entradas). Entre lectura y lectura, se debe generar un pulso de reloj para verificar si hay o no un registro asociado a la salida. Los resultados son la TABLA DE VERDAD del dispositivo.

Fundamentos: Aunque exista un bit de protección en la programación del dispositivo, es OBVIO que debe realizar una función, aquella para la que fue programado... (sino de que serviría?). Esta función NO PUEDE ESCONDERSE, ya que esta definida para los pines EXTERNOS del dispositivo, y a menos que no se tenga acceso al mismo, es posible descular el circuito asociado, y arrimar el bochin sobre los posibles usos de cada patita: entrada de datos, salida de datos, bi-direccional o minga (conectada a masa o a positivo). El caso de no tener acceso al dispositivo no es analizado por absurdo (de que hablamos sino, tío?)

 

 AL ATAKE

 

UN POCO DE HISTORIA

Seguía con interés, la parte de esta pagineta que habla de los PLD's. Pero note que había una cierta quietud en el asunto (o me pareció a mi). Repentinamente me vi (razones de trabajo, y no pregunten cual...) con la URGENTE nece$idad de leer el programa de uno de los bichos estos. Pero, caramba, no existía la continuación del continuara. Asi que desempolve la segunda neurona, y me puse a estudiar el asunto con la premura del ca$o.

Al ponerme al trabajo, una luz me deslumbro. Apagado que la hube, pensé que aunque, teóricamente los PLD's son reput(e)ados (muy) de irrompibles, deben realizar algo, y ese algo es también visible en la categoría de MUY, y ese algo visible es dependiente de lo que escribieron dentro y por lo tanto, siendo un PLD un algo previsible, (grande seria que hicieran cada uno lo que se le ocurriere, no?), debería ser posible revertir el proceso: de saber que hace, a saber que debo hacer para que lo haga... que entre paréntesis, es como se hizo la primera vez.

SEPAMOS QUE HACE

Lo primero que debemos saber entonces es que cosa hace la cosa.

Así que considere las posibilidades: que requiere el bichito para hacer lo que hace? Pues condiciones de entrada, y (o no) pulsos de reloj.

Pero las condiciones de entrada dependen de....ALTO. El PLD no lo sabe, y no le importa QUIEN le da las condiciones. Solo las recibe y las traduce en salidas. Es decir que si le doy las condiciones correctas, me dará las salidas correctas. Quizás sea necesario que las condiciones estén en el orden correcto...

Este ultimo punto me preocupo, pero solo existe problema en el caso de analizar un PLD con registros de salida, que era MI caso... Luego pensé que si le daba la condición correcta, y un pulso de reloj, alguna salida tendría que cambiar, si la condición fuera correcta. (Si tuviera huevos, podría hacer huevos con jamón, si tuviera jamón...)

Bien, entonces fijo la condición, averiguo que sale, y aplico el reloj, y veo que sale. Y que condición fijo? Pues, todas. Al leer una memoria eProm, por ejemplo, que estamos haciendo? Pues, eso. Así que construí un lector (no me sirvió mi lecto/grabador de eProms) y escribí un programita para manejarlo. He aquí, tal como se ve la pantalla:

 

 
    Entrada  -  Resultado 1  _|   Resultado 2   |_  Resultado 3
 
      000     1 1 1 0 0 1 0 1   1 1 1 1 0 1 0 1   1 1 1 1 0 1 0 1
      001     0 0 0 1 1 0 0 0   0 0 0 0 1 0 0 0   0 0 0 0 1 0 0 0
      ...     . . . . . . . .   . . . . . . . .   . . . . . . . .
      ...     . . . . . . . .   . . . . . . . .   . . . . . . . .
      1FE     0 0 0 1 0 1 1 1   0 0 0 1 0 1 1 0   0 0 0 1 0 1 1 0
      1FF     0 0 0 1 0 1 1 0   0 0 0 1 0 1 1 1   0 0 0 1 0 1 1 0
 

 

El cambio en la salida de un registro se da cuando la entrada "D" del mismo cambia (conexionado interno), y luego se produce el cambio del reloj, así que la secuencia usada para la lectura es:

 
                1- coloco entrada (salidas de un contador)
                2- leo salida (primer resultado)
                3- reloj a positivo (0->1)
                4- leo salida (segundo resultado)
                5- reloj a negativo (1->0)
                6- leo salida (tercer resultado)
                7- muestro resultados
                8- incremento contador/entrada
                9- vuelvo a posición 1-

 

Porque esa espera entre flanco + y flanco - ? Porque la entrada de reloj también puede ser usada como entrada combinacional en los casos donde los registros no se utilicen... Lo mismo es valido para la entrada I/OE, solo que esta se conecta al bit mas alto del contador de direcciones exploradas. Si es solo la habilitación que se supone que es, la salida de todas las direcciones altas serán "1" o "0". Pero si tiene una función activa en la ecuación de salida estas serán diferentes de entre si.

En caso de tener una realimentación a través de los registros, y que se forme una cadena divisora, cuanto es lo máximo que debo leer para determinar eso, contando con 8 registros? Respuesta: Si la configuración es de contador en serie, 256 veces para todas las posibilidades. Solo que no es posible debido a la configuración del reloj (todos en paralelo). Si la conexión es en cadena (shift) o en anillo (contador), solo 8 veces, lo que significa 8 veces 512, a tres bytes por lectura, es decir: 8x512x3=12.288 bytes en total... y analizar 4096 renglones (000 a FFF).

Solo que no es exactamente necesario. Se pueden aislar las condiciones en que el contador cambia, y generar 8 pulsos seguidos en esta condición, para verificar la posibilidad de conexiones en cadena de los registros. Existe también la posibilidad de que una (o varias) salidas este/n siendo usadas como entrada o como bi-direccional. Esto puede ser resuelto mas fácilmente desde el circuito eléctrico que desde la verificación de la tabla de verdad del dispositivo. Para ello las salidas son conectadas a un potencial 3/4 de Vcc (a través de una alta resistencia off coarse), y se verifica este potencial durante todas las combinaciones de entrada.

Si las tensiones de salida son "1" o "0" perfectamente definidos la pata esta siendo usada como salida (lo que no descarta la posibilidad de que se utilice como realimentación hacia otra celda), pero si en algunas combinaciones la tensión queda en los 3/4 de la fuente, es seguro que allí se coloco en estado de alta impedancia (desconexión o input). Ahora solo falta realizar variaciones en estas "salidas" durante la o las combinación/es que provocan este estado (y SOLO durante ellas!). Si no pasa nada, es un estado de desconexión, sino... son datos a agregar.

Debe tenerse en cuenta que durante la lectura de los pines detectados como bi-direccionales, no se deben modificar los estados de las entrada fijas, para no (posiblemente) modificar la condición de "entrada" de los mismos.

Se que se leerán mas datos de los necesarios para realizar el análisis completo, pero como uno nunca sabe y se busca el caso mas general de todos...

El programa PLDES.COM esta preparado para su uso con el circuito adjunto (LECTPLD_.PRN o .DKJ), y es IMPRESCINDIBLE el uso de una puerta paralelo tipo ECP o EPP . La puerta paralelo normal (SPP) no sirve ya que no garantizan (algunas si, algunas no) la entrada de datos por el bus (pines 2 a 9 de la ficha DB25, en el fondo de la PC).

El circuito auxiliar VOLTMET_.PRN o .DKJ es una posibilidad para quien no tenga osciloscopio para detectar las salidas bi-direccionales. Actúa en dos modos: Manual y Memoria. En el estado Manual el led enciende cada vez que la entrada bajo prueba se fije en un valor intermedio entre VCC y masa y se apaga en todas las demás; en el modo Memoria una vez detectada una posición así, no vuelve a apagarse mas que al pasarla a Manual.

Una vez encontradas las salidas bi-direccionales, se pueden efectuar variaciones en las mismas mediante la salida del integrado U3, conectando cada salida del mismo a una de las entradas sospechosas, a través de cada llave del DIP-SWITCH. El programa puede realizar esto indicándole cuales son los contactos cerrados, y fijando la condición "base" de las entradas. Conviene realizar esto para todas las condiciones que den lectura de bi-direccionales.

Además el integrado U5 puede ser usado como control del switch electrónico CD4066, reemplazando al DIP-SWITCH (usar 2!) y agregando el código de control necesario (que no hice de puro vago...) RECORDAR que cada condición "base" puede tener una cantidad de salidas bi-direccionales diferente de las demás, y las llaves del DIP-SWITCH deben cambiarse en consecuencia. No recordarlo puede provocar llantos, lamentos y demás tristezas (de lo que no me responsabilo) al ser posible la:

DESTRUCCION del PLD...

Si lo que hay que analizar es solo un PLD, y abur... casi conviene reemplazar el integrado U3 por llaves inversoras simples, y realizar la medición a mano. Si en cambio quieren dedicarse a leer PLD's a diestra y siniestra, bien conviene automatizar el asunto. Para ello hay sugerencias en el circuito mismo, y tienen el programa fuente, y mis bendiciones para modificarlo, retorcerlo, exprimirlo... o descartarlo y hacer uno bien hecho.

 
                                     [j]
                                       -

Ahora bien. Ya tienen todos los datos que buscaban: el verdadero desafío es interpretarlos. Para eso existen toda una serie de técnicas, desde el análisis a lo bruto hasta los diagramas de Karnaugh o el método de polinómios de Quine y McCluskey, cuya explicación esta mas allá del alcance de este documento, pero que son perfectamente accesibles en cualquier libro sobre lógica digital BASICA.

(Un ejercicio divertido: Puede alguien ubicar la fecha de nacimiento del Sr. BOOLE, cuya álgebra utilizaran en el análisis?. No se asusten...)

Con estas técnicas pueden recuperar la ecuación que se programo dentro del dispositivo, y desde ya, reproducirla con o sin modificaciones mediante un programador adecuado.

Obviamente, el conocimiento de la construcción interna del dispositivo es de gran ayuda para comprender que cosas son posibles y cuales no, y adaptar ese conocimiento al caso particular que estén analizando. (Traducción: Los manuales también existen)

NOTA IMPORTANTE:

El circuito indicado y su programa asociado solo LEE una TABLA DE VERDAD. No provoca NINGUN CAMBIO en el programa interno del PLD, ni es capaz de verificar los bytes de "FIRMA" del mismo. OK? Tampoco indica el "PROGRAMA" real, solo la FUNCION que realiza el dispositivo.

Nota no tan importante:

Para ver los diagramas .PRN o .DKJ, envíenlos a la impresora, p/ej. vía línea de comando (esa cosa obsoleta del DOS, recuerdan?), que diga así:

C:\[directorio\]>TYPE [d:\path\]nombre_del_archivo.extension >PRN

o sino

C:\[directorio\]>TYPE [d:\path\]nombre_del_archivo.extension >LPT1

Con un poco de suerte, eso debería darles un plano del circuito. (Creo..)

Nota de la nota:

Como toda indicación sobre líneas de comando DOS, los "[" y "]" indican algo opcional, las minúsculas son una especie de comodín y lo escrito fuera de los "[ ]" son comandos o nombres obligatorios. Por otra parte los archivos .PRN son para impresoras de punto (24 agujas es lo ideal) y los .DKJ son para impresoras de inyección de tinta.

...y como decía un GRANDE de aquí: vermouth con papas fritas y GOOD SHOW!

Villano bAjo.

PS: Pude encontrar los re$ultados que bu$caba. El método, al menos para mi, funciono.

Otro si digo: Si leen con cierto cuidado el programa fuente, verán como fueron apareciendo algunas necesidades luego del trabajo básico. Una interesante aplicación (detectivesca, diría) de la ingeniería inversa...

 

ADDEMDUM

Estaba yo mas feliz que mono con banana nueva, cuando decidí imprimir un planito en mi otra PC, la que funciona (a veces) con W95, utilizando el método de la línea de comando y OH! surprais, lo mochaba...

Luego de varias pruebas concluí que existía un buffer de memoria que no permite que se envíen de esa manera mas de 37.879 bytes. Esto me indico que, siendo cualquiera de los planos que envié para Uds. algo mayores que esa cifra, o hay un truco que no conozco (mas que posible) o estaba en un serio problema, ya que no todos tenemos maquinas operativas en DOS v6.22.

Después de largos minutos de cambios en las configuraciones de todos los posibles puntos de problema, y siendo imposible modificar ese tamaño de buffer, y no pudiendo determinar si el problema es local (mío) o general, decidí cortar por lo sano, y prepare un "parche" : PRINTER.COM. Para usarlo, instalenlo en el directorio donde esten los archivos a imprimir. Luego tipeen la lines de comando así:

C:\[directorio\]>PRINTER [d:\path\]nombre_del_archivo.extension

y luego pulsen Enter.

Esto esta probado y además les puede servir para cualquier otro archivo que deseen imprimir, sin pasar por algún programa especifico.

Ahora si, gud lac.

 

Estimados: Se que se estarán preguntando porque, en nombre de Bill, no hago como todo el mundo y mando los planos en un .JPG o .GIF o algo así...

Bien, es que para ver los planos como creo que deben verse, el tamaño de esos archivos me asusta, y si los achico, se pierde definición... y es un plano. En una impresora la definición es la máxima posible.(Además no tengo, aun, un editor .PDF)

Verán que hay dos versiones de cada plano, una terminada en "l" y otra terminada en "h". La primera es para hojas chicas, la otra para hojas de 13 pulgadas (carro ancho). Esta seria la mejor, pero recuerden que se lleva mas de una hoja.

 

ULTIMO MOMENTO, SUPER ADDENDUM (24/11/2001)

Debido a mis éxitos, estaba yo mas hinchado que zorete en querosén (expresión argentina que significa, bueno, eso...) cuando recibí un pedido de jelp referido a un PLD, mi bocado favorito...

Observélo con atención y descubrí, con gran satisfacción, que concurrían dos cosas lindas en el circuito asociado: tanto el pin de clock como el de I/O Eneable estaban conectados a masa, por lo que deduje que solo existía lógica de combinación dentro del PLD sujeto. (Pan Lactal Deglutido...pan comido, que le dicen)

  1. De modo que prepare la maquina infernal+la PC y dediqueme a mirar lo que salió (Tabla 1) para luego encontrar la ecuación correspondiente. (JA!)

Aquí recuerdo un verso que se cuadra:

                         Pero un día un cartonazo
                         de un barrio desconocido
                         le corto hasta el apellido
                         a tajo, punta y hachazo...

                                   (cuan cierto fue...)

La cosa fue que si miran la dichosa Tabla 1, verán que S4 es la sumatoria de los inversos de E0, E1, E5 y E7, que S5 es la inversa de esa función, y las salidas S1, S2 y S3 son la inversa de E7... y punto.

Recontra JA!

La verdadera verdad de la milanesa...

Al verificar, con un poco de inmodestia, debo confesar, el funcionamiento del PLD original en su circuito de aplicación, descubrí con gran surprais:

A)    que existía un sistema parecido (igual) a un latch dentro del PLD a saber, en las salidas S1, S2 y S3.

B)    que E2, E3 y E4 tenían algo que decir al respecto, asociándose con alguna de las salidas antemencionadas cada una. (Maquinaria dixit) 

C)    que yo fui unbo... por apurado. (unbo-ludo. Tonto, en fino)

Recupere un poco de mi autoestima y dime en averiguar como y porque un PLD podía equivocarse tanto... y descubrí que los latch eran parte de un sistema de alarma y NO EXISTIA SISTEMA DE RECUPERACION DE LA ALARMA (RESET)...

Al dispararse algún latch, solo podía retraerse la condición apagando el equipo.

Caramba con las medidas a lo bestia, me dije. Pero es la realidad. La función monitoreada es tan delicada que ante una falla conviene apagar todo. Y así se evitan el crear una condición de reset, me volví a decir.

Nuevamente ERROR.

Error porque:

         Cuál es la condición de las entradas durante el encendido?

En esos pocos milisegundos de inestabilidad de fuentes y sensores, las alarmas no deben dispararse (y no se disparan porque un reset temporizado, externo, que descubrí posteriormente, las bloquea).

Entonces, que leí en mi maquina infernal+la PC?

Algo falso. Y porque? Porque el diseño original prevee una condición inicial de los sensores, y es allí donde debo iniciar la lectura (y no en 00000000 precisamente).

Así que luego de profundas y largas reflexiones (3 seg. aprox.) decidí que debía modificar la M.I. (maquina infernal), agregando algo tan pequeño, que no molestare a Uds. con la circuiteria. Básicamente agregué dos estados a la lista de trabajos original, a saber:

1-    coloco entrada (salidas de un contador)
            * 1,5- enciendo el PLD
                2- leo salida (primer resultado)
                3- reloj a positivo (0->1)
                4- leo salida (segundo resultado)
                5- reloj a negativo (1->0)
                6- leo salida (tercer resultado)
            * 6,5- apago el PLD
                7- muestro resultados
                8- incremento contador/entrada
                9- vuelvo a posición 1-

(*)=estados agregados.

Que gano con esto? Que en cada medición estoy en una condición inicial...

Vean sino el resultado (Tabla 2).

Consideremos que la condición de alarma es con alguna de las salidas S1, S2, S3 o S5 en "0" y S4 en "1"(*), y la condición normal es todas las salidas en "1", menos S4, que pasa a "0". E0, E1 y E5 son simples habilitaciones, no alarmas.

E2, E3 y E4 son las entradas de alarma (de ahí el latch para cada una).

(*)
Alarma si (-S1)+(-S2)+(-S3)=1   <-donde (-Sx) significa Sx negado.
Normal si S1*S2*S3*S5=1
No arranca si S1*S2*S3*S4=1     <-recordar que S5=(-S4).
Ya explique que en alarma hay que apagar todo?
Estas funciones son externas al PLD. (OjO)

En la Tabla 2 se ve que la primer apreciación respecto de S4 y S5 es correcta, con algunos agregados: los latchs, que ahora se ve que corresponden de este modo: S1 es manejado por E2, S2 es manejado por la inversa de E4 y S3 es manejado por E3.

Y el reset?. Descubrí que durante E7=0, S1, S2 y S3 eran Hi-Z. Conclusión?

Que el latch se forma realimentando cada salida sobre su compuerta, a través del sistema de separación (desconexión) de salida, haciendo que la salida fuera una entrada. Es decir que cada vez que aplico un "0" en la entrada E7, el lazo de realimentación se abre, y la tensión "1" externa repone el latch, siempre que la condición de la entrada correspondiente (no de la salida devenida en entrada) sea la correcta. E7 es el RESET del PLD. (Bingo!)

Observen que con una disposición del PLD como esta, la medición con las llaves Dip-Switch hubiese dado poca información adicional. (O ninguna, si no hubiesen estado conectados a la compuerta de la salida S4).

Por otro lado, se ve que las inversas de las salidas S1, S2, y S3, deben intervenir en la sumatoria de S4 (y S5). Y ahora SI la medición es real.

La lógica total de la maquina no hubiese cambiado sí las entradas E2, E3 y E4 se conectaran directamente a la compuerta de la salida S4 (respetando sus "polaridades" o "fases", obviamente).

Por estos detalles había sugerido que el conocimiento del circuito de aplicación es importante. Solo no alcanza, y la lectura sola tampoco...

En definitiva que la M.I. (maquina infernal) sufrió una modificación (evolución) en su camino a la perfección (¡).

El método de apagar el PLD entre mediciones pueden aplicarlo manejando separadamente el transistor Q1 de los comandos de las salidas de los 74LS374, desde la puerta paralelo. (o de uno de los 74LS374, si cuadra). En definitiva, automatizar SW1. (retiren el sistema de verificación de encendido, eso ayuda)

El programa de encendido y apagado del PLD, es muy sencillo de incorporar a lo ya visto, por lo tanto lo dejo como ejercicio para el alumno... (jeje).

Conviene dejar disponible los dos tipos de medición: VCC permanente y chopeada, para tener todas las posibilidades a mano. En las mediciones de 8 pulsos no se debe usar el sistema de chopear la alimentación, es obvio.

Al programar su manejador de encendido, dejen un tiempo (yo deje 5 milisegundos) antes de medir (es mas seguro así), lo mismo que entre un apagado y el próximo encendido.

Nota: Ojo las fuentes, que estén bien filtradas, porque pueden entrar señales indeseadas por esa vía...

Otra nota: Respecto a las Tablas 1 y 2, solo puse la columna del primer resultado, después de todo, el clock no tiene nada que hacer aquí.

Finale con tutto...

En definitiva, que estoy otra vez contento con los resultados. La copia que realicé funciona tan bien como el original. Y me aprendí otra. O más de una.

Por ejemplo, una: ser un poco mas modesto... (?)

Bai bai.

Villano bAjo.

...y gracias por la paciencia!

- - - - - - - - - - - - -

Otro P.S.:

La maquina de donde salió el PLD es una bordadora industrial. Las alarmas están referidas a objetos y/o agujas rotas entre las piezas móviles.

Retirarlas o reemplazarlas con energía colocada es tentar un accidente, al hacer posible un movimiento de las partes mientras se realiza la reparación.

Dado que los movimientos son tanto eléctricos como hidráulicos, se requiere retirar tanto la energía eléctrica, como la presión antes de poder retirar las cubiertas de protección. De allí la necesidad de no permitir la recuperación de una alarma, de ESAS alarmas. (Hay otras).

Cuando pregunte que otros objetos pueden caer entre las piezas, la respuesta fue: "Dedos del operador". No quise saber mas...

 

 

Karpoff Spanish Tutor: Pagina dedicada a la divulgacion de informacion en Castellano, sobre Ingenieria Inversa y Programacion. Email "Colabora con tus Proyectos"

 

www.000webhost.com