TODOPIC
Microcontroladores PIC => Todo en microcontroladores PIC => Mensaje iniciado por: macedo en 25 de Agosto de 2009, 19:55:29
-
:lol: Hola estoy haciendo unos proyector y quiero saber si se puede meter de alguna forma una FIRMA DIGITAL dentro del codigo asemmbler para decir que es de mi propiedad, no se si me explico.
Si alguien sabe del tema por favor orienteme.
:-/Gracias
-
por que no bloqueas el pic para que no se pueda leer!? :?
-
Puedes grabar texto en la eeprom al momento de grabar el pic.
Saludos
-
Con el ID que tienen no se podra???
-
Creo que lo mejor es bloquear la lectura como indica doppel, porque por más que se escriba en la eeprom o en la flash, se puede leer el PIC modificar el Hex y ya fue la firma.
Saludos!
-
no estoy seguro pero al grabar el pic se puede modificar el ID , que peude ser leído en cualquier momento y asi saber si es tuyo .
O si haces un tiraje con ese ID marcarlos.
Saludos!
-
Hola.
Cual es el ID?????
-
Pero bloqueando la lectura, no voy a saber si es el mio o no, se podra solamente bloquear todo el programa para que no lo copien y solo dejar una porcion de lectura solamente que es donde le pondria la firma digital para poder verla.
Gracias
-
Buenos dias, una solucion a lo que planteas seria hacer algo como lo que fabrican llave con pic, tambien llamadas dongle; uno ejemplo es un pic ya programador y cuando lo conecta ya sea via serial, usb, o paralelo a una pc lo primero que envia es un seria de 8 digitos hexadecimal ahora en caso de no tener comunicacion via pc lo puedes mostrar en un lcd.
Saludos y lo otro es ver si realmente tiene un Id como comentan los colegas que ya te dieron respuesta.
Atten.
Alexander Santana.
Barcelona-Venezuela
-
hola
si no quieres leer el firm,pero quieres saber si es tuyo,la unica opcion que se me ocurre es que en el programa hagas una rutina que lea el valor de una variable y esta este almacenada en le eeprom del pic,por lo tanto podrias leer este valor,pero no el firmware. si no esta este valor,no funciona el programa,haciendo necesario copiar tambien la eeprom y si la copian,la puedes leer para saber si es tuyo,asi lo unico que se me ocurre.
saludos de antonio
-
Hola realmente no se que queres hacer, queres que tu programa autodecte si realmente es el que generaste vos ? tipo control de integridad ?
Saludos !
-
El ID del pic es un espacio de memoria que puedes programar a tu antojo , creo que son 8
Si usas MPLAB lo puedes cambiar , generalmente esta con FFFFFFFF.
Tambien con el pickit2 se puede modificar.
15.16 ID Locations
Four memory locations (2000h-2003h) are designated
as ID locations, where the user can store checksum or
other code identification numbers. These locations are
not accessible during normal execution but are
readable and writable during program/verify. It is
recommended that only the four Least Significant bits
of the ID location are used.
Esto es de un pic16F88
------------------------------------
25.6 ID Locations
Eight memory locations (200000h-200007h) are
designated as ID locations, where the user can store
checksum or other code identification numbers. These
locations are both readable and writable during normal
execution through the TBLRD and TBLWT instructions
or during program/verify. The ID locations can be read
when the device is code-protected.
Este de un pic18F4550/2550
-
Imagino que son estos...
(http://img23.imageshack.us/img23/8343/idpic.th.png) (http://img23.imageshack.us/img23/8343/idpic.png)
En el PIC16 no son leíbles desde un programa pero en el PIC18 sí... 8 bytes de regalo XD
-
Pero si son leibles y escribibles -vaya termino que me inventé- por un programador cualquiera, pues no servirian de a mucho, ya que se pueden modificar cada vez que se conecta el micro al programador no? o entendi mal?
:oops:
-
Muy bien entendido :D
Se pueden leer y programar en cualquier momento.
Pero si lleva sun registro creo qu epuedes saber bien cual es tuyo y cual no.Y el que se este robando tu proyecto debe saber bien que estas haciendo xD para copiar todos los detalles , tendria que tener una tirada de los pics firmados y darse cuenta que va una secuenta , etc.. Hipotesis xD
-
Hola amigos
Interesante este hilo, seguridad en los pic.
Me lo apunto
Un saludo
-
Hola,
Para hacerlo más dificil, pero no serviría en PICs pequeños por su capacidad, yo implementaría un algoritmo MD5 en el PIC.
Desde el PC le envías una cadena de bytes y el PIC te lo retorna operandolo con una ID que tu definas (tipo "secreto") y en MD5.
En el PC haces el mismo proceso y verificas la palabra retornada.
Claro está que la lectura del PIC ha de estar protegida.
Si tu palabra "secreta" solo la sabes tú, aunque tu código esté disponible, no podrán suplantarlo. A no ser que apliquen ingeniería inversa al software.
Si tu pic solo envía una ID es fácilmente suplantable por otro firm que haga lo mismo y con un simple analizador lógico lo habremos identificado.
Si usas un algoritmo de respuesta basado en operaciones lógicas, sustitución, desplazamientos de una palabra enviada al PIC, se puede romper con fuerza bruta o creando una pequeña red neuronal que "aprenda" y lo acabe rompiendo.
El tema está en el tipo de protección que quieras darle a tu dispositivo.
Puedes proteger el PIC todo lo que quieras, pero por 1500$US hay empresas que te leen el código fuente usando técnicas de laboratorio.
Si simplemente quieres identificar los pics, pues puedes usar una rutina de tipo Acknowledge (PC:"Eres de los mios?" --- PIC:"Si, soy el hDA3FE2"
SI quieres seguridad sin pensar en que te copien el PIC , pues una rutina de encriptación (MD5 está muy bien) o un sistema de clave pública-privada.
Pero ten en cuenta que puedes proteger el PIC, pero si no proteges el sistema con el que se comunica (soft del PC) no has conseguido nada.
Un caso propio:
Hace un par de meses, actualicé una versión de software de un dispositivo que tengo de hace algún tiempo.
El "suministrador" me dice que esta versión, debido a sus nuevas funciones necesita un hardware diferente al que ya tengo (incremento de precio).
Cuando me llega el nuevo hardware, es el mismo de siempre pero incorpora un chip a mayores: un AT88SC02.
Busco en internet y resulta que es una criptomemoria recien salida al mercado de la que casi no hay ni información en Atmel.
Problemas. Necesito hacer varios dispositivos que me funcionen con el soft que he pagado a precio de oro, pero el nuevo soft hace una verificación de un número de serie encriptado en el AT88SC02.
El tío ha estado fino. Ahora si quiero manejar más cacharros, debo pagarle el software completo y el hardware de cada uno.
¿Atacar la criptomemoria?-.... Imposible. No con mis medios.
La solución: Ingeniería inversa en el software.
Analizo y encuentro:
Programa hecho en Delphi sin ningún tipo de empaquetado, no hay ofuscación de código ni nada parecido.
Parece chupado. Un par de vueltas con el Olly y aparece mi serial encriptado.
Me encuentro que al modificar un byte del soft me salta un error de integridad en el programa. Es una rutina de chequeo de CRC.
Busco el salto condicional en el test del byte del CRC y lo modifico.
Hago pruebas con el serial, pero no estoy por la labor de identificar el algoritmo, así que me cargo todos los saltos condicionales en los chequeos del serial.
Es tan mala la protección, que hace la llamada a la rutina de comprobación del serial en cada comando, menú o botón al que se le llama, y como en cualquier compilador, el Delphi crea una especie de macro que se repite en cada rutina muy fácil de localizar e identificar.
Después de un par de horas, el AT88SC02 se ha convertido en un trozo de plástico en la placa.
Finalmente se han gastado recursos en proteger el hardware dejando totalmente desprotegido el software, con lo que la protección no ha servido de nada.
Es algo a tener en cuenta a la hora de proteger. Debemos aplicar los mismos recursos en ambos lados de la comunicación.
De nada sirve poner guardias armados en la puerta principal, si la puerta de servicio está entornada. :mrgreen:
Salu2
-
Hola, Oye muy buena esa observacion Droky de nada vale proteger hardware y no soft o software y no hardware asi que tengan eso muy pendiente.
Saludos y estamos en contacto.
Atten.
Alexander Santana.
Venezuela-Barcelona.
-
Hola buenos dias, estuve haciendo una pruebas con lo del ID de los pic y resulto provechoso si se puede identificar el pic aun estando el codigo protegido es decir, si proteges el codigo y luego lo lees logicamente no veras el hex del pic pero en la interface grafica del programador que uses si sabe el id.
Saludos y muy buen tema ya se tiene una idea de como poder saber si un proyecto el codigo es tuyo al menos que otra persona use el mismo codigo de Id que usted.
Atten.
Alexander Santana.
Barcelona-Venezuela.
-
hola
si que se pueden implementar mil cosas,pero si simplemente quiere saber si el pic es suyo,que ponga algo en la eeprom y en el firm que si ese dato no funcione.para temas mas gordos yo no utilizaria un pic,mas que nada porque tengo un amigo que ha montando una empresa (realiza diseños de seguridad entre otras cosas con fpga y demas) y no me ha aconsejado los pic para esto,para temas mas serios me ha dicho utilizar micros con rsa, des y no se que otras cosas.si tienes alguna duda,te puedo dar su email,que es muy majete y seguro que te contesta,no se cuanto tardara porque debe andar liado(hace tiempo que no se nada de el)
saludos de antonio
-
En la página de microchip , en la lista de pics que despliega con sus caracteristicas indica tambien el nivel de seguridad que tiene o puede brindar cada uno.
Saludos!
-
Hola yo le ponia al final del codigo esto:
;===========================================================================================================
; Embedded Release & Copyright Information
;===========================================================================================================
DA "Interface PIC-SAS 6.00, 6.01, 6.02 - $Revision: 3.00 $ - Copyright 2007, Alejandro MACEDO., All Rights Reserved."
; End of Embedded Release & Copyright Information
Por ponerle algo pero al comilarlo me lo volvia todo a lenguaje maquina y no se leia, cuando le das lectura por programador, lo estoy haciendo mal?
-
Los comentarios no se te compilaran, solo el DA.
saludos de antonio
-
Hola, el DA es el que quiero poner y que se vea en el PIC leido, habra que pasarlo a otro lenguaje para que quede talcual? :shock:
-
Hola lo que logre es ponerlo al final del programa y que se vea asi:
;================================================================
; Embedded Release & Copyright Information
;===============================================================
ORG 0X3A8
DE "Pulsador de Bar - $Revision: 1.00 $ - Copyright 2009, Alejandro, All Rights Reserved."
; End of Embedded Release & Copyright Information
Se lee talcual se ve al final del programa, tengan cuidado al poner la direccion del programa para no sobreescribir el OSCCAL.
Saludos
-
Pero ten en cuenta que puedes proteger el PIC, pero si no proteges el sistema con el que se comunica (soft del PC) no has conseguido nada.
De nada sirve poner guardias armados en la puerta principal, si la puerta de servicio está entornada.
Hola buenas noches Droky, oye se me olvido preguntarte que tipo de herramienta necesito para hacer proteccion en los soft que hago en la pc especificamente en delphi para que no pase lo que tu mismo comentas en este post que de nada sirve proteger el hardwarte y luego se puede rromper el soft y asi poder tener un acceso a la aplicacion.
Saludos y espero tu opiniones.
Atten.
Alexander Santana.
Venezuela-Barcelona.
-
Hola Astrocar,
El nivel de protección depende un poco hacia donde va orientado el software y el tipo de difusión que le vas a dar.
Si lo van a usar usuarios "de a pie" con pocos conocimientos técnicos, seguro que con un password te sirve.
Pero si lo van a usar usuarios técnicos y el precio de tu aplicación depende en gran medida del software, ten por seguro que lo intentarán piratear.
No hay nada completamente seguro. Todo es desprotegible y hackeable, depende de la destreza de quien lo haga, por tanto lo ideal será ponérselo lo más difícil posible para que se de por vencido....
La ofuscación de código no es demasiado apropiada, ya que los debuggers hacen uso de las llamadas a las rutinas de las API de windows como BreakPoints y la ofuscación no puede ocultar esas llamadas. Puedes darle un poquito más de trabajo al cracker en cuestión, pero siguiendo estas llamadas, se hará con tu software pronto.
Una opción muy habitual es el uso de packers, que lo que hacen es añadir ofuscación de código insertando código ensamblador transparente en los procedimientos habituales tipo "showmessagebox(), button_click()"..etc. Reducen el tamaño del programa comprimiéndolo y descomprimiéndolo en memoria en el momento de la ejecución, para evitar acceder a los vectores y offsets reales en el .exe para no permitir modificaciones. Tambien suelen añadir rutinas anti-debugger que hacen que algunos debuggers no puedan acceder al código en ejecución, inhabilitando o tomando el control de las interrupciones usadas por ellos.
Hay packers mejores y peores, pero un inexperto cracker poco tiene que hacer con un packer decentillo.
Evidentemente hay ya varios programas de detección de packers y desempaquetadores para hacer el proceso inverso.
Pásate por este enlace que te orienta un poquito sobre el tema.
http://foro.elhacker.net/ingenieria_inversa/como_proteger_tu_programa-t222129.0.html
Las protecciones tipo mochila, (HASP)
Salu2