Newsgroup: it.comp.lang.visual-basic
Titolo: Un sistema per impedire la copia del software su un altro pc

Salve a tutti.
Mi rivolgo a voi perchè ho provato a cercare su google, ma non so nemmeno
come dovrei formulare la mia richiesta :D
Pertanto, dato che qualcuno di voi avrà sicuramente avuto a che fare con il
problema, ne sono certo, chiedo a voi un aiuto per risolverlo.
Se ho sviluppato un software e voglio impedire che si installi su un altro
pc senza il mio consenso, come potrei fare?
So perfettamente che non c'è nulla di "imbattibile", ma penso che per il
costo irrisorio del mio software e per la mancata esperienza in questo
campo del mio cliente :) qualcosa basato sul semplice seriale dell'hard
disk potrebbe bastare.
Oppure qualsiasi altra tecnica va bene, basta che impedisca il
funzionamento su un altro pc per il quale io non ho fornito
l'autorizzazione.
Vi sarò immensamente grato se riusciste ad aiutarmi.
Grazie mille a tutti.

 l'autorizzazione.
Fatti dare il nome del pc,
quindi all'attivazione dell'eseguibile, verifica il nome, se ok si attiva.
Come controindicazione, possibile avere piů pc con lo stesso nome, ma se 
lavorano in rete il nome deve essere univoco.
Ave
giuseppeD
---
CCR 

Come soluzione potrebbe andare bene, ma non credo che il mio cliente sia
capace di darmi il nome corretto.
E se poi si cambia nome al pc il mio programma non funziona più?
Penso debba basarsi su unìinformazione più legata all'hardware che al
software, ad esempio l'hd serial, oppure quello del processore...
Sai indicarmi qualche esempio di codice?
Grazie mille!

 wrote in news:12cbb5v90mhb6.zu5rxyid3doq
$.
d...@40tude.net
:

sul sitocomune di it.comp.appl.access c'era una routine che verificava 
proprio il seriale del disco.
il codice era vba, ma non è difficile farlo girare in un progetto vb.
l'indirizzo:
http://www.sitocomune.com/
-- 
+-------
| Paolo opg
|
| janickg ( at ) hotmail ( dot ) com
| (fake address in reply-to field!)
+-------

 come dovrei formulare la mia richiesta :D
Avevo postato quwesto link 15 giorni fa...
http://www.planet-source-code.com/vb/scripts/ShowCode.asp?txtCodeId=48926&lngWId=1
ciao
	maxx

 software, ad esempio l'hd serial, oppure quello del processore...
Per quello che valgono questo genere di protezioni, trovo sia molto meno 
frequente che venga cambiato il nome del PC in rete piuttosto che l'hardware 
(basta un format e il seriale dell'hard disk cambia), quindi e' piu' facile 
che il cliente ti "stressi" meno, evitando di chiedere nuovi codici ogni 
volta.
Ciao
-- 
Luca Dormio - 
luca....@tin.it
________________________________
"Marty, non stai ragionando in maniera quadridimensionale"
Dr. Emmett L. Brown 

Ecco, questo è proprio quello che mi serviva!
Anche se dovrò faticare un bel po per capire come funziona ;)

 registrazione in funzione del nome recuperato e ti fai comunicare quello.
Già, ma questo punto (generare codice di registrazione in funzione del nome
del computer) mi è molto oscuro...
Ad ogni modo tu come hai risolto questo genere di problemi?


Il sisetma migliore rimane sempre quello di "WORMARE" il software....
ossia fatti un oiccolo modulo che si collega al tuo (sitoweb pc quello che
vuoi tu)
Ogni distribuzione ha al suo interno un nome criptato blowfish diverso dagli
altri
[
 apro una parentesi
io son maniaco del blowfish perchè si trovano implementazioni in  vb
è veloce
e  che io sappia non è stato ancora crakkato ne "rotto"
]
criptando con la pw particolare di ogni distribuzione ottieni delle info dal
pc ospite
che so una chiave del registro + il MAC della scheda di rete etc etc
In remoto il tuo sw SEMPRE attivo...controllerà se a cio corrisponde una
licenza valida
SE NON corrisponde manda un segnale che disattiva la copia del cliente e fa
comparire
"problemi tecnici conttatare la sw house"
se è un falso allarme riabiliti tutto
SVANTAGGI:
devi informare nella licenza il cliente con la privacy non si scherza
e non devi raccogliere dati oltre la licenza che il cliente ha firmato
SE usi la porta 80...non ti da noia neanche un Firewall!
Buon lavoro

 e non devi raccogliere dati oltre la licenza che il cliente ha firmato
