Contenido encriptado en juegos

He tenido esta idea de usar el cifrado para evitar que los usuarios descubran contenido en mi programa fuera del programa. Al igual que los usuarios, pueden encontrar texturas que nunca se usaron en el juego para ser parte de algún tipo de huevo de Pascua al revisar los datos del juego. Esto puede, por ejemplo, arruinarlo para todos si se publica en línea.

Imagina una habitación secreta donde el jugador tiene que presionar los números correctos en una puerta de seguridad en el juego, que si es correcto debería generar la clave de descifrado correcta y luego descifrar esa parte del nivel y abrir la puerta. Por lo tanto, hacer que el huevo de Pascua sea inaccesible incluso cuando se mira a través de los datos del juego, ya que la clave no está realmente almacenada, se genera en función de la entrada del usuario.

Aquí hay otro ejemplo de lo que estaba imaginando. Tengo un juego de rompecabezas con 20 niveles, cada uno encriptado con una clave diferente. En lugar de almacenar la clave de descifrado con el programa permitiendo directamente a alguien descompilar el programa y encontrarlo, en su lugar, genero la clave de cifrado / descifrado en función de la solución del rompecabezas anterior. De esta manera, el jugador tendría que descifrar el rompecabezas antes de obtener información sobre el siguiente nivel, incluso cuando revise los datos del juego.

El jugador, si está bien informado, podría forzarlo con fuerza bruta "fácilmente" dado que la cantidad de soluciones de rompecabezas es probablemente menor que la cantidad de claves de descifrado. Realmente es una cuestión de complejidad del rompecabezas y no es muy importante aquí. Aunque publiqué una respuesta al respecto aquí

¿Hay programas / juegos hoy que hayan hecho algo como esto? ¿Almacenar contenido encriptado en sus juegos? ¿Y si no por qué? ¿Hay muchas reglas y regulaciones al respecto, ya sea a nivel de tienda o país? ¿Alguien ve alguna trampa obvia que me falta? Ignorando cosas como la experiencia del usuario, la idea me parece sólida y me da curiosidad por qué no he visto esto antes.

Editar : Puede que no esté claro exactamente lo que estoy diciendo, así que aquí hay un ejemplo más concreto.

Digamos que tengo una función que toma una cadena de 20 caracteres y genera una clave simétrica que puedo usar para cifrar / descifrar parte del contenido del juego. La única forma en que el usuario puede llegar a ese contenido es conocer esos 20 caracteres y generar la misma clave. Esta clave nunca se almacena directamente y se genera sobre la marcha en función de la entrada del usuario. Estos personajes estarían ocultos en el juego en lo que podrían ser libros, diálogo con NPC, incluso incluso fuera del juego en la parte posterior de la caja.

Entonces, con 2 * 10 ^ 28 combinaciones posibles para probar, probablemente sea más probable que las personas encuentren el contenido de la manera prevista en lugar de mirar a través de los datos del juego.

Edición 2 : el contenido en cuestión se cifrará con una clave arbitraria y secreta antes de ser enviado al consumidor. Obviamente, esta clave no se enviará con el juego. Él o ella de alguna manera tendrían que volver a armar la clave dada una serie de pistas hechas en base a la clave, y que están ocultas en todo el juego o en otro lugar. Sin embargo, este sistema sería transparente para el usuario, ya que no sabría que el contenido estaba encriptado a menos que realmente revisara los datos del juego.

Como muchos han mencionado, esto tiene un inconveniente obvio en que su caso de uso es limitado. Una vez que una sola persona lo ha descubierto, puede compartirlo con todos los demás, si no es la clave / solución, entonces el contenido en sí. Sin embargo, si su intención es mantener algo tan secreto que una sola persona no debería ser capaz de resolverlo y las personas tienen que trabajar juntas para resolverlo, o tiene miedo de que su huevo de Pascua esté tan bien oculto (por diseño) que es más probable que alguien lo encuentre en el código más bien a través del juego. Entonces creo que esto podría funcionar muy bien.

Yo personalmente recomendaría usarlo solo una vez por juego y solo para cosas que no afecten el juego central, por ejemplo, huevos de pascua, un final secreto. Cualquier rompecabezas tendría que ser tan complicado o bien oculto para frenar a las personas lo suficiente como para que valga la pena cifrar el contenido y si este rompecabezas se interpuso en el camino de las personas que progresan, entonces probablemente nadie se esté divirtiendo.

Esta pregunta es si es posible (no solo comercialmente viable o alguna otra interpretación) forzar al menos a 1 usuario a resolver un rompecabezas en lugar de piratear para desbloquear cierto contenido del juego.

Que yo sepa esto es definitivamente posible. De hecho, es extraño para mí que otras respuestas digan que no es posible, incluso cuando se ha declarado explícitamente que la clave no se genera ni se almacena, simplemente se lee desde el estado del juego (lo que podría tener posibles problemas de googleplexes). valores). El argumento de que "el juego sabe cómo descifrarlo" para que no funcione implicaría que cualquier software de cifrado / descifrado de código abierto (por ejemplo, TrueCrypt) es intrínsecamente inseguro porque usted sabe "cómo" descifrar contenedores (simplemente ingrese una cadena basada en la entrada del teclado, es simple ¿verdad?).

En el caso más simple, imagine que el juego en sí es un simulador de teclado y hace la pregunta "¿cuál es la contraseña de mis archivos encriptados?", Claramente todos estamos de acuerdo en que tener el código fuente del juego no ayudaría. Ahora imagine que el juego hace las preguntas "¿cuál es el nombre del animal más grande en la Tierra concatenado con el nombre del animal más pequeño?". ¿No está claro que incluso tener el código fuente del juego no ayudaría, y todavía tienes que resolver el rompecabezas?

Con respecto a si esto es posible, la respuesta es absoluta SÍ, esto es posible.

Ha sido probado Muchas, muchas veces. Hay toda una subsector dedicada a intentar utilizar el cifrado para evitar que los usuarios accedan a un programa como mejor les parezca. Y nunca funciona. Los mejores esquemas de protección tienden a durar aproximadamente un mes antes de que se descifren, y lo que pasa con Internet es que, una vez que se descifra una vez, se descifra en todas partes para siempre tan pronto como alguien lo publica. La trampa obvia que falta es que para que su programa use los datos, debe contener toda la información necesaria para descifrarlos, y si la computadora puede hacer eso, una persona con acceso a la computadora puede hacerlo. ese.

Se le ha llamado "el problema fundamental de la criptografía": Alice quiere enviar un mensaje a Bob, sin que Charlie pueda leerlo, incluso si se entera de él. El problema con el enfoque que está proponiendo es que Bob y Charlie son la misma persona en este caso.

Puedo entender el deseo de no malcriar a sus usuarios, pero si las personas quieren spoilers, los encontrarán, y si no lo hacen, tenderán a evitarlos activamente. Pero si realmente quieres hacer un gran juego, toma la ruta opuesta: apertura radical. Mira cosas como Neverwinter Nights , Starcraft o la serie Elder Scrolls , juegos que siguen siendo populares durante años y años después del lanzamiento. Lo hacen porque incluyen potentes herramientas de diseño con el juego que permiten a los usuarios profundizar en todo, descubrir cómo funciona y crear y compartir su propio contenido. Un juego es solo un juego, hasta que se convierte en una comunidad y las comunidades perduran.

He estado lo suficiente como para saber que si el contenido está allí, alguien lo encontrará. Hacerlo más difícil solo atraerá a personas más decididas. Cuanto más popular sea su producto, más interesante se vuelve. En parte porque es un desafío, en parte porque hay tantos lugares en los que puedes ganar "credibilidad" publicando este tipo de información.

Si el juego genera la clave localmente, puede encontrar una manera de hacer trampa en el juego hasta el punto donde se genera la clave, o simplemente desenterrar el código correcto. Si la clave se le envía desde un servidor al completar ciertos pasos en el juego, alguien engañará a su servidor para que crea que han llegado lo suficientemente lejos.

Al final, tu juego se beneficiará mucho más del tiempo que pases haciéndolo divertido y atractivo, además de dificultar descubrir cuál es el color del siguiente nivel.

La razón principal por la que esto debería estar en gamedev.SE es que hacer este cifrado tiene consecuencias en el juego.

Desea que la solución a un rompecabezas sea la clave de cifrado para el siguiente. Es decir, los datos reales de esa solución deben descifrar el siguiente rompecabezas. Esto significa que la clave de descifrado no forma parte de los datos de tu juego en ningún lado; Es generado por el jugador.

