This forum uses cookies
This forum makes use of cookies to store your login information if you are registered, and your last visit if you are not. Cookies are small text documents stored on your computer; the cookies set by this forum can only be used on this website and pose no security risk. Cookies on this forum also track the specific topics you have read and when you last read them. Please confirm whether you accept or reject these cookies being set.

A cookie will be stored in your browser regardless of choice to prevent you being asked this question again. You will be able to change your cookie settings at any time using the link in the footer.

  • 1 voto(s) - 4 Media
  • 1
  • 2
  • 3
  • 4
  • 5
[Proyecto] AVR Fuse Doctor
#1
Hola a todos, estoy enredando mucho con un ATtiny13 y me he comprado un Fuse Doctor, más que nada porque voy a usar el pin de de reset como GPIO y necesitaré esto para resetear los fusibles.

Pues bien, estoy un pelín enfadado, ya que me encantan las cosas open source.

Me he comprado este Fuse Doctor: http://www.ebay.es/itm/222408487177?_trk...EBIDX%3AIT

Y el problema es que como véis en la imagen, han lijado la serigrafía del micro, supongo que quieren proteger su diseño  Facepalm

Me he propuesto realizar un diseño mejorado y publicarlo todo: firmware, esquemático y layout de Altium.

Si alguien quiere participar que lo diga.

[Imagen: 11828lg.jpg]

[Imagen: 209fyhi.jpg]

[Imagen: bgcr6h.jpg]

Actualización.

Voy a trabajar a partir del diseño de: http://mdiy.pl/attiny-fusebit-hvsp-doctor/?lang=en

Esquemático:

[Imagen: avr_attiny_hvsp_fusebit_doctor_schematic.png]

La primera mejora que se me ocurre es alimentar todo el circuito con +5V. Así podríamos simplemente usar el cargador de un móvil para usar el circuito, ya que no todo el mundo tiene fuente de alimentación.

Lo primero que voy a hacer es simular el circuito que genera la señal de +12V; señal la cual va al pin de reset de nuestro attiny brikeado.


[Imagen: rauwl1.jpg]

Y en abierto

[Imagen: bgcr6h.jpg]

Una vez comprobado que efectivamente le llegan (más o menos) +12V, lo siguiente es eliminar ese circuito y en su lugar tratar de sacar +12V a partir de +5V.
  Responder
#2
Me quedo por aquí =)

De todos modos, has mirado estos proyectos?
http://mdiy.pl/atmega-fusebit-doctor-hvpp/?lang=en
http://mdiy.pl/attiny-fusebit-hvsp-doctor/?lang=en

Del segundo se pueden descargar los fuentes del firm. La pena es el primero, que es más completo (y nuevo) y no comparte los fuentes. Pero igual te sirve de base.

Teniendo los esquemáticos y layout, si somos varios interesados, igual podríamos pedir una tirada de placas a Elecrow y tener así tanto el Doctor como las placas de adaptación.
  Responder
#3
(19-04-2017, 08:44 AM)WeSo escribió: Me quedo por aquí =)

De todos modos, has mirado estos proyectos?
http://mdiy.pl/atmega-fusebit-doctor-hvpp/?lang=en
http://mdiy.pl/attiny-fusebit-hvsp-doctor/?lang=en

Del segundo se pueden descargar los fuentes del firm. La pena es el primero, que es más completo (y nuevo) y no comparte los fuentes. Pero igual te sirve de base.

Teniendo los esquemáticos y layout, si somos varios interesados, igual podríamos pedir una tirada de placas a Elecrow y tener así tanto el Doctor como las placas de adaptación.

sí, los he estado viendo. Lo ideal, en mi opinión, sería tenerlo todo en una única placa, y eliminar las placas de adaptación.

¿Por qué crees que han lijado la serigrafía del micro?
  Responder
#4
Teniendo esquemas se podría montar todo en una placa, está claro. Y seguramente entrase todo en una de 100x50mm para pedir a Elecrow.