Questo e' il meno, secondo me... tra gli svantaggi vedo invece il fatto il 
cliente deve sempre essere dotato di connessione, ma soprattutto tu azienza 
devi garantire un servizio sempre "up", che richiede un impegno e anche un 
certo investimento di risorse.
Per alcune tipologie di applicazioni, che gia' per natura devono accedere 
alla rete puo' non essere un problema, ma non c'e' cosa che fa piu' 
incacchiare di un programma desktop che nulla ha da spartire con Internet, e 
che non parte perche' da una parte o dall'altra non c'e' connessione...


 che non parte perche' da una parte o dall'altra non c'e' connessione...
Quoto. Io ho trovato una soluzione particolare che però vale nel mio 
caso e non necessariamente con gli altri.
Il codice di sblocco è un misto tra i dati dell'azienda che lo usa, il 
seriale dell'hd e data-ora dell'installazione.
Se i cliente formatta il pc mi deve richiamare, ma sono *SICURO* che il 
cliente non me lo copia.
Per Gestione Ottica invece ho reso la cosa meno incasinata (legge solo 
il seriale dell'hd e i dati dell'azienda) ma con una garanzia dalla mia 
parte. Se il cliente riesce in qualche modo a duplicare il sw su 2 pc 
separati, questi non saranno in grado di comunicarsi i dati inerenti 
magazzino, fatturazione, messenger ecc... questo perchè per stabilire 
una connessione tra i due pc bisogna passare per forza dal mio server 
(il quale controlla che gli utenti siano abilitati alla comunicazione).
bye
-- 
Gestione Ottica - Gestionale per Ottici e Programmi Gratuiti su:
http://www.nicolaottomano.it
Sinapsi Antispam. Antispam Gratuito.
http://www.nicolaottomano.it/sinapsi.htm
email spamtrap: 
spam...@nicolaottomano.it

Ecco, in effetti la soluzione di OttomanoNicola mi sembra la più adatta,
anche perchè il software che ho sviluppato è una semplicissima gestione
magazzino e soprattutto perchè io non sono affatto un'azienda e non vale la
pena implementare l'ottima soluzione di wodka40°.
Premesso ciò, ho pensato a questa semplicissima tecnica:
rilevo da software il seriale dell'hard disk, lo unisco in qualche modo con
la data di installazione (anche se non so ancora come si faccia a
recuperare, forse è più facile recuperare la data del primo avvio del
programma) e mi faccio comunicare ciò che ne esce.
Da quello che ricevo, mediante un algoritmo qualsiasi, genero una chiave
che inserita nel software dovrà essere riconvertita a seriale hd e data di
installazione, e se corrispondono allora il software si attiva.
Bene. Facile a dirsi....
Come faccio ad unire seriale e data? Ho pensato di inserire anno
all'inizio, mese a metà e giorno alla fine della stringa del seriale
dell'hard disk. Ciò è facilmente invertibile e quindi sono a posto.
Ok, adesso come fare a "crittografare" questa informazione?
Ripeto, non necessito di utilizzare algoritmi come DES, o Blowfish per 2
semplici motivi: 
-il livello del mio software (e del mio cliente ;)) non richiede tale
livello di sicurezza.
-non ho il tempo di capire come funzionano DES e blowfish, e non ho voglia
di incollare i progetti già pronti nel mio software senza sapere come
agiscono, cosa che non credo abbia mai fatto chi frequenta questo ng :)
Qualcuno che ha incontrato il mio stesso problema, come ad esempio
OttomanoNicola (anche se non credo voglia svelarmi la sua soluzione ;)),
può suggerirmi come "criptare" ciò che ricevo dal cliente, oppure dove
reperire informazioni a riguardo?
Ringrazio sentitamente coloro che mi aiuteranno ;)

 Ciao
