Contenuti crittografati nei giochi

Ho avuto l'idea di usare la crittografia per impedire agli utenti di capire il contenuto del mio programma al di fuori del programma stesso. Come gli utenti possono trovare trame mai utilizzate nel gioco che fanno parte di un qualche tipo di uovo di Pasqua mentre vanno attraverso i dati di gioco. Questo può ad esempio rovinarlo per tutti se pubblicato online.

Immagina una stanza segreta in cui il giocatore deve premere i numeri corretti su una porta di sicurezza nel gioco, che se corretta dovrebbe generare la chiave di decrittazione corretta e quindi decifrare quella parte del livello e aprire la porta. Pertanto, rendendo l'uovo di Pasqua altrimenti inaccessibile anche quando si guardano i dati di gioco poiché la chiave non è effettivamente memorizzata, viene generata in base all'input dell'utente.

Ecco un altro esempio di ciò che stavo immaginando. Ho un gioco puzzle con diciamo 20 livelli, ognuno criptato usando una chiave diversa. Invece di archiviare la chiave di decrittazione con il programma che consente direttamente a qualcuno di decompilare il programma e trovarlo, invece genera la chiave di crittografia / decrittazione basata sulla soluzione del puzzle precedente. In questo modo il giocatore dovrebbe effettivamente capire il puzzle prima di ottenere qualsiasi informazione sul livello successivo, anche guardando i dati di gioco.

Il giocatore, se ben informato, potrebbe eventualmente forzarlo "facilmente" dato che il numero di soluzioni puzzle è probabilmente inferiore al numero di chiavi di decrittazione. È davvero una questione di complessità del puzzle e non è molto importante qui. Anche se ho pubblicato una risposta a riguardo qui

Esistono programmi / giochi oggi che hanno fatto qualcosa del genere? Archiviare contenuti crittografati nei loro giochi? E se no perché? Ci sono molte regole e regolamenti al riguardo, a livello di negozio o paese? Qualcuno vede alcune insidie ​​ovvie che mi manca? Ignorando cose come l'esperienza dell'utente, l'idea mi sembra valida e mi incuriosisce perché non l'ho mai vista prima.

Modifica : potrebbe non essere chiaro esattamente quello che sto dicendo, quindi ecco un esempio più concreto.

Diciamo che ho una funzione che accetta una stringa di 20 caratteri e genera una chiave simmetrica che posso usare per crittografare / decrittografare alcuni contenuti del gioco. L'unico modo in cui l'utente potrebbe arrivare a quel contenuto è conoscere quei 20 caratteri e generare la stessa chiave. Questa chiave non viene mai memorizzata direttamente e viene generata al volo in base all'input dell'utente. Questi personaggi sarebbero nascosti nel gioco in quelli che potrebbero essere libri, dialoghi con gli NPC, forse anche al di fuori del gioco sul retro della scatola.

Quindi con 2 * 10 ^ 28 possibili combinazioni da provare sarebbe probabilmente più probabile che le persone trovino il contenuto nel modo previsto piuttosto che guardando attraverso i dati di gioco.

Modifica 2 : il contenuto in questione verrebbe crittografato con una chiave arbitraria e segreta prima di essere spedito al consumatore. Questa chiave ovviamente non verrà spedita con il gioco. Dovrebbe in qualche modo rompersi insieme la chiave, data una serie di indizi basati sulla chiave, e che sono nascosti nel gioco o da qualche altra parte. Questo sistema sarebbe tuttavia trasparente per l'utente in quanto non sapresti che il contenuto è stato crittografato se non avessi effettivamente esaminato i dati di gioco.