Y aquí está la consecuencia. El descifrado suele ser binario. O tiene la clave de descifrado exacta necesaria para desencriptar los datos, o no la tiene.

La consecuencia aquí es que cualquier juego que diseñe debe tener un enfoque tan limitado que solo haya una solución posible para cada nivel. Por lo tanto, la mecánica de tu rompecabezas debe diseñarse con mucho cuidado de modo que el jugador no pueda resolver el rompecabezas de una manera diferente a tu intención.

Tome Portal, Test Chamber 10 por ejemplo. Se supone que debes ir a la izquierda, hacer algunas cosas, luego ir a la derecha y hacer algunas cosas, todo para bajar una plataforma.

O simplemente puedes darte un poco de velocidad y lanzarte a la plataforma cuando entras.

GLaDOS: Entonces hiciste un juego de rompecabezas. Un juego de rompecabezas que castiga a las personas que más disfrutan de los juegos de rompecabezas. Buen trabajo. Pero al menos esos piratas informáticos no obtendrán sus valiosos datos. Porque las personas que disfrutan resolviendo juegos de rompecabezas son el tipo exacto de personas que buscan soluciones para juegos de rompecabezas en línea.

Entonces eso vale totalmente la pena.

Entonces, los juegos de rompecabezas como Adventures of Lolo, SpaceCHEM y Portal (entre millones de otros) están listos . En cambio, tienes que diseñar tu juego de tal manera que sea imposible crear un rompecabezas que tenga más de una solución. Eso requiere mucho cuidado y, por lo general, requiere una restricción de juego sustancial.

GLaDOS: Entonces hiciste un juego de rompecabezas. Un juego destinado a ser jugado por personas a las que les gusta encontrar soluciones creativas a los rompecabezas. E hiciste un juego que no tiene soluciones creativas para los rompecabezas. * aplauso *

No digo que no puedas crear un juego así. O que tal juego no puede ser bueno. Solo que ese juego debería diseñarse de cierta manera.

Ah, y tienes que diseñar esta jugabilidad de modo que sea imposible (o muy difícil) encontrar mecánicamente una solución.

GLaDOS: Entonces hiciste un juego de rompecabezas. Un juego de rompecabezas que es más interesante piratear que jugar. Buen trabajo.

Por supuesto, hay una advertencia para esto: el significado de "solución". O, más concretamente, ¿qué elementos de una solución tiene en cuenta?

Para cualquier juego que implique un personaje en movimiento, probablemente no va a utilizar los movimientos exactos del personaje para construir la clave de descifrado. Por ejemplo, si tiene un juego de rompecabezas en el que el jugador necesita recoger ciertos elementos para "resolver" el rompecabezas, puede hacer que la clave dependa del orden en que se tocan esos elementos.

Por supuesto, esto se encuentra con el problema anterior, donde un jugador encuentra una manera de hacer las cosas fuera de orden. Lo que nuevamente significa que tienes que diseñar el rompecabezas de modo que solo haya un orden en el que puedas recoger las cosas.

Además, cualquier elemento que use para construir la clave de descifrado debe proporcionar suficiente entropía para dificultar el descifrado por fuerza bruta. Usando la mecánica de orden de colección anterior, cada elemento nuevo es efectivamente un bit extra. Si un nivel solo tiene 8 elementos, está haciendo un cifrado de 8 bits. Que es una mierda; la mayoría de los teléfonos inteligentes pueden manejar eso en segundos.

Hoy en día, necesita al menos 128 para hacerlo aún un poco desafiante. Lo que ahora significa que cada nivel debe tener muchas cosas, lo que una vez más impacta el diseño de tu juego.

Las respuestas aquí son buenas; Sin embargo, lo miraría desde otra perspectiva. Lo que estás describiendo es una característica . Las características tienen costos y beneficios. Los costos incluyen tanto los costos en dólares de la creación de la función como los "costos de oportunidad". Esos son: en un mundo donde tienes dólares finitos y horas finitas y programadores finitos, cada función que haces significa un número infinito de funciones posibles que no se hicieron en su lugar.

Entonces la pregunta es: ¿puede indicar los costos de esta función en términos reales? No hay funciones gratuitas, así que sea realista sobre los costos. ¿Estás dispuesto a pagar mil dólares por esta función? ¿Cien mil? ¿Un millón? ¿Qué características está dispuesto a cortar para tener esta característica?

Creo que una vez que comience a priorizar las cosas en términos de costos, beneficios y oportunidades perdidas, se dará cuenta de que ya ha pasado demasiado tiempo pensando en esta característica cuando podría haber estado pensando en formas de hacer que el juego sea más divertido.

El problema de Alice Bob y Eve ilustra esto bien. Como Mason señaló en su respuesta, no puedes guardar un secreto de Eve si Eve también es Bob.

Por lo tanto, cualquier solución consistiría en que Bob no tenga toda la información necesaria. Tendría que tratar cada nivel como un mensaje individual, cifrado por separado, y tener una fuente externa de mensajes para el siguiente nivel que pudiera mantener los mensajes correctamente.

Pero eventualmente, eso se vuelve discutible. Si alguien puede jugar el juego ellos mismos, también puede escribir un programa para ingerir el juego también. Entonces, todo lo que está haciendo es obligarlos a ir y venir desde su fuente externa (probablemente un servidor de algún tipo). Una vez que descifran cómo elaborar los mensajes a su servidor, es la misma historia de siempre.

Pero estás olvidando un elemento clave aquí. Es un juego. Si alguien hace trampa en un juego, gran grito. No escribiste el juego para los tramposos. Es lo mismo con los recorridos de búsqueda o las guías de nivelación: las personas que quieren el desafío de resolverlo por su cuenta ignorarán las soluciones publicadas. Incluso si pudieras hacer imposible descifrar el juego sin jugarlo (sabemos que es lógicamente imposible, pero AUN SI PUEDES) solo se necesitaría un tipo caminando antes de que publicara todo lo necesario para vencerlo. Entonces solo estás retrasando lo inevitable.

Pasa tu tiempo haciendo un juego increíble. Hay diez cosas que todo juego necesita y la última vez que miré, el cifrado no era una de ellas.

Creo que tu idea no tiene sentido.

Cuando alguien juega tu juego, eligen jugarlo, no lo hacen para ganar un premio, lo hacen por diversión.

Los usuarios saben que lo más divertido es jugar de la manera que quisiste decir y no engañarán , ya que tus clientes ya confían en ti como narrador.

Además, tan pronto como alguien encuentre la solución a un rompecabezas, es decir, su clave, simplemente puede publicarlo en algún lugar de Internet.
Los jugadores que quieran hacer trampa aún podrían hacerlo.

Sin embargo, si su juego presenta múltiples soluciones, como los niveles secretos de Super Mario Land, cifrar sus activos evitará un fácil acceso a esas soluciones.

Si bien esto parece un punto a favor de su idea, al final no lo es.

Incluso con el cifrado, aún sería posible saber que existen soluciones secretas.
Una vez que se sabe que existe una solución secreta, evitar que los jugadores miren los activos secretos sería irrelevante, ya que aún querrían acceder a las partes ocultas del juego a través del juego en sí (sí, incluso si ya han visto todos los elementos ocultos). textura / clip / audio / texto).

Puede evitar la filtración de la existencia de soluciones secretas utilizando alguna técnica inconsciente ¹ , pero aún sería sospechoso (¿por qué hacer eso si no hay soluciones secretas?), Los jugadores perderían interés en encontrarlas y usted tendría menos jugadores , no mas.
Después de todo, podemos jugar un par de horas más después de haber completado un juego para activar algunos huevos de Pascua, ¡pero no jugaremos ni un minuto más si activarlos requiere un esfuerzo titánico!

Lo que desea hacer es como un libro de escritura donde el próximo capítulo está encriptado con una palabra del capítulo actual, para evitar que los lectores se estropeen el final.
Piénsalo, ¿no tiene sentido?

_{^{1 Al} igual que VeraCrypt lo hace con volúmenes ocultos.}

No comentaré sobre la viabilidad comercial, sin embargo, desde una perspectiva técnica pura, es un desafío divertido.

Primero me gustaría señalar que cualquier cosa que no esté encriptada no se puede proteger. No se puede cerrar la entrada a un secreto, los crackers encontrarán una forma de rodear la puerta, sino que debes hacer que todo el secreto sea la puerta misma. En términos de activos, esto no significa necesariamente las texturas completas, etc., simplemente encriptar el plan y cuáles se usan y cómo es suficiente, y por razones de rendimiento, deseará encriptar la menor cantidad de datos posible.

