Karpoff Spanish Tutor 1999-2001

Programa:

Programas dentro de PLD's


 

PROTECCION:

Hardlock. PLD's, no dongles...

Objetivo:

Leer la funcion grabada adentro (JA!)

Descripcion:

Simplemente lo hago funcionar ...y miro!

Dificultad:

Prohibido para mayores de 4 años (de electronica).

DOWNLOAD:

Descargar Pld’s 

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, pense 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.

Asi 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 pense 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. Asi 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 realimentacion 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 realimentacion 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-direcionales. 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-direcionales 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 algebra utilizaran en el analisis?. 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 inyeccion 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 decidi imprimir un planito en mi otra PC, la que funciona (a veces) con W95, utilizando el metodo de la linea de comando y OH! surprais, lo mochaba...

Luego de varias pruebas conclui que existia un buffer de memoria que no permite que se envien de esa manera mas de 37.879 bytes. Esto me indico que, siendo cualquiera de los planos que envie 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.

Despues 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 (mio) o general, decidi 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 asi:

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

y luego pulsen Enter.

Esto esta probado y ademas les puede servir para cualquier otro archivo que deseen imprimir, sin pasar por algun programa especifico.

Ahora si, gud lac.

 

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

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 definicion... y es un plano. En una impresora la definicion es la maxima posible.(Ademas no tengo, aun, un editor .PDF)

Veran 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.

 

 

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