25 Euro su Aruba!
UN file MDB....
se sei paranoico...altri 25 euro su un altro provider e il tuo sw-ino che se
non risponde un URL va su un altro....
(Blowfish esiste anche in versione ASP)
Si collega ( a scelta):
a) Ogni tanto....
b)Quando installi
c)Al termine licenza
d)....se sei paranoico...o vedi uno sguardo furbino nel cliente (a me
succede...forse voi lavorate per grandi serie aziende...ed io lavorando
invece per il "volgo"...trovo spesso quel lampo nel cliente.....[i
commercialisti sono i peggio!!!! :-) ] )
se sei paranoico dicevo....ad ogni lancio dell'installazione cerca una conn
se la trova esegue il test!
Considerazioni:
1) Per un programma che costa 200 Euro il gioco non  vale la candela!
Sbagliato!
200 euro "one spot" per un cliente....avete ragione!
20 Sw da 200 Euro già cambia!(e mi fermo a queste poche cifre)...ed in
questo modo uno non impazza a gestire le licenze....sono in una tabella mdb
con un bel flagghettino "Falla esplodere" SI/NO
2) "Cavolo devo avere una conn ad internet"
Beh...per costare poco...investo in un po di pubblicità...ma non mi metto a
portare ed installare il cd dal cliente!
Se la scarica da internet...la prova come trial.....e poi la converte.
Aggiornamenti e tutto ...li becca da li!
Non gli riesce?...ok ...però paga l'assistenza!
L'importante è essere chiari con il cliente fin da subito. Se il cliente
"sa" che deve beccare da internet o che ha un assistenza telefonica o altro
a pagamento
.. nel 99% dei casi non ci son storie (lo scassabiiiiip c'è sempre)
Un programma da 5000 Euro o più sicuramente avrà da me un altra
considerazione e fornirò all'acquirente anche un elegante manuale in
similpelle di pvc...
per gli altri...mi dispiace...un bel pdf da stampare a spese del cliente!
Saluti!



Beh, il mio software costa poco meno di 200 euro, ed č sicuramente onespot
;)
Diciamo che č piů un "favore remunerato" piuttosto che un software vero e
proprio ;)

 In data Mon, 11 Apr 2005 08:53:58 +0200, Wodka40° ha scritto:
ho buttato giu uno schema di massima!
(tanto lo dovevo fare anche per altre ragioni)
estremamente DIDATTICO....lo puoi compattare ed eliminare un sacco di
passaggi e variabili...una volta capito che fa!
Si fonda tutto sullo XOR...come gran parte della criptografia...
LO XOR ha la proprietà di
DATO XOR CHIAVE= schifezza
schifezza XOR CHIAVE= DATO
cosa fa sto codice....
prende il seriale dll'HD e lo cripta con una PW precablata.....
poi questo dato lo decripta e ti ritorna il seriale dell'HD in chiaro.
se fai l'incontrario non è quello che volevi ottenere?
tanto il sistema è abbastanza modulare (tira fuori dai command il codice e
mettilo in function...casomai!)
Come non gli da noia se PW e seriale son di lunghezze diverse...."filla" lui
la pw secondo uno schema di ripetizione ciclica...ma nulla toglie di farne
uno diverso.
Come lo XOR viene fatto convertento in byte....byte xor byte...e
trasmettendo un codice esadecimale che viene poi smontato e decriptato....
SVANTAGGI:
devi metterci tu i vari ON ERROR etc etc.....l'ho buttato giù alla svelta
stamani incazzato fradicio perchè il vento m'ha strappato l'antenna tv e non
trovo l'antennista!
è un po lungo ...non lo posto qui.....ma lo metto sul mio sito web "All
purpose"
spetta che ti dico dove.....

 spetta che ti dico dove.....
che Aruba sta riavviando il server!!!!!
:-)

 che so una chiave del registro + il MAC della scheda di rete etc etc
