- Questo topic ha 9 risposte, 3 partecipanti ed è stato aggiornato l'ultima volta 11 anni, 1 mese fa da
.
-
Post
-
Inserisco questo post solleticato dalle molte richieste che mi giungono dai nostri clienti. Spesso si sviluppano programmi per automazione di macchine per il costruttore che produce poi in serie la macchina. Tutti quelli che programmano PLC sanno che i costi di sviluppo del sofware di macchina sono elevati e spesso si decide di spalmarli sulle forniture degli impianti come royalties. Il problema in questi casi è evitare la copia del programma PLC in modo da proteggersi sull’investimento di sviluppo, ecco come SlimLine soluziona il problema.
Il programmatore può scegliere di non trasferire il codice sorgente sullo SlimLine, in questo caso viene trasferito il solo codice oggetto compilato di cui non è possibile il download.
Nel caso si decida di trasferire una copia del programma sorgente sullo SlimLine in modo da poter operare sullo stesso nel futuro per eventuali modifiche, è possibile proteggerlo con password.
Le tecniche viste nel post precedente si basano sul presupposto che sia sempre il programmatore ad operare sullo SlimLine, senza mai fornire copia del programma al cliente. Ma molte volte per necesità di installazione (La macchina viene installata da un tecnico del costruttore) è necessario fornire copia del programma di macchina con modifiche al costruttore. Inoltre può essere richiesto che l’installatore sia in grado di effettuare direttamente sull’impianto piccole modifiche e/o debug sul programma stesso.In questi casi le tecniche precedenti di protezione decadono, SlimLine offre la possibilità di superare queste esigenze con una tecnica di protezione basata sul Customer Code. Tramite connessione seriale o TCP/IP su porta 23 (Telnet), è possibile attivare un interprete comandi testuali, rimando al Manuale riferimento comandi Telnet CPU SlimLine. Autenticandosi al sistema come utente Amministratore (Default Login Admin Password Admin) è possibile con il comando sysconfig -cc xxxxxx definire un numero di Customer Code, (Esempio sysconfig -cc 000123456, assegna il valore 123456). Naturalmente bisognerà modificare le credenziali di accesso all’utente amministratore (Vedi comando userconfig) per evitare che qualcun altro possa accedervi.Ora basterà inserire nelle funzioni, blocchi funzioni o parti di programma più critiche, il controllo sul valore della variabile SysCustomerCode e verificare se corrisponde a quello impostato in Customer Code. Naturalmente queste parti di programma andranno criptate in modo da non esplicitarle.Questa soluzione permette di legare l’esecuzione del programma al solo sistema in cui è stato definito il Customer Code, e quindi sarà possibile inviare al cliente il programma sorgente lasciandogli la possibilità di modificarlo a suo piacere. Allego un semplice progetto LogicLab che mette in pratica questa tecnica (Download programma).Per decriptare il blocco funzione posizionarsi con il mouse sopra di esso e con il tasto destro aprire il pop up Decript, definendo la password che è password. (Screenshot).
Allego per il download una dipensa sulla Proprietà intellettuale del software redatta qualche anno fà da un mio cliente nonchè amico l’Ing Luca Marani. La dispensa tratta in modo generale la problematica della protezione del software e seppure datata di qualche anno è ancora attualissima.
Sto cercando di utilizzare il SysCustomerCode, per proteggere una applicazione, ho notato che questo valore è comunque leggibile, pur avendo tutte le funzioni e programmi criptati, infatti se ho un aggiornamento con LogicLab basta aggiungere un programma fittizio e nella finestra del Watch aggiungere SysCustomerCode per visualizzare il codice.
Attualmente il server web ed il modbus che non utilizzo sono attivi, ma, la situazione dovrebbe essere, la seguente: lo SlimLine sarà venduto con, credenziali di accesso diverse dalle classiche, server web bloccato (utilizzo sysconfig –wid da Telnet) ed anche il modbus di tutte le porte sarà disabilitato, perché utilizzo un protocollo UDP e TCP/IP custom se in futuro ho un aggiornamento, dando al cliente e/o installatore il progetto comunque criptato, utilizzando LogicLab potrebbe risalire a questo codice c’è un modo per ovviare a questo ?
Cerco di spiegare meglio come funziona la protezione basata sul SysCustomerCode, la variabile è accessibile al programma utente perchè deve essere controllata nelle funzioni e FB protetti del cliente, e quindi è anche visualizzabile in debug. Ma si tratta di una variabile di sola lettura, quindi se si mette nella finestra di watch e si cerca di modificarne il valore LogicLab darà un errore.
Se qualcuno più smaliziato inserisce un ramo di programma ladder che con una istruzione MOVE oppure da ST con una assegnazione cerca di scrivere il valore nella variabile SysCustomeCode LogicLab si accorgerà del tentativo di scrivere su una variabile di sola lettura e darà un errore in compilazione.
Le protezioni descritte sono gestite da LogicLab, ma se qualcuno fosse così eclettico da inventarsi un qualche modo per riuscire a scrivere nella variabile SysCustomerCode il valore che tu hai fissato e che controlli nelle tue funzioni protette, ecco che interviene un controllo a livello sistema operativo di SlimLine. Il sistema operativo controlla il valore impostato della variabile con il valore presente in SysCustomerCode, e se riscontra una differenza (Segno che qualcuno in qualche modo ne ha forzato la scrittura) arresta l’esecuzione del programma.
Allo stato attuale (Sperando di non essere smentiti da qualche hacker) possiamo garantire che il Customer Code dà sufficenti garanzie di protezione sulla proprietà intellettuale del software.
Aggiungo per completezza dell’argomento che sui sistemi SlimLine è possibile avere anche un Manufacturer ID (MID), questo identificativo viene impostato sul dispositivo direttamente dalla Elsist che ne tiene tracciabilità. In questo modo nei programmi sviluppati che fanno riferimento a questo codice si ha la certezza che non possano essere eseguiti su sistemi SlimLine che non hanno lo stesso MID definito.
A differenza del Customer code, questo codice non è visibile da programma utente, esso viene controllato eseguendo una specifica funzione embedded che ne verifica l’esettezza utilizzando un algoritmo di criptazione. Ulteriori informazioni sono disponibili in questa FAQ.
Buongiorno, mi riferisco alla nota sulla possibile visualizzazione del customer code. Non ho mai pensato a questa eventualità, ma se in effetti è possibile visualizzare questo codice attraverso un watch allora la protezione non può funzionare.
Sviluppo un programma per una macchina di serie e proteggo l’esecuzione dei blocchi criptati con il cc, a fine sviluppo devo fornire il sorgente ovviamente criptato. Se il cliente vuole attivare il programma su una nuova CPU e legge questi forum, non farà altro che collegarsi ad una macchina funzionante, leggere il cc ed impostarlo nella nuova CPU.
Si dovrebbe fare in modo che da LogicLab non si possa richiedere il cc se non avviando un controllo che richieda utente e password prima di fornire il cc, un po come si fa da toolly per impostarlo.
Bloccare la lettura del SysCustomerCode non è possibile in quanto questo codice deve comunque essere leggibile da programma e quindi basterebbbe per un cliente realizzare un semplice ramo nel programma che con un MOVE ne copia il valore su una sua variabile per poterlo acquisire.
Come forse non è stato ben spiegato nei post precedenti, il SysCustomerCode può proteggere il programma solo se non si danno i sorgenti al cliente. Nel caso in cui si diano i sorgenti al cliente l’unico modo di proteggere efficacemente il programma è utilizzare il Manufacturer ID.
Altra tecnica che alcuni adottano è di utilizzare una variabile in memoria RETAIN impostandone in debug il suo valore, il blocco funzione criptato controlla questo valore e se diverso si blocca. Non essendo nota la locazione di memoria utilizzata e quasi impossibile bypassare la protezione.
Questa ultima affermazione va in contraddizione con il post del 07/09/2012 07:01:08. Non avendo approfondito da parte mia l’analisi dei consigli che mi avete indicato ho investito parecchio lavoro per proteggere varie parti di programma, che alla fine sono facilmente aggirabili.
Non si potrebbe fare in modo che la funzione che richiede il SysCustomerCode abbia come parametro utente e password ? a questo punto il cliente finale non ha nessuna esigenza di dare questo parametro e la richiesta del codice verrebbe protetta.
Si in effetti ho riletto quanto dichiarato nel post che tu citi e ci sono contraddizioni. Attualmente abbiamo rilasciato i nuovi moduli CPU Compact e la versione B dei moduli CPU ARM7. Questi nuovi prodotti sono retrocompatibili, ma avendo ridesegnato alcuni parti del sistema operativo stiamo lavorando su una nuova funzione per migliorare questo aspetto di protezione a livello utente.
- Devi essere connesso per rispondere a questo topic.