Newsgroup: it.lavoro.informatica
Titolo: ot- protezione del software

E' sicuro un programma protetto da un file cifrato e una chiave hardware 
(seriale o usb) ?
Cioč in termini percentuali  l'aggiunta di una chiave HW al solo file 
cifrato , di quanto aumenta la resistenza alla pirateria rispetto all'uso 
del solo file cifrato ?
Per craccare la chiave , l'utente finale ha bisogno di un esperto 
informatico ?
Grazie delle info! 

 informatico ?
In genere modifichi l'exe bypassando il check della chiave.
Per uno che ci capisce è un attimo. Però blocchi davvero la
maggior parte degli utonti.
Fra

maggior parte degli utonti.
Bhe... un attimo, proprio non direi. Debuggare (nel senso di usare un
debugger, per eseguirla, così da vedere le istruzioni in LM)
un'applicazione Windows è una vera avventura. Lo faccio spesso, per le
mie applicazioni in C++, quando succedono "cose strane". Pur avendo
anche i sorgenti, non sempre se ne viene a capo.
Ci sono alcuni suggerimenti utili, per rendere più sicuro il codice.
parlo del C++, ma si può estendere ad altri linguaggi.  Il primo e più
semplice è quello di non scrivere la funzione che controlla la chiave
come funzione, ma di usare una macro oppure accertarsi che sia una
funzione inline di una classe. Chiamando la "funzione" da più punti
(ad esempio: prima di ogni stampa) si otterrà che il codice che
controlla la chiave è "spalmato" in tutto l'exe. La "funzione" poi non
dovrebbe restituire un valore (true/false, ad esempio) ma andare a
modificare alcune variabili globali, indispensabili al funzionamento
del programma. Si mette poi un bel timer (o analoghi meccanismi) che,
periodicamente, controllano i valori e terminano il programma, se la
chiave manca. Ovviamente, il programma senza chiave non deve
distruggere o invalidare i dati dell'utente...
Se si lavora con linguaggi interpretati, si può pensare di mettere (o
duplicare!) il codice di verifica della chiave in una Dll esterna.
Con questi ed altri "trucchetti", nessuno spenderà il tempo che serve
per cercare di sproteggere l'applicazione... e non avrà alcuna
garanzia di successo. Potrebbe costare meno comprarsi il pacchetto.
Caso per caso, si dovrebbe anche valutare l'ipotesi di non proteggere
affatto l'applicazione. Questo è fattibile, se il guadagno deriva più
dall'assistenza/manutenzione, che non dalla vendita stessa. Non dico
OpenSource o freeware, ma licenze d'uso vendute regolarmente, senza
però proteggerle (non credo sia il tuo caso, comunque).
Stefano

 garanzia di successo. Potrebbe costare meno comprarsi il pacchetto.
Non avra' alcuna garanzia di successo? IMHO, in quel caso potrebbe
essere conveniente fare un po' di reverse engineering e agire
direttamente sul driver della chiave per simulare la sua presenza,
mantenendo inalterato applicativo e librerie...
bye G.L.

 mantenendo inalterato applicativo e librerie...
In ambito di grande distribuzione (videogiochi e software) NESSUNA
protezione è durata più di due giorni. E parlo di tecnologie costosissime.
Fra

 informatico ?
Dipende. Se trova su emule il crack non ha bisogno di nulla di 
particolare, come ogni altro software. Se non lo trova allora ha bisogno 
di fare debug, non è una operazione che richiede una particolare scienza 
ma non è alla portata di tutti.

 resistenza alla pirateria rispetto all'uso del solo file cifrato ?
Al di la del fatto che io sono abbastanza contrario alle chiavi
hardware - che, quando le abbiamo usate, abbiamo avuto casini
inenarrabili di compatibilità con altri software che usavano altre
chiavi - , parti dal principio che non esiste un software a prova di
cracker. Poniti un altro quesito: qual'è il destinatario medio del tuo
software? Se la risposta è un contabile o anche un utente evoluto, il
livello di protezione che hai è del 100%; certo, ovvio che puoi trovare
chi ha l'amico che sa come evitare la tua protezione, ma l'amico deve
essere parecchio evoluto, come informatico. Io scrivo applicazioni
ormai da vent'anni (sigh! :( ), ma non avendo avuto mai il piacere di
affrontare assembly o linguaggio macchina, non saprei nemmeno da dove
iniziare.
-- 
Ciao!
Luca

 protezione č durata piů di due giorni. E parlo di tecnologie costosissime.
E' risaputo. :-) BTW, qua si parlava di applicativi di non larghissima
distribuzione/diffusione.
bye G.L.

mantenendo inalterato applicativo e librerie...
Per fortuna le chiavi più moderne utilizzano algoritmi di crittografia
"interni", implementati nell'hardware (per quanto si vede
dall'esterno, almeno). Un driver che simuli la chiave dovrebbe
decrittare i dati forniti dall'applicativo, simulando gli algoritmi
interni della chiave... o semplicemente con associazioni pacchetto di
input<->pacchetto di output. Basterebbe generare pacchetti casuali di
dati, da far decrittare alla chiave, per rendere difficoltosa la
scrittura di un driver adeguato. Se poi l'applicativo è abbastanza
furbo da non "bruciarsi" subito tutti i pacchetti di dati da
decrittare... potresti riuscire a realizzare un driver che funziona
per alcuni giorni... o mesi... e poi fallisce. Passeresti la vita ad
inseguire i pacchetti... ;)))
"Fare un po' di reverse engineering" non è poi così facile, come si
crede. Devi provarci, per capire cosa significa.
Stefano

 crede. Devi provarci, per capire cosa significa.
Lo so benissimo, ma e' la cosa che tu hai sollevato riguardo
l'appicativo, per far si' di sproteggerlo...  :-)
bye G.L.

 distribuzione/diffusione.
Quindi gli investimenti per la protezione sono molto minori. Quindi
se te lo vogliono bucare te lo bucano in quattro ore :-)
Fra


sicuramente sei maggiormente protetto. Per craccare la chiave ci vuole
di più di un esperto informatico e quindi se il tuo programma non
raggiunge una estesa distribuzione tale da far gola a qualche
bravissimo cracker (ne sono pochi)  puoi dormire sonni tranquilli.
dovresti usare qualche precauzione nel codice... tipo dei controlli in
più punti e magari dei controlli Polimorfici nel tempo