.NET Tutorial 13. Como »Juankear» aplicaciones .NET y estrategias para evitarlo (Parte II)

Tal y como vimos en la anterior entrega, es "relativamente fácil" fisgonear en el código de una aplicación .NET. A continuación veremos varias formas de impedir esto:

Evitando el desensamblado

La forma más simple de evitar el desensamblado es añadir la siguiente directiva en cualquier módulo / clase de nuestro proyecto:

Imports System.Runtime.CompilerServices
<Assembly: SuppressIldasmAttribute()>
 

Si hacemos esto, al cargar nuestro exe dentro del ildasm obtendremos este "bonito" mensaje:

Añadir esta directiva puede persuadir a un "juanker casual". Eludir este "trick" es relativamente fácil para un cracker experimentado. Aunque como ya expliqué en la entrega anterior nuestra intención es eludir a esos "aprendices" de juankers, ya que contra los pr00s poco o nada hay que hacer ¬¬

 

Ofuscando el código

Esta es sin duda la parte más interesante del "asunto". El termino ofuscar tal y como indica sirve para como yo digo "marear la perdiz". El EXE se podrá seguir abriendo con el .NET Reflector u otras herramientas similares (algunos ofuscadores incluso impiden que el exe pueda abrirse con el .NET Reflector).

Lo que ocurre es que una vez ofuscado el código, éste ya no será tan "comprensible" para nuestros amigos "juankers"

A continuación puedes ver el "Tutorial11" después de pasarlo por un "Ofuscador"


(Haz click para agrandar la imagen)

Este es el Evento "Click" del Formulario de Login:


(Haz click para agrandar la imagen)

Compáralo con el mismo código sin ofuscar que vimos en la entrega anterior:

Y esta es la función "VerificarLogin" una vez ofuscada:

Que nada o poco tiene que ver con la función "VerificarLogin" que vimos en la entrega anterior:

 

Existen ofuscadores y "ofuscadores". Visual Studio (creo que solo en versiones "Professional" o superiores) dispone de un ofuscador "gratuito" llamado Dotfuscator Community Edition.

Uno de los inconvenientes de la versión del Dotfuscator Community Edition es que no permite ofuscar cadenas. Y claro, esto es un grave "inconveniente", ya que de poco o nada me sirve que "ofusque" el procedimiento VerificarLogin y lo llame $123klÑ342_p23sd# si luego se sigue viendo Return (Password = "1234") no sé si me entendéis.

Otro problema que le he encontrado al Dotfuscator Community Edition es que hay veces que al ofuscar y crear el nuevo ejecutable, dicho ejecutable es "inservible" y siempre genera un error al iniciarse. Posiblemente esto no ocurra con programas pequeños. Yo tengo aplicaciones que tienen más de 200.000 líneas de código (como veis de "pequeño" tiene poco) y el Dotfuscator se atraganta con dichas aplicaciones.

Buscando por internet encontré un ofuscador gratuito y que de momento no me ha dado ningún problema.

Se trata del Eazfuscator.

Es tremendamente simple de usar, ofusca cadenas, se traga perfectamente mis aplicaciones tochas. La última versión incluso permite ofuscar ensamblados para XNA 3.0.

Funciona incluso en las versiones "Express" de Visual Studio. Además no podrás usar el ilasm para volver a ensamblar un exe "modificado" ya que Eazfuscator añade un "resource" con una firma "digital" del exe original, que impide que se vuelva a "recompilar". (Actualización 05/08/2009: Esto no es del todo cierto, tal y como se puede ver en el Anexo Tutorial 13)

El único "pero" es que no permite especificar que clases o procedimientos quieres ofuscar. Te ofusca todo. Pero "joer" es gratuito!!! 🙂

Si estas dispuesto a pagar te recomiento {smartAssembly}.  En mi opinión es simplemente genial. Puedes decidir que clases, procedimientos o funciones quieres ofuscar. Además, no podrás abrir los EXEs con .NET Reflector, ni desemsamblarlos ni nada. El uso es también muy simple y la atención al cliente 10/10.

 

Un quebradero de cabeza más: Managed Spy 

Ante todo decir que esta "utilidad" está en la propia MSDN, en concreto en este artículo:
http://msdn.microsoft.com/en-us/magazine/cc163617.aspx

Como habéis adivinado (y si no ya os lo digo yo) es la versión "tuneada" del Spy++ que se instala en la carpeta Visual Studio Tools pero para aplicaciones ".NET" (de ahí lo de Managed)

¿Y digo "tuneada" por qué? La utilidad Spy++ se utiliza para obtener los identificadores de "ventana" de cualquier control de cualquier aplicación que se está ejecutando. Con dichos identificadores es posible llamar a determinadas APIs de Windows para "alterar" las propiedades de dicho control.

Managed Spy ya hace esto por nosotros y la verdad, a mi me ha dejado bastante "descolocado" y ahora veréis el por que:

Ejecutamos nuestro Tutorial11 y ponemos un password "incorrecto".

Si recordáis al poner un password "incorrecto" había cieras opciones desabilitadas.

Pues bien…ejecutamos ahora el Managed Spy:


(Haz click para agrandar la imagen)

Vemos que hay un "objeto" que se llama "GrpBoxPremium" y al que podemos acceder a sus propiedades como si estuviesemos en el IDE de programación (LOL!!!!):


(Haz click para agrandar la imagen)

Si cambias la propiedad Enabled a su valor True: sorpresa!!!!:


(haz click para agrandar la imagen)

Pero es que eso no es todo. Puedes CAMBIAR ABSOLUTAMENTE CUALQUIER PROPIEDAD de CUALQUIER CONTROL. Simplemente "O-EME-GE"! ¬¬


(Haz click para agrandar la imagen)

Por lo tanto, visto lo visto, no creo que sea una buena opción poner "cosas invisibles" o "deshabilitadas". Y si lo haces, asegúrate que cuando hagan click en dichas opciones, realmente tengan acceso a dichas opciones, es decir, en el evento Click o en el que sea, deberías añadir algún tipo de comprobación de si el usuario tiene o no permiso para ejecutar aquella opción, no vaya a ser que este ejecutando el Managed Spy (u otra cosa similar).

Estoy investigando si esto del Managed Spy se puede evitar de algún modo. Os comentaré algo si encuentro el cómo hacerlo.

PD: por cierto, el botón "Comentar" no muerde 🙂

 

Saludos.
mov eax,ollydbg; Int 13h