La serigrafía la borran siempre por lo mismo, para que no sepas qué componente es y no puedas cacharrearlo. En este caso, es un microcontrolador, eso lo tenemos claro, pero no sabemos el modelo.
  Responder
#5
(19-04-2017, 09:07 AM)WeSo escribió: Teniendo esquemas se podría montar todo en una placa, está claro. Y seguramente entrase todo en una de 100x50mm para pedir a Elecrow.

La serigrafía la borran siempre por lo mismo, para que no sepas qué componente es y no puedas cacharrearlo. En este caso, es un microcontrolador, eso lo tenemos claro, pero no sabemos el modelo.

No le veo sentido a ocultar el modelo, porque igualmente (por ejemplo en el caso de que sea un AVR), podemos puentearle los pines del icsp con un usbasp y ver en atmel studio qué chip es. Y aparte, aunque sepamos qué chip concreto es, si tienen activados los lock bits, no podemos leer su flash para hacer un dumpeo y replicar su placa ...

Sobre los códigos de ese proyecto, el autor tiene publicado los compilados (.hex), pero no el código fuente. Pero eso no es problema, es divertido.
  Responder
#6
Hombre, yo no conozco todos los integrados de ATMEL, pero no sé si todos los de un encapsulado de 20 patas comparten el mismo pinout o si por el contrario tienen distintos modelos con mismo encapsulado y pinout.
Igual en esta ocasión es evidente que es un microcontrolador, pero en placas más complejas, da bastante por saco no saber qué integrado es, ya que puede tener características específicas para un diseño, que serán muy difíciles (o imposibles) de averiguar. Por ejemplo, analizando una parte de un circuito puedes deducir que un integrado en un operacional, pero te puedes pegar un tiro cuando ves la de miles de modelos que hay en el mercado con distintas características.

El lockbit no es completamente seguro hoy por hoy. Partiendo de la base de que al final la mayoría de cosas se pueden reventar, los autores muchas veces tratan de dificultar la tarea lo máximo posible. Es más, hay empresas que se dedican exclusivamente a éstos propósitos, además de las que hay haciendo hardware pen. test.

Sí, tiene publicados los hex, pero son ganas de tocar las narices y obligar a modificarlo en ensamblador teniendo los fuentes en código sin compilar, pero bueno.
  Responder
#7
Yo trabaje un tiempo en una empresa que fabricaba placas electronicas y borraban con laser la serigrafia de los componentes, el propósito es evidente, que no sepas que es lo que lleva y no puedas copiarlo fácilmente, los fuses que yo sepa aun no los ha conseguido reventar nadie (por la cuenta que les trae a los fabricantes de microcontroladores, así debe ser), por otro lado, aunque dudo que sea el caso, a veces se borra la serigrafia pues se le carga a dicho microcontrolador un bootloader propio con el cual puedas sobrescribir internamente la flash del programa, esto posibilita la actualización del firmware del microcontrolador y implementación de posibles mejoras.

Que yo sepa el micro puede reprogramarse a si mismo incluso con los fuses antiescritura en on.


Yo personalmente había pensado en esta posibilidad, metiendole un bootloader con una clave única que solo sepa su programador, de esta forma el micro esperaría una clave y sin ella no podría ser reprogramado, no me estrañaria nada que esto se aplique en la realidad.
  Responder
#8
(20-04-2017, 04:25 PM)Shellmer escribió: Yo trabaje un tiempo en una empresa que fabricaba placas electronicas y borraban con laser la serigrafia de los componentes, el propósito es evidente, que no sepas que es lo que lleva y no puedas copiarlo fácilmente, los fuses que yo sepa aun no los ha conseguido reventar nadie (por la cuenta que les trae a los fabricantes de microcontroladores, así debe ser), por otro lado, aunque dudo que sea el caso, a veces se borra la serigrafia pues se le carga a dicho microcontrolador un bootloader propio con el cual puedas sobrescribir internamente la flash del programa, esto posibilita la actualización del firmware del microcontrolador y implementación de posibles mejoras.

