Ofuscar Codigo

[Vicente]

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

[Tei]

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).

[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 :)

Un saludo!

Vicente

[Tei]

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.

[pacomix]

[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.

[ethernet]

Para ofuscar (y más) proguard, está claro :)

[Prompt]

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.

[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.

[Tei]

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).

[MrK]

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:

Código [Seleccionar] Expand


<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