La cosa è perfetta.
Mi permetto solo di consigliare di definire questa combinazione di codici 
una-tantum, scriverla criptata da qualche parte nel registro, e riutilizzare 
sempre quella.
In questo modo, è possibile aggiungere qualche carattere random, aumentando 
la complessità della cosa.
Il ricalcolo del codice ogni volta, genera immani problemi quando i dati di 
input variano (il seriale degli hd non cambia, ma ha la sfiga che i pc di 
una stessa azienda spesso hanno hd con lo stesso seriale, e quelli vecchi 
hanno seriale 0, mentre il MAC della scheda di rete è un casino quando su 
una macchina ci sono più schede, perchè l'enumerazione delle stesse non è 
garantita identica ad ogni riavvio, e puoi trovarti oggi a leggere un Mac e 
domani un altro).
Aggiungendo a questa roba un po' di char random, ottieni una chiave con cui 
si può fare ciò che si vuole.
La contropartita è che se qualcuno scopre dove si trova la chiave del 
registro, può divulgare la cosa e chiunque può crackare il sw forzando tale 
chiave nel proprio registro.
D'altro canto, se esiste qualcosa vivo on-line, un semplice conteggio degli 
accessi da parte di una determinata chiave rende evidente un'eventuale 
clonazione dell'installazione.
Ciao
Alberto
-- 
"C'è un Calvelli dentro ognuno di noi" (cit.) 


www.villaceleste.it
sezione "spippolando e programmando"
Capitolo "Spippolamenti in VB6"

 reperire informazioni a riguardo?
Mah, non è che ci siano delle cose particolarmente incasinate.
TI puoi creare un tuo algoritmo (come ad esempio la somma della data al 
seriale dell'hd). Poi puoi sommargli (o moltiplicare, fare una XOR e 
quant'altro) una parola chiave a tuo piacimento ed infine fare un bell 
MD5 di ciò che hai.
Dall'MD5 puoi star sicuro che non si risale al valore di partenza.


"problemi tecnici conttatare la sw house"
Wodka,
potresti aggiungere qualche dettaglio in piů su come implementare
questo passaggio (web -> disattiva SW)? - Anche a grandi linee.
Ciao


[CUT]
Grazie per la risposta.
Premetto che non ho mai usato winsock.
Mi sembra di capire che questa tua (interessante) soluzione preveda
la presenza in remoto di un applicazione server che dialoga via
winsock con il client su una data porta (e magari via UDT).
Dal punto di vista pratico, perň, (corregimi se sbaglio),
l'applicazione in ascolto dovrebbe girare su server dedicato.
Per cui sarebbe inapplicabile se si avesse a disposizione solo uno
spazio web su un server non dedicato, quindi senza la possibilitŕ di
installare nulla.
Io pensavo a un qualche tipo di soluzione che preveda solo ASP.
Cosa si potrebbe fare in questo caso?
Ciao


Beh devi avere una porta accessibile e aperta....potresti anche farla sulla
80 ma č un po casinosa!
a grandi linee puoi fare in 2(3) modi:
1) Tieni sempre in ascolto il tuo "worm" e aspetti la famosa
"Ł&/$ŁRŁ&R/Ł$/&" che decriptata diventa un "BOOM"
Svantaggi.....beh con un netstat l'utonto spippolatore vede che qualcosa
ascolta su quella porta.....consuma risorse
2) Se invio all'atto dell'installazione la richiesta di conferma...mi
aspetto entro 30 secondi, 1 minuto, quello che vuoi una risposta
(sempre il solito "Ł&/$ŁRŁ&R/Ł$/&" )...se non arrivo....continuo a
dichiarare la copia come trial!...se vuole riprova!
Quindi basta attivare il winsock per 1 minuto.
Se l'utonto installa per piů di una volta....in remoto il mio mdb se ne
accorge!...
(3)Soluzione ibrida.....ogni 15 giorni...1 mese...1 anno... controlla
qualcosa ed invia ed aspetta risposta
Considerazioni....
il wodkino si fida molto delle linee telefoniche italiane...ed ha un passato
da lamerone da sbarco (per alcune cose lo č ancora)
quindi:
a) NO TCP SI UDP
b) IF Arrivato="BOOM" then
        msgbox "Errore tecnico irreversibile contattare software house al
numero 1112223334455"
        end
    end if
o il piů cattivo....
    if arrivato="BOOM" then
        msgbox "Hijo de Puta non toccarmi"
        end
    end if
