Licenza di valutazione del software [chiuso]

Question

La mia azienda sta cercando di iniziare a distribuire alcuni software che abbiamo sviluppato e vorrebbe poter consentire alle persone di provare il software prima di acquistarlo.Vorremmo anche assicurarci che non possa essere copiato e distribuito ai clienti dei nostri clienti.

Un modello che abbiamo visto è quello di legare una licenza a un indirizzo MAC in modo che il software funzioni solo su una macchina.

Quello che mi chiedo è: qual è un buon modo per generare una chiave di licenza con diverse informazioni incorporate, come la data di scadenza della licenza, l'indirizzo MAC e diverse restrizioni software?

Answer 1

Ti suggerirei di prendere le informazioni che desideri nella chiave, di eseguirne l'hashing con md5, quindi di prendere semplicemente i primi X caratteri (dove X è una lunghezza della chiave che ritieni gestibile).

Dal punto di vista crittografico, è tutt'altro che perfetto, ma questo è il tipo di area in cui vuoi fare il minimo sforzo per fermare un aggressore occasionale: qualsiasi cosa più rapidamente diventa un buco nero.

Oh, dovrei anche sottolineare che, se segui questa strada, ti consigliamo di fornire la data di scadenza (e qualsiasi altra informazione che potresti voler leggere tu stesso) in testo semplice (o leggermente offuscato) come parte della chiave. - L'md5 serve solo a impedire all'utente finale di modificare la data di scadenza per estendere la licenza.

La cosa più semplice sarebbe un file chiave come questo...

# License key for XYZZY
expiry-date=2009-01-01
other-info=blah
key=[md5 has of MAC address, expiry date, other-info]

Answer 2

Ho utilizzato sia FLEXlm di Macrovision (ex Globetrotter) che il più recente RLM di Reprise Software (a quanto ho capito, scritto dagli autori originali di FlexLM).Entrambi possono disattivare l'indirizzo MAC o un dongle fisico, possono essere bloccati sul nodo (legati a una sola macchina) o "mobile" (qualsiasi macchina autorizzata sulla rete può ottenere una licenza distribuita da un server di licenza centrale, fino a un numero massimo di copie ritirate simultaneamente determinato dall'importo pagato).Esistono diversi modi flessibili per configurarlo, comprese le date di scadenza, le singole funzionalità concesse in sublicenza, ecc.L'integrazione in un'applicazione non è molto difficile.Questi sono solo i due che ho usato, sono sicuro che ce ne sono altri che fanno altrettanto bene il lavoro.

Questi programmi possono essere facilmente violati, il che significa che sono noti exploit che consentono alle persone di aggirare la sicurezza dell'applicazione che li utilizza, tagliando le proprie licenze per falsificare il server delle licenze o semplicemente applicando patch al codice binario per aggirare il controllo della licenza ( essenzialmente sostituendo la chiamata della subroutine alla loro libreria con il codice che dice semplicemente "return 'true'".È più complicato di così, ma è proprio a questo che si riduce.Vedrai versioni crackate del tuo prodotto pubblicate su vari siti Warez.Può essere molto frustrante e demoralizzante, tanto più che spesso sono interessati a crackare per amore del cracking e non hanno nemmeno alcuna utilità per il tuo prodotto o conoscenza di cosa farne.(Questo è ovvio se si dispone di un programma sufficientemente specializzato.)

Per questo motivo, alcune persone diranno che dovresti scriverne uno tuo, magari anche cambiare frequentemente lo schema di crittografia.Ma non sono d'accordo.È vero che eseguire il proprio rollover significa che gli exploit noti contro FLEXlm o RLM non funzioneranno immediatamente per la tua applicazione.Tuttavia, a meno che tu non sia un esperto totale di questo tipo di sicurezza (che chiaramente non sei o non porresti la domanda), è molto probabile che nella tua inesperienza finirai per scrivere un sistema molto meno sicuro e più facilmente crackabile. sistema rispetto ai leader di mercato (per quanto deboli possano essere).

L'altro motivo per non lanciare il tuo è semplicemente che è un gioco senza fine del gatto col topo.È meglio per i tuoi clienti e le tue vendite dedicare il minimo sforzo alla sicurezza delle licenze e dedicare il tempo al debug o all'aggiunta di funzionalità.È necessario affrontare il sistema di licenze semplicemente come "mantenere oneste le persone oneste", ma senza impedire un crack determinato.Accetta il fatto che i cracker non avrebbero comunque pagato per il software.

