J'écris un jeu qui aura beaucoup d'informations (configuration, contenus, etc.) à l'intérieur de certains documents XML, ainsi que des fichiers de ressources. Cela facilitera la tâche de moi-même et d'autres de modifier le programme sans avoir à modifier les fichiers C ++ réels et sans avoir à recompiler.
Toutefois, comme le programme commence à croître, il y a une augmentation des fichiers dans le même répertoire que le programme. J'ai donc pensé à les mettre à l'intérieur d'une archive de fichiers (puisqu'il s'agit principalement de texte, cela va bien avec la compression).
Ma question est la suivante: sera-t-il plus facile de compresser tous les fichiers et:
Je pense que les nombres 1 et 2 sont similaires, mais je n'ai pas pu trouver d'informations sur si Zlib pouvait gérer des archives protégées par mot de passe.
Notez également que je ne veux pas que les fichiers à l'intérieur de l'archive soient "extraits" dans le dossier pendant que le programme l'utilise. Il ne devrait être que dans la mémoire du système.
3 Réponses :
Si je devais choisir parmi vos trois options, j'irais pour Crypto ++, car il s'adapte bien avec C ++ iostreams.
mais: vous êtes
Tout en mémoire, puis retour. Je reconsidérerais vraiment ce choix. Pourquoi ne pas utiliser, par exemple. SQLite pour stocker toutes vos données dans une base de données basée sur un fichier (SQLite ne nécessite aucun processus de base de données externe)?
Cryptage peut être ajouté via diverses extensions ( voir ou Vous n'obtenez pas de compression, mais encore une fois, en utilisant SQLite au lieu de XML, ce n'est pas un problème de toute façon (ni donc je pense).
J'ai envisagé une base de données, mais comme il existe de nombreux types de fichiers (non seulement de la configuration XML), je ne pense pas qu'il serait logique de stocker un fichier .png, par exemple dans une base de données. De plus, si je devais éditer de nombreux ou un fichier unique, je pourrais simplement: décompresser le fichier, le modifier et faire la réprimer. Je pense que une base de données serait un peu plus compliquée.
Définir un mot de passe (comme un zip protégé par mot de passe), puis fournissez le mot de passe lorsque le programme en a besoin
Premièrement, vous ne pouvez pas faire cela à moins que vous ne poserez à un utilisateur pour le mot de passe. Si cette clé de cryptage est stockée dans le code, ne pariez pas sur un ingénieur inversé déterminé de le trouver et de la déchiffrer les archives.
La grande règle est la suivante: vous ne peut pas Stocker les touches de chiffrement dans votre logiciel, car si vous le faites, quel est le point d'utilisation du cryptage? Je peux trouver votre clé.
Maintenant, sur d'autres points. ZLIB ne prend pas en charge le cryptage et car ils pointent, pkzip est plutôt cassé de toute façon . Je soupçonne si vous étiez tellement enclin à en trouver un, vous trouverez probablement une bibliothèque zip / compression capable de gérer le cryptage. ( ZipRarchive Je crois que les poignées Zip + AES, mais vous devez payer pour cela).
Mais je seconde la réponse de Daniel qui vient d'être affichée sur mon écran. Pourquoi? Le chiffrement / la compression ne vous donnera aucun avantage à moins que l'utilisateur présente une forme de jeton (mot de passe, SmartCard, etc.) ne présente pas dans vos fichiers binaires ou associés compilés. De même, si vous n'utilisez pas de masses d'espace disque, pourquoi compresser?
Je n'ai jamais utilisé SQLite avant, donc si vous êtes en désaccord, veuillez en parler, mais quand je suis arrivé à l'idée d'archive, c'était parce que je pouvais organiser des fichiers similaires dans leur propre archive (BGM, System, MAP1, MAP2) qui ferait des mises à jour Simple, car tout le programme de mise à jour doit faire est de supprimer le fichier existant et de le remplacer par une version plus récente. Avec SQLite, l'organisation générale de tous les fichiers et du processus de mise à jour serait plus chaotique.
"Vous ne pouvez pas stocker les clés de cryptage dans votre logiciel, car si vous le faites, quel est le point d'utilisation du cryptage?". Le cryptage asymétrique offre une protection des sommages: les archives peuvent être lisibles avec les clés de déchiffrement (publiques), mais non écrites.
@Msalters True, mais ensuite lesdites données doivent rester fixes ou réapprovisionnées à partir du fournisseur d'origine, c'est-à-dire le titulaire de la clé de cryptage privé. Vous ne pouvez pas empêcher l'utilisateur de lire ces archives, que je
De même, rien ne vous empêche l'attaquant remplaçant ladite clé publique dans le binaire. Pas facile, mais faisable. Bien sûr, à ce niveau d'ingénierie inverse, ils peuvent être capables de contourner toute quelle que soit la caractéristique protégée. Le point ici est que le cryptage comme méthode n'arrête pas d'arrêter les ingénieurs inverse déterminés. Jamais.
Je pense que vous avez mal compris les possibilités soulevées par cryptage.
Tant que le programme est exécuté sur un hôte non approuvé, il est impossible de ne rien garantir.
Au plus, vous pouvez le rendre difficile (cryptage, obfuscation de code) ou extrêmement difficile (code auto-modificateur, détection de débogage / crochets), pour une personne à inverser l'ingénieur du code, mais vous ne pouvez pas empêcher la fissuration. Et avec Internet, il sera disponible pour tous dès qu'il est fissuré par une seule personne.
La même chose se passe, véritablement, pour empêcher un individu d'altérer la configuration. Quelle que soit la méthode (CRC, hachage -> à la manière dont le cryptage n'est pas destinée à empêcher la falsification), il est toujours possible d'inverser l'ingénieur, il a suffisamment de temps et de moyens (et de motivation).
Le seul moyen de garantir une configuration négligée serait de le stocker quelque part que vous contrôlez (un serveur), le signer (asymétrique) et le programme vérifie la signature. Mais cela n'empêcherait pas que quelqu'un de venir avec un patch qui permettrons à votre programme d'exécuter avec un fichier de configuration fourni (non signé) à l'utilisateur ...
Et vous connaissez le pire d'entre eux? Les gens préféreront probablement la version fissurée, car libéré du fardeau de toutes ces mesures de "sécurité" qu'il fonctionnera plus vite ...
Note: Oui, il est illégal, mais soyons pragmatiques ...
Remarque: En ce qui concerne la motivation, plus vous êtes intelligent avec la protection du programme, plus il est attrayant aux pirates pirates -> C'est comme un teaseur de cerveau pour eux!
Alors, comment fournissez-vous un service sécurisé?
Il ne peut être fait que si vous offrez un client léger et exécute tout sur un serveur en qui vous avez confiance ... Et même vous aurez peut-être du mal à vous assurer que personne ne trouve que les portes de votre serveur que vous n'avez pas pensé. à propos de.
Dans vos chaussures, je vous assurerais simplement de détecter la falsification de la lumière avec la configuration (traitez-la comme hostile et assurez-vous de valider les données avant de rouler quoi que ce soit). Une fois que toute corruption de fichier est également probable et si un fichier de configuration corrompu signifiait une machine de client ruiné, il y aurait un enfer à payer :)
Même si vous n'avez pas répondu à ma question, cela me donne beaucoup de choses à penser, et vous avez souligné des choses que j'aurais oublié moi-même. Mais tu as raison. Dans mon jeu, j'ai un "fichier facultatif" appelé débogage. Si présent, il y aura des informations de débogage à l'intérieur, par exemple: désactivation du service de correction, vous permettant de jouer sans corriger. Ou, un autre exemple: permettant au jeu de lire dans un dossier de fichiers plutôt que d'une archive, si l'archive n'est pas présente. C'est génial pour créer rapidement du contenu, mais je ne voudrais pas que quelqu'un l'utilise. Donc, je vais le garder au serveur.
Pourquoi avez-vous besoin de crypter ce genre de choses?
Il doit être crypté parce que je ne veux pas que quelqu'un soit modifié ou inverse l'ingénierie.
Si les données et le code exécutable sont sur la machine de l'utilisateur, votre cryptage n'arrête pas un pirate informatique déterminé.
AFAIK, de nombreux jeux utilisent leur propre système de fichiers virtuel, et généralement uniquement pour des fichiers en lecture seule. Pour protéger un jeu enregistré, vous pouvez utiliser CRC.