Windows Metafile
The original Windows Metafile format was not device-independent (though could be made more so with placement headers) and may contain both vector graphics and bitmap components.
Essentially, a metafile stores a list of records consisting of drawing commands, property definitions and graphics objects to display an image on screen.
It is the native vector format for Microsoft Office applications such as Word, PowerPoint, and Publisher.
[3] EMF+ is an extension to EMF files and embedded in these comment records, allowing for images and text using commands, objects and properties that are similar to Windows GDI+.
Over time the existence of that historic specification was largely forgotten and some alternative implementations resorted to reverse engineering to figure out the file format from existing WMF files, which was difficult and error prone.
[6] In September 2006, Microsoft again published the WMF file format specification in a more complete form[7] in the context of the Microsoft Open Specification Promise, promising to not assert patent rights to file format implementors.
[10][13] WMF, EMF and EMF+ files all consist of a series of records that are played back to produce graphical output.
For example, the BitmapCoreHeader contains information about the dimensions and color format of a device-independent bitmap,[52] which is itself part of a DeviceIndependentBitmap object.
According to Secunia, "The vulnerability is caused due to an error in the handling of Windows Metafile files ('.wmf') containing specially crafted SETABORTPROC 'Escape' records.
Such records allow arbitrary user-defined function to be executed when the rendering of a WMF file fails.
This change happened at approximately the same time as Microsoft was creating the 32 bit reimplementation of GDI for Windows NT, and it is likely that the vulnerability occurred during this effort.
After Steve Gibson accused Microsoft of deliberately implementing a backdoor into their code,[144][145] Mark Russinovich provided a rebuttal, and stated that: ...things were different when the format was architected.
In any case, its not clear that the developers envisioned applications creating on-disk metafiles with abort procedures.
Of course the device context is available to the function handler — it is one of the two parameters that is passed to it (see above), and it is required in order to abort the printing.
The original headers is just a container for images, the second and third version encapsulates the original header and contains a pixel format record and support for OpenGL records, and the third version encapsulates the second header extension and increases EMF accuracy and scalability of EMFs as it adds the ability to measure distances of device surfaces using the metric system.
EmfMetafileHeaderExtension1 is a record that is inserted directly after the original EMF header, specifies whether there is a pixel format descriptor and the offset to the descriptor object within the header, as well as a field that specifies if OpenGL records exist in the metafile.
The WMF format was designed to be executed by the Windows GDI layer in order to restore the image, but as the WMF binary files contain the definition of the GDI graphic primitives that constitute this image, it is possible to design alternative libraries that render WMF binary files or convert them into other graphic formats.