Come molti hanno già detto, questo ha un aspetto negativo evidente in quanto il suo caso d'uso è limitato. Una volta che una sola persona l'ha capito, può condividerla con tutti gli altri, se non la chiave / soluzione, quindi il contenuto stesso. Tuttavia, se la tua intenzione è quella di mantenere qualcosa di così segreto che una sola persona non dovrebbe essere in grado di risolverlo e le persone devono lavorare insieme per risolverlo, o hai paura che il tuo uovo di Pasqua sia così ben nascosto (in base alla progettazione) che è più probabile che qualcuno lo trovi nel codice piuttosto che durante il gioco. Quindi penso che potrebbe funzionare alla grande.

Personalmente consiglierei di usarlo solo una volta per partita e solo per cose che non influiscono sul gioco principale, ad esempio le uova di Pasqua, un finale segreto. Ogni enigma dovrebbe essere così complicato o ben nascosto per rallentare le persone abbastanza da rendere la crittografia del contenuto degna di nota e se questo enigma ostacolava il progresso delle persone, allora probabilmente nessuno si sta divertendo.

Questa domanda è chiedersi se è possibile (non solo commercialmente fattibile o qualche altra interpretazione) forzare almeno 1 utente a risolvere un enigma invece di hackerare per sbloccare determinati contenuti di gioco.

Per quanto ne sappia, questo è sicuramente possibile. In effetti, è strano per me che altre risposte stiano dicendo che non è assolutamente possibile, anche quando è stato affermato esplicitamente che la chiave non è né generata né memorizzata, semplicemente letta dallo stato del gioco (che potrebbe avere possibili valori). L'argomento secondo cui "il gioco sa come decrittografarlo" in modo che non funzioni implica che qualsiasi software di crittografia / decrittografia open source (ad esempio TrueCrypt) è intrinsecamente insicuro perché sai "come" decifrare i contenitori (basta inserire una stringa basata sull'input da tastiera, è semplice vero?).

Nel caso assolutamente più semplice, immagina che il gioco stesso sia un simulatore di tastiera e pone la domanda "qual è la password per i miei file crittografati?", Chiaramente siamo tutti d'accordo sul fatto che avere il codice sorgente del gioco non sarebbe d'aiuto. Ora immagina che il gioco ponga le domande "Qual è il nome dell'animale più grande sulla Terra concatenato con il nome dell'animale più piccolo?". Non è chiaro che anche avere il codice sorgente del gioco non sarebbe d'aiuto, e devi ancora risolvere il puzzle?

Per quanto possibile, la risposta è SÌ assoluta, ciò è possibile.

È stato provato. Molte, molte volte C'è un intero sottosettore dedicato al tentativo di utilizzare la crittografia per impedire agli utenti di accedere a un programma come ritengono opportuno. E non funziona mai. I migliori schemi di protezione tendono a durare circa un mese prima che vengano crackati, e la cosa su Internet è, una volta che viene crackato una volta, viene crackato ovunque per sempre non appena qualcuno lo pubblica. L'ovvia trappola che ti manca è che affinché il tuo programma utilizzi i dati, deve contenere tutte le informazioni necessarie per decrittografarlo e, se il computer può farlo, una persona con accesso al computer può farlo quello.

È stato chiamato "il problema fondamentale della crittografia": Alice vuole inviare un messaggio a Bob, senza che Charlie sia in grado di leggerlo, anche se se ne accorge. Il problema con l'approccio che stai proponendo è che Bob e Charlie sono la stessa persona in questo caso.

Posso capire il desiderio di non rovinare i tuoi utenti, ma se le persone vogliono spoiler li troveranno e, in caso contrario, tenderanno ad evitare attivamente spoiler. Ma se vuoi davvero fare un grande gioco, segui la strada opposta: apertura radicale. Guarda cose come Neverwinter Nights , Starcraft o la serie Elder Scrolls , giochi che restano popolari per anni e anni dopo l'uscita. Lo fanno perché forniscono potenti strumenti di progettazione con il gioco che consentono agli utenti di scavare in tutto, capire come funziona e costruire e condividere i propri contenuti. Un gioco è solo un gioco, fino a quando non diventa una comunità e le comunità resistono.

Sono in giro da abbastanza tempo per sapere che se il contenuto è lì, qualcuno lo troverà. Renderlo più difficile attirerà solo persone più determinate. Più popolare è il tuo prodotto, più interessante diventa. In parte perché è una sfida, in parte perché ci sono così tanti posti in cui puoi guadagnare "credibilità" pubblicando questo tipo di informazioni.

Se la chiave viene generata localmente dal gioco, puoi trovare un modo per imbrogliare il gioco fino al punto in cui viene generata la chiave, o semplicemente estrarre il giusto pezzo di codice. Se la chiave ti viene inviata da un server al completamento di alcuni passaggi del gioco, qualcuno indurrà il tuo server a credere di essere andato abbastanza lontano.

Alla fine, il tuo gioco trarrà molto più beneficio dal tempo impiegato a renderlo divertente e coinvolgente, oltre a rendere difficile scoprire quale sia il colore di livello successivo.

Il motivo principale per cui questo dovrebbe essere su gamedev.SE è che fare questa crittografia ha conseguenze sul gameplay.

Volete che la soluzione di un puzzle sia la chiave di crittografia per il successivo. Cioè, i dati effettivi di quella soluzione devono decrittografare il puzzle successivo. Ciò significa che la chiave di decodifica non fa parte dei dati del tuo gioco da nessuna parte; è generato dal giocatore.

Ed ecco la conseguenza. La decrittografia è generalmente binaria. O hai l'esatta chiave di decrittazione necessaria per annullare la crittografia dei dati, oppure no.

La conseguenza qui è che qualunque gioco tu abbia progettato deve essere focalizzato in modo così ristretto che esiste una sola soluzione possibile per ogni livello. Quindi le meccaniche del tuo puzzle devono essere progettate con molta attenzione in modo tale che il giocatore non possa risolvere il puzzle in modo diverso dalle tue intenzioni.

Prendi ad esempio Portal, Test Chamber 10. Dovresti andare a sinistra, fare alcune cose, quindi andare a destra e fare alcune cose, tutto per abbassare una piattaforma.

Oppure puoi semplicemente darti un po 'di velocità e lanciarti sulla piattaforma quando entri.

GLaDOS: Quindi hai creato un puzzle game. Un gioco puzzle che punisce le persone che più amano i giochi puzzle. Buon lavoro. Ma almeno quegli hacker non otterranno i tuoi dati preziosi. Perché le persone a cui piace risolvere i giochi puzzle sono esattamente i tipi di persone che cercano soluzioni ai giochi puzzle online.

Quindi ne vale assolutamente la pena.

Quindi, giochi puzzle come Adventures of Lolo, SpaceCHEM e Portal (tra milioni di altri) sono appena usciti. Invece, devi progettare il tuo gioco in modo che sia impossibile creare un puzzle che abbia più di una soluzione. Ciò richiede molta cura e di solito richiede un sostanziale restringimento del gameplay.

GLaDOS: Quindi hai creato un puzzle game. Un gioco pensato per essere giocato da persone a cui piace trovare soluzioni creative ai puzzle. E hai creato un gioco che non ha soluzioni creative ai puzzle. * Slow-clap *

Non sto dicendo che non puoi creare un gioco del genere. O che un gioco del genere non può essere buono. Solo che un tale gioco dovrebbe essere progettato in un certo modo.

Oh, e devi progettare questo gameplay in modo che sia impossibile (o altamente difficile) trovare meccanicamente una soluzione.

GLaDOS: Quindi hai creato un puzzle game. Un puzzle game più interessante da hackerare che da giocare. Buon lavoro.

Certamente, c'è un avvertimento in questo: il significato di "soluzione". O più al punto, quali elementi di una soluzione prendi in considerazione?

Per qualsiasi gioco che coinvolga un personaggio in movimento, probabilmente non userai i movimenti esatti del personaggio per costruire la chiave di decrittazione. Ad esempio, se hai un gioco puzzle in cui il giocatore deve raccogliere determinati oggetti per "risolvere" il puzzle, puoi fare in modo che la chiave dipenda dall'ordine in cui tali oggetti vengono toccati.

Naturalmente, questo si imbatte in quel problema sopra, in cui un giocatore trova un modo per fare le cose fuori servizio. Il che significa che devi progettare il puzzle in modo tale che ci sia un solo ordine in cui potresti raccogliere le cose.

Inoltre, qualsiasi elemento tu usi per costruire la chiave di decrittazione deve fornire entropia sufficiente a rendere difficile la decrittazione della forza bruta. Utilizzando la meccanica dell'ordine di raccolta sopra, ogni nuovo articolo è effettivamente un bit in più. Se un livello ha solo 8 elementi, stai eseguendo la crittografia a 8 bit. Che è una schifezza; la maggior parte degli smartphone può gestirlo in pochi secondi.

Al giorno d'oggi, hai bisogno di almeno 128 per renderlo anche leggermente impegnativo. Il che ora significa che ogni livello deve contenere un sacco di roba, influendo ancora una volta sul design del tuo gioco.

Le risposte qui sono buone; Vorrei guardarlo da un'altra prospettiva però. Quello che stai descrivendo è una funzione . Le funzionalità hanno costi e benefici. I costi includono sia i costi in dollari per la creazione della funzionalità, sia i "costi opportunità". Questi sono: in un mondo in cui hai dollari finiti, ore finite e programmatori finiti, ogni funzione che fai significa un numero infinito di possibili funzioni che non sono state fatte al suo posto.

Quindi la domanda è: puoi indicare i costi di questa funzione in termini reali? Non ci sono funzionalità gratuite, quindi sii realistico sui costi. Vuoi pagare mille dollari per questa funzione? Centomila? Un milione? Quali funzioni sei disposto a tagliare per avere questa funzione?

Penso che una volta che inizi a dare la priorità alle cose in termini di costi, benefici e opportunità perse, ti renderai conto che hai già passato troppo tempo a pensare a questa funzione quando avresti potuto pensare a modi per rendere il gioco più divertente.

Il problema di Alice Bob ed Eva lo dimostra bene. Come Mason ha sottolineato nella sua risposta, non puoi mantenere un segreto da Eva se Eva è anche Bob.

Pertanto, qualsiasi soluzione consisterebbe nel fatto che Bob non avesse tutte le informazioni necessarie. Dovresti trattare ogni livello come un singolo messaggio, crittografato separatamente l'uno dall'altro, e avere una fonte esterna di messaggi per il livello successivo in grado di conservare correttamente i messaggi.

Ma alla fine, diventa discutibile. Se qualcuno può giocare da solo, può anche scrivere un programma per ingerire anche il gioco. Quindi tutto ciò che stai facendo è costringerli ad andare avanti e indietro dalla tua fonte esterna (probabilmente un server di qualche tipo). Una volta che decifrano come creare i messaggi sul tuo server, è la stessa vecchia storia.

Ma stai dimenticando un elemento chiave qui. È un gioco. Se qualcuno imbroglia in un gioco, grande whoop. Non hai scritto il gioco per imbroglioni. È la stessa cosa con le procedure dettagliate o le guide di livellamento delle missioni: le persone che vogliono affrontare la sfida da sole ignoreranno le soluzioni pubblicate. Anche se tu fossi in grado di rendere impossibile decifrare il gioco senza giocarci (sappiamo che è logicamente impossibile, ma ANCHE SE tu potessi) ci vorrebbe solo un ragazzo che ci attraversa prima di pubblicare tutto il necessario per batterlo. Quindi stai solo ritardando l'inevitabile.

Trascorri il tuo tempo facendo un gioco fantastico. Ci sono dieci cose di cui ogni gioco ha bisogno e l'ultima volta che ho guardato, la crittografia non era una di queste.

Credo che la tua idea sia inutile.

Quando qualcuno gioca, sceglie di giocare, non lo fa per vincere un premio, lo fa per divertimento.

Gli utenti sanno che il più divertente viene dal modo in cui intendevi e non imbrogliano , poiché i tuoi clienti si fidano già di te come narratore.

Inoltre, non appena qualcuno ha trovato la soluzione a un puzzle, ovvero la tua chiave, può semplicemente pubblicarlo da qualche parte su Internet.
I giocatori che vogliono imbrogliare sarebbero comunque in grado di farlo.

Tuttavia, se il tuo gioco presenta più soluzioni, come i livelli segreti di Super Mario Land, la crittografia delle risorse impedirà un facile accesso a tali soluzioni.

Mentre questo sembra un punto a favore della tua idea, alla fine non lo è.

Anche con la crittografia sarebbe ancora possibile sapere che esistono soluzioni segrete.
Una volta noto che esiste una soluzione segreta, impedire ai giocatori di guardare le risorse segrete sarebbe irrilevante in quanto vorrebbero comunque accedere alle parti nascoste del gioco attraverso il gioco stesso (sì, anche se hanno già visto ogni nascosto tessitura / clip / / testo audio).

Puoi prevenire la fuoriuscita dell'esistenza di soluzioni segrete usando qualche ignara tecnica ¹ , ma sarebbe comunque sospetto (perché farlo se non ci sono soluzioni segrete?), I giocatori perderebbero interesse a trovarle e avresti meno giocatori , non di più.
Dopotutto possiamo giocare ancora un paio d'ore dopo aver completato una partita per far scattare alcune uova di Pasqua, ma non giocheremo un minuto in più se attivarle richiederebbe uno sforzo titanico!

Quello che vuoi fare è come un libro di scrittura in cui il prossimo capitolo è crittografato con una parola del capitolo corrente, per impedire ai lettori di rovinarsi il finale.
Pensaci, non è inutile?

_{¹ Praticamente come fa VeraCrypt con volumi nascosti.}

Non commenterò la fattibilità commerciale, tuttavia da una prospettiva puramente tecnica è una sfida divertente.

Vorrei prima notare che tutto ciò che non è crittografato non può essere protetto. Non puoi bloccare l'ingresso in un segreto, i cracker troveranno un modo per aggirare il cancello, invece devi rendere l'intero segreto lo stesso cancello. In termini di risorse, ciò non deve necessariamente significare l'intera trama, ecc ... semplicemente crittografando il piano e quali sono utilizzati e come è sufficiente, e per motivi di prestazioni desidererai crittografare il minor numero possibile di dati.

In secondo luogo, hai ragione nel dire che se la chiave è contenuta nel software, verrà presa in giro dal software. Molti giochi, quando proteggono i contenuti, cercano di usare la sicurezza per oscurità o meccanismi che assicurano che il software di gioco non sia stato alterato. Quelli stanno solo ritardando le tattiche.

La tua idea di utilizzare la soluzione di un enigma come chiave è piuttosto interessante, tuttavia, l'utilizzo della chiave fornita direttamente è probabilmente facilmente forzato. Invece, considera l'input dell'utente come una password e usa uno schema di hashing della password all'avanguardia: l'hash prodotto è la chiave.

Tuttavia, anche in questo caso, c'è un errore nell'ipotesi che la chiave non sia presente nel gioco. In caso contrario, non potresti indirizzare i tuoi giocatori verso di esso; quindi, piuttosto che cercare di forzare bruscamente la cassaforte, si potrebbe invece decodificare le risorse del gioco alla ricerca di indizi. Un potenziale enigma a cui riesco a pensare è usare le trame per codificare i glifi, e quindi la password consisterebbe in alcuni dei disponibili sulla tastiera, come rivelato dalle posizioni che il giocatore avrebbe dovuto visitare (in ordine):