En segundo lugar, tiene razón en que si la clave está contenida en el software, se burlará del software. Muchos juegos, cuando protegen el contenido, intentan usar la seguridad por oscuridad o mecanismos que aseguran que el software del juego no haya sido alterado. Esas son solo tácticas dilatorias.

Su idea de usar la solución de un enigma como clave es bastante interesante, sin embargo, usar la clave proporcionada directamente es probable que sea fácilmente forzado por la fuerza bruta. En su lugar, trate la entrada del usuario como una contraseña y use un esquema de hash de contraseña de última generación: el hash producido es la clave.

Sin embargo, incluso entonces, hay un error en su suposición de que la clave no está presente en el juego. Si no fuera así, no podrías dirigir a tus jugadores hacia él; por lo tanto, en lugar de tratar de forzar la caja fuerte, uno podría hacer ingeniería inversa de los activos del juego en busca de pistas. Un rompecabezas potencial que se me ocurre es usar texturas para codificar glifos, y luego la contraseña consistiría en algunos de los disponibles en el teclado, como lo revelan las ubicaciones que el jugador debería haber visitado (en orden):

• El quid del problema es que el reconocimiento de imágenes sigue siendo algo difícil para las computadoras
• además de que ponemos en capas el hecho de que las galletas CAPTCHA están ajustadas para letras y dígitos, no para glifos personalizados
• además de eso, combinamos el hecho de que al combinar múltiples texturas (con transparencia) para revelar el glifo al jugador, ningún activo en el juego contiene cómo debería verse el glifo
• usa otra textura (con fragmentos) por todo el lugar, pero nunca de una manera que genere un glifo completo, excepto en lugares ocultos que el jugador nunca debería poder alcanzar

y cualquier programa para extraer automáticamente la combinación de glifos ganadora tendrá un día infernal.

En tercer lugar, la siguiente dificultad es compartir. Una vez que se encuentra la solución a un secreto, se revelará. Idealmente, a cada individuo se le debe entregar una versión ligeramente diferente del software: una donde la clave sea única para su versión del juego. Para hacerlo práctico, supongo que sería más fácil separar el juego (con sus activos) de los "secretos" (encriptados) y el "controlador secreto" (el generador de claves, que coloca muchos fragmentos de textura en muchos lugares diferentes) , algunos de los cuales forman las contraseñas).

El vector de ataque obvio es engañar al generador al elegir siempre la misma contraseña o al verificador para que siempre acepte la misma contraseña (descargando el archivo de secretos de otra persona, por ejemplo).

Aquí, una posible solución sería vincular los archivos a la cuenta del usuario y saltear la contraseña como generalmente se recomienda:

• cuando el usuario solicita un conjunto de archivos, genera aleatoriamente una sal y tantas contraseñas como secretos, luego crea los activos secretos (es posible que desees limitar este proceso a una vez / día / usuario, por ejemplo, para evitar sobrecargar tu servidor)
• almacenar la marca de tiempo de la generación y la sal en la información de la cuenta del usuario
• devolver la marca de tiempo y los archivos secretos personalizados al usuario

Luego, cuando el usuario esté listo para enviar una contraseña:

• hacer que el usuario inicie sesión (si aún no lo estaba)
• haga que el software envíe la marca de tiempo y la contraseña de glifo
• Si la marca de tiempo es diferente de la almacenada, avise al usuario que está utilizando un conjunto obsoleto de archivos secretos
• Si la contraseña ya se ha intentado demasiadas veces, informe al usuario que está utilizando un conjunto obsoleto de archivos secretos.
• de lo contrario, utilice la clave de sal + contraseña para generar la clave
• de lo contrario, envíe la clave al usuario para que pueda ver sus archivos personalizados.
• aumentar la cantidad de veces que esta cuenta intentó esta contraseña

El objetivo aquí es impedir el intercambio de cuentas tanto como sea posible:

• compartir una cuenta para generar archivos secretos es (a) limitado, porque solo se puede generar uno por día y (b) inútil, porque el último generado hace que el otro quede obsoleto
• compartir una cuenta y distribuir los archivos secretos asociados es inútil, porque una contraseña determinada solo se puede usar N veces antes de que ya no entregue la clave

Y ya casi estamos allí.

