Come posso proteggere il mio gioco con chiave CD / numero seriale?


25

Quindi ho deciso di voler impedire alle copie piratate del mio gioco XNA di accedere ai server di gioco ufficiali (che sono moderati, quindi le persone che hanno pagato per il gioco avranno la migliore esperienza) disconnettendo i client con CD errati o generati, duplicati o vietati chiavi (o numeri di serie, poiché il gioco è digitale e non ci sono CD di sorta).

Come posso ottenere quel sistema di protezione del numero seriale nel mio gioco (sia client che server di autenticazione principale), quindi non è facilmente hackerabile?


Si noti che non ho esperienza con una buona protezione di quel tipo per il software.

Non l'ho mai fatto prima, ma capisco le basi. Capisco perché non riesco a eseguire i controlli delle chiavi sul client, quindi per me va bene utilizzare l'autenticazione login / pass con l'immissione della chiave singola.

Attualmente, l'obiettivo di questa protezione è mantenere i potenziali imbroglioni e comportarsi in modo dirompente i giocatori fuori dai server ufficiali. Chiunque può giocare su server privati ​​con o senza chiave, ma le possibilità che possano avere un'esperienza indesiderata con altri giocatori sono maggiori. Immagino sia abbastanza facile acquistare giocatori, dal momento che devono essere online per giocare sui server ufficiali.

Poiché l'hacking del client è troppo facile, proteggerò solo le procedure di registrazione iniziale (e possibilmente l'autenticazione sul lato server), in modo che nessuno possa rubare le chiavi mentre vengono trasferite.


Guarda anche:

In che modo i giochi multiplayer dovrebbero gestire l'autenticazione?


Se qualcuno vota verso il basso, mi aspetto almeno un commento su ciò che non va nella domanda. Ragazzi, davvero, voglio che la mia domanda sia buona e aiuti più persone di me.
user1306322

4
Immagino sia stata una reazione automatica all'aggiunta di DRM. Questo tipo non è particolarmente male, ma molti di noi hanno brutte esperienze con esso - come quando Spore ha bloccato la mia installazione di Windows.
Izkata,

Invece di una chiave CD hai considerato un approccio simile a MMO / simile a Minecraft che richiede un nome utente / password per accedere e utilizzarlo per autenticare gli utenti?
Tetrad,

4
Volendo DRM su un'app .NET !? Questo alla fine fallirà con strumenti come Reflector. Dai un'occhiata a Terraria. Lo sviluppo si è interrotto a causa della pirateria (e molte entrate ...). Mi piace l'idea basata sull'autenticazione di @ Tetrad in quanto impedisce alle persone di dover solo patchare la funzione di validazione. Conserva tutti i dati sul tuo server e quando il loro accesso ha esito positivo, fornisci loro i dati. Se conservi i dati localmente, possono semplicemente correggere la funzione di autenticazione.

2
@Anko che era un riferimento alla famosa citazione "Abbiamo bisogno di più minerali" . E intendo fatti e competenze. Forse anche i dettagli. Non saprei quando un problema importante ha avuto abbastanza attenzione, mi è sembrato che ci fosse qualcosa da aggiungere, ei visitatori del sito potrebbero trovare questo argomento interessante (e possibilmente diventare nuovi utenti), quindi ho aumentato la generosità.
user1306322,

Risposte:


24

Fondamentalmente, hai tre requisiti:

  1. non dovrebbe essere facile usare la stessa chiave per più istanze client,
  2. non dovrebbe essere facile generare nuove chiavi valide e
  3. non dovrebbe essere facile rubare la chiave di un cliente legittimo.

La prima parte dovrebbe essere piuttosto semplice: non lasciare che due giocatori accedano allo stesso server con la stessa chiave contemporaneamente. Puoi anche fare in modo che i server scambino informazioni sugli utenti che hanno effettuato l'accesso o contattare un server di autenticazione condiviso, in modo che anche l'utilizzo della stessa chiave per giocatori diversi su server diversi allo stesso tempo fallisca. Probabilmente vorrai anche cercare modelli sospetti di utilizzo delle chiavi e, se determini che una chiave è trapelata, aggiungila a un elenco di chiavi vietate.


