Ok, entonces, como alguien más mencionó, el código auto modificable * dentro del ejecutable * generalmente no es posible ahora. Esta es realmente una medida de seguridad para evitar que el código se modifique cuando no debería.
Sin embargo, muchos juegos realmente ejecutan la lógica real del juego a un nivel completamente diferente, no en el código fuente compilado sino en los scripts interpretados. Y esto abre más posibilidades para modificar el código, porque lo más probable es que se carguen en la memoria de datos antes de ser procesados, lo que se modificará. (Nota: cuando digo “memoria de datos” no estoy sugiriendo que haya algún tipo diferente de memoria, sino que hay varias secciones de memoria, que se asignan a usos específicos, y el sistema de mapeo de memoria evita que se usen para cosas equivocadas.)
Además, creo que vale la pena señalar que en muchos juegos, puedes descubrir lo que contiene el juego simplemente mirando los nombres de los archivos, por lo que ocultar algo de las personas no se trata solo de esconder cosas en el código sino también de esconderlas Los datos en sí. Los datos para un juego se pueden almacenar de una gran variedad de formas: muchos de ellos se agrupan en archivos grandes para mayor eficiencia, y estos a menudo se agrupan en función de su proximidad, por ejemplo, colocan todos los diferentes objetos de datos necesarios para un nivel particular en el mismo archivo.
Un último punto, volver al tema del código en lugar de los datos, es decir que hay herramientas que pueden recompilar un ejecutable en el código C ++; obviamente, no es capaz de interpretar cuál es el “significado” del código, pero puede hacer cosas como mostrarle la lógica y, en teoría, podría permitir que alguien realice ingeniería inversa casi todo en su código. Entonces, como dice una de las otras respuestas, en realidad debes comenzar a pensar en la seguridad a través de la oscuridad. Esto no es fácil de hacer, pero probablemente sea la única forma en que no se pasará por alto rápidamente.