Paquete de contenido personalizado para archivos

Estoy a punto de comprar bastantes paquetes de modelos de un sitio web para crear prototipos de mi juego. En el contrato establece que debo protegerlos para evitar que el público tenga acceso a ellos.

Recuerdo haber trabajado con los juegos de Valve, ellos usaron .gcf (archivo de contenido del juego) que básicamente era un archivo de todo el contenido de cada juego. Empacaron en sonido / materiales / modelos / mapas / etc. Pensé que podría no ser una mala idea desarrollar algo similar a esto, y simplemente escribir una pequeña herramienta para permitirme agregar / eliminar archivos.

El problema es que realmente no tengo idea de cómo comenzar con algo como esto. Probé Google pero ni siquiera sabía qué buscar. Si alguien tiene alguna idea, enlaces que puedan ser útiles, o cualquier otra cosa, lo agradecería enormemente.

Almacene sus datos en un formato de archivo ligeramente oscuro, como 7-Zip .

Dales una extensión de archivo diferente para que un usuario casual no pueda abrirlos fácilmente con su programa zip.

Use physfs para leer y acceder a esos archivos. También le permite trabajar con archivos en su directorio local, para que pueda probar fácilmente nuevos recursos sin reconstruir sus paquetes. Muy recomendable.

Considere un cifrado muy trivial en el contenido, por ejemplo. Encriptación XOR . Escriba un pequeño archivo por lotes o script para construir sus paquetes, encriptando los datos a medida que ingresan, y use la misma función para descifrar los datos en su juego.

Esto no mantendrá alejado a un usuario determinado, nada lo hará. Pero será lo suficientemente bueno como para satisfacer los requisitos de sus paquetes de modelos.

Si solo está creando prototipos, entonces no me preocuparía empaquetar sus activos en un archivo GCF / ZIP / PAK; ¡El público no va a ver tu prototipo!

Además, el GCF de Valve proporciona tanta protección para su contenido como lo haría un archivo ZIP, es decir, cero. El archivo no está encriptado; Puede descargar GCFScape para explorar y extraer su contenido.

No vale la pena esforzarse en crear su propio sistema de archivos de paquetes a menos que tenga necesidades específicas en este momento que los archivos ZIP o el mecanismo de acceso a archivos del sistema operativo no satisfacen; de hecho, las únicas razones por las que puedo pensar son:

• Ofuscación de contenido (mantener sus archivos libres de modificaciones tiene sus usos; todavía sugiero que sea excesivo para sus necesidades actuales),
• Almacenar metadatos adicionales por archivo de una manera específica del juego para ayudar a impulsar los datos de su contenido de alguna manera,
• Eludir las limitaciones del sistema de archivos del sistema operativo, como la necesidad de acceder a miles de archivos pequeños rápidamente o garantizar el acceso contiguo a los datos. (Esta es una necesidad de facto cuando se trabaja en consolas).

Este requisito es, bueno, una mierda.

Dado que el juego puede acceder a los datos, y el usuario tiene acceso al juego, si tiene la habilidad y la determinación suficientes, logrará realizar una ingeniería inversa del formato que utilizó para almacenar los datos y tomar la clave eventual si fue lo suficientemente tonto para encriptarlo.

No puede agregar seguridad. Repito: simplemente NO PUEDES agregar seguridad . Solo puede agregar oscuridad, y la oscuridad es totalmente inútil, ya que, como dije, un usuario con suficiente habilidad y determinación simplemente lo romperá.

No firme nada que le pregunte algo que no se puede hacer.

Muchas veces noto que los paquetes de contenido personalizado tienden a ser un archivo .zip o .rar con una extensión diferente. Por supuesto, esto no es bueno si el sitio web quiere algún tipo de cifrado personalizado.

Algunas ideas

1] ¿Has utilizado un formato de modelo estándar (por ejemplo, .obj o .x) o utilizas un formato de modelo personalizado al cargar directamente en tu juego? Si tiene un formato personalizado, y uno tendría que aplicar ingeniería inversa al formato de su modelo para obtener una forma útil, entonces ya tiene cierto nivel de protección contra el destripador de activos oportunista.

2] El punto de Kylotan sobre el cifrado XOR es excelente, excepto para tener en cuenta que puede cifrar usando una secuencia generada por un número pseudoaleatorio (posiblemente sembrado por un hash en el nombre del archivo) para evitar largas secuencias de ceros en sus datos de origen que muestran su cadena de cifrado. Por supuesto, tendría que descifrar sus archivos en el lugar inmediatamente después de cargarlos, pero dividir su archivo cifrado en bloques reiniciables le permitirá iniciar el descifrado en el lugar en varios subprocesos si esto realmente se convirtió en una carga de tiempo de carga . Pero dudo seriamente que se requiera este nivel de "protección", particularmente, como otros han dicho, el destripador determinado lo evitará. p.ej. interceptando las llamadas de sorteo mediante el uso de una biblioteca de desvío de DLL y leyendo directamente los búferes de vértices / búferes de índice.

3] Tendría que preguntar al proveedor de activos original sobre sus requisitos de protección, pero podría ser solo una cuestión de agregar una propaganda sobre los derechos de autor de los activos a la pantalla de inicio de su programa y / o su EULA.