Per la seconda parte, un modo è semplicemente quello di mantenere un database di tutte le chiavi emesse valide. Finché le chiavi sono abbastanza lunghe (diciamo, 128 bit o più) e scelte casualmente (usando un RNG sicuro), le probabilità che chiunque riesca a indovinare una chiave valida sono essenzialmente zero. (Anche chiavi molto più brevi possono essere sicure se si utilizza un qualche tipo di limitazione della velocità in caso di tentativi di accesso falliti per fermare i tentativi di trovare chiavi valide con la forza bruta.)

In alternativa, puoi generare le chiavi prendendo qualsiasi identificatore univoco e aggiungendo ad esso un codice di autenticazione del messaggio (come HMAC ), calcolato usando una chiave master segreta. Ancora una volta, fintanto che il MAC è abbastanza lungo, le probabilità che chiunque non sappia che la chiave master sia in grado di indovinare un MAC valido per qualsiasi ID è trascurabile. Un vantaggio di questo metodo, oltre a rimuovere la necessità di un database di chiavi, è che l'identificatore può essere qualsiasi stringa univoca e può codificare le informazioni sul client per cui è stata emessa la chiave.

Un problema con l'utilizzo dei MAC è che i server di gioco ufficiali (o almeno il server di autenticazione) devono conoscere la chiave master per verificare il MAC, il che significa che, se i server vengono hackerati, la chiave master potrebbe essere trapelata. Un modo per mitigare questo rischio potrebbe essere quello di calcolare diversi MAC per ciascun ID, utilizzando chiavi master diverse, ma memorizzando solo una delle chiavi master sui server di gioco. In questo modo, se la chiave master viene mai trapelata e utilizzata per generare ID falsi, è possibile revocarla e passare a un'altra chiave master. In alternativa, è possibile sostituire i MAC con firme digitali , che possono essere verificati utilizzando solo la metà pubblica della chiave principale.


Per la terza parte, un approccio consiste nell'assicurarsi che il client non invierà la propria chiave a nessuno senza verificare che il destinatario sia davvero un server ufficiale legittimo. Ad esempio, potresti utilizzare SSL / TLS (o DTLS ) per il processo di accesso, emettere certificati personalizzati per i tuoi server di gioco e avere solo i certificati di attendibilità del client emessi da te. Convenientemente, l'utilizzo di TLS proteggerà anche le chiavi del client (e qualsiasi altro dato di autenticazione) da intercettatori, ad esempio su reti WLAN pubbliche.

Sfortunatamente, questo approccio non consente ai server di terze parti di verificare le chiavi del client anche se lo desiderano. È possibile aggirare il problema configurando un server di autenticazione ufficiale che i server di gioco di terze parti possono utilizzare, ad esempio facendo in modo che il client acceda al server di autenticazione e riceva un token casuale una tantum che possono utilizzare per accedere al server di gioco (che quindi invia il token al server di autenticazione per verificarlo).

In alternativa, è possibile emettere certificati client effettivi o qualcosa di simile ai propri clienti. È possibile utilizzare un protocollo esistente (come TLS) che supporti l'autenticazione del certificato client (consigliato) o implementare il proprio, ad esempio in questo modo:

  • Il certificato client è costituito da una stringa di ID arbitraria, una coppia di chiavi pubblica / privata e una firma digitale dell'ID e della chiave pubblica che utilizza la chiave master.
  • Per accedere, il client invia il proprio ID, chiave pubblica e firma. Il server risponde con una stringa di verifica univoca (preferibilmente includendo un ID server e un timestamp, che il client dovrebbe verificare), che il client firma con la chiave privata (per dimostrare di conoscere la chiave) e invia la firma al server.
  • Il server controlla entrambe le firme, dimostrando che l'ID + chiave pubblica forma una chiave client legittima (poiché erano firmate con la chiave master) e che la chiave client appartiene effettivamente al client (poiché il client potrebbe firmare la sfida del server con il privato chiave).

