Proteger PIC de intrusos

[softjad]

¿Hasta punto podemos proteger un PIC de las lecturas no deseadas?

¿Será posible alguien obtener una lectura de un PIC Protejido?

[BrunoF]

Hola. Bueno...todos los PICs traen proteccion contra lectura, algunos con la posibilidad de impedir el acceso a ciertas partes o tipos de memoria, y otros solamente una proteccion general.
¿Hasta que punto?
Bueno, todo es relativo, el contenido del PIC debe ser realmente valioso para que alguien se digne a mutilar uno y leerlo. Como ser posible lo es, y ya se ha hablado en el foro y publicado paginas con personas que han logrado leer pics protegidos contra lectura.
La tarea no es nada facil, por lo tanto, poco probable que lean un PIC que protegiste.
Saludos

[patolinec]

La verdad es que solo necesitarias en el momento de la grabacion del pic en la parte de la palabra de configuracion activar el CODE PROTECT y se genera una capa que protege el codigo grabado, ademas si pudiera alguien  leerleo si es en ensamblador se lo podra decompilar pero si esta echo en c o pero en basic la tarea es muy complicada y mucho mas extensa que hacer el codigo nuevo, por lo que no te preocupes que al activar esta opcion tu propiedad intelectual esta garantizada

[Chaly29]

Hola patolinec, creo que tienes una confución ya que si un PIC tiene un programa ya sea haya sido creado en .asm o en C en el propio PIC solo hay instrucciones de codigo, por lo tanto para decopilarlo es facil si sabes de .asm, no importando el lenguaje que hayas usado para crearlo, es solo una aclaracion.

Un saludo.

Atte. CARLOS.

[patolinec]

Totalmente de acuerdo contigo Chaly, creo que no me exprese del todo bien lo que intentaba decir es que si por ejmplo un programa de manejo de USB en C es entendible, pero en ensablador (vaya a saber Dios cuando lo entiendes ), pero con todo es bastante seguro colocar el codigo de proteccion

[Chaly29]

Hola patolinec, definitivamente tu fuerte es el C, pero para mi es el .asm, por lo que si me pones una rutina para el manejo del USB en C te aseguro que no entendere ni lo más mínimo, pero nada de nada      , ahora ya me gustaria tener una rutina de manejo de USB en asembler, te aseguro que me haría vastante feliz   

Un saludo.

Atte. CARLOS.

[pibe]

Yo estoy igual que Chaly.
Una vez tuve que pasar a mano un programa hecho en C a asembler. Vaya tela, y eso que venía con comentarios por cada instrucción.
Aunque estoy de acuerdo con la otra persona: Si escribiste un programa en C y pretendes releerlo desde el HEX de la memoria del micro , pasarlo a asm con un desensamblador te será casi imposible de transformarlo a C si no tienes MUCHA experiencia en asm primero.

[patolinec]

Pues Chaly lo que tengo es una rutina de USB pero para el 16C7X5 es bastante bueno y para tu gusto esta en ensanblador, el programa host esta hecho en VB6 y es bastante bueno para que puedas realizar algunos cambios, necesitas el HID que es el isntalador del driver del PIC para el VB6 cualquier cosa me avisas

[maunix]

Estamos de acuerdo en que uno cuando desensambla quedará en ensamblador.

Los compiladores de C hacen cosas más allá de lo 'evidente' para alguien que viene del ensamblador.  Montones de cosas tienen que ver con cargar datos en un stack, descargar y manejos internos que no son públicos para la mayoría de los mortales.

Eso hace que un código que fue escrito en C sea más dificil de interpretar que un código escrito en ensamblador.

Cuanto más complejo y más funciones lógicas tenga un código en C, más dificil será de interpretar.

Así y todo, un código en ensamblador incluso escrito por nosotros mismos puede ser complicado de interpretar cuando uno no tiene nombres de variables, etc.  En mis códigos suelo usar muchos macros que me facilitan tareas repetitivas.  Si veo el código asm puro de lo que se generó luego de 2000 líneas de código tal vez estaré algo más que perdido.  Sobre todo en el manejo de variables cuando son de varios bytes de longitud.  Lo obvio en un código no lo es tanto cuando uno levanta el código desensamblado. 

Ej: movlw  VARIABLE+3

Esa simple línea se va a ensamblar con la dirección absoluta que tomó VARIABLE+3 al momento de la compilación.  Nada hace pensar que la vayamos a asociar a VARIABLE, salvo un minucioso estudio del código.

Yendo más allá con el ejemplo para ser más claro.

Código: ASM

1. VARIABLE equ 0x20
2.  
3.         movlw   0x04
4.         movwf   VARIABLE
5.  
6.         bcf     PIR1,TMR1IF
7.  
8.         movlw   0x08
9.         movwf   VARIABLE+3

Al ensamblarse VARIABLE será reemplazado por 0x20 y VARIABLE+3 por 0x23.   Entonces si uno ve el 0x20 y el 0x23 cómo sabe que es de la misma variable?

Más complicado aún cuando uno quiere interpretar una función que fue hecha en C y con envío de parámetros, cuando un parámetro puede ser o bien el valor o bien un puntero hacia el valor!


En mi opinión el que COPIA generalmente lo hace para grabar un micro con el firmware idéntico no y se detiene en la interpretación del código ya que le puede llevar semanas o meses entender un código que fue escrito por otro.

Saludos

[BrunoF]

Hola Maunix, es que precisamente si haces MOVLW VARIABLE+3 estas utilizando la direccion a la que apunta variable como apoyo, y no como parte dependiente y que haga variar el codigo.
Para mi no resulta en mayor complejidad, ya que en realidad, tu quisiste decir: movlw 0x23,y NO esta asociado a la variable. Y ese mismo movlw 0x23 es lo que voy a leer en el programa que obtuve del pic y desensamble.
Saludos.