Metarchivo de Windows

Windows Metafile ( WMF ) es un formato de archivo de imagen diseñado originalmente para Microsoft Windows en la década de 1990. El formato original de Windows Metafile no era independiente del dispositivo (aunque podía serlo más con encabezados de ubicación) y podía contener tanto gráficos vectoriales como componentes de mapa de bits . Actúa de manera similar a los archivos SVG . Los archivos WMF fueron reemplazados posteriormente por los archivos Enhanced Metafiles (EMF), que sí ofrecían independencia del dispositivo. Los archivos EMF se mejoraron a su vez mediante archivos EMF+ .

Básicamente, un metarchivo almacena una lista de registros que consiste en comandos de dibujo, definiciones de propiedades y objetos gráficos para mostrar una imagen en la pantalla. ^[1] Los comandos de dibujo utilizados están estrechamente relacionados con los comandos de la API de Interfaz de dispositivo gráfico (GDI) utilizada para dibujar en Microsoft Windows.

Existen tres tipos principales de metarchivos: un WMF es un formato de 16 bits introducido en Windows 3.0 . Es el formato vectorial nativo de las aplicaciones de Microsoft Office, como Word , PowerPoint y Publisher . A partir de 2023 ^[actualizar], está disponible la revisión 17 de la especificación del formato de metarchivo de Windows. ^[2] Los archivos EMF, que reemplazaron a los archivos WMF, funcionan según el mismo principio, solo que es un formato de archivo de 32 bits que también permite la incrustación de datos privados dentro de registros de "comentarios". ^[3] EMF+ es una extensión de los archivos EMF y se incrusta en estos registros de comentarios, lo que permite imágenes y texto utilizando comandos, objetos y propiedades similares a Windows GDI+ . ^[4]

El formato de archivo WMF original de 16 bits se especificó en su totalidad en el volumen 4 de la documentación del SDK de Windows 3.1 de 1992 ^[5] (al menos si se combinaba con las descripciones de las funciones y estructuras individuales en los otros volúmenes), pero esa especificación era vaga en cuanto a algunos detalles. Estos manuales se publicaron como libros impresos disponibles en las librerías sin necesidad de firmar un acuerdo de licencia de usuario final (EULA) ni otras restricciones de licencia inusuales (solo una advertencia general de que, si se compraba como parte de un paquete de software, el software estaría sujeto a una).

Con el tiempo, la existencia de esa especificación histórica se olvidó en gran medida y algunas implementaciones alternativas recurrieron a la ingeniería inversa para averiguar el formato de archivo a partir de los archivos WMF existentes, lo que era difícil y propenso a errores. ^[6] En septiembre de 2006, Microsoft volvió a publicar la especificación del formato de archivo WMF en una forma más completa ^[7] en el contexto de la Promesa de Especificación Abierta de Microsoft , prometiendo no hacer valer los derechos de patente a los implementadores de formatos de archivo. ^[8]

Más tarde, Microsoft desaprobó los archivos WMF en favor de los archivos EMF de 32 bits , ya que los archivos WMF tenían problemas reales con la independencia del dispositivo, a pesar del uso de un encabezado de archivo "ubicable" que proporcionaba una independencia básica del dispositivo. Microsoft descubrió que los desarrolladores que usaban el formato estaban "[incrustando] comentarios de aplicación, ubicación o escala en los metarchivos... Otros añadían encabezados al metarchivo que proporcionaban información específica de la aplicación", lo que causaba importantes problemas de compatibilidad. ^[9] Por lo tanto, en 1992 con Windows NT 3.1 , Microsoft introdujo el formato de metarchivo mejorado (EMF) ^[10] , un formato que se basaba en la API de Win32 y con el que incorporaron la independencia del dispositivo. ^{[11] [9]} — estos también se conocían como metarchivos NT. ^[12] Con el lanzamiento de Windows XP y GDI+, el conjunto de registros tuvo que aumentar significativamente, por lo que Microsoft lanzó EMF+ como una extensión del formato de archivo EMF existente. ^{[10] [13]}

Los archivos WMF, EMF y EMF+ constan de una serie de registros que se reproducen para generar una salida gráfica. Algunos registros definen objetos que pueden especificar objetos gráficos utilizados para determinar cómo se deben dibujar los gráficos (por ejemplo, los lápices especifican el color y el ancho de las líneas). Cada uno de estos objetos se almacena en metarchivos y se colocan en una tabla de objetos, que realiza un seguimiento del uso de los objetos gráficos mientras se procesa el metarchivo. La tabla de objetos es una matriz asociativa de índices a estructuras de objetos gráficos definidas dentro del metarchivo.