Que yo sepa el micro puede reprogramarse a si mismo incluso con los fuses antiescritura en on.


Yo personalmente había pensado en esta posibilidad, metiendole un bootloader con una clave única que solo sepa su programador, de esta forma el micro esperaría una clave y sin ella no podría ser reprogramado, no me estrañaria nada que esto se aplique en la realidad.
Hay "mil" técnicas, como por ejemplo glitching. Hay empresas que por una "módica" cantidad te sacan el código de un microcontrolador utilizando todo tipo de técnicas tanto intrusivas como no intrusivas.
No es algo trivial ni barato, pero con los medios necesarios (dinero), si un producto es muy popular, te lo pueden reventar.

En el otro lado, las mismas empresas que te revientan protecciones, ofrecen servicios de protección, pero que obviamente no son más que trabas ante un posible ataque.

A nivel de desarrollo hay técnicas muy ingeniosas, como freir a propósito una parte de la EEROM durante la fabricación del producto con un programa de tipo test, de tal modo que cuando arranque el programa original conozca qué bits de la EEPROM están quemados, y que si no detecta los que corresponde (por ejemplo que se copia el código en otro microcontrolador no "autorizado") deje de funcionar. Pero claro, esto no es más que otra traba, ya que si tenemos el código, podemos saltarnos esta protección.

Actualmente lo que más puede proteger algo es hacerlo que dependa de un tercero, ya sea a través de servicios de red u otros componentes en la misma placa, pero sigue siendo factible.

La protección que comentas, no le veo la gracia, básicamente porque lo que suele interesar es protegernos de la lectura, no de la escritura.

Lo que hay que asumir es que si damos el pelotazo y hacemos un producto popular y exclusivo, nos lo van a poder copiar tarde o temprano.

Joder, vaya tochopost me ha quedado xD

P.D. No diría que un micro se "reprograma" al uso, ya que hay una parte inicial que necesitas que sea haga externamente. Poniéndole una boot (como el arduino) conseguimos que ejecute un código que cargamos en la memoria no volátil (siguiendo el ejemplo de Arduino, para poder usar su IDE necesitamos cargar primero el bootloader, el cual ejecuta el código en determinado espacio de direcciones).
  Responder
#9
Claro, ya se que se necesita cargar el bootloader para hacer eso, yo lo he hecho en algunos micros de Microchip porque me resultaba un coñazo reprogramarlos con el programador, hasta he llegado a adaptar el bootloader a mano por no ser compatibles con algún micro que me interesaba.

Considero que la protección contra escritura es bastante importante, piensa en que si no la tienes es muy fácil reprogramar la sección de memoria que carga el programa, donde se realiza la llamada a la main, y ponerle una llamada a un código que lea la flash y la transmita por algún pin leyendolo con otro micro y pasandolo al .hex.

Es cierto que hay métodos y métodos y si algo he aprendido en mi vida como programador es que siempre hay algún c... que te intenta joder el programa, el dicho "hay que programar para tontos" es el más descriptivo, la gente siempre encuentra la manera de reventar el programa, y uno ha de acostumbrarse a programar pensando en cualquier combinatoria posible. Supongo que como dices, lo mismo pasa a la hora de proteger el producto... en mi caso no tengo experiencia en ello, así que poco puedo decir al respecto.

Ahora solo falta que saquen un descompilador que te pase el código .hex a C, el ensamblador es un galimatias, y sinceramente, no me aclaro con el.
  Responder
#10
(20-04-2017, 08:09 PM)Shellmer escribió: Considero que la protección contra escritura es bastante importante, piensa en que si no la tienes es muy fácil reprogramar la sección de memoria que carga el programa, donde se realiza la llamada a la main, y ponerle una llamada a un código que lea la flash y la transmita por algún pin leyendolo con otro micro y pasandolo al .hex. 
Y cómo sabes qué sección es? Si no tiene bootloader, el programa principal puede cargar al inicio, por lo que te lo estarías cargando. Que puedes sacar parte? pues sí, pero sigues sin tener el programa.
  Responder