Finalmente, incluso allí, un cracker podría lanzar una versión modificada del juego en la que los activos secretos se descifran y se integran directamente (evitando su cuidadoso esquema de verificación).

La solución es simple (y hace que casi todo lo anterior sea obsoleto ¹ ): no confíe en el cliente.

Crea una tabla de clasificación en tu sitio web y realiza un seguimiento del progreso de los jugadores en su cuenta. Los jugadores pueden afirmar que han terminado el juego todo lo que quieren, pero a menos que su cuenta refleje esto, todos saben que han estado haciendo trampa ...

... esto se llama presión social;)

¹ Excepto el archivo de posicionamiento de textura, que utilizamos para evitar que un programa adivine la clave y, sin embargo, hace posible que un usuario la obtenga.

Es una idea interesante. una variante en los discos de rompecabezas y los sistemas de protección contra copia enter-the-word-from-the-manual. Creo que algunos de los juegos "ARG" funcionan así, donde se entiende que los jugadores actúan colectivamente contra el diseñador del juego.

Obviamente, una vez que la primera persona lo descifre, lo publicará en Internet.

El contenido generativo o procesal puede funcionar de la misma manera: no ves el mismo mundo que otro jugador a menos que compartas una "semilla".

No puedo ver ningún problema legal con él, aunque Apple puede rechazarlo de su tienda de aplicaciones y es posible que deba proporcionar la solución para que se apruebe en las consolas de juegos.

Contemplar medidas de seguridad adicionales es entretenido, pero no agrega un valor concreto a su producto: demuestra su ingenio a las galletas que encuentran su producto. Por principio, tu antagonista te alcanzará.

A diferencia de los desarrolladores que prosperan en creatividad, los crackers son personas analíticas: pueden explotar intuitivamente su programa. Cuando los desarrolladores tienden a tomar medidas de seguridad excesivas, niegan que el cracker pueda revertir su esquema de protección, nuevamente .

Ya sea que desee participar en esta competencia de fondo, esa es su decisión, pero no permita que distraiga su producto final, lo que debe complacer al cliente. Un esquema de cifrado peculiar que convierte el juego en una babosa no ayuda.

Mason Wheeler tiene razón: no puedes hacerlo. Alguien siempre puede aplicar ingeniería inversa a su juego si así lo desea.

No es necesario que "protejas" tu juego de la forma que describes. Tan pronto como una persona encuentra el huevo de Pascua, el secreto está fuera de la bolsa. Si cada copia del juego tiene un huevo de Pascua diferente, solo se conocerá la copia del hacker. ¿Realmente te importa que un hacker de cada 1000 personas haya encontrado el huevo de Pascua sin pasar por el juego?

La ley de derechos de autor es tal que nadie puede ganar dinero con su juego sin correr el riesgo de una demanda grave, por lo que los derechos de autor lo protegen.

En cuanto a los usuarios aleatorios que ponen sus texturas en su avatar del foro, ¿y qué? Considéralo publicidad de base.

Obsesionarse con las cosas de "protección" simplemente te distraerá de realidades difíciles como: hacer el juego .

Cuando veo personas sin productos que hablan sobre sus esquemas de protección de IP para cosas que ni siquiera existen, es un momento de abandono para mí porque levanta una gran bandera roja de mierda sobre todo el proyecto.

Algunas posibilidades:

• Claro viejo código de ofuscación . No hará que el código sea imposible de decodificar, pero al menos será difícil.

• Solución del lado del servidor. Envía algunos comandos especiales al servidor y el servidor puede enviarle el código ... o incluso descargar un DLC.

• Puede usar Steganography para ocultar el código ejecutable en otro contenido.

Esto no hará que su secreto sea 100% seguro, pero parece que nadie perderá dinero si se revela el secreto.

Es inútil como cualquier otro esquema en el que almacene tanto la clave como el algoritmo en el cliente. Si pregunta "¿dónde está la clave, confío en la información de los usuarios y no la guardo yo mismo?", Recuerde que su rompecabezas tiene reglas y recursos según sus definiciones: se resuelve mediante algún algoritmo, no mediante la fuerza bruta. Este algoritmo exacto y sus recursos ES el algoritmo de generación de claves que acaba de codificar en el juego en estado ofuscado. Cualquiera puede recuperar su clave "inexistente" simplemente escribiendo un pequeño programa que resuelva su rompecabezas de acuerdo con sus reglas.