.

Ofuscate or not ofuscate. Cotilleando codigo ajeno

  Dado el interes de mis nuevos compañeros de trabajo vamos a contar algunas cosillas de la decompilacion. Antes de hablar de ofuscacion de codigo seria conveniente el por que del uso de la ofuscacion en .NET 


MSIL

  Es el lenguaje intermedio que usa .NET, nuestro programas, dll, ..... al compilar no pasan directamente a codigo maquina, si no que se convierte en este codigo. Y ya puede ser ejecutado bajo el Framework de .NET,


Reflector

   Herramienta IMPRESIONANTE, problarla todos aquellos que no la hayais visto trabajar nunca, puedes abrir cualquier exe, dll, ... desarrollado en .NET ( dado que lees es el MSIL ) y ver el codigo fuente de la aplicacion sin mayor misterio. Y sin duda que no se os olviden probar los plugins con el que podras decompilar SilverLight, que nos salgan para PowerShell, ....  <Descargar>
 


DotFuscator

   Ofuscador de codigo con el podemos codificar el codigo MSIL, asi podremos evitar que con herramientas como reflector a pelo podamos meternos hasta la cocina en el codigo del vecino. Viene integrado con el Visual Studio. Seguro que lo tienes instalado y aun no te habias dado ni cuenta. ;)

 

  Ejemplo del uso de Reflector y DotFuscator

 

    Problemas ..... los hay, la ofuscacion no es una solucion definitva de ocultacion de codigo, dado que como podreis ver, tanto en el video como en vuestras pruebas, el codigo en si queda bastante ilegible, el gran problema que tienes son los string, en ese caso es que puedes volver a reconstruirlas. Si en las string tienes las cadenas de conexion, con login y password, las sentencias SQL, o todo lo que sabeis que se llegan a meter en este formato, pueden ser obtenidas y provocar problemas.

 

   No puedes hablar de ofuscacion si nombrar otra gran herramienta:

   Salamander, otro gran decompilador a dia de hoy es capaz de directamente desofucar las cadenas o poder examinar todo string que queramos.

 

 Conclusion

       No creo en la ofuscacion, dado que lo el codigo que pueda genera cualquier programador, puedo hacerlo otro con la misma funcionalidad o mejor. Lo que hay que proteger son los datos en si, que a dia de hoy es lo que realmente tiene valor, tanto de logins, como urls, como el dato de cualquier persona.

      La otra opcion a la ofuscacion es el patentar tu algoritmo, pero en un mundo que convive perfectamente con el Software Libre, creo que el tema de patentar un bucle for no es algo de lo que merezca la pena ni pensar.
 

   Y si estais mas interesados en algoritmia de ofuscacion os recomiento este ppt

 

Posted: 3/10/2007 15:00 por Thempra | con 7 comment(s)
Archivado en:
Comparte este post:

Comentarios

d ha opinado:

si pongo la cadena de conexión a mi base de datos en una clase (dll) me la van a abrir y podrán enrar en mi base de datos.

si lo pongo en el web.config...hay alguna posiblidad de que alguien vea mi web.config?

cual es la forma más segura de poner la cadena de conexión?

# October 3, 2007 4:10 PM

Thempra ha opinado:

  Este tipo de metodos "normalmente" no se usan para web, dado que para ello has de tener acceso fisico al fichero.

 El IIS en aplicaciones .NET no te deja acceder a determinados ficheros ni directorios, como por ejemplo el web.config, /bin , /App_Code , ........ por lo tanto bien poniendolo en una DLL o en el web.config estaria igual de seguro respecto a ese tema.

# October 3, 2007 4:22 PM

d ha opinado:

tienes razón, para desofuscar deberían entrar en mi servidor

gracias

# October 3, 2007 5:01 PM

El Bruno ha opinado:

pues recuerdo que alla por el año 2001, en una de las primeras presentaciones que dabamos de VS.Net; alguien me dijo que no le gustaba nada la opción de que alguien pudiese decompilar y "ver" su código ... que para los desarrollos en .Net todo el mundo se "copiaria" codigo de otros.

Mi respuesta fue la siguiente:

"si conoces SAP o JDEdwards, y un poco de Java, puedes decompilar toda la aplicación, y crearte tu propio ElBrunoSAP o ElBrunoEdwards ... sin embargo no veo que la gente "copie" estas aplicaciones :D"

se q el ejemplo es un poco bestial por la cantidad de lineas de codigo que tienen estas aplicaciones ... pero a efectos prácticos sirve para la idea principal: el código es importante, pero es más importante aún el conocimiento sobre un dominio especifico de negocio para crear ese código.

mi humilde punto de vista

Saludos

# October 3, 2007 6:13 PM

Marc Rubiño ha opinado:

Muy interesante el artículo, tener en cuenta que cuando alguien quiere hacer daño ya se las ingenia para buscarle la vuelta a las cosas ^^.

Siempre ha existido gente interesada en proteger las aplicaciones y más gente aún esperando para poder crackear el código.

Siempre tenemos que evitar tener la información sensible en nuestra aplicación.

Saludos

# October 3, 2007 7:07 PM