Package de contenu personnalisé pour les fichiers

13

Je suis sur le point d'acheter plusieurs packs de modèles sur un site Web pour prototyper mon jeu. Dans le contrat, il est stipulé que je dois les protéger afin d'empêcher le public d'y avoir accès.

Je me souviens avoir travaillé avec les jeux Valve, ils utilisaient .gcf (fichier de contenu de jeu) qui était essentiellement une archive de tout le contenu de chaque jeu. Ils ont emballé dans le son / matériaux / modèles / cartes / etc. J'ai pensé que ce n'était peut-être pas une mauvaise idée de développer quelque chose de similaire, et d'écrire juste un petit outil pour me permettre d'y ajouter / supprimer des fichiers.

Le problème est que je n'ai vraiment aucune idée de comment commencer quelque chose comme ça. J'ai essayé Google mais je ne savais même pas quoi chercher. Si quelqu'un a des idées, des liens qui pourraient être utiles ou autre chose, je l'apprécierais grandement.

game-design c++ Aidan Knight
la source

Réponses:

9

Stockez vos données dans un format d'archive légèrement obscur tel que 7-Zip .

Donnez-leur une extension de fichier différente afin qu'un utilisateur occasionnel ne puisse pas facilement les ouvrir avec leur programme zip.

Utilisez physfs pour lire et accéder à ces fichiers. Il vous permet également de travailler avec des fichiers dans votre répertoire local, de sorte que vous pouvez facilement tester de nouvelles ressources sans reconstruire vos packages. Hautement recommandé.

Considérez un cryptage très trivial sur le contenu, par exemple. Chiffrement XOR . Écrivez un petit fichier batch ou un script pour construire vos packages, en chiffrant les données au fur et à mesure, et utilisez la même fonction pour déchiffrer les données de votre jeu.

Cela n'empêchera pas un utilisateur déterminé - rien ne le fera. Mais il sera suffisant pour satisfaire les exigences de vos packs de modèles.

Kylotan
la source
Quelqu'un m'a recommandé des physfs l'autre soir. Jolie petite bibliothèque.
greyfade
8

Si vous ne faites que du prototypage, je ne me soucierais pas de regrouper vos actifs dans un fichier GCF / ZIP / PAK; le public ne verra pas votre prototype!

De plus, le GCF de Valve offre autant de protection pour votre contenu qu'un fichier ZIP - c'est-à-dire zéro. Le fichier n'est pas crypté; vous pouvez télécharger GCFScape pour parcourir et extraire son contenu.

Il ne vaut pas mettre l'effort dans la création de votre propre système de fichiers pack sauf si vous avez des besoins spécifiques en ce moment qui ne sont pas pris en charge par ZIP fichiers ou propre mécanisme d'accès aux fichiers du système d' exploitation; en fait, les seules raisons auxquelles je peux penser sont:

  • Obfuscation de contenu (garder vos fichiers à l'abri du bricolage a ses utilisations; je suggère toujours sa surpuissance pour vos besoins actuels),
  • Stocker des métadonnées supplémentaires par fichier d'une manière spécifique au jeu pour aider les données à générer votre contenu d'une manière ou d'une autre,
  • Contourner les limitations du système de fichiers du système d'exploitation, telles que la nécessité d'accéder rapidement à des milliers de petits fichiers ou d'assurer l'accès aux données contiguës. (Il s'agit d'un besoin de facto lorsque vous travaillez sur des consoles.)
Blair Holloway
la source
Je suis complètement d'accord. Le problème est que je ne pourrai pas publier une démo sans une certaine forme de protection en place. ZIP est trop connu, PAK est à peu près le même. Au moins avec un format personnalisé (Valve nécessite une clé CTX codée en dur dans le moteur de jeu pour accéder aux fichiers GCF), le joe moyen ne pourra pas simplement exécuter un outil d'extraction dessus et y entrer.
Aidan Knight
Woops, je n'avais pas réalisé qu'entrer ne descendrait pas. Quoi qu'il en soit, j'ai trouvé ce nemesis.thewavelength.net/index.php?p=35 qui semble être une bibliothèque open source qui fournit des fonctionnalités GCF indépendantes des jeux Valve. Le problème que je vois ici est qu'il est beaucoup trop robuste, et je cherchais quelque chose d'un peu plus simple juste pour créer une version de base à développer plus tard. (Pour être honnête, la façon dont il code me fait mal à la tête)
Aidan Knight
4
Par curiosité, ce contrat mentionne- t- il comment vous êtes censé protéger leur contenu?
Blair Holloway
2
c'est le but! Puisque vous ne pouvez pas vraiment le sécuriser, il est obligatoire pour vous (si vous n'êtes pas stupide) de savoir exactement ce que ces incompétents veulent que vous fassiez. Sinon quoi que vous fassiez, car cela ne fonctionnera pas, vous pouvez être tenu responsable (de ne pas faire quelque chose qui ne pourrait pas être fait en premier lieu).
o0 '.
3

Cette exigence est, bien, des conneries.

Étant donné que le jeu peut accéder aux données et que l'utilisateur a accès au jeu, s'il est suffisamment compétent et déterminé, il parviendra à rétroconcevoir le format que vous avez utilisé pour stocker les données et à saisir la clé éventuelle si vous étiez assez fou. pour le crypter.

Vous ne pouvez pas ajouter de sécurité. Je le répète: vous NE POUVEZ PAS ajouter de sécurité . Vous pouvez seulement ajouter de l'obscurité, et l'obscurité est totalement inutile, car - comme je l'ai dit - un utilisateur avec suffisamment de compétence et de détermination va simplement le casser.

Ne signez rien qui vous demande quelque chose qui ne peut pas être fait.

o0 '.
la source
1
L'obscurité n'est pas inutile car la plupart des utilisateurs n'ont pas "suffisamment de compétences et de détermination". Il en va de même pour la sécurisation de votre maison: quiconque veut vraiment y entrer peut le faire, mais il est toujours considéré comme intéressant de le rendre gênant pour eux.
Kylotan
Contrepoint: l'obscurité est inutile car contrairement à l'entrée par effraction dans votre maison, une fois que quelqu'un est entré dans votre jeu, il peut être trivial pour quiconque de le faire. (D'un autre côté - l'obscurité n'est pas inutile, car Brett a besoin des modèles. Je ne pense pas que l'analogie résiste bien.)
Si quelqu'un vole une pièce d'or de votre maison, il a votre pièce d'or. Si quelqu'un saisit votre précieux modèle de votre fichier de données, il peut faire autant de copies qu'il le souhaite. Donc, non, cet exemple ne fonctionne pas car ici, peu importe le nombre de personnes qui traversent votre protection sans valeur: une suffit.
o0 '.
L'un suffit, en supposant que les autres se soucient suffisamment d'arrêter de regarder leurs fichiers locaux et d'aller en ligne pour regarder, et à condition que quelqu'un fasse l'effort de publier les choses en ligne (ce qui est illégal, alors que la visualisation de votre copie locale ne l'est pas), ou de publier instructions, qui supposent que vous avez la patience de les suivre. Toutes les petites choses aident.
Kylotan
1
Chaque petit aide pour quoi ? Empêcher les utilisateurs de regarder vos données et de ne rien faire est tellement inutile que cela me rend triste. Cette exigence idiote existe très certainement pour empêcher d'autres personnes de réutiliser ces données, vous n'avez donc qu'à vous soucier de personnes déterminées qui feront de leur mieux et réussiront (car, comme je l'ai dit, à long terme, elles ne peuvent tout simplement pas échouer) .
o0 '.
1

Souvent, je remarque que les packages de contenu personnalisés ont tendance à être une archive .zip ou .rar avec une extension différente. Bien sûr, cela ne sert à rien si le site Web souhaite un cryptage personnalisé quelconque.

Christopher Horenstein
la source
Oui, Ogre prend déjà en charge le chargement des ressources via un fichier zip. Quelqu'un a mentionné dans un salon de discussion juste en train de mot de passe le fichier zip, mais avec la quantité d'outils pour les casser, ce n'est vraiment pas mon premier choix. J'aimerais vraiment faire quelque chose de similaire aux fichiers .gcf que Valve utilise, mais je ne sais même pas quoi chercher pour commencer.
Aidan Knight
Si quelqu'un déchire votre fichier zip, quel est votre problème? Vraiment. Ils peuvent casser tout ce que vous pouvez leur lancer. Tu as essayé. D'où tirez-vous la ligne de conduite pour laquelle ces concédants de licence peuvent vous tenir responsable?
Neverender
1

Quelques idées:

1] Avez-vous utilisé un format de modèle standard (par exemple .obj ou .x) ou utilisez-vous un format de modèle personnalisé lors du chargement directement dans votre jeu? Si vous avez un format personnalisé et qu'il faudrait inverser le format de votre modèle pour le mettre sous une forme utile, alors vous avez déjà un certain niveau de protection contre le ripper d'actifs opportuniste.

2] Le point de Kylotan sur le chiffrement XOR est excellent, sauf pour noter que vous pouvez chiffrer en utilisant une séquence générée par un nombre pseudo-aléatoire (éventuellement ensemencée par un hachage sur le nom de fichier) pour éviter de longues séquences de zéros dans vos données source montrant votre chaîne de chiffrement. Bien sûr, vous devrez décrypter vos fichiers sur place immédiatement après leur chargement, mais la division de votre fichier crypté en blocs redémarrables vous permettra de lancer le décryptage en place sur plusieurs threads si cela devient vraiment une charge de temps de chargement . Mais je doute sérieusement que ce niveau de "protection" soit nécessaire - en particulier, comme d'autres l'ont dit, le ripper déterminé le contournera. par exemple. en interceptant les appels de dessin en utilisant une bibliothèque de détour de DLL et en relisant directement les tampons de vertex / tampons d'index.

3] Vous devrez demander au fournisseur d'actifs d'origine quelles sont ses exigences en matière de protection, mais il pourrait simplement s'agir d'ajouter un texte de présentation sur les droits d'auteur des actifs à votre écran de démarrage du programme et / ou à votre CLUF.

jpaver
la source