WIM

From IeXwiki

Contents

[edit]

Overview

Microsoft Windows Codename: Longhorn Windows Imaging, also commonly referred to as 'WIM'. This imaging format was seen in the early Longhorn alpha builds and has undergone many revisions since. The image consists of several layers and is similar to that of a drive image (eg. Ghost) that's applied to the target drive upon installation.

[edit]

Official Documentation

Microsoft has published the spec for this format at: http://www.microsoft.com/downloads/details.aspx?FamilyId=184706A3-6E05-4D9D-A034-830F4290EE42&displaylang=en

[edit]

Image Format Overview

The file, as said earlier, consists of several layers. These layers, in order of occurrance within' the image file, are:

  • <wim header>
  • <file/folder data>
  • <file/folder data definition schtuff>
  • <wim description file?>
[edit]

Header

The static portion of the header consists of 22 bytes.

  • 8 bytes: Signature "MSWIM\0\0\0"
  • 4 bytes: Header length (including signature length)
  • 4 bytes: WIM version
    • Older images contain: 0x010A00
    • Newer images contain: 0x010C00
  • 2 bytes: Compression On/Off Flag ?
    • 0x1: Uncompressed file data
    • 0x2: Unknown
    • 0x3: Compressed file data
  • 4 bytes: LZX/LZNT buffer window size

The rest of the header contains section headers identifying the different sections present in the image. All images seen to date contain three of such headers:

  • #1 - File lookup table
  • #2 - XML configuration file
  • #3 - Boot image data

Each header consists of 24 bytes:

  • 7 bytes: Size of associated data (if data is compressed - compressed file size)
  • 1 byte: Type flag
    • 0x2: XML configuration file
    • 0x4: File lookup table
    • 0x6: Boot image data
  • 8 bytes: Data start offset (absolute)
  • 8 bytes: Uncompressed size of associated data

NOTE: ZoRoNaX says the size and type flag fields could both be 4 byte fields instead of the values above. This is untested.

[edit]

File lookup table

This table contains the list of files and folders present within' the image and any of their properties. Keep in mind multiple pointers can point to the same file/folder data (prevent bloat from duplicate files).

Each entry in this table is 50 bytes long:

  • 7 bytes: Compressed file length
  • 1 byte: Type flag
    • 0x0: Not compressed
    • 0x2: Image listing
    • 0x4: Compressed
  • 8 bytes: Offset of data within' image (absolute)
  • 8 bytes: Uncompressed file length
  • 4 bytes: File identifier
  • 2 bytes: Unknown (was 4 bytes in older images)
  • 20 bytes: SHA-1 hash (zero-filled if type = 0x2)

NOTE: ZoRoNaX says the size and type flag fields could both be 4 byte fields instead of the values above. This is untested.

[edit]

Image list

This list is merely an ASCII-based INI-like file, compressed and stored within' the image. If not compressed, the list takes on another undocumented format (will likely go away when finalized).

Syntax: [SectionName] Name=Value "Long Name"=Value

Notes:

  • The RootDrive attribute in the [Image] section specifies which 'Directory Listing Section' to use for root drive application.
  • The [Security] section contains ACL data, hence the NTFS requirement.

Example:

[Security] "0x0"=01000480140000...

"0x0" = Security list identifier in hexadecimal format. 01000480140000... = ACL data

  • The [xN] sections contain the various directories with references to the files and other directories contained within', with N being an integer in hexadecimal format (directory identifier).

Example:

[xA] "msn6.exe& quot;=0x775,,0x20,0x8439AF48,0x1C2F7E3,0x843C11A2,0x1C2F7E3,0x8E25AC40,0x1C2F7DA ,0x27,,,455EC0039363D7....

To explain the example, all the data above has been replaced with digits. Use the digits to identify it's cooresponding data using the table below:

"(1)" = (2),(3),(4),(5),(6),(7),(8),(9),(10),(11),(12),(13),(14)

  • (1) - Long filename
  • (2) - Directory/file identifier. If a file, you can locate this file within' the file lookup table. If a directory, it's contents and properties are defined in the section header containing this identifier.
  • (3) - The 8.3 compatible directory or file name
  • (4) - Flags
    • 0x1: +R (read-only)
    • 0x2: +H (hidden)
    • 0x4: +S (system file)
    • 0x8: +A (archive)
    • 0x10: Folder
    • 0x20: File
    • 0x800: +C (compressed)
  • (5) - File creation time (Low DWORD - see C/C++ FILETIME structure)
  • (6) - File creation time (High DWORD - see C/C++ FILETIME structure)
  • (7) - File last accessed time (?) (Low DWORD - see C/C++ FILETIME structure)
  • (8) - File last accessed time (?) (High DWORD - see C/C++ FILETIME structure)
  • (9) - File last modified time (Low DWORD - see C/C++ FILETIME structure)
  • (10) - File last modified time (High DWORD - see C/C++ FILETIME structure)
  • (11) - Security section identifier
  • (12) - (?)
  • (13) - (?)
  • (14) - File-specific ACL data (?)

NOTE: The FILETIME structure is a structure of 100-nanosecond intervals since January 1, 1601 (epoch) and can be easily converted using Win32 API.

[edit]

Authors

Data contributed by ZoRoNaX and Rafael.

Retrieved from "http://www.iexbeta.com/wiki/index.php/WIM"