Non tutti possono assumere questo tipo di atteggiamento zen.Alcune persone non riescono a dormire la notte sapendo che qualcuno da qualche parte riceve qualcosa in cambio di niente.Ma cerca di imparare ad affrontarlo.Non puoi fermare i pirati, ma puoi bilanciare tempo/sforzo/spese cercando di fermare tutta la pirateria con il miglioramento del tuo prodotto per gli utenti.Ricorda, a volte le applicazioni più piratate sono anche le più popolari e redditizie.Buona fortuna e dormi bene.

Answer 3

Abbiamo utilizzato il seguente algoritmo in la mia compagnia per anni senza un solo incidente.

1. Decidi i campi che desideri nel codice.Bit-pack il più possibile.Ad esempio, le date potrebbero essere "numero di giorni dal 2007" e quindi puoi farla franca con 16 bit.
2. Aggiungi un campo "checksum" aggiuntivo.(Vedrai perché tra un secondo.) Il valore di questo campo è un checksum dei byte compressi dagli altri campi.Usiamo "i primi 32 bit da MD5".
3. Crittografa tutto utilizzando TÈ.Per la chiave, utilizzare qualcosa che identifichi il cliente (ad es.nome dell'azienda + indirizzo email personale), in questo modo se qualcuno vuole pubblicare una chiave sull'interweb deve includere le proprie informazioni di contatto in testo semplice.
4. Converti hex in una stringa in un modo sensato.Puoi scrivere cifre esadecimali diritte, ma ad alcune persone piace scegliere un set diverso di 16 caratteri per renderlo meno ovvio.Includi anche trattini o qualcosa del genere regolarmente in modo che sia più facile leggerlo al telefono.

Per decrittografare, convertire esadecimale in stringa e decrittografare con TEA.Ma poi c'è questo passaggio aggiuntivo:Calcola il tuo checksum dei campi (ignorando il campo checksum) e confrontalo con il checksum fornito. Questo è il passaggio che garantisce che nessuno abbia manomesso la chiave.

Il motivo è che TEA mescola completamente i bit, quindi se viene modificato anche un solo bit, tutti gli altri bit hanno la stessa probabilità di cambiare durante la decrittografia TEA, quindi il checksum non passerà.

È hackerabile?Ovviamente!Quasi tutto lo è, ma è abbastanza rigoroso e semplice da implementare.

Se legare le informazioni di contatto non è sufficiente, includi un campo per "ID nodo" e bloccalo sull'indirizzo MAC o qualcosa come suggerisci.

Answer 4

Non utilizzare indirizzi MAC.Su alcuni hardware che abbiamo testato, in particolare alcuni Thinkpad IBM, l'indirizzo MAC può cambiare al riavvio.Non ci siamo preoccupati di indagare Perché lo era, ma abbiamo imparato abbastanza presto durante la nostra ricerca a non fare affidamento su di esso.

Disclaimer e plug obbligatori:l'azienda che ho co-fondato produce il Soluzione di licenza OffByZero Cobalt.Quindi probabilmente non ti sorprenderà sapere che consiglio di esternalizzare le tue licenze e concentrarti sulle tue competenze principali.

Seriamente, queste cose sono piuttosto difficili da ottenere nel modo giusto, e le conseguenze di un errore potrebbero essere piuttosto negative.Se hai un volume basso e un prezzo elevato, alcune copie piratate potrebbero incidere seriamente sulle tue entrate, e se hai un volume elevato e un prezzo basso, allora warez d00dz è incentivato a crackare il tuo software per divertimento e reputazione.

Una cosa da tenere a mente è che non esiste una licenza veramente a prova di crack;una volta che qualcuno ha il tuo codice byte sul proprio hardware, hai dato via la possibilità di controllare completamente cosa ne fanno.

Ciò che fa un buon sistema di licenza è alzare il livello sufficientemente in alto da rendere l'acquisto del software un'opzione migliore, soprattutto con l'aumento del software piratato infetto da malware.Ti consigliamo di adottare una serie di misure per proteggere la tua domanda:

• ottenere un buon sistema di licenze di terze parti
• arricchisci il tuo codice con controlli contenuti nell'ambito (ad es.nessuna variabile globale come fIsLicensed, non controlla lo stato di una funzionalità vicino al codice che implementa la funzionalità)
• impiegare un serio offuscamento nel caso del codice .NET o Java

Answer 5

L'azienda per cui ho lavorato effettivamente utilizzava a chiavetta USB.Questo è stato utile perché:

• Anche il nostro software era installato su quella chiavetta USB
• Il programma verrà eseguito solo se trova la chiave hardware (unica) (qualsiasi chiave USB standard ce l'ha, quindi non è necessario acquistare qualcosa di speciale, va bene qualsiasi chiavetta)
• non era limitato a un computer, ma poteva essere installato su un altro sistema, se lo si desiderava

So che alla maggior parte delle persone non piacciono i dongle, ma in questo caso è stato abbastanza utile perché in realtà veniva utilizzato per uno scopo speciale media Player che abbiamo anche consegnato, le chiavi USB potrebbero quindi essere utilizzate come demo Qualunque pc, ma anche, e senza alcuna modifica, essere utilizzato nell'applicazione reale (ovvero nei giocatori reali), una volta soddisfatto il cliente

Answer 6

Manteniamo le cose semplici:archiviare tutti i dati di licenza in un XML (facile da leggere e gestire), creare un hash dell'intero XML e quindi crittografarlo con un'utilità (anch'essa propria e semplice).

Anche questo è lungi dall'essere perfetto, ma può durare per un po' di tempo.

Answer 7

Quasi tutti i sistemi di licenza commerciale sono stati violati, ne abbiamo utilizzati molti nel corso degli anni e alla fine tutti vengono violati, la regola generale è scriverne uno tuo, cambiarlo a ogni versione, una volta che sei felice prova a crackarlo tu stesso.

Niente è veramente sicuro, in definitiva guarda i grandi attori Microsoft ecc., seguono il modello che le persone oneste pagheranno e gli altri copieranno, non impegnarti troppo.

Se vale la pena pagare la tua domanda, le persone lo faranno.

Answer 8

Ho utilizzato diversi prodotti diversi per la generazione delle licenze e ho creato la mia soluzione, ma tutto dipende da cosa ti darà la massima flessibilità ora e in futuro.

Gli argomenti su cui dovresti concentrarti per generare le tue chiavi di licenza sono...

Formattazione HEX, crittografia a curva ellittica e qualsiasi algoritmo di crittografia come AES/Rijndael, DES, Blowfish, ecc.Sono ottimi per creare chiavi di licenza.

Naturalmente non basta avere una chiave, è necessario anche associarla ad un prodotto e programmare l'applicazione in modo che si blocchi in base ad un sistema di chiavi da voi creato.

Mi sono divertito a creare la mia soluzione, ma alla fine, quando si è trattato di guadagnare con il software, ho dovuto cedere e ottenere una soluzione commerciale che mi avrebbe fatto risparmiare tempo nella generazione delle chiavi e nella gestione della mia linea di prodotti...

Il mio preferito finora è stato License Vault di SpearmanTech, ma ho anche provato FlexNet (costoso), XHEO (è richiesta troppa programmazione) e SeriousBit Ellipter.

Alla fine ho scelto il prodotto License Vault perché lo avrei acquistato a un prezzo molto più economico rispetto agli altri e aveva semplicemente di più da offrirmi poiché svolgiamo la maggior parte del nostro lavoro in .NET 3.5.

Answer 9

È difficile fornire una buona risposta senza sapere nulla del tuo prodotto e dei tuoi clienti.Per il software aziendale venduto a tecnici è possibile utilizzare un sistema di licenza abbastanza complesso e loro lo capiranno.Per il software consumer venduto a utenti poco esperti di computer, è necessario un sistema molto più semplice.

In generale, ho adottato la pratica di creare un sistema molto semplice che mantenga oneste le persone oneste.Chiunque voglia davvero rubare il tuo software troverà un modo per aggirare qualsiasi sistema DRM.

In passato ho utilizzato Armadillo (ora Software Passport) per progetti C++.Attualmente sto utilizzando XHEO per progetti C#.

Answer 10

Se il tuo prodotto richiede l'uso di Internet, puoi generare un ID univoco per la macchina e utilizzarlo per verificare con un servizio Web di licenza.

In caso contrario, penso che optare per un prodotto commerciale sia la strada da percorrere.Sì, possono essere hackerati, ma per la persona assolutamente determinata a farlo, è improbabile che avrebbe mai pagato.

Abbiamo utilizzato: http://www.aspack.com/asprotect.aspx

Utilizziamo anche una chiamata di funzione nel loro prodotto SDK che ci fornisce un ID univoco per una macchina.

Buona compagnia anche se chiaramente non di madrelingua inglese poiché il loro primo prodotto si chiamava "AsPack".