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

 

5 comentarios sobre “Ofuscate or not ofuscate. Cotilleando codigo ajeno”

  1. 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?

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

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

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

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *