Contenu crypté dans les jeux

J'avais eu l'idée d'utiliser le cryptage pour empêcher les utilisateurs de trouver du contenu dans mon programme en dehors du programme lui-même. Comme les utilisateurs peuvent trouver des textures jamais utilisées dans le jeu destinées à faire partie d'une sorte d'oeuf de Pâques lors de la consultation des données du jeu. Cela peut par exemple le ruiner pour tout le monde s'il est posté en ligne.

Imaginez une pièce secrète dans laquelle le joueur doit composer les numéros corrects sur une porte de sécurité du jeu. Ce dernier, s'il est correct, devrait générer la clé de déchiffrement correcte, puis déchiffrer cette partie du niveau et ouvrir la porte. Rendre l'œuf de Pâques autrement inaccessible même lorsque vous parcourez les données du jeu, car la clé n'est pas réellement stockée, elle est générée à partir des entrées de l'utilisateur.

Voici un autre exemple de ce que j'imaginais. J'ai un jeu de réflexion avec 20 niveaux, chacun crypté à l'aide d'une clé différente. Au lieu de stocker la clé de déchiffrement dans le programme en permettant à quelqu'un de le décompiler et de le trouver, je génère la clé de chiffrement / déchiffrement en fonction de la solution du puzzle précédent. De cette façon, le joueur devrait résoudre le casse-tête avant d’obtenir des informations sur le niveau suivant, même en regardant à travers les données du jeu.

Le joueur, s'il en a connaissance, pourrait le forcer "facilement", étant donné que le nombre de solutions de casse-tête est probablement inférieur au nombre de clés de déchiffrement. C'est vraiment une question de complexité du casse-tête et ce n'est pas très important ici. Bien que j'ai posté une réponse à ce sujet ici

Y at-il des programmes / jeux aujourd'hui qui ont fait quelque chose comme ça? Stocker du contenu crypté dans leurs jeux? Et sinon pourquoi? Existe-t-il beaucoup de règles et de réglementations à ce sujet, que ce soit au niveau du magasin ou du pays? Quelqu'un voit-il des pièges évidents qui me manquent? Ignorant des choses comme l'expérience utilisateur, l'idée me semble bonne et me rend curieux de savoir pourquoi je ne l'ai pas vu auparavant.

Edit : Il se peut que ce que je dis ne soit pas clair, alors voici un exemple plus concret.

Disons que j'ai une fonction qui prend une chaîne de 20 caractères et génère une clé symétrique que je peux utiliser pour chiffrer / déchiffrer du contenu dans le jeu. La seule façon pour l'utilisateur d'accéder à ce contenu est de connaître ces 20 caractères et de générer la même clé. Cette clé n'est jamais directement stockée et est générée à la volée en fonction des entrées de l'utilisateur. Ces personnages seraient cachés dans le jeu dans ce qui pourrait être des livres, un dialogue avec des PNJ, peut-être même en dehors du jeu, même au dos de la boîte.

Donc, avec 2 * 10 ^ 28 combinaisons possibles à essayer, il serait probablement plus probable que les gens trouvent le contenu de la manière prévue plutôt qu'en consultant les données du jeu.

Éditer 2 : le contenu en question serait chiffré avec une clé arbitraire et secrète avant d' être expédié au consommateur. Cette clé ne sera évidemment pas livrée avec le jeu. Il ou elle devrait en quelque sorte reconstituer la clé grâce à une série d’indices basés sur la clé et qui sont cachés tout au long du jeu ou ailleurs. Ce système serait toutefois transparent pour l'utilisateur car vous ne sauriez pas que le contenu est crypté à moins que vous ne parcouriez les données du jeu.

Comme beaucoup l'ont mentionné, cela présente un inconvénient évident en ce sens que son cas d'utilisation est limité. Une fois qu'une seule personne l'a compris, il / elle peut le partager avec tout le monde, sinon la clé / solution, puis le contenu lui-même. Toutefois, si votre intention est de garder quelque chose de si secret qu'une seule personne ne devrait pas être capable de le résoudre et que les gens doivent travailler ensemble pour le résoudre, ou vous avez peur que votre œuf de Pâques soit si bien caché (à dessein) qu'il Il est plus probable que quelqu'un le trouve dans le code plutôt que par le jeu. Ensuite, je pense que cela pourrait très bien fonctionner.