(Questo protocollo potrebbe essere ulteriormente semplificato facendo in modo che il client generi la "sfida", consistente in un ID server e un timestamp, e firmarlo. Naturalmente, il server deve verificare che l'ID e il timestamp siano validi. Si noti inoltre che questo semplice protocollo, da solo, non impedirà a un aggressore intermediario di essere in grado di dirottare la sessione del client, sebbene impedirà loro di ottenere la chiave privata del client necessaria per gli accessi futuri.)


2
Un punto minore: mentre una chiave totalmente casuale fornisce il massimo spazio per le chiavi (ed è perfettamente praticabile se si esegue la convalida su un database di chiavi emesse) non è facile da usare. Inserisci un po 'di convalida nella chiave stessa in modo che la maggior parte dei errori di lettura vengano rilevati prima di provare a colpire il server.
Loren Pechtel,

Penso che @LorenPechtel abbia un punto di forza in termini di facilità d'uso della chiave, e l'utente pagato che digita e invia accidentalmente una chiave "errore di battitura / ortografia" (typo) al server è sempre possibile.
Vishnu,

@Vishnu Conosco un utente che digita le chiavi Preferirei di gran lunga avere alcune informazioni di controllo per gruppo anche se ciò significava digitare una chiave più lunga.
Loren Pechtel,

16

Non esiste una soluzione al 100%, ma potresti iniziare con un approccio piuttosto semplice:

  • Avrai bisogno di un modo per verificare le chiavi generate, ad esempio checksum inclusi. Certo, questo non deve essere troppo facile da capire.

  • Opzionale (ma consigliato) ci sarebbe un database lato server che verifica le chiavi con un database di tutte le chiavi fornite in modo da non poter generare le chiavi, anche se ti capita di avere l'algoritmo (ignoriamo il bruteforcing).

Da lì in poi puoi avere due approcci diversi, ma in entrambi i casi qualcosa è molto importante:

  • Non verificare la chiave sul lato client. Questo è molto importante, perché in realtà è piuttosto facile decompilare le cose scritte in .net / XNA. Se devi richiedere la chiave o passarla (login o registrazione) hash la chiave (con un ulteriore salt ecc.) E inviarla al server.

Per quanto riguarda i percorsi effettivi:

  • È necessario inviare la chiave con hash (vedi sopra) durante la procedura di autenticazione / accesso.

  • In alternativa (IMO il migliore, anche se a molti non piace questo tipo di "DRM"): non utilizzare affatto la chiave nel client. Invece, è necessario che l'utente acceda a un account e richieda una chiave CD valida (ciò richiede il database sopra menzionato) per creare account. Ecco come funzionano i giochi moderni, ad esempio qualsiasi MMORPG pay-to-play.

Personalmente, seguirei l'approccio dell'account per un semplice motivo: alla fine, non puoi impedire alle persone di rubare chiavi CD (bruteforcing, reverse engineering o truffa). In quanto tali, le persone potrebbero semplicemente creare una nuova chiave per continuare a giocare o per bloccare gli altri dal gioco. Con le chiavi associate all'account nessuno è in grado di fare nulla con una chiave già in uso. Nel caso in cui qualcuno abbia acquistato una chiave generata da qualcun altro, è comunque possibile trasferire la proprietà dell'account presumendo che ne sia stata fornita una prova sufficiente.


2
Invece di checksum standard, è necessario utilizzare un algoritmo di hashing crittograficamente sicuro. È possibile mantenere la chiave privata sul server e fornire al client la chiave pubblica e quindi si sa che senza accesso al server il sistema è sicuro.
Adam

@Adam: l'utilizzo di un algoritmo di hash crittograficamente sicuro garantirà che gli aggressori non possano generare chiavi valide, ma il problema è ugualmente irrisolvibile dall'autorità incaricata di distribuire chiavi legittime. Sebbene in realtà un semplice checksum non sia molto sicuro, le funzioni a senso unico non sono vitali in questo contesto.
Marcks Thomas,

Bene, puoi combinare entrambi, ad esempio rendendo la prima parte della chiave una combinazione casuale di caratteri e la seconda metà dell'hash. Chiunque venda il gioco non potrebbe comunque utilizzare un keygen (a meno che non ci sia un modo per garantire che non si verifichino collisioni / conflitti, come un "ID fornitore" come parte della chiave).
Mario,

1

Pangea Software, creatore di numerosi giochi per Mac, ha scritto un argomento sulla protezione dalla copia nel suo (ora gratuito) libro di sviluppo. Il libro spiega anche come gestire chiavi piratate e altri hack che le persone usano. Il libro si concentra sullo sviluppo di giochi per Mac, ma le idee potrebbero essere ancora utili per altre piattaforme. Il libro include il codice sorgente di ogni capitolo, parte del download di seguito. C'è anche il codice sorgente (scritto in C) incluso relativo alla protezione dalla copia.

Il libro può essere scaricato qui .


Non ho trovato nulla di utile in quei libri.
user1306322

Personalmente ho pensato che il capitolo 16 avesse dei buoni consigli, ma YMMV.
Wolfgang Schreurs,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.