Protezione Atmega328P

[simonpro]

Ciao Leonardo, è un piacere ricevere il tuo aiuto

Ho recuperato un Dragon ed un ATMEGA328 e ho fatto la procedura che hai descritto con un micro funzionante.

Premetto una cosa che avevo gia specificato precedentemente: io devo sbrikkare gli Atmega328P-PU, non Atmega328 (sono differenti come tu saprai gia...)

Ho notato che ripetendo la lettura dell'ID ogni tanto non viene letto bene (device signature = 0xFFFFFF), dopodiché sistematicamente dopo circa 30 secondi dalla programmazione non viene letto piu nulla.

Esatto, è la stessa cosa che succede anche a me e che non riesco piu a sbrikkare ripristinando il fuse RSTDISBL: infatti dopo la programmazione del fuse, la device signature diventa 0xFFFFFF.

Quindi per usare la HVPP in modo affidabile bisognerebbe impostare un tempo di avvio del clock lungo.

Cioè, cosa dovrei fare?
Spiegami in maniera semplice come devo fare a impostare un tempo di avvio del clock lungo...

In attesa Grazie, sei gentilissimo!!!

[Leonardo]

Ciao Simone,

Ho trovato a portata di mano in DIP solamente un ATMEGA328 e ho fatto la prova con quello, è comunque molto simile al tuo micro se non per funzionalità di risparmio energetico e altre piccolissime differenze.

Nella pagina dei fuses devi impostare LOW.SUT_CKSEL ad un valore con un elevato start-up time ed abilitare LOW.CKDIV8 (attenzione che la frequenza operativa cambierà di conseguenza!). Secondo me ad ogni modo è meglio evitare di disabilitare il pin di RESET se non per proteggerlo ulteriormente dalla lettura visto che con alcuni programmatori come il dragon poi si fa fatica a leggere il micro

Ciao
Leonardo

[simonpro]

Ciao Leonardo.

Ho appenato provato ad aggiornare come da tuo suggerimento, riavviato Atmel Studio 7, e tentato di ripristinare il fuse RSTDISBL, ma purtroppo non è cambiato nulla, in device signature vedo semrpe 0xFFFFFF e non riesco a sbrikkarlo.

Ho anche provato l'altra soluzione, impostando un tempo di avvio del clock lungo e abilitato LOW.CKLDIV8 ma non è cambiato nulla, non mi esegue la riprogrammazione....

A questo punto non so se è un BUG hardware di avrdragon o di atmel studio 7...
Colgo l'occasione, data la tua gentilezza e disponibilità, nel chiederti quali fuse devo utilizzare affinchè il mio firmware all'interno del Atmega328P, sia completamente protetto da ogni possibile tentativo di estrazione o lettura del firmware

Leggendo un po in rete, qualcuno asserisce che basterebbe modificare i lock bits BLB0 e BLB1.
Qualcuno invece asserisce che occorre disabilitare il fuse SPIEN.

Cio che mi occorre è semplice: evitare che il firmware possa essere copiato/letto/estratto in formato hex. Quindi completamente protetto da ogni tentativo di recupero, e se il furbo tentasse di effettuare qualche tentativo e il microcontrollore dovesse resettarsi cancellando cio che c'è all'interno, non è un problema, anzi dovrà contattarmi per installargli un nuovo Atmega328P.

Ma vorrei il tuo parere

[Leonardo]

Ciao,

Potresti fare una prova con una vecchia versione di Atmel Studio (es v5) già che ci sei per vedere se é un bug software.
Per i fuses a memoria direi che spien è superfluo, fai magari qualche prova in lettura visto che hai il dragon.
Ciao

[js-bascom]

evitare che il firmware possa essere copiato/letto/estratto in formato hex.

Come gia mensionato da Leonardo questo e IMPOSSIBILE con la maggioranza di chips, forse si puo ottenere con chips che sono stati disegnati per operazioni di alta sicurezza. I fuses sono li per evitare il leggere del chip alle persone oneste.

Poi per il codice di un M328 non ne vale proprio la pena, abbastanza facile copiare il funzionamanto nel proprio codice.

Se fosse qualche cosa che ti farebbe un milionario penso che qualcuno in China, Russia (poveracci) e dintorni estraebbe il codice in qualche modo.

Ma come sta diventanto difficile scrivere in Italiano!