Personnellement, je recommanderais de ne l'utiliser qu'une fois par partie et uniquement pour des choses qui n'affectent pas le jeu, par exemple les oeufs de Pâques, une fin secrète. Chaque casse-tête devrait être si compliqué ou si bien caché pour ralentir suffisamment les gens pour que le cryptage du contenu en vaille la peine. Si ce casse-tête empêchait les gens de progresser, personne ne s'amusait probablement.

Cette question consiste à savoir s’il est possible (et pas seulement une interprétation commercialement viable ou autre) d’obliger au moins un utilisateur à résoudre un casse-tête au lieu d’un piratage informatique pour déverrouiller certains contenus de jeux.

A ma connaissance, c'est certainement possible. En fait, c’est bizarre pour moi que d’autres réponses disent que c’est carrément impossible, même quand il a été dit très explicitement que la clé n’est ni générée ni stockée, mais simplement lue depuis l’état du jeu (ce qui pourrait avoir des googleplexes possibles). valeurs). L'argument selon lequel "le jeu sait comment le déchiffrer" et qu'il ne fonctionnera pas impliquerait alors que tout logiciel de chiffrement / déchiffrement open source (par exemple, TrueCrypt) est intrinsèquement peu sûr, car vous savez "comment" déchiffrer les conteneurs (il suffit d'entrer une chaîne basée sur la saisie au clavier, c’est simple non?).

Dans le cas le plus simple, imaginons que le jeu lui-même est un simulateur de clavier et qu'il pose la question "quel est le mot de passe de mes fichiers cryptés?", Nous sommes tous d'accord pour dire que le code source du jeu ne serait d'aucune aide. Maintenant, imaginez que le jeu pose les questions "quel est le nom du plus grand animal sur Terre concaténé avec le nom du plus petit animal?". N’est-il pas évident que le fait d’avoir le code source du jeu n’aiderait pas, et vous devez toujours résoudre le casse-tête?

Pour ce qui est de savoir si cela est possible, la réponse est absolue, c'est possible.

Cela a été essayé. Beaucoup, beaucoup de fois. Il existe toute une sous-industrie qui tente d'utiliser le cryptage pour empêcher les utilisateurs d'accéder à un programme comme bon leur semble. Et ça ne marche jamais. Les meilleurs systèmes de protection ont tendance à durer environ un mois avant d'être fissurés, et le problème d'Internet est qu'une fois fissuré une fois, il est craqué partout pour toujours dès que quelqu'un le publie. Le piège évident qui vous manque est que, pour que votre programme utilise les données, il doit contenir toutes les informations nécessaires pour le déchiffrer. Si l'ordinateur peut le faire, une personne ayant accès à l'ordinateur peut le faire. cette.

Cela a été appelé "le problème fondamental de la cryptographie": Alice veut envoyer un message à Bob, sans que Charlie puisse le lire même s'il le récupère. Le problème avec l'approche que vous proposez est que Bob et Charlie sont la même personne dans ce cas.

Je peux comprendre le désir de ne pas gâcher vos utilisateurs, mais si les gens veulent des spoilers, ils les trouveront et s’ils ne le font pas, ils auront tendance à éviter activement les spoilers. Mais si vous voulez vraiment faire un bon jeu, prenez la voie opposée: une ouverture radicale. Regardez des trucs comme Neverwinter Nights , Starcraft ou la série Elder Scrolls , des jeux qui restent populaires pendant des années et des années après leur sortie. Ils le font parce qu’ils incluent dans le jeu des outils de conception puissants qui permettent aux utilisateurs d’explorer tout, de comprendre comment cela fonctionne, de créer et de partager leur propre contenu. Un jeu n'est qu'un jeu, jusqu'à ce qu'il devienne une communauté et que les communautés perdurent.

Cela fait assez longtemps que je sais que si le contenu existe, quelqu'un le trouvera. Le rendre plus difficile attirera simplement des personnes plus déterminées. Plus votre produit est populaire, plus il devient intéressant. En partie parce que c'est un défi, en partie parce qu'il y a tellement d'endroits où vous pouvez gagner en "crédibilité" en publiant ce type d'informations.

Si la clé est générée localement par le jeu, vous pouvez trouver un moyen de tricher dans le jeu jusqu'à ce que la clé soit générée, ou simplement extraire le bon morceau de code. Si la clé vous est envoyée par un serveur après certaines étapes du jeu, quelqu'un trompera votre serveur en lui faisant croire qu'il est allé assez loin.

En fin de compte, votre jeu bénéficiera beaucoup plus du temps que vous passerez à le rendre amusant et engageant, au lieu de rendre difficile la recherche du niveau de couleur supérieur.

La raison principale pour laquelle cela devrait être sur gamedev.SE est que faire de ce cryptage a des conséquences sur le gameplay.

Vous voulez que la solution d'un puzzle soit la clé de cryptage du suivant. C'est-à-dire que les données réelles de cette solution doivent déchiffrer le prochain casse-tête. Cela signifie que la clé de déchiffrement ne fait pas partie des données de votre jeu. il est généré par le joueur.

Et voici la conséquence. Le décryptage est généralement binaire. Soit vous avez la clé de décryptage exacte nécessaire pour décrypter les données, soit vous ne l’avez pas.

La conséquence ici est que, quel que soit le jeu que vous concevez, il doit être ciblé si étroitement qu'il n'y a qu'une seule solution possible à chaque niveau. Donc, la mécanique de votre puzzle doit être très soigneusement conçue pour que le joueur ne puisse pas résoudre le puzzle différemment de votre intention.

Prenez Portal, Test Chamber 10 par exemple. Vous êtes censé aller à gauche, faire des choses, puis aller à droite et faire des choses, tout cela pour abaisser une plate-forme.

Ou vous pouvez simplement vous donner une certaine vitesse et vous jeter sur la plate-forme lorsque vous entrez directement.

GLaDOS: Vous avez donc créé un jeu de puzzle. Un jeu de réflexion qui punit les personnes qui aiment le plus les jeux de réflexion. Bon travail. Mais au moins, ces pirates informatiques ne pourront pas accéder à vos précieuses données. Parce que les personnes qui aiment résoudre des jeux de réflexion sont le type exact de personnes qui recherchent des solutions aux jeux de réflexion en ligne.

Donc ça en vaut la peine.

Ainsi, les jeux de réflexion tels que Adventures of Lolo, SpaceCHEM et Portal (parmi des millions d’autres) sont bien connus . Au lieu de cela, vous devez concevoir votre jeu de telle sorte qu'il soit impossible de créer un casse-tête comportant plus d'une solution. Cela nécessite beaucoup de soin et nécessite généralement une jouabilité très limitée.

GLaDOS: Vous avez donc créé un jeu de puzzle. Un jeu destiné à ceux qui aiment trouver des solutions créatives aux puzzles. Et vous avez créé un jeu qui ne contient aucune solution créative aux énigmes. *Battement lent*

Je ne dis pas que vous ne pouvez pas créer un tel jeu. Ou qu'un tel jeu ne peut pas être bon. Seul un tel jeu devrait être conçu d'une certaine manière.

Oh, et vous devez concevoir ce gameplay de telle sorte qu'il soit impossible (ou très difficile) de trouver une solution mécanique .

GLaDOS: Vous avez donc créé un jeu de puzzle. Un jeu de puzzle qu'il est plus intéressant de pirater que de jouer. Bon travail.

Bien sûr, il y a une mise en garde à cela: le sens de "solution". Ou plus précisément, quels éléments de solution prenez-vous en compte?

Pour tout jeu impliquant un personnage en mouvement, vous n'utiliserez probablement pas les mouvements exacts du personnage pour construire la clé de déchiffrement. Par exemple, si vous avez un jeu de casse-tête dans lequel le joueur doit prendre certains objets pour "résoudre" le casse-tête, vous pouvez faire en sorte que la clé dépende de l'ordre dans lequel ces éléments sont touchés.

Bien sûr, cela se heurte au problème ci-dessus, où un joueur trouve un moyen de faire les choses dans le désordre. Ce qui signifie encore une fois que vous devez concevoir le puzzle de telle sorte qu’il n’y ait qu’une seule commande dans laquelle vous puissiez prendre des commandes.

En outre, quels que soient les éléments que vous utilisez pour construire la clé de déchiffrement, vous devez fournir une entropie suffisante pour rendre le déchiffrement brutal difficile. En utilisant le mécanisme d'ordre de collecte ci-dessus, chaque nouvel article constitue en réalité un bit supplémentaire. Si un niveau ne comporte que 8 éléments, vous utilisez un cryptage 8 bits. Qui est la merde; la plupart des smartphones peuvent gérer cela en quelques secondes.

De nos jours, il en faut au moins 128 pour que ce soit un peu difficile. Ce qui signifie maintenant que chaque niveau doit contenir de nombreuses ressources, ce qui aura un impact sur votre conception du jeu.

Les réponses ici sont bonnes; Je le regarderais d'un autre point de vue cependant. Ce que vous décrivez est une fonctionnalité . Les fonctionnalités ont des coûts et des avantages. Les coûts comprennent à la fois les coûts en dollars liés à la création de la fonctionnalité et les "coûts d'opportunité". Celles-ci sont: dans un monde où vous avez des dollars et des heures finis et des programmeurs finis, chaque fonctionnalité que vous créez signifie un nombre infini de fonctionnalités possibles qui n'ont pas été créées à la place.

La question est donc la suivante: pouvez-vous énoncer les coûts de cette fonctionnalité en termes réels? Il n'y a pas de fonctionnalités gratuites, soyez réaliste quant aux coûts. Êtes-vous prêt à payer mille dollars pour cette fonctionnalité? Cent mille? Un million? Quelles fonctionnalités voulez-vous couper pour avoir cette fonctionnalité?

Je pense qu'une fois que vous aurez commencé à hiérarchiser les coûts, les avantages et les opportunités manquées, vous vous rendrez compte que vous avez déjà passé trop de temps à réfléchir à cette fonctionnalité alors que vous auriez pu penser à des façons de rendre le jeu plus amusant.

Le problème d'Alice Bob et Eve l'illustre bien. Comme Mason l'a souligné dans sa réponse, vous ne pouvez pas garder un secret d'Eve si Eve est aussi Bob.

Ainsi, toute solution consisterait en ce que Bob ne dispose pas de toutes les informations nécessaires. Vous devez traiter chaque niveau comme un message individuel, chiffré séparément, et disposer d'une source externe de messages pour le niveau suivant, capable de conserver correctement les messages.

Mais finalement, cela devient discutable. Si quelqu'un peut jouer le jeu eux-mêmes, alors peut également écrire un programme pour ingérer le jeu aussi. Donc, tout ce que vous faites est de les forcer à aller et venir de votre source externe (probablement un serveur). Une fois qu'ils ont découvert comment créer les messages sur votre serveur, c'est la même vieille histoire.