Los archivos WMF y EMF manejan el procesamiento de objetos de manera diferente a los registros EMF+ en los archivos EMF. A medida que se procesa un archivo WMF y EMF, los registros se leen en una tabla de objetos una vez que se define un objeto. Si se elimina un objeto, se libera el objeto de la tabla y se puede reutilizar el identificador. Cabe destacar que un objeto no se utilizará hasta que se seleccione específicamente durante la reproducción de la grabación. ^{[14] [15]} Esto difiere para los archivos EMF+, que también utilizan una matriz asociativa a través de un mapa hash que registra el objeto junto con un identificador de objeto. Sin embargo, a diferencia de los archivos WMF y EMF que pueden eliminar un objeto, cuando se crea un nuevo objeto que tiene el mismo índice que un objeto existente, la entrada en la tabla se reemplaza con el nuevo objeto. Un archivo EMF tampoco necesita seleccionar específicamente un objeto antes de usarlo. ^[16]

Los archivos WMF no fueron diseñados originalmente para ser independientes del dispositivo, lo que significa que un archivo no podía reproducirse en dispositivos de salida que difirieran del dispositivo original en el que se grabó el archivo. Aldus Corporation inventó una solución parcial a este problema , al agregar un encabezado "ubicable" adicional, llamado "encabezado APM", ^[18] que agregó un rectángulo delimitador, una versión del metarchivo, el tamaño del metarchivo, la cantidad de objetos en el metarchivo y el tamaño del registro individual más grande en el metarchivo. ^{[19] [20]} Esto fue incorporado más tarde al formato WMF por Microsoft , a partir de Windows 2000. [ ^21]

Los archivos WMF están estructurados por una serie de registros, comenzando con una serie de registros de control: el registro de encabezado, ^{[19] [22]} el registro de ubicación opcional antes mencionado, ^[23] y finalizando con un registro de fin de archivo . ^{[19] [24]}

Los registros de control encapsulan los registros que forman la imagen en sí. Estos registros funcionan dentro de lo que se conoce como el contexto del dispositivo de reproducción , que es la colección de propiedades y objetos que forman el entorno gráfico de un dispositivo mientras el metarchivo se "reproduce" en este dispositivo de salida. ^[25]

Los registros que no sean registros de control se pueden agrupar en gran medida en registros de mapa de bits, registros de dibujo, registros de objetos, registros de estado y registros de escape.

Los registros de mapa de bits administran y generan imágenes de mapa de bits .

Los registros de dibujo producen salida gráfica.

Los registros de objetos crean y administran objetos gráficos. En los archivos WMF hay dos grandes categorías de objetos: objetos gráficos y objetos de estructura. Los objetos de estructura no se crean ni se eliminan explícitamente en un WMF, sino que son estructuras complejas. Por ejemplo, BitmapCoreHeader contiene información sobre las dimensiones y el formato de color de un mapa de bits independiente del dispositivo, ^[52] que es en sí mismo parte de un objeto DeviceIndependentBitmap. ^[53] Sin embargo, un objeto gráfico especifica parámetros para la salida de gráficos y, durante la reproducción del WMF, configura el contexto del dispositivo de reproducción. ^[54]

Los objetos gráficos pueden ser pinceles (definen el estilo, el color y el patrón de un pincel que define cómo pintar un área del gráfico), fuentes (definen propiedades que afectan cómo se muestra el texto), paletas (especifican colores como valores independientes del dispositivo, definidos por una aplicación), lápices (especifican los atributos gráficos de una línea) y regiones (que especifican segmentos de línea y curva que definen una forma). ^[54]

Los registros de estado administran las propiedades gráficas del contexto del dispositivo de reproducción. ^[67]

Los registros de escape son un medio para ampliar la funcionalidad del metarchivo a través de registros que no están definidos de otro modo como un tipo de registro WMF. Cada registro de escape contiene una función de registro, una función de escape y, potencialmente, datos de escape.

Los siguientes registros de escape forman un archivo WMF.

Se encontró una vulnerabilidad importante en los registros de escape alrededor del registro de escape Abort, que almacena el código del procedimiento de aborto dentro del propio registro. Esto afectó a los sistemas Windows (consulte CVE - 2005-4560) y al proyecto Wine (consulte CVE - 2006-0106). Según Secunia , "La vulnerabilidad se debe a un error en el manejo de los archivos Windows Metafile ('.wmf') que contienen registros 'Escape' SETABORTPROC especialmente diseñados. Dichos registros permiten que se ejecute una función arbitraria definida por el usuario cuando falla la representación de un archivo WMF". ^[142] Según la documentación del SDK de Windows 3.1, el escape SETABORTPROC quedó obsoleto y fue reemplazado por la función del mismo nombre en Windows 3.1, mucho antes de que se descubriera la vulnerabilidad de WMF. ^[143] Sin embargo, el código de escape obsoleto se mantuvo para la compatibilidad con programas de 16 bits escritos para (o al menos compatibles con versiones anteriores) Windows 3.0. Este cambio ocurrió aproximadamente al mismo tiempo que Microsoft estaba creando la reimplementación de 32 bits de GDI para Windows NT, y es probable que la vulnerabilidad haya ocurrido durante este esfuerzo.

Después de que Steve Gibson acusó a Microsoft de implementar deliberadamente una puerta trasera en su código, ^{[144] [145]} Mark Russinovich proporcionó una refutación y declaró que:

... las cosas eran diferentes cuando se diseñó el formato. En el modelo de memoria “grande” de Windows 3.1, el código es inherentemente independiente de la ubicación y Windows nunca fue parcheado, por lo que tanto Windows como una aplicación podían simplemente copiar una función de aplicación en el archivo WMF y asumir que funcionaría cuando la misma aplicación la reprodujera en una sesión de ejecución posterior. En cualquier caso, no está claro que los desarrolladores imaginaran que las aplicaciones crearan metarchivos en disco con procedimientos de cancelación. Además, como señaló Stephen Toulouse de Microsoft en la refutación de Microsoft a las afirmaciones de Steve, el panorama de seguridad a principios de los años 90 era muy diferente al de hoy y todo el código, incluido el almacenado en un archivo WMF, era inherentemente confiable. ^[146]

Peter Ferrie, de Symantec Security Response, EE.UU., también estuvo en desacuerdo con Gibson y señaló que:

Gibson afirmó que se crea un hilo para ejecutar el controlador SetAbortProc. De hecho, no se crea ningún hilo para ejecutar el controlador: es una devolución de llamada, que es llamada por el analizador, y el analizador tiene que esperar hasta que la devolución de llamada regrese, de lo contrario se pierde todo el objetivo de la función (abortar la impresión). Por su propia admisión, Gibson no leyó la documentación (de hecho, afirmó que no pudo encontrarla, aunque está disponible gratuitamente en el sitio web de Microsoft), y afirmó que el contexto del dispositivo no está disponible para el controlador de la función. Por supuesto, el contexto del dispositivo está disponible para el controlador de la función: es uno de los dos parámetros que se le pasan (ver arriba), y es necesario para abortar la impresión. Finalmente, Gibson afirmó que el flujo de control no podía regresar a Windows. Es simplemente una cuestión de que la función regrese y descarte los parámetros que se pasaron en la pila. Si el registro está bien formado, Windows continuará analizando el archivo, como antes. ... Gibson admite que estaba adivinando sobre varias cosas. Lamentablemente, su suposición fue errónea. Supongo que ahora sabemos más. ^[147]

Los archivos EMF tienen tres versiones posibles de encabezados. Los encabezados originales son solo un contenedor para imágenes, la segunda y tercera versión encapsulan el encabezado original y contienen un registro de formato de píxel y compatibilidad con registros OpenGL, y la tercera versión encapsula la segunda extensión de encabezado y aumenta la precisión y la escalabilidad de los EMF, ya que agrega la capacidad de medir distancias de superficies de dispositivos utilizando el sistema métrico. ^[148]

Cada encabezado EMF comienza con un registro EMR_HEADER y registra las propiedades relevantes del dispositivo en el que se grabó la imagen del metarchivo. El encabezado EMF original tiene un encabezado de 80 bytes y una cadena de descripción de longitud variable opcional. ^[149] Otros metarchivos contienen campos de extensión, que encapsulan el encabezado original. EmfMetafileHeaderExtension1es un registro que se inserta directamente después del encabezado EMF original, especifica si hay un descriptor de formato de píxel y el desplazamiento hasta el objeto descriptor dentro del encabezado, así como un campo que especifica si existen registros OpenGL en el metarchivo. ^[150] El descriptor de formato de píxel especifica las capacidades de la superficie de dibujo y si un píxel está codificado en RGBA o es un índice en una tabla de colores. ^[151] EmfMetafileHeaderExtension2 es un registro que se inserta directamente después del EmfMetafileHeaderExtension1registro y contiene dos campos con los valores X e Y para medir la superficie del dispositivo en micrómetros. ^[152]

Al igual que los archivos WMF, los registros se pueden clasificar por función; sin embargo, existen más tipos de registros en los archivos EMF que en los archivos WMF. Los registros se pueden clasificar como registros de control, de mapa de bits, de recorte, de comentario, de dibujo, de escape, de creación de objetos, de manipulación de objetos, OpenGL, de corchetes de ruta, de estado y de transformación.

Con el lanzamiento de Windows XP , se introdujo el formato Enhanced Metafile Format Plus Extensions (EMF+). EMF+ proporciona una forma de serializar llamadas a la API GDI+ de la misma manera que WMF/EMF almacena llamadas a GDI.

También existen versiones comprimidas de Metarchivos de Windows conocidas como Metarchivo Comprimido de Windows (WMZ) y Metarchivo Comprimido Mejorado de Windows (EMZ), ^[153] que son básicamente archivos WMF y EMF comprimidos con gzip respectivamente.

El formato WMF fue diseñado para ser ejecutado por la capa GDI de Windows con el fin de restaurar la imagen , pero como los archivos binarios WMF contienen la definición de las primitivas gráficas GDI que constituyen esta imagen, es posible diseñar bibliotecas alternativas que rendericen archivos binarios WMF o los conviertan en otros formatos gráficos.

• Posdata
• Lenguaje de marcado vectorial (VML)
• Gráficos vectoriales escalables (SVG)

• Especificación del formato de metarchivo de Windows de Microsoft
• Metarchivos – Aplicaciones de Windows
• Resumen de formatos de archivo en fileformat.info
• Preguntas frecuentes sobre metarchivos de Windows