next topic »

[Reply #420 on:]

[SPIEN disattiva la programmazione SPI ma non la programmazione interna, quindi se c'è un bootloader in ascolto sulla seriale puoi riflashare il micro, giusto?

Se è attiva la protezione in scrittura della flash tramite l.b. il bootloader non può riprogrammare il micro, avevo già fatto presente che per bloccare la riprogrammazione SPI o Jtag è necessario disabilitare i relativi fuse, dopo di che solo tramite HV è possibile riprogrammare il micro.

[Reply #421 on:]

[SPIEN disattiva la programmazione SPI ma non la programmazione interna, quindi se c'è un bootloader in ascolto sulla seriale puoi riflashare il micro, giusto?

Se è attiva la protezione in scrittura della flash tramite l.b. il bootloader non può riprogrammare il micro, avevo già fatto presente che per bloccare la riprogrammazione SPI o Jtag è necessario disabilitare i relativi fuse, dopo di che solo tramite HV è possibile riprogrammare il micro.

Bene, quindi di protezioni a questo punto Mike ne ha un bel po' a sua disposizione:
- fuse SPIEN anti programmazione SPI
- fuse RSTDISBL anti pin reset
- lock bit anti scrittura bootloader (BLB0 e BLB1)

[Reply #422 on:]

@ QP: io non voglio disabilitare il chip_erase, solo che non sia attivo in condizioni normali; cioè l'utente non dovrebbe poter fare una normale operazione di scrittura con successo, se ho attivato la protezione. Prendo atto che non è possibile.

@ Astro: ma un firmware all'interno di un micro è capace di gestire una autoscrittura nella flash? mi torna utile questa info per l'articolo, se me la confermi

@ Leo e BB: considerando che parlerò di stand-alone il problema bootloader non me lo pongo proprio, quindi la disabilitazione reset non mi serve; invece ok per la disabilitazione SPI, provata, l'effetto è che il micro non è sovrascrivibile via ISP(bene!) ma non è più neanche leggibile (male!) nemmeno se lascio i lock bits a FF; infatti mi dà errore di signature. Con la scusa ho capito cosa è successo a quei 2-3 chip che ho immolato per la progettazione dell'HV, a forza di sparargli botte da 12V (parlo di centinaia di volte....) devo aver danneggiato il circuito del pin reset di questi micro, e quindi è come se fosse disabilitato, perché ho provato la disabilitazione del reset e l'effetto è lo stesso: invalid device signature (quindi sia se disabilito il reset che se disabilito lo SPI).
Conclusioni, la procedura:
impostazione fuse per no SPI
lockbits su FE o FC
protegge il micro da lettura e scrittura

la procedura:
lockbits su FC protegge il micro dalla sola lettura
non c'è modo di proteggere il micro da scrittura e lasciarlo libero in lettura (condizione FE), ma comunque direi di avere una soluzione per tutto, questa particolare opzione non ha significato per me.
Naturalmente ho provato sia da IDE che da riga di comando, identici comportamenti.Grazie!

[Reply #423 on:]

Scusa Mike ma ogni tanto perdo il filo del tuo ragionamento e delle tue necessità....
Scrivi:

NON riesco a leggere con AVRDUDE (bene!)
RIESCO a scrivere con AVRDUDE (male!).

Poi affermi invece:

il micro non è sovrascrivibile via ISP(bene!) ma non è più neanche leggibile (male!)

Quindi ora non ti va bene che sia leggibili ma ti va bene che non sia riscrivibile però ieri dicevi l'esatto opposto 

[Reply #424 on:]

@ Astro: ma un firmware all'interno di un micro è capace di gestire una autoscrittura nella flash? mi torna utile questa info per l'articolo, se me la confermi

Scusa se rispondo io.
E' proprio quello che fa il bootloader. Scrive nella zona definita Application section che è la flash decurtata della quantita riservata all'area del bootloader. Per farlo, il codeice del bootloader fa uso di macro in assembly che utilizzano l'istruzione (assembly) SPM.
Un esempio tratto da boot.h, alla 7^a riga

Code:

#define __boot_page_fill_short(address, data)   \
(__extension__({                                 \
    __asm__ __volatile__                         \
    (                                            \
        "movw  r0, %3\n\t"                       \
        "out %0, %1\n\t"                         \
        "spm\n\t"                                \
        "clr  r1\n\t"                            \
        :                                        \
        : "i" (_SFR_IO_ADDR(__SPM_REG)),        \
          "r" ((uint8_t)__BOOT_PAGE_FILL),       \
          "z" ((uint16_t)address),               \
          "r" ((uint16_t)data)                   \
        : "r0"                                   \
    );                                           \
}))

Ciao
QP

[Reply #425 on:]

Se è per questo, è possibile per lo stesso codice scrivere all'interno di sé stesso, ossia un programma può cambiare in tempo reale il contenuto della memoria che occupa. A parte le considerazioni sul fatto che se si sbaglia locazione di memoria poi si rende il codice ineseguibile, la possibilità c'è ed è documentata dal datasheet.

[Reply #426 on:]

@Menniti , quindi obbiettivo raggiunto
....anche se
http://www.cl.cam.ac.uk/~sps32/mcu_lock.html 

[Reply #427 on:]

@ QP: grazie del chiarimento, ma in condizione FC ho messo il chip con bootloader caricato direttamente su Arduino e sono riuscito ugualmente a caricare un blink, quindi il blocco continua a non avere alcuna utilità. Forse, come dicevi tu stesso mi pare, bisognerebbe mettere mano anche ai BLB, però l'uovo non vale la candela.

@ Leo: vuoi farmi passare per un rincoglionito ? La premessa fondamentale è che io NON voglio proteggere alcun firmware, ma devo solo presentare un progetto del Programmatore HV spiegandone caratteristiche ed uso, quindi immagino che uno che lo voglia realizzare voglia poi provare a sfruttarne tutte le caratteristiche. La prima coppia di affermazioni era legata al settaggio FC che, teoricamente, doveva impedirmi sia di leggere che di scrivere, non è così, una bene, una male. La seconda coppia riguarda il fatto che in condizione FE (solo write protect), con l'ausilio della SPI disabled mi aspettavo di non poter più scrivere ma di poter continuare a leggere, così non è, uno bene, uno male. I miei giudizi riguardano le prove che faccio rispetto a ciò che mi aspetto come esito, non sono assoluti, perché sto usando uno strumento che deve poter agire parzialmente su questi parametri; non sto cercando, come premesso di proteggere un micro. Chiaro ora?   la mia mente è salva per ora ?

@ BB: come battuta va benissimo, ma restando in tema l'obiettivo è raggiunto; scusa, se sto progettando uno strumento che ha la funzione chip erase non ho certo bisogno di ricorrere ad un tesista russo per farmi cancellare un micro (ciò che ho "intuito" dando un'occhiata al volo al tuo link).

[Reply #428 on:]

@ Leo: vuoi farmi passare per un rincoglionito ? La premessa fondamentale è che io NON voglio proteggere alcun firmware, ma devo solo presentare un progetto del Programmatore HV spiegandone caratteristiche ed uso, quindi immagino che uno che lo voglia realizzare voglia poi provare a sfruttarne tutte le caratteristiche. La prima coppia di affermazioni era legata al settaggio FC che, teoricamente, doveva impedirmi sia di leggere che di scrivere, non è così, una bene, una male. La seconda coppia riguarda il fatto che in condizione FE (solo write protect), con l'ausilio della SPI disabled mi aspettavo di non poter più scrivere ma di poter continuare a leggere, così non è, uno bene, uno male. I miei giudizi riguardano le prove che faccio rispetto a ciò che mi aspetto come esito, non sono assoluti, perché sto usando uno strumento che deve poter agire parzialmente su questi parametri; non sto cercando, come premesso di proteggere un micro. Chiaro ora?   la mia mente è salva per ora ?

No, il rinco... sono io perché siccome non mi ricordo le cose, poi mi tocca andare a ricercare ciò che uno scrive per seguire il filo del discorso, solo che poi mi intreccio lo stesso 
Ti chiedo, tu vuoi impedire la scrittura E la lettura, giusto?

[Reply #429 on:]

no, il mio intento esatto è: impedire la lettura e/o la scrittura, ecco perché NON ho raggiunto il 100% del mio scopo: oggi posso impedire la lettura, posso impedire la lettura e la scrittura, ma NON posso impedire la scrittura lasciando libera la lettura.
Questa è da incorniciare

[Reply #430 on:]

Mike, ma questo non potrai mai ottenerlo.
I lock bit servono proprio per impedire primariamente la lettura della memoria: sono nati come una sorta di "lucchetto" (da "lock") per bloccare ogni tentativo di copia del firmware non autorizzata. Lo scopo primario è proprio quello di evitare che un cinese si svegli la mattina e decida di clonare un certo dispositivo basato su un micro. Anche se non è in possesso del codice del firmware, che gliene frega? Compra uno di quei dispositivi, fa un dump del firmware, dopo di che realizza 100000 copie del dispositivo ed in ogni micro inserisce il firmware che ha prelevato dal micro. A lui non importa che sia in codice macchina, tanto lo deve semplicemente rimettere in un altro micro.

Se usciamo da questo presupposto, usciamo dal significato di lock bit.

[Reply #431 on:]

Mike, ma questo non potrai mai ottenerlo.
I lock bit servono proprio per impedire primariamente la lettura della memoria: sono nati come una sorta di "lucchetto" (da "lock") per bloccare ogni tentativo di copia del firmware non autorizzata. Lo scopo primario è proprio quello di evitare che un cinese si svegli la mattina e decida di clonare un certo dispositivo basato su un micro. Anche se non è in possesso del codice del firmware, che gliene frega? Compra uno di quei dispositivi, fa un dump del firmware, dopo di che realizza 100000 copie del dispositivo ed in ogni micro inserisce il firmware che ha prelevato dal micro. A lui non importa che sia in codice macchina, tanto lo deve semplicemente rimettere in un altro micro.
Se usciamo da questo presupposto, usciamo dal significato di lock bit.

Forse vuoi dire una cosa diversa da ciò che intendo io, rileggiti il mio post in cui ho copiato le caratteristiche dei due lb, in breve:
FE: write protect
FC: write & verify protect
quindi in FE teoricamente dovrei poter leggere (e lo faccio) ma non scrivere (ma lo faccio lo stesso); poi mettiamola sul filosofico ed hai ragione tu, ma il datasheet parla chiaro.

[Reply #432 on:]

Ma astro ti ha spiegato che l'impedimento alla scrittura non si applica ai tentativi "interni", fatti cioè dal bootloader.
Ecco perché ti dicevo che secondo me dovresti togliere il bootloader e disattivare il pin di reset.

[Reply #433 on:]

Forse vuoi dire una cosa diversa da ciò che intendo io, rileggiti il mio post in cui ho copiato le caratteristiche dei due lb, in breve:

Michele stai travisando completamente il significato, e l'uso, dei L.B., adesso non ho tempo per darti una spiegazione dettagliata, devo uscire e vado di fretta, più tardi ti spiego per bene il tutto.

[Reply #434 on:]

intervengo giusto per spezzare una lancia
Michele in genere non travisa niente, a limite sono i manuali che sono scritti criptici ed interpretabili 

Io anche mi sarei aspettato che usando protezione massima non avrei potuto programmare il micro

attendiamo illuminanti delucidazioni al fine di buttarci in test atti a conferme/smentite (in genere con voi e' la prima opzione che si avvera  )