• il nocciolo del problema è che il riconoscimento delle immagini è ancora piuttosto difficile per i computer
• sulla quale si sovrappone il fatto che i cracker CAPTCHA sono sintonizzati per lettere e cifre, non per glifi personalizzati
• in cima al quale mettiamo a strati il ​​fatto che combinando più trame (con trasparenza) per rivelare il glifo al giocatore, nessuna singola risorsa nel gioco contiene come dovrebbe apparire il glifo
• usa un'altra trama (con frammenti) in tutto il luogo, ma mai in un modo che generi un glifo completo tranne nei luoghi nascosti che il giocatore non dovrebbe mai essere in grado di raggiungere

e qualsiasi programma per estrarre automaticamente la combinazione di glifi vincente avrà un inferno di un giorno.

In terzo luogo, la prossima difficoltà è la condivisione. Una volta trovata la soluzione a un segreto, verrà rivelata. Idealmente, a ciascun individuo dovrebbe essere consegnata una versione leggermente diversa del software: una in cui la chiave è unica per la sua versione del gioco. Per renderlo pratico, suppongo che sarebbe più facile separare il gioco (con le sue risorse) dai "segreti" (crittografati) e "driver segreto" (il generatore di chiavi, che posiziona molti frammenti di trama in molti luoghi diversi , alcuni dei quali formano le password).

Il vettore di attacco ovvio sta ingannando il generatore nel scegliere sempre la stessa password o inducendo il verificatore ad accettare sempre la stessa password (scaricando ad esempio il file dei segreti di qualcun altro).

Qui, una potenziale soluzione sarebbe quella di collegare i file all'account dell'utente e di salare la password come di solito è raccomandato:

• quando l'utente richiede un set di file, genera in modo casuale un salt e tutte le password che hai segreti, quindi crea le risorse segrete (potresti voler limitare questo processo a una volta / giorno / utente per esempio, per evitare di sovraccaricare il tuo server)
• memorizzare il timestamp della generazione e il sale nelle informazioni dell'account dell'utente
• rispedire all'utente il timestamp e i file segreti personalizzati

Quindi, quando l'utente è pronto a inviare una password:

• far accedere l'utente (se non lo era già)
• fare in modo che il software invii sia la data / ora che la password di glifo
• se il timestamp è diverso da quello memorizzato, avvisare l'utente che sta utilizzando un set obsoleto di file segreti
• se la password è già stata tentata troppe volte, avvisare l'utente che sta utilizzando un set obsoleto di file segreti
• altrimenti, hash salt + password per produrre la chiave
• in caso contrario, rispedire la chiave all'utente in modo che possa vedere i suoi file personalizzati
• aumentare il numero di volte in cui questa password è stata tentata da questo account

L'obiettivo qui è impedire il più possibile la condivisione degli account:

• la condivisione di un account per generare file segreti è (a) limitata, perché solo uno può essere generato al giorno e (b) inutile, perché l'ultimo generato rende l'altro obsoleto
• condividere un account e distribuire i file segreti associati è inutile, perché una determinata password può essere utilizzata solo N volte prima che non restituisca più la chiave

E ci siamo quasi.

Infine, anche lì, un cracker potrebbe rilasciare una versione modificata del gioco in cui le risorse segrete vengono decodificate e integrate direttamente (ignorando il tuo accurato schema di verifica).

La soluzione è semplice (e rende quasi tutto al di sopra di ¹ obsoleto ): non fidarti del client.

Crea una classifica sul tuo sito web e tieni traccia dei progressi dei giocatori nel loro account. I giocatori possono affermare di aver finito il gioco tutto ciò che vogliono, ma a meno che il loro account non rifletta questo, tutti sanno che hanno imbrogliato ...

... questo si chiama pressione sociale;)

¹ Tranne il file di posizionamento delle trame, che è stato utilizzato per impedire a un programma di indovinare la chiave e tuttavia consentire a un utente di ottenerla.

