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 se podía mejorar con encabezados de ubicación) y podía contener tanto gráficos vectoriales como componentes de mapa de bits . Funciona de manera similar a los archivos SVG . Posteriormente, los archivos WMF fueron reemplazados por los Enhanced Metafiles (archivos EMF), que sí ofrecían independencia del dispositivo. Los archivos EMF, a su vez, se mejoraron mediante los archivos EMF+ .

En esencia, un metarchivo almacena una lista de registros que consisten en comandos de dibujo, definiciones de propiedades y objetos gráficos para mostrar una imagen en pantalla. ^{[ 1 ]} Los comandos de dibujo utilizados están estrechamente relacionados con los comandos de la API de la Interfaz de Dispositivos Gráficos (GDI) utilizada para dibujar en Microsoft Windows.

Hay tres tipos principales de metarchivos: un WMF es un formato de 16 bits introducido en Windows 3.0 . Es el formato vectorial nativo para aplicaciones de Microsoft Office como Word , PowerPoint y Publisher . A partir de abril de 2024 , la revisión 18 de la especificación del formato de metarchivo de Windows está disponible. ^{[ 2 ]} Los archivos EMF, que reemplazaron a los archivos WMF, funcionan con 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 los 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 usando comandos, objetos y propiedades que son similares a Windows GDI+ . ^{[ 4 ]}

El formato de archivo WMF original de 16 bits se especificó completamente en el volumen 4 de la documentación del SDK de Windows 3.1 de 1992 ^{[ 5 ]} (al menos si se combina con las descripciones de las funciones y estructuras individuales en los otros volúmenes), pero esa especificación era vaga en algunos detalles. Estos manuales se publicaron como libros impresos disponibles en librerías sin 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 descifrar el formato de archivo a partir de archivos WMF existentes, lo cual era difícil y propenso a errores. ^{[ 6 ]} En septiembre de 2006, Microsoft volvió a publicar la especificación del formato de archivo WMF de forma más completa ^{[ 7 ]} en el contexto de la Promesa de Especificación Abierta de Microsoft , comprometiéndose a no reclamar derechos de patente a los implementadores del formato de archivo. ^{[ 8 ]}

Más tarde, Microsoft dejó de usar los archivos WMF en favor de los archivos EMF de 32 bits, ya que los archivos WMF presentaban 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 escalado en los metarchivos... Otros añadían encabezados al metarchivo que proporcionaban diversa 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 incorporaban 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 aumentarse 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 especifican los elementos gráficos utilizados para determinar cómo se deben dibujar los gráficos (por ejemplo, los lápices especifican el color y el grosor de las líneas). Cada uno de estos objetos se almacena en metarchivos y se coloca en una tabla de objetos, que registra el uso de los objetos gráficos durante el procesamiento del metarchivo. La tabla de objetos es una matriz asociativa de índices a las 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 archivos EMF. A medida que se procesa un archivo WMF o EMF, los registros se leen en una tabla de objetos una vez que se define un objeto. Si se elimina un objeto, este se libera de la tabla y su identificador puede reutilizarse. 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 con 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 ]}

WMF

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 distintos del dispositivo original en el que se grabó. Aldus Corporation inventó una solución parcial a este problema , añadiendo un encabezado adicional "ubicable", llamado "encabezado APM" ^{[ 18 ]} , que añadía un rectángulo delimitador, una versión del metarchivo, el tamaño del metarchivo, el número de objetos en el metarchivo y el tamaño del registro individual más grande en el metarchivo. ^{[ 19 ] [ 20 ]} Posteriormente, Microsoft lo incorporó al formato WMF , a partir de Windows 2000. ^{[ 21 ]}

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

Los registros de control contienen los registros que componen la imagen en sí. Estos registros funcionan dentro de lo que se conoce como el contexto del dispositivo de reproducción , que es el conjunto de propiedades y objetos que conforman el entorno gráfico de un dispositivo mientras el metarchivo se reproduce en dicho dispositivo de salida . ^{[ 25 ]}

Los registros distintos de los 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.

Registros de mapa de bits

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

Registros de dibujo

Los registros de dibujo generan resultados gráficos.

Registros de objetos

Los registros de objetos crean y gestionan objetos gráficos. En los archivos WMF existen 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 sustituyen a 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 a su vez forma parte de un objeto DeviceIndependentBitmap. ^{[ 53 ]} Un objeto gráfico, en cambio, especifica parámetros para la salida gráfica y, durante la reproducción del WMF, establece el contexto del dispositivo de reproducción. ^{[ 54 ]}

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

registros estatales

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

récords de escape

Los registros de escape son un medio para extender la funcionalidad de los metaarchivos mediante registros que no están definidos 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 conforman 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 (ver CVE - 2005-4560 ) y al proyecto Wine (ver CVE - 2006-0106 ). Según Secunia , "La vulnerabilidad se debe a un error en el manejo de los archivos de metarchivo de Windows ('.wmf') que contienen registros de 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 WMF. ^{[ 143 ]} Sin embargo, el código de escape obsoleto se conservó para la compatibilidad con programas de 16 bits escritos para (o al menos retrocompatibles con) Windows 3.0. Este cambio se produjo 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 surgiera durante este proceso.

Después de que Steve Gibson acusara a Microsoft de implementar deliberadamente una puerta trasera en su código, ^{[ 144 ] [ 145 ]} Mark Russinovich ofreció 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 se actualizó, por lo que tanto Windows como una aplicación podían simplemente copiar una función de la 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 previeran que las aplicaciones crearan metarchivos en disco con procedimientos de aborto. 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 la década de 1990 era muy diferente al actual 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 discrepó con Gibson, señalando que:

Gibson afirmó que se crea un hilo para ejecutar el controlador SetAbortProc. En realidad, no se crea ningún hilo para ejecutar el controlador; se trata de una función de devolución de llamada, a la que llama el analizador, y este debe esperar a que la función devuelva un valor; de lo contrario, se pierde el propósito de la función (abortar la impresión). Gibson admitió no haber leído la documentación (de hecho, afirmó no haberla encontrado, aunque está disponible gratuitamente en el sitio web de Microsoft) y sostuvo que el contexto del dispositivo no está disponible para el controlador de la función. Por supuesto que el contexto del dispositivo está disponible para el controlador de la función : es uno de los dos parámetros que se le pasan (véase más arriba) y es necesario para abortar la impresión. Finalmente, Gibson afirmó que el flujo de control no podía regresar a Windows. Simplemente se trata de que la función devuelva un valor 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 varias cosas. Desafortunadamente, adivinó mal. Supongo que ahora lo sabemos mejor. ^{[ 147 ]}

Campo electromagnético

Los archivos EMF tienen tres versiones posibles de encabezados. El encabezado original es simplemente un contenedor para imágenes; la segunda y tercera versión encapsulan el encabezado original y contienen un registro de formato de píxeles y compatibilidad con registros OpenGL; y la tercera versión encapsula la extensión del segundo encabezado y aumenta la precisión y la escalabilidad de los archivos EMF, ya que añade 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 al 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 WMF. Los registros se pueden clasificar como de control, mapa de bits, recorte, comentario, dibujo, escape, creación de objetos, manipulación de objetos, OpenGL, corchetes de ruta, estado y transformación.

El formato WMF fue diseñado para ser ejecutado por la capa GDI de Windows con el fin de restaurar la imagen , pero, dado que 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 a 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 del formato de archivo en fileformat.info
• Preguntas frecuentes sobre el metarchivo de Windows