c) Tutto crolla davanti ad un firewall ben programmato certo!
Ho bisogno di poter mandare e ricevere dati!
Non si implementano tecniche di lamerone trolloso!!!
Ma quello che mi serve per controllare la licenza mi serve anche per
segnalare update e ricevere aggiornamenti!
Quindi per l'utonto onesto...č un plus meritevole!

 Io pensavo a un qualche tipo di soluzione che preveda solo ASP.
Non cambia niente.
Wodka suggeriva una logica di funzionamento, non espressamente una o l'altra 
delle tecnologie con cui realizzare i moduli.
E la parte server può benissimo essere in Asp.


E la parte server può benissimo essere in Asp.
Ecco, appunto. Mi interessava capire in che modo implementare la cosa
in quest'ultimo scenario (idee, links ecc.). Per ora mi viene in testa
soltanto qualcosa fatto con stream ado e xml.
Dico anche la mia sul resto. Sto sperimentando una soluzione che
prevede l'acquisizione di un max di 3 parametri:
Seriale HD, MAC Address e Seriale Bios.
(NB. Per seriale HD intendo quello di fabbrica).
Anche considerata la diversità di configurazione dei target, direi
che almeno nel 90% dei casi riesci a beccarli tutti e tre.
La stringa di licenza che contiene questi parametri è criptata su
file.
Il programma all'avvio legge il file, acquisisce i parametri HW,
confronta e, se almeno uno dei parametri coincide, va avanti.
In ultima analisi, però, c'è da dire che quasi mai ci si interessa
dell'algoritmo di criptazione per craccare un programma.
(non sono un esperto, riporto quello che si legge in giro)
Quello che di solito si va a cercare (con roba tipo SoftIce) è il
punto o i punti di uscita delle routines di validazione. Si cambia
un byte e il gioco è fatto.
Così facendo, però, si modifica anche il checksum dell'eseguibile, e
qui ritorno al discorso di partenza. Il controllo del checksum
potrebbe essere fatto (laddove possibile) via web.
Dopodichè mi si dirà che anche queste ultime istruzioni possono essere
bypassate. Questo è ovvio. Non esiste nulla che non possa essere
craccato. Quello che si può fare è solo cercare di rendere la cosa un
po' più complicata.
Ciao

> Non cambia niente.
sto completando un progettino che usa roba simile....se hai pazienza un
pochetto lo finisco
(roba di al massimo domani mattina....)
e poi lo metto online...se poi lo reputate interessante lo manderò al SC


Anticipazioni? ;)
PS. Ho provato or ora a usare le API Internet per fare sta cosa. A
prima vista sembra il modo piů semplice. Piazzi nel buffer il
Response.Write di una pagina ASP (il checksum della versione del prg,
magari criptato), e lo confronti con quello calcolato. 
Oppure il contrario: posti il checksum calcolato e il buffer conterrŕ
la risposta (vai avanti / ti sego). Devo perň riflettere sulle
(eventuali) controindicazioni.
Ciao

Wodka40° ha scritto:

Manda che pubblico.


bye
Che discorsi! E' ovvio. ;) 
Forse mi sono spiegato male. Il file contiene (criptati) i dati HW di
*quella* macchina, che vanno confrontati con quelli letti on-the-fly.
Copiare il file su un'altra macchina farebbe fallire il confronto.
En passant, lo faccio su file e non su registry, perche prevedo un
checksum anche del file stesso.
Nel mio caso, la cosa funzionerebbe così:
-La versione demo preleva i dati della macchina e crea una stringa
relativa a quella macchina.
-L'utente alla richiesta di registrazione copia/incolla la *sua*
stringa nel form di registrazione (pagina web)
-Il file di licenza, che fornisco in seguito insieme alla versione
licenziata, contiene gli stessi dati, criptati con chiave diversa.
-La versione *licenziata* legge da un lato il file, dall'altro i dati
HW di quella macchina ed effettua il confronto.
-Per prevenire il più possibile le richieste di nuove licenze in
seguito a cambiamenti HW (scassare un HD è all'ordine del giorno), mi
accontento che almeno uno dei valori coincida.
Ciao

 file.
Male, male male... Non devi mettere niente su file. Altrimenti l'utente 
prende il file e lo passa su un'altro pc.
Devi leggerli ogni volta e ogni volta devi calcolarti il codice di sblocco.
bye