È un'idea interessante; una variante sui dischi puzzle e sui sistemi di protezione dalla copia digitati dal manuale. Penso che alcuni dei giochi "ARG" funzionino in questo modo, dove si comprende che i giocatori agiscono collettivamente contro il progettista del gioco.

Ovviamente una volta che la prima persona lo decifrerà lo pubblicheranno su Internet.

I contenuti generativi o procedurali possono funzionare allo stesso modo: non vedi lo stesso mondo di un altro giocatore se non condividi un "seme".

Non riesco a vedere alcun problema legale con esso, anche se Apple potrebbe rifiutarlo dal loro App store e potresti dover fornire la soluzione per ottenerlo approvato sulle console di gioco.

Contemplare ulteriori misure di sicurezza è divertente, ma non aggiunge valore concreto al tuo prodotto, ma dimostra la tua abilità con i cracker che incontrano il tuo prodotto. In linea di principio, il tuo antagonista ti raggiungerà.

Contrariamente agli sviluppatori che prosperano nella creatività, i cracker sono persone analitiche: possono sfruttare intuitivamente il tuo programma. Quando gli sviluppatori tendono a misure di sicurezza eccessive, vengono negati: il cracker potrebbe invertire nuovamente il loro schema di protezione .

Che tu voglia partecipare a questo concorso di base, questa è la tua chiamata, ma non lasciarti distrarre dal tuo prodotto finale, il che deve soddisfare il cliente. Uno stravagante schema di crittografia che trasforma il gioco in una lumaca non aiuta.

Mason Wheeler ha ragione: non puoi farlo. Qualcuno può sempre decodificare il tuo gioco se lo desidera.

Non è necessario "proteggere" il tuo gioco come descritto. Non appena una persona trova l'uovo di Pasqua, il segreto è fuori dalla borsa. Se ogni copia del gioco ha un uovo di Pasqua diverso, allora sarà conosciuta solo la copia dell'hacker. Ti interessa davvero che un hacker su 1000 persone abbia trovato l'uovo di Pasqua senza passare per il gameplay?

La legge sul copyright è tale che nessuno può guadagnare con il tuo gioco senza rischiare una causa legale, quindi il copyright ti protegge.

Per quanto riguarda gli utenti casuali che mettono le tue trame sull'avatar del loro forum, e allora? Consideralo la pubblicità di base.

Diventare ossessivi riguardo alla "protezione" delle cose ti distrarrà da realtà difficili come: creare il gioco .

Quando vedo persone senza prodotto che parlano dei loro schemi di protezione IP per cose che non esistono nemmeno, è per me un momento di passaggio perché alza un enorme stronzetto rosso su tutto il progetto.

Alcune possibilità:

• Semplice offuscamento del vecchio codice . Non renderà impossibile la decodifica del codice, ma almeno sarà difficile.

• Soluzione lato server. Si inviano alcuni comandi speciali al server e il server può inviare il codice ... o persino scaricare un DLC.

• È possibile utilizzare Steganography per nascondere il codice eseguibile in altri contenuti.

Questo non renderà il tuo segreto sicuro al 100%, ma sembra che nessuno perderà nemmeno i soldi se il segreto viene rivelato.

È inutile come qualsiasi altro schema in cui si memorizzano chiave e algoritmo sul client. Se chiedi "dov'è la chiave, faccio affidamento sul contributo degli utenti e non lo memorizzo da solo?", Ricorda che il tuo puzzle ha regole e risorse per le sue definizioni - è risolto da un algoritmo, non dal bruteforcing. Questo algoritmo esatto e le sue risorse sono l'algoritmo di generazione delle chiavi che hai appena codificato nel gioco in uno stato offuscato. Chiunque può recuperare la chiave "inesistente" semplicemente scrivendo un piccolo programma che risolve il tuo puzzle secondo le tue regole.