Proteggere la propria idea

Buongiorno e chiedo scusa se la sezione non è corretta.
Ho sviluppato un progetto piuttosto complesso usando Arduino. Ora un amico mi chiede di poterlo avere in uso, per qualche mese oppure di vendergli il prodotto. Mi rendo conto che potrebbe essere contro la filosofia open, ma io vorrei evitare che l'amico si trasformi in quello che poi mette il progetto su scala più larga e lo rivende usando quanto gli fornisco.
In pratica, non potendo evitare che si faccia un reverse dei circuiti etc. Come proteggo almeno il firmware?

Grazie.

Con i lock bit. Sono registri particolari del chip che servono a bloccare la lettura della Flash.
Ti invito a fare una ricerca, l'argomento è stato ampiamente trattato.
Ti passo 2 link veloci:
http://forum.arduino.cc/index.php?topic=223499.0
http://forum.arduino.cc/index.php/topic,97755.0.html

Grazie Leo gentilissimo do un occhio subito scusa per la domanda ripetuta… Se ho bisogno continuo qui.

@cc88, ti invitiamo a presentarti (dicci quali conoscenze hai di elettronica e di programmazione) qui: Presentazioni
e a leggere il regolamento: Regolamento

Grande Nid, se malauguratamente nella Seconda Guerra Mondiale ci fossi stato tu al posto di Heinrich Müller, a quest'ora di quei poveri Ebrei non sarebbe rimasto nemmeno il ricordo, mentre lui, per buona fortuna dell'umanità e per il coraggio dei tanti Schindler e Perlasca, se ne fece passare sotto il naso milioni e milioni, anche se purtroppo riuscì a fermarne tanti. Il paragone è funesto ma non avevo altro modo per esaltare la tua efficienza :grin:

Anche questo link Proteggere software da copia - Generale - Arduino Forum

quoto un pezzo di quel treadh anche se un po' retrò

Lo hai fatto poi questo programmatore Michele?
Leggendo quello che hai scritto "va preparato montando opportuna zoccolatura" mi chiedevo e se fosse una Mega che non puoi estrarre il chip? come fai?

Una volta che hai fuso i fuse :smiley: ... ti saluto?

ciao

PS: si l'hai fatto ... domanda scema ahahhah http://www.elettronicain.it/myMain/riviste/p_rivista.asp?nrRivista=EI165&tipo=edicola

Certo, presentato sui numeri Apr-Mag-Giu-Lug 2012, funziona da spettacolo XD, Io all'epoca mi concentrai solo sui PDIP, come puoi vedere dalla foto. Incredibile come proprio ieri sera pensavo a questa osservazione che fai tu oggi :grin:
In realtà si potrebbero studiare degli adattatori SMD-PDIP, che lato SMD sono socket di programmazione (tipo ZIF), in cui infili il micro a pressione, e lato PDIP si potrebbe innestare nello ZIF 40 del mio strumento.
Ti allego un'immagine per farti capirfe cosa intendo, solo che ovviemente la pinatura PDIP andrebbe adeguata allo ZIF 40, anche perché non servono tutti i 100 pin del 2560 :wink:

Programmatore HV stand-alone.JPG

Quindi ci vorrebbe una sorta di attrezzo da inserire sopra al chip a pressione tipo cappello, ma essendo connesso ad altri circuiti forse si rischia di danneggiare l'elettronica intorno ... bho non so la butto lì :slight_smile: dato che non so quali dei 100 pin vanno impiegati allo scopo.

ciao

No, il chip lo devi necessariamente dissaldare da Arduino MEGA, anche se la cosa andrebbe approfondita. Mi spiego: le linee interessate dalla programmazione HV sono una ventina, oltre alle alimentazioni; se queste linee (ricavabili dal data-sheet, alla voce programmazione HVPP) fossero tutte libere allora vi si potrebbe arrivare tramite gli header laterali, con dei comunissimi cavetti jumper da innestare poi nello ZIF 28 o 40 del Programmatore. L'unico dubbio ce l'ho sul fatto che l'HV genera un suo clock da fornire al momento opportuno al micro, con tempistiche molto rigide, quindi penso che almeno il quarzo bisognerebbe levarlo dalla MEGA, però sarebbe un male minore no? :wink:

Bhe allora conviene programmare un Atiny bloccare il software del chiipino (se si può) e usarlo come chiave hardware e richiamarlo con I2C o ICSP, oppure piazzare una decina di Byte sparsi qua e la nella Eeprom, però in questo caso può essere copiata se sai cosa blocca il software.

non ho capito il legame tra la nostra discussione e quello che stai dicendo ora... se ti riferivi al fatto di bloccare il lock bit Byte si dovrebbe poter fare anche da AVRDUDE, per lo sblocco poi serve un chip_erase e quindi si perde anche la flash, ma lo scopo è quello di proteggerne il contenuto da copia, no?

Chiedo scusa a tutti se non mi sono presentato ma l'avevo già fatto tempo fa (credo due annetti). Poi per del tempo non ho più fatto l'accesso al forum e recentemente provandoci (con l'account e pwd che ricordavo) mi veniva detto che non era un account valido. Così ho rifatto la registrazione con la solita mail che uso e mi è stato ricreato l'account, ma ripeto ero già registrato da tempo. Ricordo infatti benissimo il prof. Menniti, leo, uwe a tanti altri. Non ho pensato quindi di presentarmi nuovamente.

L'argomento riguarda proteggere la propria idea:

  • Se tu mi consegni un arduino con un programma funzionante e io lo voglio copiare alla faccia tua, quando eseguo un download otterrò una pappardella di char hex, che non riusciro a riportare in file leggibile e modificarlo, posso solo prenderlo e copiarlo su un altro chip tale e quale, ma se inserisco una chiave hardware non duplicabile che non mi fa funzionare il programma lo scopo è comunque raggiunto.

  • Se blocco il download del programma a livello hardware lo scopo è comunque raggiunto.

Quindi mi pare di capire che ci siano due metodi hardware per bloccare il chip sempre che esso possa essere estratto e piazzato su un programmatore, chiedo a te delucidazioni perchè sull'argomento ho letto vari interventi, ma non c'è un treadh che spiega dalla A all Z come impedire un furto di software o di un idea.

La mia risposta alternativa che non ha forse legami con il discorso intavolato tra noi due si riferisce al fatto che non si può chiedere a un possessore di un chip 328 SMD come la YUN o di un 2560 come la mega di dissaldarlo fare la procedura e poi risaldarlo, è assurdo non credi?
Quindi pensavo ad una alternativa per chi non può estrarre il chip :slight_smile:

PS: Ora vado sulla luna a bermi una birra ahahahahhahaha ... a più tardi

ah, ok, credo di aver capito; come detto in precedenza il blocco del BLB si fa tramite AVRDUDE quindi penso che basti collegarsi alla board da proteggere via ISP ed è fatta, senza smontare nulla; semmai il problema è di chi vuole sproteggere, ma non dovremmo preoccuparcene noi del nemico, vero?
I passaggi per impostare la protezione del BLB li ho spiegati su uno dei numeri in cui ho pubblicato l'HV, ma ovviamente riguardavano l'HV.
Si tratta di studiarsi un attimo questo byte sul data-sheet e poi impostarne il valore in base alle proprie esigenze; la sua particolarità è che ha tre diversi settaggi (vado molto a memoria): free, sola lettura, lock; si può facilmente "salire" ma non si può più scendere. Cioè se imposti sola lettura non puoi più tornare a free ma puoi andare a lock, e da qui non puoi più tornare indietro.
L'unico modo per tornare a free è quello di eseguire il chip_erase che azzera il BLB ma cancella anche flash e eeprom e quindi la protezione funziona

pablos:
Bhe allora conviene programmare un Atiny bloccare il software del chiipino (se si può) e usarlo come chiave hardware e richiamarlo con I2C o ICSP, oppure piazzare una decina di Byte sparsi qua e la nella Eeprom, però in questo caso può essere copiata se sai cosa blocca il software.

Cos'è che vorresti fare, non l'ho mica capito.

leo72:

pablos:
Bhe allora conviene programmare un Atiny bloccare il software del chiipino (se si può) e usarlo come chiave hardware e richiamarlo con I2C o ICSP, oppure piazzare una decina di Byte sparsi qua e la nella Eeprom, però in questo caso può essere copiata se sai cosa blocca il software.

Cos'è che vorresti fare, non l'ho mica capito.

La risposta l'ha data a fine del suo ultimo post:

PS: Ora vado sulla luna a bermi una birra ahahahahhahaha ... a più tardi

:stuck_out_tongue_closed_eyes: :stuck_out_tongue_closed_eyes: :stuck_out_tongue_closed_eyes:

Dunque, confermo che i comandi di protezione e chip_erase possono essere inviati tramite AVRDUDE:

Per la protezione serve l'opzione -u lock (il valore va cercato nel data-sheet)

Mentre per togliere la protezione, ma ovviamente cancellando tutto, serve l'opzione -e che:

Causes a chip erase to be executed. This will reset the contents of the flash ROM
and EEPROM to the value ‘0xff’, and clear all lock bits.

Questo sistema di bloccaggio descitto tramite lockbits è l'unico sistema di bloccaggio possibile con arduino compilatore perchè usa un suo bootloader non codificato, questo perchè arduino nasce come open source e non marketing. Quali sono le limitazioni di questo sistema se invece si vorrebbe usarlo come marketing? Mettiamo che vendi 100 schede ben bloccate e poi ti accorgi che c'è un bug o devi fare un aggiornamento, cosa succede, semplice : devi farti rispedire a casa tutte le 100 schede , riprogrammarle , ribloccarle e rispedirle con 100 pacchettini, con almeno un miliaio di euro di costi di spedizione tra pacchettini, corriere etc.. Questo è quello si faceva 10-15 anni fà , oggi nel marketing chi fà una cosa del genere appartiene al vecchio ed è destinato al fallimento.
Oggi si deve mettere sul proprio sito la versione riveduta e corretta del firmware e lasciare che l'utente finale con 2 passaggi aggiorni il firmware, tutti gli apparati moderni funzionano così, il costo aggiuntivo per bug o modifiche per il venditore è pari a zero.
Cosa si deve fare con arduino per passare da open souce a marketing? Non utilizzare il bootloader di arduino, "impiantando" un BL codificato in modo che decodifichi il codice Hex che arriva dalla seriale e ne ricavi il vero e funzionante codice Hex che scriverà nella flash, I lockbits vengono impostati in modo che la flash non potrà essere letta dall'utente tramite ISP o PARALLEL programming, ...... nè quella del BL nè quella Utente ..... l'unico che può scrivere nella flash utente è solo il BL codificato, la chiave di codifica la conosci solo tu, il programma utente viene "fatto passare" dalla chiave di codifica generando il file utente codificato che potrai tranquillamente mettere sul tuo sito.
Per la trasmissione dei dati sulla seriale puoi usare un tuo protocollo proprietario ma io ho implementato nel mio BL il protocollo Xmodem perchè ben supportato sia da Hyperterminal che da Teraterminal, l'utente finale non deve altro che scaricarsi Teraterminal e il file Hex codificato , resettare arduino e entro 1 secondo premere il tasto "d" sul PC per attivare il BL, poi hai un minuto per selezionare il file hex_codificato e trasferirlo mediante Xmodem a arduino, se non si riesce ad attivare il BL entro un secondo o scade il tempo massimo per far partire il trasferimento, il BL restituisce il controllo al vecchio programma utente senza nessun danneggiamento sia del programma utente che del BL, se l'utente trasmette un file corrotto o non corretto, la scheda non funzionerà ma basterà ripetere la procedura e caricare il programma corretto che riprenderà correttamente a funzionare, l'unica maniera per corrompere definivamente il funzionamento della scheda è dare tramite ISP un comando di ERASE, ripristinando così i fuses ma cancellando il BL. Ora se ovviamente l'utente tenta di caricare un BL differente da quello originale codificato con la chiave esatta non potrà mai far funzionare il nostro eseguibile codificato e la scheda dovrà essere spedita al venditore, il venditore si accorge facilmente della sostituzione del BL e addebiterà costo di riprogrammazione e spedizione all'utente hacker birbacchione.
Mi pare chiaro o no?

Mi pare chiaro o no?

sti caxxi se è chiaro!! scusa non lo facciamo più ahahahahhahaha

Le prime volte è un pò difficile da fare ma ne vale la pena,

Mi pare anche che non sarebbe corretto usare arduino compilatore generare il Hex e codificarlo, quindi sarebbe meglio usare un altro compilatore.