viernes, 28 de agosto de 2009

Modelo de Compilación y Ejecución del .NET Framework

En este artículo, revisaremos el modelo de ejecución del .NET Framework, el proceso de compilación y revisar internamente un ensamblado.

¿CÓMO SE CONSTRUYE UN ENSAMBLADO?

Todo ensamblado está implementado a partir de un lenguaje de programación soportado por el .NET Framework: C#, Visual Basic, etc., cada uno de estos lenguajes, sólo proporciona su sintaxis y compilador para convertir el código fuente a un archivo compilado en lenguaje intermedio (Intermediate Language), el cual puede ser un archivo EXE ó DLL (ensamblado). En el siguiente gráfico puede observar el proceso de compilación.

Compilacion

Una vez generado el ensamblado, será desplegado hacia la PC del usuario o servidor, donde el .NET Framework se encuentra instalado como prerrequisito.

¿QUÉ SUCEDE DURANTE LA EJECUCIÓN DEL ENSAMBLADO?

Luego de desplegar el ensamblado, su ejecución queda bajo responsabilidad del .NET Framework, el cual, proporciona una serie de servicios que habilitan un ambiente seguro para la ejecución (managed code) dentro del CLR (Common Language Runtime), entres los que podemos nombrar:

  • El Motor de ejecución JIT (Just In Time Activation), este servicio, se encarga de tomar la porción de código que necesita ser ejecutada (On Demand), y lo convierte a lenguaje de máquina, esto es necesario, debido a que el procesador donde ejecuta el ensamblado, puede ser diferente al que se usó para su construcción.
  • Garbage Collection: este proceso se encarga de ir monitoreando los recursos que ya no son empleados por la aplicación, para ser depurados a partir de Heap del sistema (repositorio de las instancias de objetos en desuso), o también cuando la aplicación requiere recursos, aquí es importante recalcar que el objeto responsable de liberar los recursos es el Garbage Collector (GC), el cual NO DEBE ser ejecutado desde la aplicación por motivos de performance.
  • Seguridad: esta característica, permite controlar el acceso a los recursos del ensamblado, ya sea a partir de la identidad de otro ensamblado (Code Access Security – CAS), o la entidad de un usuario (Role Base Security – RBS), para lo cual, un ensamblado debe tener asociado un Nombre Seguro (Strong Name) de esto hablaremos más adelante.

En el siguiente gráfico podemos observar el trabajo del CLR durante la ejecución de un ensamblado.

EjecucionCLR

CONTRUYENDO UN ENSAMBLADO Y ANALIZANDOLO POR DENTRO.

En este ejemplo, vamos a construir un ensamblado empleado el Visual NotePad :-) , y haremos uso del compilador del lenguaje, para luego analizar la estructura interna del ensamblado.

Paso 1: Abrir una ventana del Block de Notas de Windows: Inicio – Ejecutar – Notepad [ENTER].

Paso 2: Ingrese las siguientes líneas de código, respetando el uso de mayúsculas y minúsculas.

C#

DemoCSharp

VB

DemoVB

Paso 3: Grabe el archivo en un directorio de trabajo (Ejemplo: C:\DemosNet\), asigne como nombre de archivo: DemoNet.cs ó DemoNet.vb (hasta esta parte hemos implementado el código fuente según el primer gráfico)

Paso 4: Ingrese a la línea de comandos del Visual Studio .NET 2008: Inicio – Programas – Microsoft Visual Studio 2008 – Visual Studio Tools – Visual Studio 2008 Command Prompt.

Paso 5: Desde la línea de comandos, ingrese a la carpeta de trabajo: C:\> CD DemosNet [ENTER].