#11
Si ejecutas un salto a una posicion cerca del final de la memoria que incluya el programa de lectura podrias sacar gran parte del programa, y si tienes dos micros de estos podrias ejecutar el salto a otro segmento diferente por si te cargases algo al final de la memoria al reescribir el primer micro, juntar ambos codigos que extrajeses y sacar el 99% del .hex...

Evidentemente tal y como dices tendriamos un programa inconsistente al que le faltaria un 1% de su contenido justo el trocito que uno se ha cargado al meter la instruccion de salto, teniendo esto en mente si ficho programa se carga en un nuevo micro podria arrancar... o no, dependiendo de lo que uno se haya cargado... no voy a decir que sea facil, pero seguro que se puede hacer algo.

La direccion a sobreescribir es la del reset vector y no todos los microcontroladores tienen la misma, de todas formas nunca he tocado esto para nada asi que no sabria decirte si se puede cambiar dicha direccion, si se pudiese pienso que podria mandarse cargar el codigo extra directamente sin sobreescribir nada, siempre que nuestro codigo lo grabasemos en memoria vacia.

Como dices siempre hay maneras de que te revienten el programa, esta es una manera que yo he pensado que podria funcionar... no lo he probado nunca, evidentemente, asi que quede claro que son conjeturas de lo que podria hacerse, luego en la practica puede que ni se pueda hacer y nada de esto sea aplicable.
  Responder
#12
Muchas veces una de las protecciones es tener un código único por cada micro (con pequeñas modificaciones o distribuciones) y no se dispone de dos idénticos. Y también es común utilizar en producción micros OTP que no permiten estar sobrescribiendo alegremente.
Está claro que puede ser una alternativa para según qué protecciones, no deja de ser una puerta más que le ponemos al campo para dificultar la tarea del interesado en extraerlo.

Por cierto, hay algún intento por ahí de decompilador de ensamblador a C (las pruebas que yo he hecho no han sido muy satisfactorias), y de hecho muchas de las empresas que te hacen las "recuperaciones" de los micros, te dan la posibilidad de enviártelo en dicho lenguaje.

Al final hablando de cómo conseguir el código del Fuse Doctor hemos acabado en temas de protección, que vienen al hilo de lo que se quieren en el post, pero que igual nos daría para otro nuevo xD
  Responder
#13
Nada nada, es que nos emocionamos hablando de micros jajaja. Yo no soy ningun experto desde luego pero es raro encontrar gente que sepa del tema.
Siento haber desvirtuado el tema.
  Responder
#14
Ésta es una charla que estuvo bien que dieron hace unos años en las OSHWCON que hicieron en Madrid sobre ingeniería inversa:

https://www.youtube.com/watch?v=YV6pjc9sshk

Estuve en su día y creo recordar que mostraba algo de decapar los integrados para leer el programa, de los micros que habláis no tienen ninguna protección contra este tipo de cosas más álla de los fuses, por lo que sacar el código es relativamente sencillo para las empresas que se dedican a ello.



  Responder
#15
actualizado el #1
La primera mejora propuesta es alimentar todo el circuito con +5V, en vez de una parte con 5 y otra parte con 12.
  Responder


Posibles temas similares…
Tema Autor Respuestas Vistas Último mensaje
  Duda con interrupciones externas en AVR cybero 1 2,167 18-05-2017, 12:04 PM
Último mensaje: WeSo
  ¿Qué programador usáis para AVR? cybero 1 1,261 12-05-2017, 03:43 PM
Último mensaje: BricoGeek
  [AVR] ¿Alguien usa USBasp? cybero 2 2,068 07-05-2017, 11:31 PM
Último mensaje: cybero
  Programación para AVR. ¿Por dónde empezar? cybero 2 1,891 17-02-2017, 05:01 PM
Último mensaje: cybero
  Alguien en el foro que domine C para AVR Jaimelito 3 1,593 01-11-2015, 03:55 PM
Último mensaje: Jaimelito