Domanda

Ho alcuni software di prova che desidero distribuire ai clienti. Voglio che il software basato sulla versione di prova smetta di funzionare dopo 30 giorni dall'installazione.

Un semplice controllo della data di sistema nel software è il modo più semplice per raggiungere questo obiettivo, ma un client non potrebbe aggirare facilmente questa protezione modificando la sua data / ora di sistema in Windows?

Esiste un modo migliore per realizzare ciò che voglio?

È stato utile?

Soluzione

La migliore scommessa è di non avvisarli, e dopo 30 giorni (assicurati di controllare entrambi i modi, altrimenti possono impostare l'orologio su in futuro, installare l'app e reimpostare l'orologio su oggi) smette di funzionare, anche blocca l'app una volta scaduto il periodo della traccia, quindi anche se ripristinano l'orologio, dovrebbe comunque essere bloccato

Altri suggerimenti

Verificherei l'ora modificata del file modificato più di recente (probabilmente ci sono alcuni percorsi comuni che vengono aggiornati frequentemente, ma potresti semplicemente cercare nel filesystem).

Inoltre, puoi ridurre il "tempo rimanente" (memorizzato in una posizione segreta) per il tempo in cui l'app era in esecuzione per la sua sessione. Quando raggiunge 0, hanno finito. Puoi anche rilevare che l'orologio si è spostato indietro rispetto all'ultimo valore visualizzato in qualsiasi sessione e penalizzarlo rimuovendo ad es. un'intera giornata.

Chi sono i tuoi clienti? Se è per il pubblico in generale, ed è un pubblico abbastanza ristretto, penso che tu possa seguire l'approccio basato sul tempo. Sono d'accordo che gli utenti si stancheranno di regolare l'orologio di sistema e acquisteranno semplicemente il tuo software. Ma se si tratta di un software molto popolare o se è rivolto agli sviluppatori , allora sì, probabilmente dovresti rafforzare la protezione di prova perché si spezzerà abbastanza rapidamente.

Sì, possono suonare l'orologio di sistema. Ma a poco a poco diventa sempre più scomodo farlo più si supera la data di fine del periodo di prova. Smetteranno di usare il tuo software prima di guardare l'orologio.

O, ancora più probabilmente, hackereranno il tuo schema di protezione in modo da dare loro un tempo indefinito per usarlo.

Suggerirei di richiamare periodicamente il software sul server; l'utente può giocherellare con l'orologio di sistema tutto ciò che vuole, ma tu controlli l'orologio sul tuo server. Se il server sa quando è stata emessa la licenza, può rispondere in modo appropriato a una richiesta del client indipendentemente dallo stato dell'orologio del client.

Dichiarazione di non responsabilità & amp; plug: la società che ho co-fondato produce la OffByZero Cobalt soluzione di licenza . È una soluzione chiavi in ??mano per la protezione del software, & amp; gestisce in modo specifico il tipo di scenario limitato nel tempo che citi.

Come notato, le licenze basate sul tempo sono abbastanza facili da aggirare. Puoi saltare attraverso alcuni cerchi per impedire alle persone di ripristinare l'orologio di sistema. Potresti contattare un time server certificato e impostare l'orologio interno in quel modo, ma non ci vorrebbe uno scienziato missilistico per decifrarlo se possono accedere al tuo codice. Un modo semplice è trovare il controllo del tempo nell'elenco asm e diramarlo.

Ci lavoriamo da anni (divulgazione: lavoro per una società di protezione dalla copia (www.wibu.us)) e utilizzo una combinazione di un orologio interno su un chip per smart card e time server certificati, oltre ad alcuni codici per assicurarti di non poter mai impostare il tempo indietro (il codice è sempre crittografato, quindi non è patchabile). Abbiamo anche una soluzione solo software che utilizza un orologio interno ma non su un chip per smart card. Ci sono degli svantaggi in tutte le misure di sicurezza; trovare il giusto compromesso per il tuo mercato, prezzo, ecc. è il trucco.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top