Paso 6: Dependiendo del lenguaje de su preferencia, haga uso del compilador respectivo (posiblemente se puede mostrar una advertencia al compilar en C#, esto no es crítico):

CS

CompilaCS

VB

CompilaVB

En el directo se habrá generado el archivo DemoNet.exe, el cual procederemos a ejecutar (hasta esta parte se ha construido el ensamblado, según el gráfico).

Paso 7: Desde el directorio de trabajo, en la línea de comando de Visual Studio 2008, escriba: C:\DemosNet>DemoNet.exe [ENTER], observe el resultado.

DemoEjecuta

Paso 8: Para revisar la estructura del ensamblado, desde la línea de comandos, escriba la siguiente sentencia:

C:\DemosNet>ILDASM DemoNet.exe [ENTER]

Esto mostrará la ventana del Intermediate Language Disasembler, donde puede observar el Manifiesto del ensamblado y su contenido (clases compiladas).

ILParte1

Ingrese al Manifiesto del ensamblado, en esta sección se puede localizar parte de la identidad del ensamblado como: versión, llave pública (todo esto forma parte del nombre seguro, esto será configurado desde Visual Studio).

ILParte2Manifiesto

Cierre la ventana anterior, e ingrese al código del método Main.

ILParte3

Puede notar porqué el ejemplo se trató de una mala práctica, muchos podemos cometer el error de exponer data sensible como: cadenas de conexión, rutas, etc, esto puede estar a disposición de personas no autorizadas, ¿Qué pasa con esto?, ¿El .NET Framework es inseguro?, ¿Ya no debo seguir pensando en usar .NET?, pues nada de eso, todo es un esquema de diseño de sus aplicaciones, en el cual debe considerar los mecanismos de seguridad a aplicar (De esto trataré en el siguiente artículo.).

Hagamos el papel de un Hacker Junior, y vamos a alterar el archivo de forma maliciosa (se imaginan una sentencia SQL, el cual en vez de “Select * From Usuarios”, alguien lo reemplace por “Delete From Usuarios”), es muy serio el tema de seguridad, veamos.

Paso 9: Cierre la ventana anterior, y desde el menú del ILDASM, seleccione:

FileDump 

Paso 10: Acepte las configuraciones por defecto (clic en el botón OK), e ingrese como nombre de archivo: DemoNet.IL, y proceda a grabar.

GrabarIL

Cierre la ventana del ILDASM, y regrese a la línea de comandos del Visual Studio 2008.

Paso 11: Desde el explorador de Windows, edite el archivo DemoNet.IL, y reemplace el valor de la variable a alterar y grabe los cambios.

HackCarpeta

Paso 12: Antes de recompilar el lenguaje intermedio, elimine el ensamblado anterior: C:\DemosNet>DEL DemoNet.exe [ENTER].

Paso 13: Proceda a recompilar el ensamblado usando la siguiente sentencia.

Recompilar

Paso 14: Proceda a ejecutar nuevamente el ensamblado y observe los resultados.

ResultadoHack

Puede notar que el resultado ha cambiado, y no hubo ningún mecanismo que evite esto, PERO por ninguna razón estoy afirmando que el .NET Framework es inseguro.

CONCLUSIONES FINALES.

En este artículo, hemos conocido cómo trabaja el proceso de compilación y ejecución del .NET Framework, y también cómo es la estructura de un ensamblado, en los próximos artículos hablaremos acerca de los mecanismos de seguridad y de cómo evitar que un ensamblado sea modificado, aunque personalmente, esto me ha ayudado en alguna oportunidad, pero puede ser mal aplicado.

Por último, el ILDASM e ILASM, son parte de las herramientas de línea de comandos del .NET Framework, que iremos conociendo más adelante, sólo hay que tener en cuenta, que en un ambiente de producción, no todas las herramientas están disponibles, ya que son parte del .NET Framework SDK. Hasta la próxima.

1 comentario:

  1. Hola Cristiam , una consulta aislada a este post, en una oportunidad en una charla comentaste que usar las clasicas referencias de VS para conectar las difernetes capas de una aplicacion no era una buena practica en su lugar recomendabas otro mecanismo, podrias decirnos cual era y que pginas podemos visitar para leer sobre el tema y su tuvieras una demo mucho mejor. Saludos y Exitos... Percy Herrera

    ResponderEliminar