Newsgroup: it.comp.lang.visual-basic
Titolo: [OT?] Identificativo macchina per protezioni software

Ho letto i vari articoli relativi ai numeri di serie (processore, HD,
schede, etc.), ma mi pare di aver capito che non ci sia un modo certo per
"riconoscere" una macchina o un HD, contando sulla certa esistenza e
univocità di determinate informazioni.
Mi piacerebbe se si potesse, al solo fine di trovare un metodo di protezione
software valido, raggruppare qui le varie idee, con un'unica regola: "Devono
essere applicabili sempre, su ogni macchina e/o versione di Win."
Comincio io:
Lavoro sulla data e ora di creazione di un certo file, camuffo
abbondantemente il tutto con l'anagrafica dell'utente e deposito nei miei
files per effettuare i controlli ogni volta. Funziona bene e, salvo
craccando il software (ma questo credo sia un problema di ogni metodo), è
piuttosto sicuro. C'è però un grosso svantaggio: Se l'utente chiama e dice
"ho cambiato il disco (o il PC)", non c'è modo di sapere se sta davvero
sostituendo dell'hardware o ... se ci sta provando ad autorizzare un'altra
macchina. E' pur vero che le mie ri-abilitazioni (telefoniche sia per
comodità che per distanza, io non vedo nemmeno alcuni miei utenti) sono
annuali e quindi non potrà chiedermi, fra un anno, di riabilitare due
macchine (avendo pagato la licenza per una sola), ma ... se ripete il
giochetto e mi dice qualcosa della serie "ho dovuto riformattare tutto", "è
entrato un fulmine", "un incendio in azienda", "mia moglie mi ha buttato il
PC dal balcone"?
Grazie a tutti.

 wrote in message
news:SKOJ8.868$t47....@twister1.libero.it...

Io invece stavo cercando il modo di leggere il numero di serie di un cd
vergine in modo da verificarlo di tanto in tanto. Sembra però, da alcune
prove che ho fatto, che cambi ad ogni masterizzazione (il che è un bene nel
caso di copia, ma pultroppo non si può sapere prima della masterizzazione
del software)..
Non puoi affidarti ad una chiave ardware usb (anche se sono aggirabili)?

 Non puoi affidarti ad una chiave ardware usb (anche se sono aggirabili)?
La mia protezione software ce l'ho, volevo solo migliorarla applicando
qualche nuova idea. Le chiavi hardware, a parte i costi e i problemi che
possono creare con le altre periferiche collegate (compatibilità,
trasparenza, etc.), sono anche (volendo, ovviamente) duplicabili. Le ho
escluse.

 escluse.
Qualsiasi attacco viene sempre fatto al software.
Nessun pazzo tenterebbe di 'duplicare' una chiave hardware.
Perché?
Perché qualsiasi hw ha un costo, ed il principio di chi cerca di
sproteggere è avere un 'costo zero'.
Sìccapìto?
Le chiavi hw si sproteggono modificando la libreria che le pilota (il
driver), oppure evitando che il prg ne controlli l'esistenza.
Qualsiasi cosa ti inventi c'è sempre qualcuno che può comprendere cosa
fa il tuo codice, semplicemente leggendo con un disassemblatore (o un
debugger) il codice macchina. Se scrivi qualcosa di veramente geniale
abbandona l'idea della protezione, tanto dopo 2 ore ci sarà il crack
nella rete.
Altrimenti, se vuoi rompere le balle ai tuoi clienti basta un controllo
sull'hardware, sui dati di registrazione, su un codice creato 'on the
fly' dal programma. Ricorda comunque che rompi solo a chi paga... Chi
vuole copiare copierà ugualmente.
-> GbC
http://www.gbcweb.com
F53C7B7263B8B09CCFE6AEBEFD97168F58B0C450

 ha scritto nel messaggio
news:ad8mqn$fbr$1...@nntp.weblinea.it...

Ho provato a seguire la tua stessa strada, con insuccesso :_-(.
Tutto ciò secondo me è comprensibile, un supporto non formattato non ha
numero si volome ecc. quindi...
Altra possibilità: su ogni CD esiste un codice a barre univoco (molto
probabilmente) e visto che viene apposto in fase di creazione e non di
masterizzazione è quasi inattaccabile (Escludendo crack ecc. che bypassano
ogni cosa): PROBLEMA: i lettori CD che leggono il codice a barre costano in
media 2-3-4-5 volte tanto un lettore CD normale, penso sia difficile
spiegare al cliente che il mio programma costa 10 ?, ma per usarlo deve
spenderne 350 per comprarsi il lettore CD giusto.
Cmq se vuoi realizzare quel tipo di protezione crei un cd multisessione con
qualche file anche a caso.., leggi il numero seriale assegnato, ricompili,
masterizzi in un altra sessione delle stesso cd i nuovi file e chiudi il cd
impedendo altre scritture, scomodo... e mi pare che CloneCD copi anche il
numero seriale.
Ciao
    Sharkman

 wrote in message
news:mtRJ8.2014$t47....@twister1.libero.it...

Un'altra idea potrebbe essere Internet (anche se non corrisponde ai criteri
da te impostati)
che potrebbe coadiuvare la tua protezione. Non dovrebbe essere un vincolo
necessario
al funzionamento del tuo programma ma se questo, di tanto in tanto, verifica
l'attivazione su un tuo sito...
Ad esempio:
hai la tua stringa ricavata dal seriale HD, processore ecc..
nel tuo programma inserisci un seriale o un codice di attivazione telefonico
e personale
ogni tanto vai sul tuo sito e confronti se il codice di attivazione è
presente su due macchine.
Ovviamente il codice di attivazione dovrà avere una parte fissa (codice
cliente).
Certo la cosa ha del particolare:
e se l'utente non ha internet su quella macchina?
e se si collega ad internet quando il programma è chiuso?
Per la seconda si potrebbe pensare a un TSR ma per laprima non c'è speranza.


Già provato. Alla successiva sessione cambia il numero seriale.
Comunque è ovvio che c'è sempre un crack dietro l'angolo.
Più che altro si cerca di rendere la vita difficile a chi il software
non lo paga.

vuole copiare copierà ugualmente.
Sintetico ed esaustivo allo stesso tempo :-)
Da scolpire per i posteri che avanzeranno nuovamente questa domanda.
La inserisco nelle FAQ.
-- 
ciao, hal

 >vuole copiare copierà ugualmente.
Oppure si tratterebbe di criptare l'exe, e fare in modo che in runtime
(all'avvio) si decripti da solo. Ovviamente da nessuna parte del codice ci
deve essere meorizzata la chiave per il crypt/decrypt. Questo perchè
altrimenti con una ricerca si potrebbe venire a conoscenza di cosa è usato e
quindi far fare un passo avanti a chi vuole decriptare.
Poi per quanto riguarda la procedura di crypting, crearne una che sia
l'ammasso di almeno altre 5 procedure, in modo da rendere impossibile il
tentativo di decrypt.
Però chi cracca a volte ruba la procedura di crypting/decrypting in modo da
riutilizzarla a proprio piacere, senza per questo doversi scervellare per
capire come decriptare.
Quindi ora la questione è:
    Il criptaggio dell'eseguibile potrebbe andare bene, in modo da aver
sempre pisogno della chiave per decriptarlo;
    Questione numero 1: Come fare ad avere una chiave che l'utente stesso
non debba far girare? Cioè bisognerebbe creare una chiave che l'utente
stesso debba voler conservare (chessò, dati privati, codice della carta di
credito, NOMEUTENTE seguito da GAY... ecc)
    Questione numero 2: Come fare in modo che la procedura di decrypt non
vada rubata dai piratini? Chiamate alle librerie? Controllo del nome
dell'eseguibile in corso? Dimensione? Tutti CMP e JMP che possono essere
manipolati... forse si potrebbe usare anche la dimensione del file e il nome
dello stesso da unire alla chiave in modo che vengano utilizzate per forza
per decriptare.
Altro non so dire... forse ho dato un'idea e qualcuno potrà farne tesoro
meglio di me.

 La inserisco nelle FAQ.
Non la penso come voi. Un software gestionale con date contabili/fiscali
"sensibili" (quindi oggetto di verifica rispetto alla scadenza) non è
certamente utilizzabile da chi non ha avuto un minimo di addestramento,
anche indiretto. Lo so, quindi, che comunque un contatto ci deve essere.
Il problema infatti non è questo (io distribuisco gratuitamente il mio
software in forma demo, ovvero limitata solo nel numero dei records
gestibili, non nelle funzionalità, e, anzi, so che nel 50% dei casi, chi ci
spende almeno 3/4 ore sopra poi ... "lo vuole"), ma di chi ha regolarmente
pagato la licenza per una macchina e ne vuol fare un'altra senza pagare,
oppure che ha pagato per "n" postazioni collegate al server e ne vuol fare
"n+1", o, ancora, di chi non ha pagato una certa opzione/modulo (che so? le
fatture estero oppure la gestione della produzione) e vuole usufruirne
gratis.
Quindi: non voglio proteggere le copie illegali (come detto, sono il primo a
diffonderle gratuitamente e autorizzo esplicitamente a farlo!), ma desidero
controllare gli abusi non pagati di chi ha già pagato e vuole avere più di
quanto ha diritto.

 ha scritto nel messaggio
news:pB2K8.4037$QT3.1...@twister2.libero.it...

Il tuo problema è ben noto e di difficile 'definitiva' soluzione anche
perchè
esiste sempre una scuola di pensiero che dice che è pur vero che il software
è tuo, ma i dati sono del cliente....
Propri mentre scrivo mi è venuta in mente una idea 'diabolica'
attivabile con pochi presupposti:
    una certa frequenza di aggiornamento del software da parte tua
    la memorizzazione dei codici di abilitazione che rilasci
premesso cio' basterebbe che tu inserissi una black-list dei codici obsoleti
in ogni aggiornamento in modo da poter disabilitare le installazioni
sospette
mi spiego meglio :
il cliente "ABC" acquista la licenza e ti chiede il codice di abilitazione
che tu memorizzi come codice attivo nel tuo db
successivamente "ABC" formatta il disco e chiede un nuovo codice
tu lo rilasci , lo memorizzi nel db, ma contemporaneamente segni
come non attivo il precedente
con il primo aggiornamento che invierai al cliente una routine confronterà
il codice di attivazione presente con quelli leciti e quindi si installerà o
disabiliterà l'installazione del cliente
Risultati: se il cliente ha veramente formattato... nessun problema
              se il cliente ha fatto il furbo sarà punito....
ciao

 >

acia, grazie. Anche se già prevedo lo storico delle abilitazioni, ragionerò
meglio su quanto proponi, in particolare relativamente agli aggiornamenti.
Ma c'è anche la situazione per la quale "salta l'abilitazione", pur lecita.
Per esempio uno spostamento delle cartelle (entro o fuori dal disco) e un
loro ripristino (con data e ora che sono chiaramente diverse). In tal caso
lo storico permane (non si è formattato il disco) e si crea una situazione
di incongruenza: storico ok, ma abilitazione non corretta. E' un vero
labirinto!


Visto l'interesse.... cerco di essere piu' chiaro e chiarire il tuo
dubbio...
sei tu come distributore del software che dei tenere lo storico delle
abilitazioni da cui estrarre quelle sostituite per qualsiasi ragione, il
cliente avrà nel tuo database sempre e solo un codice attivo
da questo database estrarrai ad ogni rilascio di aggiornamento la lista dei
codici annullati che inserirai nel codice del programma che gestiste
l'installazione degli aggiornamenti presso il cliente il quale tr l'altro se
il codice sulla macchina del cliente fa parte della lista ...
la logica e' quella degli ultimi service pack di M$ anche se in quel caso
viene confrontato il numero di licenza e non il codice di abilitazione...

 viene confrontato il numero di licenza e non il codice di abilitazione...
Ok , questo era chiaro, ma un minimo di controllo sulla macchina del cliente
ci deve essere, altrimenti chiunque può installare (su qualunque macchina)
non solo il Setup iniziale, ma anche gli aggiornamenti. Il problema che
resta è: Da dove rilevo il codice assegnato a un cliente per confrontarlo
con quelli "leciti" sul mio db e/o nei programmi di aggiornamento?
Evidentemente da qualcosa depositato sulla macchina del cliente. Ma, e
torniamo a bomba, se questa macchina è stata riformattata? O è davvero
nuova? Oppure è ancora la vecchia, ma quel codicillo è saltato?

è tuo, ma i dati sono del cliente....
C'e' chi ha vinto delle cause giudiziare per questo ;-)
-- 
ciao, hal


infatti occorre trovare gli strumenti adatti:
e.g. l'abilitazione deve proteggere solo i programmi di caricamento/aggiunta
e le elaborazioni diciamo correnti
ma deve consentire in qualunque situazione di 'consultare' lo storico

 ha scritto nel messaggio
news:Ac4K8.4431$t47.1...@twister1.libero.it...

quando attivi il programma con il codice di abilitazione lo scriverai da
qualche parte no? e se l'installazione e' nuova prima di caricare
'aggiornamenti' richiedi di abilitarla
e quindi scrivi il codicillo

 univocità di determinate informazioni.
[cut]
Ci provo....
Supponiamo che il programma sia gestionale....l'utente ogni tanto deve
salvare i dati....nel salvataggio inserisci qualche routine che tenga conto
del seriale del processore....del seriale del hd ..o del seriale di quel che
vuoi tu.
Se la macchina dell'utente si "fonde " non fonde mai tutto,  parte il
processore o l'hd o l'alimentatore o la scheda madre.
Se l'utente ti chiede una copia del cd la copia dovrebbe controllare che il
ripristino dei salvataggi abbia un dato che tu hai inserito nei dati di
salvataggio.
Se l'utente fa la prima installazione ti crei una chiave di avvio che
risieda su qualche sito ftp il , tuo o qualche altro...la chiave avrà una
durata limitata nel tempo..dopo di che la cancelli..., certo l'utente
potrebbe farsi una copia della chiave, ma potresti fare in modo che la
chiave sia codificata con la data.....
Oppure....questo CD si autodistruggerà tra 5 secondi..........
(che bella la prima serie di Mission Impossible)
PS.
Questo post è stao inviato dopo 5 biccheri di grappa friulana non mi assumo
responsabilità...e se proprio debbo assumermele ....lapidatemi
Babau(Emanuele)

(all'avvio) si decripti da solo. Ovviamente da nessuna parte del codice 
Inutile... ci dovrà anche essere il codice per decriptarlo e i pirati
(non piratini) partiranno da lì per poi analizzarne il comportamento
una volta in memoria! ;-)
-- 
Visita il sito comune del NG: 
http://www.it-lang-vb.net
Visit: 
http://www.hardwaretips.com