Hola,
Bueno recientemente hemos acabado lo que se podria lamar la version 1.0 del juego SpaceBugs y ahora toca que este todo "intocable" o al menos dificil de tocar.
La validacion de envio de records a la base de datos y tal se solucionara no hay problema.
Pero tenemos un archivo niveles.xml y codigo fuente que con un decompilador pues se ve todo. Esta programado con Android asi que no se si habra algun programa o metodo que sirva con cualquier lenguaje para ofuscar o hacer cosas de este tipo.
A ver si alguein nos puede echar una mano.
para android habeis trabajado con eclipse, y eclipse tiene un ofuscador de serie si no recuerdo mal, y a malas uno de los 20000 plugins que tiene ^^
editado: http://wiki.eclipse.org/Obfuscate_the_code
Antes de darte una solución, esto me recuerda al tipico comportamiento español.
Sin ánimo de ofender matriax ni de referirme a ti.
¿Por qué no quieres que pueda ver la gente tu código?
¿Crees que algún personaje puede beneficiarse de tu esfuerzo?
Estoy seguro que para hacer tu juego has tenido que buscar infinidad de recursos por internet y habrás aprendido mucho de otras personas que decidieron compartir su código y esfuerzo de años para que gente como tu pudiera aprender.
El mayor ejemplo de esto es el del señor Carmak. Creo que ningún motor y juego actuales ni antiguos ( que los abrá ) refiriendome a HL, Quake... etc, no ofuscan el código ni los recursos, los dejan disponibles para que los usuarios modifiquen y hagan mejoras en el tiempo.
Y aprendan, que sería de algunos magnates de videojuegos sin que Carmak hubiera compartido su código de la tecnología anterior.
Por lo tanto y sin ser muy coñazo. Si nos beneficiamos de lo que otros publican, ¿Por qué queremos impedir que se beneficien de nosotros?
Por ponerte un ejemplo en mi web estan las demos, los .lua están ahi y se pueden hacer muchas cosas, evidentemente no hay documentación. Pero es que lo mejor de todo es que hay shaders que tienen curro, basados en otros. Y hay un shader que tiene mucho curro detrás y cualquiera puede descargarselo de la sección "Downloads" por separado si gusta.
Personalmente, tengo que decir, que veo cientos de visitas a la sección download de mi web, donde con google analytics veo de donde vienen y veo como la gente descarga los shaders y las demos. Estoy seguro que muchos borrarán la cabecera de los shaders o scripts y se "apropiarán" de mi duro trabajo que hago medio dormido a las tantas de la noche cada día. Me da coraje, si... tengo la bandeja de entrada vacía sin ningún "gracias".
Pero! que demonios tengo que dar gracias del trabajo que tengo porque hubo personas que hicieron lo mismo que yo!
matriax! comparte tu código amiguete!! :) no ofusques!!
Contestación: comprime en zip y cargate la cabecera. Si quieres puedes hacerte una propia, sustituyela por un formato binario propio matriaxHeader.
O, hazte un altgoritmo de empaquetado warro y creas una cabecera donde señalas el offset de donde empieza cada archivo y su tamaño, en la cabecera principal guardas el listado con las carpetas y ficheros.
Cita de: "Prompt"Antes de darte una solución, esto me recuerda al tipico comportamiento español.
Sin ánimo de ofender matriax ni de referirme a ti.
¿Por qué no quieres que pueda ver la gente tu código?
¿Crees que algún personaje puede beneficiarse de tu esfuerzo?
Estoy seguro que para hacer tu juego has tenido que buscar infinidad de recursos por internet y habrás aprendido mucho de otras personas que decidieron compartir su código y esfuerzo de años para que gente como tu pudiera aprender.
El mayor ejemplo de esto es el del señor Carmak. Creo que ningún motor y juego actuales ni antiguos ( que los abrá ) refiriendome a HL, Quake... etc, no ofuscan el código ni los recursos, los dejan disponibles para que los usuarios modifiquen y hagan mejoras en el tiempo.
Y aprendan, que sería de algunos magnates de videojuegos sin que Carmak hubiera compartido su código de la tecnología anterior.
Por lo tanto y sin ser muy coñazo. Si nos beneficiamos de lo que otros publican, ¿Por qué queremos impedir que se beneficien de nosotros?
Por ponerte un ejemplo en mi web estan las demos, los .lua están ahi y se pueden hacer muchas cosas, evidentemente no hay documentación. Pero es que lo mejor de todo es que hay shaders que tienen curro, basados en otros. Y hay un shader que tiene mucho curro detrás y cualquiera puede descargarselo de la sección "Downloads" por separado si gusta.
Personalmente, tengo que decir, que veo cientos de visitas a la sección download de mi web, donde con google analytics veo de donde vienen y veo como la gente descarga los shaders y las demos. Estoy seguro que muchos borrarán la cabecera de los shaders o scripts y se "apropiarán" de mi duro trabajo que hago medio dormido a las tantas de la noche cada día. Me da coraje, si... tengo la bandeja de entrada vacía sin ningún "gracias".
Pero! que demonios tengo que dar gracias del trabajo que tengo porque hubo personas que hicieron lo mismo que yo!
matriax! comparte tu código amiguete!! :) no ofusques!!
Contestación: comprime en zip y cargate la cabecera. Si quieres puedes hacerte una propia, sustituyela por un formato binario propio matriaxHeader.
O, hazte un altgoritmo de empaquetado warro y creas una cabecera donde señalas el offset de donde empieza cada archivo y su tamaño, en la cabecera principal guardas el listado con las carpetas y ficheros.
Vamos a ver señor Prompt, sin animo de ofender tampoco XDDD
El codigo sera abierto, pero el archivo niveles.xml y otro codigo fuente como la activacion de los jefes secretos, asi como el de las puntuaciones tiene que ir codificado para que nadie pueda toquetearlos.
Segun Angel actualmente se puede entrar en la base de datos del juego y poner la puntuacion manualmente y luego subirla y tener 999999999, y ademas tambien puedes modificar el archivo niveles.xml que contiene la dificultad de los niveles( y poner que te salga siempre escudos, o vidas...), y por codigo tamien puedes activarte todos los jefes finales para jugarlos, etc...
Asi que ese es el motivo de querer ofuscar ciertas cosas :) .
Cita de: "Buffon"para android habeis trabajado con eclipse, y eclipse tiene un ofuscador de serie si no recuerdo mal, y a malas uno de los 20000 plugins que tiene ^^
editado: http://wiki.eclipse.org/Obfuscate_the_code
Se lo comentare a Angel, yo de Eclipse ni idea.
Saludos!
:O malvado! no dejas que la gente haga trainers!!
que será de nosotros si nos quedamos atascados!
Cita de: "Prompt":O malvado! no dejas que la gente haga trainers!!
que será de nosotros si nos quedamos atascados!
Pues viciaros mas y lo conseguireis.
Sinceramente el juego en estos momentos esta tirado, las vidas estan baratas, y durante el juego te salen como minimo 2 medias vidas.
Cuando arreglemos eso sacaremos una demo o beta ya veremos comolo planteamos para que la gente haga un poco de betatest.
Creo que sería interesante en la base de datos, para este caso, no sólo guardar la puntuación por ejemplo sino un hash de la misma con unas claves privadas vuestras.
Tengo programado un SHA256 en java con claves en el código y sólo tendriais que ofuscar esa parte, dado que al meter los datos en la base de datos, si la forma lo siguiente.
----------------------------------------------------------------
| Nombre | Puntuacion | Nivel | Hash |
----------------------------------------------------------------
| Pepe | 34000 | 36 | ab3421ccd......h2h |
----------------------------------------------------------------
Esta claro que aún así todo el mundo podría utilizar esa clase, a no ser que autentiqueis antes su accesso de alguna manera que sólo sepais hacer vosotros.
Como estaría ofuscada sería muy chungo ver lo que hace, pero ya te digo yo que me he pillado aplicaciones java de firma digital de documentos con validación OCSP ofuscados y he acabado entendiendo en 16 horas (2 días laborables) su funcionamiento e implantándolo en mi aplicación.
y ahora resulta que medio año después de eso la he hecho yo por mi cuenta siguiendo standards xD
Respondo tarde, pero es que ha sido ahora cuando me ha venido a flote una cosa que tengo en mente desde hace mucho y, casualidades de la vida, tiene que ver con todo este tema.
¿Por qué hay tanta tendencia a hacer todos los ficheros etiquetados con XML? XML tiene sus utilidades, pero para un fichero relativamente pequeño y con una secuencia de datos bastante repetitiva (es decir, que los registros casi no tienen atributos opcionales), basta con cualquier formato binario. Es una forma de encriptación de cara a la galería, vamos, que nadie va a coger un simple editor de texto y a modificar a pelo los valores de los atributos. ¿Qué no puedes crear ficheros binarios fácilmente? Pues se hace un programita en 5-10 minutos que guarde los valores de turno en el fichero y ya está.
Para tu juego creo que para niveles.xml bastaría con un binario.
Cita de: "LC0"Respondo tarde, pero es que ha sido ahora cuando me ha venido a flote una cosa que tengo en mente desde hace mucho y, casualidades de la vida, tiene que ver con todo este tema.
¿Por qué hay tanta tendencia a hacer todos los ficheros etiquetados con XML? XML tiene sus utilidades, pero para un fichero relativamente pequeño y con una secuencia de datos bastante repetitiva (es decir, que los registros casi no tienen atributos opcionales), basta con cualquier formato binario. Es una forma de encriptación de cara a la galería, vamos, que nadie va a coger un simple editor de texto y a modificar a pelo los valores de los atributos. ¿Qué no puedes crear ficheros binarios fácilmente? Pues se hace un programita en 5-10 minutos que guarde los valores de turno en el fichero y ya está.
Para tu juego creo que para niveles.xml bastaría con un binario.
Esto es como todo en la vida.
Si no lo complicas nada, la gente normal seguirá sin saber como acceder al fichero y modificarlo, pero los que tengan un poco de idea te pondrán la máxima puntuación y te joderán.
Si lo complicas un poco, la gente normal seguirá sin saber como acceder al fichero y modificarlo, los que tengan un poco de idea desistirán a la media hora, pero los que tengan algo de picardía te pondrán la puntuación que les de la gana y te joderán.
Pero lo más bonito es que aunque lo pongas en binario, los que tengan idea te sacarán la estructura y te joderán, y aunque le hagas un hash con un sha256 te joderán igual, por que sacarán que clase realiza el hash y verán cuál es la llamada que la hace, simplemente tendrán que llamarla.
En lo que quería hacer más hincapié es en esa tendencia de usar xml's para todo. No solo ya por el tema que comentamos, sino que, por ejemplo, imagina que quieres hacer esto:
<números>
<entero>3</entero>
<entero>4</entero>
<entero>5</entero>
</números>
¿No sería mejor para todos un binario donde se guarden los enteros (suponiendo que solo vas a usar enteros, claro)? Por temas de tiempo y espacio (solo debería ocupar el fichero de marras 24B, y no es necesario enganchar con ningún parser de xml, sino que, con un simple while(!file.eof()), te sobra).
Hombre, los XML son gordos, pero usando XPath está tirado parsearlos y hacer queries sobre ellos :) Y si la librería del lenguaje que usas ya trae el parser de XML pues mira...
Un saludo,
Vicente
Cita de: "LC0"En lo que quería hacer más hincapié es en esa tendencia de usar xml's para todo.
Incluso sin llegar a binarios, si quieres que sea legible, puedes hacer un simple numeros.txt:
Citar3
4
5
X'D Pero no te canses, LCO, a la gente le encanta matar moscas a cañonazos.
Tengo entendido que el uso popularizado del XML viene sobre todo por temas de portabilidad entre arquitecturas ademas de "usabilidad". Me comentaban que un binario no se leeria igual segun arquitecturas (me pusieron como ejemplo los PPC) aunque no me quedo esto claro del todo.
Yo tambien soy partidario de usar binarios frente a XML. En VB6 me resultaba infinitamente mas comodo escribir directamente complejas estructuras de datos, rebuscadas como ellas solas, en un archivo binario con tan solo una simple llamada y lo mismo para recuperarlos del archivo, una gozada, ahorrabas espacio, los datos se preservaban tal cual y se hacia ilegible el contenido del archivo y no requerias de ningun parser ni conversor especial. En .NET me toca la moral que se haya complicado mas el asunto con los binarios, que poder se puede, pero en esta plataforma es mas sencillo serializar a XML que a binario o al menos lo que yo he visto hasta la fecha.
Salu2...
Ex3, todo depende de la biblioteca de lectura/escritura de turno, pero lo más normal es que te haga transparente el tema de la codificación interna. Muchos engines y bibliotecas gráficas en C++ vienen con funciones para ello (Irrlicht y Allegro, por ejemplo). Además, ese tipo de problemas podrías seguir teniéndolo con los xmls.
Vicente,
Citar
Y si la librería del lenguaje que usas ya trae el parser de XML pues mira...
Los ensamblados de C# te tienen muy mal acostumbrado, ¿eh? :P. Depende más bien, por lo que parece, del lenguaje que de librerías. Con C++ me da la impresión de que se sigue la tendencia (muy correcta a mi parecer, por cierto) de hacer las bibliotecas para gestionar xmls aparte, por lo que tendrás que enganchar a un .lib/.a más y, si me apuras, otra dll en la lista de dependencias. Vamos, que no te vas a encontrar fácilmente con una biblioteca para hacer juegos con un gestor de estos.
Con Java o C#, como vienen en la propia API de esos lenguajes, pues nada, a tirar para adelante.
Cita de: "LC0"Los ensamblados de C# te tienen muy mal acostumbrado, ¿eh? :P. Depende más bien, por lo que parece, del lenguaje que de librerías. Con C++ me da la impresión de que se sigue la tendencia (muy correcta a mi parecer, por cierto) de hacer las bibliotecas para gestionar xmls aparte, por lo que tendrás que enganchar a un .lib/.a más y, si me apuras, otra dll en la lista de dependencias. Vamos, que no te vas a encontrar fácilmente con una biblioteca para hacer juegos con un gestor de estos.
Con Java o C#, como vienen en la propia API de esos lenguajes, pues nada, a tirar para adelante.
Para manejar XML desde C# se usa la DLL System.Xml.dll, diferente de la DLL básica (System.dll). Ahora que te guste más que tu entorno traiga ya una librería estándar para realizar la tarea X o que te la tengas que buscar de terceros es pura cuestión de gustos :)
Y fijate que incluso dentro de .NET, no todos los lenguajes son iguales. La siguiente propiedad de VB 9.0 no existe en C# 3.0:
Deep XML Support
http://msdn2.microsoft.com/en-us/library/ms364068(VS.80).aspx#vb9overview_topic6
Un saludo!
Vicente
Edit: la url está un poco chunga, copy y paste y listo
XML esta muy bien para aplicaciones de negocios,
para juegos encuentro que tiene un problema que no siempre sera importante: parsear un xml es bastante lento.
esto se ve en juegos como Civilization IV en el que se demora un poco la carga mientras se parsean los ficheros (son muchos xml).
estas chapuzas de utilizar binarios, es muy 1996, pero tienden a ser mas rapidas.
otra opcion para "ofuscar" el xml, es utilizar algun tipo de codificacion binaria de xml, y renombrar los ficheros como .dat. Asi nadie tiene porque saber que ahi tienes un xml, y sera un poco mas dificil de modificar, y es posible que haya alguna ganancia por ser binarios (no se, quizas ocupen menos bytes).
Es cierto que cargar Xml es más lento que cargar binarios, pero si los ficheros de datos del Civilization IV fueran binarios quizás no habría la cantidad de mods que hay :)
Un saludo!
Vicente
Cita de: "Vicente"Es cierto que cargar Xml es más lento que cargar binarios, pero si los ficheros de datos del Civilization IV fueran binarios quizás no habría la cantidad de mods que hay :)
Totalmente cierto.
[LC0]
Amigo mío, lo que tu dices es bien cierto y estoy de acuerdo contigo hasta cierto punto. Lo bueno es saber qué usar en cada caso, según el tipo de aplicación al que te enfrentas. La mejor opción creo que es aunar las ventajas de las dos opciones.
Por ejemplo, si vas a programar un pequeño juego donde tú vas a ser el único programador, o a lo sumo dos, pues casi que no merece la pena usar ficheros .xml para la configuración y demás, sino hacerlo directamente en binario.
Ahora te pongo otro caso, el juego crece, ya no es un pequeño arcade y necesita de una cantidad de parámetros considerables por cada nivel, zona o como hayas dividido tu juego, enemigos, comportamientos de jugadores, etc... ¿Cómo es más práctico en este caso editar dichos parámetros? ¿Hacerlo directamente en binario o en .xml? Se podría hacer en .xml ya que es casi más claro y luego generar un binario a partir de dichos datos, para que la aplicación no pierda tiempo en interpretar dichos .xml. La ventaja de esto es que cualquiera podría toquetear con dichos parámetros, luego compilar y ver los resultados sin tener que calentarse el coco. Por ejemplo, testeadores o gente que sin tener idea de programación pueda estar toqueteando la velocidad de los enemigos, número de balas por segundo, etc...
Y ahora te pongo otro caso, parecido el anterior, pero la complejidad de la aplicación, juego, o lo que sea, ha crecido tanto, que ya incluso tener que compilar cada vez que se quiera hacer una modificación a algún parámetro se ha vuelto taaaaaaaaaaaaaaaaaaaaaaan pesada que te tiras 30 minutos cada vez x'D. Pues haces que tu aplicación interprete el/los .xml y genere un binario si han cambiado. Ahí tienes ya velocidad y la versatilidad de usar los .xml.
Todo esto también se aplica of course para scripts en diferentes lenguajes y demás.
Ale ahora si he dicho alguna burrada pegadme vale? xD
Un saludo a todos.
Para ofuscar (y más) proguard, está claro :)
Cita de: "Buffon"
Esto es como todo en la vida.
Si no lo complicas nada, la gente normal seguirá sin saber como acceder al fichero y modificarlo, pero los que tengan un poco de idea te pondrán la máxima puntuación y te joderán.
Si lo complicas un poco, la gente normal seguirá sin saber como acceder al fichero y modificarlo, los que tengan un poco de idea desistirán a la media hora, pero los que tengan algo de picardía te pondrán la puntuación que les de la gana y te joderán.
Pero lo más bonito es que aunque lo pongas en binario, los que tengan idea te sacarán la estructura y te joderán, y aunque le hagas un hash con un sha256 te joderán igual, por que sacarán que clase realiza el hash y verán cuál es la llamada que la hace, simplemente tendrán que llamarla.
Encriptación RSA de 1024 (2048 está prohibido en USA).
Actualmente es imposible con los ordenadores normales sacar una clave de 256 en menos de 1 mes. Mas o menos, vease WPA del wireless y como crackear una conexión.
La problematica de toda encriptación, compresión y ofuscación es que al subirlo a memoria para procesar lo subes desencriptado y se puede leer. Es un poco pro... pero se puede. Por eso empresas de seguridad venden llaves USB protegidas para que la enciptación y desencriptación se produzca en la llave.
Creo que puede ser una opción interesante para lo que buscas.
Cita de: "Prompt"Cita de: "Buffon"
Esto es como todo en la vida.
Si no lo complicas nada, la gente normal seguirá sin saber como acceder al fichero y modificarlo, pero los que tengan un poco de idea te pondrán la máxima puntuación y te joderán.
Si lo complicas un poco, la gente normal seguirá sin saber como acceder al fichero y modificarlo, los que tengan un poco de idea desistirán a la media hora, pero los que tengan algo de picardía te pondrán la puntuación que les de la gana y te joderán.
Pero lo más bonito es que aunque lo pongas en binario, los que tengan idea te sacarán la estructura y te joderán, y aunque le hagas un hash con un sha256 te joderán igual, por que sacarán que clase realiza el hash y verán cuál es la llamada que la hace, simplemente tendrán que llamarla.
Encriptación RSA de 1024 (2048 está prohibido en USA).
Actualmente es imposible con los ordenadores normales sacar una clave de 256 en menos de 1 mes. Mas o menos, vease WPA del wireless y como crackear una conexión.
La problematica de toda encriptación, compresión y ofuscación es que al subirlo a memoria para procesar lo subes desencriptado y se puede leer. Es un poco pro... pero se puede. Por eso empresas de seguridad venden llaves USB protegidas para que la enciptación y desencriptación se produzca en la llave.
Creo que puede ser una opción interesante para lo que buscas.
que me vas a contar que no sepa, si curro de criptógrafo o como modernamente se quiera llamar.
El problema de tener el código en java es que es muy sencillo decompilarlo, si usas una semilla propia te la pueden ver, como vas a usar las clases de java, las claves son las suyas, con lo cuál cualquiera que use tu semilla va a recibir el mismo resultado para guardarlo.
La gracia está en hacerte tu propio hash, ofuscarlo y que les sea mucho más chungo sacar las claves, montarte una manera muy rara de authenticación con la clase para que te reconozca, o para que sólo se pueda usar desde un terminal móvil.
como dije tengo un sha256 implementado en java, con sus claves bien puestas y no tengo ningún problema en darles el código.
Si la aplicación fuera en Native C, no habría problema de utilizar las clases del sistema por que es mucho más dificil de decompilar.
No me he leido el hilo.
Pero si cifras con un algoritmo asimetrico, como no tienen la clave de cifrado, aunque pudieran leer los datos (consigan la clave de descifrado), no pueden "firmar" datos manipulados (siguen sin tener la clave de cifrado).
Cita de: "LC0"En lo que quería hacer más hincapié es en esa tendencia de usar xml's para todo. No solo ya por el tema que comentamos, sino que, por ejemplo, imagina que quieres hacer esto:
<números>
<entero>3</entero>
<entero>4</entero>
<entero>5</entero>
</números>
¿No sería mejor para todos un binario donde se guarden los enteros (suponiendo que solo vas a usar enteros, claro)? Por temas de tiempo y espacio (solo debería ocupar el fichero de marras 24B, y no es necesario enganchar con ningún parser de xml, sino que, con un simple while(!file.eof()), te sobra).
dios, debe ser el primer mensaje en stratos con el que estoy completamente de acuerdo xD