Mais vous oubliez un élément clé ici. C'est un jeu. Si quelqu'un triche dans un jeu, big whoop. Vous n'avez pas écrit le jeu pour les tricheurs. C'est la même chose avec les procédures de quête ou les guides de mise à niveau: les personnes qui souhaitent relever le défi de le découvrir par elles-mêmes ignoreront les solutions affichées. Même si vous pouviez rendre le jeu impossible sans le jouer (nous savons que c'est logiquement impossible, mais MÊME SI vous le pouvez), il ne faudrait qu'un gars qui passe avant de poster tout le nécessaire pour le battre. Donc, vous ne faites que retarder l'inévitable.

Passez votre temps à faire un jeu génial. Il y a dix choses dont chaque jeu a besoin et dernièrement, le cryptage n'en faisait pas partie.

Je crois que votre idée est inutile.

Quand quelqu'un joue à votre jeu, il choisit de le jouer, il ne le fait pas pour gagner un prix, il le fait pour le plaisir.

Les utilisateurs savent que le plus amusant est de jouer comme vous le voulez et ne triche pas . En tant que clients, ils vous font déjà confiance en tant que conteur.

De plus, dès que quelqu'un a trouvé la solution à un casse-tête, c'est-à-dire votre clé, il peut simplement le poster quelque part sur Internet.
Les joueurs qui veulent tricher pourront toujours le faire.

Cependant, si votre jeu présente plusieurs solutions, telles que les niveaux secrets de Super Mario Land, le cryptage de vos ressources empêchera un accès facile à ces solutions.

Bien que cela semble être un argument en faveur de votre idée, finalement ce n’est pas le cas.

Même avec le cryptage, il serait toujours possible de savoir que de telles solutions secrètes existent.
Une fois qu’une solution secrète est connue, il serait inutile d’empêcher les joueurs de consulter les ressources secrètes, car ils souhaiteraient toujours accéder aux parties cachées du jeu à travers le jeu lui-même (oui, même s’ils ont déjà vu tous les texture / clip / audio / texte).

Vous pouvez empêcher la fuite de l'existence de solutions secrètes en utilisant une technique inconsciente ¹ , mais cela resterait tout de même suspect (pourquoi faire cela s'il n'y a pas de solution secrète?), Les joueurs perdraient tout intérêt à les trouver et vous en auriez moins , pas plus.
Après tout, nous pouvons jouer quelques heures de plus après avoir terminé un jeu pour déclencher des œufs de Pâques, mais nous ne jouerons pas une minute de plus si les déclencher nécessiterait un effort titanesque!

Ce que vous voulez faire est comme un livre d'écriture dans lequel le prochain chapitre est crypté avec un mot du chapitre actuel, afin d'éviter que les lecteurs ne se gâchent la fin.
Pensez-y, n'est-ce pas inutile?

_{¹ Un peu comme VeraCrypt le faire avec des volumes cachés.}

Je ne commenterai pas la viabilité commerciale, mais d'un point de vue purement technique, le défi est amusant.

Je voudrais d’abord noter que tout ce qui n’est pas chiffré ne peut pas être protégé. Vous ne pouvez pas faire passer l’entrée dans un secret, les pirates vont trouver un moyen de contourner la porte, mais vous devez faire de la porte tout le secret. En termes d'actifs, cela ne signifie pas nécessairement que les textures entières, etc., ne font que chiffrer le plan, quels sont ceux qui sont utilisés et comment, et pour des raisons de performances, vous souhaiterez chiffrer le moins de données possible.

Deuxièmement, vous avez raison de dire que si la clé est contenue dans le logiciel, elle sera masquée par le logiciel. De nombreux jeux, lors de la protection du contenu, tentent d’utiliser soit la sécurité par obscurité, soit des mécanismes garantissant que le logiciel de jeu n’a pas été modifié. Ce ne sont que des tactiques dilatoires.

Votre idée d'utiliser la solution d'une énigme comme clé est plutôt intéressante, cependant, utiliser la clé fournie directement risque d'être facilement forcé. Traitez plutôt la saisie de l'utilisateur comme un mot de passe et utilisez un schéma de hachage de mot de passe à la pointe de la technologie: le hachage produit est la clé.

Cependant, même dans ce cas, il y a une erreur dans votre hypothèse selon laquelle la clé n'est pas présente dans le jeu. Si ce n'était pas le cas, vous ne pourriez pas diriger vos joueurs vers elle. Par conséquent, plutôt que d'essayer de forcer brutalement le coffre-fort, on pourrait plutôt procéder à l'ingénierie inverse des ressources du jeu à la recherche d'indices. Un casse-tête potentiel auquel je peux penser est d'utiliser des textures pour coder des glyphes, puis le mot de passe consiste en une partie des mots disponibles sur le clavier, comme le révèlent les endroits que le joueur aurait dû visiter (dans l'ordre):

• le noeud du problème est que la reconnaissance d'image est encore un peu difficile pour les ordinateurs
• sur le fait que nous superposons le fait que les craquelins CAPTCHA sont accordés pour les lettres et les chiffres, pas les glyphes personnalisés
• En outre, en combinant plusieurs textures (avec transparence) pour révéler le glyphe au joueur, aucun élément du jeu ne contient l'aspect que devrait avoir le glyphe.
• utilisez une autre texture (avec des fragments) un peu partout, mais jamais de manière à générer un glyphe complet sauf dans des endroits cachés que le joueur ne devrait jamais pouvoir atteindre

et tout programme d'extraction automatique de la combinaison gagnante de glyphes aura une journée bien remplie.

Troisièmement, la prochaine difficulté est le partage. Une fois que la solution à un secret est trouvée, il sera révélé. Idéalement, chaque utilisateur devrait se voir proposer une version légèrement différente du logiciel: une version dans laquelle la clé est unique pour sa version du jeu. Pour rendre cela pratique, je suppose qu'il serait plus facile de séparer le jeu (avec ses atouts) des "secrets" (cryptés) et du "pilote secret" (le générateur de clé, qui place de nombreux fragments de texture dans de nombreux endroits différents , dont certains forment les mots de passe).

Le vecteur d'attaque évident consiste à tromper le générateur en choisissant toujours le même mot de passe ou en incitant le vérificateur à accepter toujours le même mot de passe (en téléchargeant le fichier secret de quelqu'un d'autre, par exemple).

Ici, une solution potentielle serait de lier les fichiers au compte de l'utilisateur et de saler le mot de passe comme il est habituellement recommandé:

• lorsque l'utilisateur demande un ensemble de fichiers, générez de manière aléatoire un sel et autant de mots de passe que vous avez de secrets, puis créez les actifs secrets (vous pouvez limiter ce processus à une fois / jour / utilisateur par exemple, pour éviter de surcharger votre serveur)
• stocker l'horodatage de la génération et du sel dans les informations de compte de l'utilisateur
• renvoyer l'horodatage et les fichiers secrets personnalisés à l'utilisateur

Ensuite, lorsque l'utilisateur est prêt à soumettre un mot de passe:

• demander à l'utilisateur de se connecter (si elle ne l'était pas déjà)
• demande au logiciel d'envoyer à la fois le mot de passe d'horodatage et le glyphe
• si l'horodatage est différent de celui stocké, informez l'utilisateur qu'elle utilise un ensemble obsolète de fichiers secrets
• si le mot de passe a déjà été tenté plusieurs fois, informez l'utilisateur qu'elle utilise un ensemble obsolète de fichiers secrets
• sinon, hachez le sel + mot de passe pour produire la clé
• sinon, renvoyez la clé à l'utilisateur pour qu'il puisse voir ses fichiers personnalisés
• augmenter le nombre de tentatives de mot de passe par ce compte

Le but ici est d’empêcher le plus possible le partage de compte:

• Le partage d'un compte pour générer des fichiers secrets est (a) limité, car un seul peut être généré par jour et (b) inutile, car le dernier généré rend l'autre obsolète.
• le partage d'un compte et la distribution des fichiers secrets associés sont inutiles, car un mot de passe donné ne peut être utilisé que N fois avant qu'il ne produise plus la clé

Et nous y sommes presque.

Enfin, même là, un pirate informatique pourrait publier une version modifiée du jeu dans laquelle les actifs secrets sont déchiffrés et directement intégrés (en contournant votre schéma de vérification minutieux).

La solution est simple (et rend presque tout ce qui précède obsolète ¹ ): ne faites pas confiance au client.

Créez un classement sur votre site Web et suivez l'évolution des joueurs sur leur compte. Les joueurs peuvent affirmer qu'ils ont terminé le jeu comme ils le souhaitent, mais à moins que leur compte ne le reflète, tout le monde sait qu'ils ont triché ...

... cela s'appelle la pression sociale;)

¹ Excepté le fichier de positionnement de texture, que nous avons utilisé pour empêcher un programme de deviner la clé tout en permettant à un utilisateur de l'obtenir.

C'est une idée intéressante. une variante sur les disques de casse-tête et les systèmes de protection contre la copie manuels. Je pense que certains des jeux "ARG" fonctionnent de la sorte, où il est en quelque sorte compris que les joueurs agissent collectivement contre le concepteur de jeu.

Évidemment, une fois que la première personne l’a déchiffré, il le publiera sur Internet.

Le contenu génératif ou procédural peut fonctionner de la même manière: vous ne voyez pas le même monde qu'un autre joueur à moins de partager une "graine".

Je ne vois pas de problème juridique avec ce logiciel, même si Apple peut le rejeter depuis leur App store et vous devrez peut-être fournir la solution pour que cela soit approuvé sur les consoles de jeux.

Il est amusant de réfléchir à des mesures de sécurité supplémentaires, mais cela n’ajoute pas de valeur concrète à votre produit. Cela témoigne de votre réactivité vis-à-vis des craqueurs rencontrés avec votre produit. En principe, votre antagoniste vous rattrapera.

Contrairement aux développeurs qui s'épanouissent dans la créativité, les crackers sont des personnes analytiques: ils peuvent exploiter intuitivement votre programme. Lorsque les développeurs ont tendance à des mesures de sécurité excessives, ils sont dans le déni - que le pirate pourrait revenir sur leur système de protection, encore une fois .

Que vous souhaitiez participer à cette compétition de fond est votre appel - mais ne le laissez pas distraire de votre produit final, qui doit plaire au client. Un schéma de cryptage original qui transforme le jeu en slug n'aide pas.

Mason Wheeler a raison: vous ne pouvez pas le faire. Quelqu'un peut toujours désosser votre jeu s'il le souhaite.

De toute façon, vous n’avez pas besoin de "protéger" votre jeu comme vous le décrivez. Dès qu'une personne trouve l'œuf de Pâques, le secret est dévoilé. Si chaque copie du jeu a un œuf de Pâques différent, seule la copie du pirate informatique sera connue. Vous souciez-vous vraiment qu'un pirate informatique sur 1000 personnes ait trouvé l'œuf de Pâques sans passer par le jeu?

La loi sur le droit d'auteur est telle que personne ne peut gagner de l'argent avec votre jeu sans risquer un procès sérieux, le droit d'auteur vous protège donc.

En ce qui concerne les utilisateurs aléatoires mettant vos textures sur leur avatar de forum, et alors? Considérez cela comme une publicité de base.

Être obsédé par la "protection" des choses ne fera que vous distraire des réalités difficiles telles que: créer le jeu .

Quand je vois des gens sans produits parler de leurs systèmes de protection de la propriété intellectuelle pour des choses qui n'existent même pas, c'est une sorte de moment d'évasion pour moi parce que cela soulève un énorme drapeau rouge de connerie sur tout le projet.

Quelques possibilités:

• Obscurcissement du code ancien simple . Cela ne rendra pas le code impossible à décoder, mais au moins ce sera difficile.

• Solution côté serveur. Vous envoyez des commandes spéciales au serveur et celui-ci peut vous envoyer le code ... ou même télécharger un DLC.

• Vous pouvez utiliser la stéganographie pour masquer le code exécutable dans un autre contenu.

Cela ne sécurisera pas votre secret à 100% mais il semble que personne ne perdra même de l'argent si le secret est révélé.

Il est inutile comme n'importe quel autre schéma dans lequel vous stockez la clé et l'algorithme sur le client. Si vous demandez "où est la clé, je me fie à la saisie des utilisateurs et ne la stocke pas moi-même?", Rappelez-vous que votre puzzle a des règles et des ressources selon ses définitions - il est résolu par un algorithme et non par un renforcement brutal. Cet algorithme exact et ses ressources sont l'algorithme de génération de clé que vous venez de coder en dur dans le jeu à l'état obscurci. N'importe qui peut récupérer votre clé "inexistante" en écrivant simplement un petit programme qui résout votre casse-tête selon vos règles.