Newsgroup: it.hobby.elettronica.digitale
Titolo: Aggiornamenti firmware

Salve, vorrei progettare un sistema per aggiornare il firmware delle schede 
che hanno i clienti, stando attento però ad eventuali reverse engineering!
Avete delle idee da suggerirmi? Essendo un problema comune a molti .. 
esistono prodotti commerciali che lo fanno?
grazie

*FeDe*:

Hum. Avevo letto di software downloader con crittografia DES.
Prova a googlare 'ste parole qui.

*FeDe* ha scritto:

Con che micro lavori?
In generale dovrai usare un bootloader. Questo si occupa di ricevere da 
un canale il nuovo firmware (es. seriale) e di programmare la flash 
stessa con i nuovi dati.
Se lo scrivi tu, puoi cifrare come preferisci lo stream di dati 
lasciando il compito al micro di decifrarli e poi di programmarsi.
Normalmente si tende a minimizzare la grandezza del bootloader per 
lasciare più spazio al codice programma, ma se ne hai a sufficienza 
nulla ti impedisce di rendere il bootloader complesso. A meno di 
limitazioni hardware del micro in questione ovviamente.
Ciao!
Marco / iw2nzm

esistono prodotti commerciali che lo fanno?
Che io sappia non esistono prodotti appositi, ma il problema č risolvibile in
diversi modi.
Si piň elaborare il file .hex, in genere un ASCII-INTEL, in modo da rendere piů
difficile un reverse engineering, oppure si possono inglobare i dati da
trasmettere in un file .exe in modo da rendere difficile l'individuazione dei
dati
Io ho fatto un app in QB che inglobava il file in un .exe stand-alone facendo
solo qualche XOR, una cosa abbastanza sicura, non ho a che fare con la nsa.
Il problema principale č che con il dos oltre COM4 non si va, e con i
convertitori USB odierni č un problema.
Poi si puň variare il baud-rate durante la trasmissione, guisto per complicare
la vita a chi usa gli sniffers, e ci saranno tanti altri trucchi che non so.
Ovviamente occorre che sul firmware del processore, nel bootloader vengano
eseguite le operazioni inverse in modo che i dati trasmessi vadano al posto
giusto.
--
ciao
  Stefano

 limitazioni hardware del micro in questione ovviamente.
Per gli AVR li trova già fatti:
http://www.atmel.com/dyn/resources/prod_documents/doc2541.pdf
http://www.atmel.com/dyn/resources/prod_documents/doc2589.pdf

 lasciando il compito al micro di decifrarli e poi di programmarsi.
Ok, ma quindi tu intendi dire che il bootloader deve essere nel micro
delle schede sin dall'uscita del prodotto dalla fabbrica!
Altrimenti dovrei scaricarlo sul micro!
Se lo vado a scaricare, non posso a sua volta criptarlo.
Quindi qualcuno potrebbe "sniffare" i pin del micro mentre lo sto
programmando col bootloader, fare un reverse engineering, e quindi
capire c0ome vado a criptare il firmware.
Grazie


Esattamente, se vuoi inviare il tuo firmware criptato l'unica cosa 
sicura è avere un bootloader.
Se hai già fuori prodotti senza bootloader purtroppo non ci sono 
possibilità.
-- 
  _|/ Francesco Sacchi - Develer S.r.l., R&D dept.
   |\ 
http://www.develer.com/
 - 
http://www.bertos.org/

 capire c0ome vado a criptare il firmware.
Perché mai dovrebbero fare una fatica simile, quando l'algoritmo del DES è
pubblico da sempre? Mi sa tu non abbia molta familiarità con la
crittografia... ;-)
Piuttosto il problema è come trasmettere la chiave di decrittazione. Se i
tuoi apparati hanno un numero di serie nel firmware, potresti usare quello,
cosa che ti permetterebbe anche impedire che lo stesso update possa essere
messo su più macchine.

> ?

>> ?
Credo si riferisse al fatto che, se un controller non supporta il
"self-programming", il trasferimento dei vettori di interrupt, i lock su
sezioni della memoria, ovvero se lo puoi solo programmare con un
programmatore esterno, non puoi crittare alcunché.

 bootloader aggiornato!
Sempre abbiano un numero di serie od un qualcosa che possa essere usato
come chiave. Volendo la puoi nascondere nel codice del bootloader, ad
esempio specificando, con un valore contenuto in una posizione definita di
una stringa "random", l'offset del punto da cui iniziare a caricare un
pezzetto del programma stesso, da usare poi come chiave.


Esatto.
Almeno la prima volta devi programmare un bootloader non criptato.


*FeDe* ha scritto:

che fanno...reverse engineering ?
http://www.flylogic.net
saluti


http://www.flylogic.net
"awesome", come dicono loro
Davvero imprerssionanti le immagini sul Mega88.
--
ciao
  Stefano

 Davvero imprerssionanti le immagini sul Mega88.
A me ha impressionato molto pi� il fatto che, mentre il Mega 88 ha i
fusibili di protezione coperti da uno strato di metallizazione, rendendo
impossibile cancellarli con gli UV, anche gli ultimi PIC sono
vulnerabilissimi e che, soprattutto, lo � il chip ST per le smartcard!!

 
nei prossimi giorni avrò giusto da fare il bootloader per i microchip, 
serie 24 (serie 18 lo abbiamo già implementato e utilizzato da tempo, 
con pacchetti criptati sul canale di comunicazione decrittati dal 
bootloader, come detto da altri qui)
prima di tutto puoi dare un'occhiata alle an1157 e an1094 per il 
bootloader della serie 24, e ce n'è una anche per la serie 18
idee sparse che abbiamo buttato giù oltre a ciò che è stato fatto per la 
serie 18:
- separare il più possibile la parte di acquisizione del singolo 
carattere, facendo ad es. una GetChar(), in modo da poter facilmente 
implementare un bootloader da uart, da usb, da una memoria eeprom, da 
ethernet..., cambiando la sola getchar
- realizzare un sistema che ci salvi anche quando il programma 'utente' 
per qualche malsana ragione è difettoso oppure non è in grado di fare 
partire correttamente la procedura di riprogrammazione: ad es. nei primi 
100ms parto in modalità boot e se ricevo pacchetti di 
start-programmazione rispondo e parto col boot, altrimenti parto col 
programma utente. Questa modalità ha il problema che ne posso 
programmare uno solo alla volta e non più n come prima...
ps quanto tempo sprecato con i serie 18! la serie 24 costa praticamente 
la metà ed è molto più potente, e il passaggio è stato indolore!