Stay classy, Microsoft

I thought when I was looking at the Windows Registry I’d seen it all … until today when I found that the Windows 7 installation CD contains what seems like a registry that directly encodes an XML schema document.

WHY!!!

If you have a Win7 install CD, it is /sources/schema.dat. After passing it through hivexregedit –export you get:

Windows Registry Editor Version 5.00

[\]

[\wcm://Microsoft-Windows-DNS-Client?version=6.1.7600.16385&language=neutral&processorArchitecture=amd64&publicKeyToken=31bf3856ad364e35&versionScope=nonSxS&scope=allUsers]

[\wcm://Microsoft-Windows-DNS-Client?version=6.1.7600.16385&language=neutral&processorArchitecture=amd64&publicKeyToken=31bf3856ad364e35&versionScope=nonSxS&scope=allUsers\metadata]
"@_legacyHandler"=hex(10000005):04,00,00,00
"@_targetNamespace"=hex(1000000c):4d,00,69,00,63,00,72,00,6f,00,73,00,6f,00,66,00,74,00,2d,00,57,00,69,00,6e,00,64,00,6f,00,77,00,73,00,2d,00,44,00,4e,00,53,00,2d,00,43,00,6c,00,69,00,65,00,6e,00,74,00,00,00
"@language"=hex(1000000c):6e,00,65,00,75,00,74,00,72,00,61,00,6c,00,00,00
"@processorArchitecture"=hex(1000000c):61,00,6d,00,64,00,36,00,34,00,00,00
"@publicKeyToken"=hex(1000000c):33,00,31,00,62,00,66,00,33,00,38,00,35,00,36,00,61,00,64,00,33,00,36,00,34,00,65,00,33,00,35,00,00,00
"@version"=hex(1000000c):36,00,2e,00,31,00,2e,00,37,00,36,00,30,00,30,00,2e,00,31,00,36,00,33,00,38,00,35,00,00,00
"@versionScope"=hex(1000000c):6e,00,6f,00,6e,00,53,00,78,00,53,00,00,00
"@xmlns:asmv3"=hex(1000000c):75,00,72,00,6e,00,3a,00,73,00,63,00,68,00,65,00,6d,00,61,00,73,00,2d,00,6d,00,69,00,63,00,72,00,6f,00,73,00,6f,00,66,00,74,00,2d,00,63,00,6f,00,6d,00,3a,00,61,00,73,00,6d,00,2e,00,76,00,33,00,00,00
"@xmlns:wcm"=hex(1000000c):68,00,74,00,74,00,70,00,3a,00,2f,00,2f,00,73,00,63,00,68,00,65,00,6d,00,61,00,73,00,2e,00,6d,00,69,00,63,00,72,00,6f,00,73,00,6f,00,66,00,74,00,2e,00,63,00,6f,00,6d,00,2f,00,57,00,4d,00,49,00,43,00,6f,00,6e,00,66,00,69,00,67,00,2f,00,32,00,30,00,30,00,32,00,2f,00,53,00,74,00,61,00,74,00,65,00,00,00
"@xmlns:xmlns"=hex(1000000c):68,00,74,00,74,00,70,00,3a,00,2f,00,2f,00,77,00,77,00,77,00,2e,00,77,00,33,00,2e,00,6f,00,72,00,67,00,2f,00,32,00,30,00,30,00,30,00,2f,00,78,00,6d,00,6c,00,6e,00,73,00,2f,00,00,00
"@xmlns:xsd"=hex(1000000c):68,00,74,00,74,00,70,00,3a,00,2f,00,2f,00,77,00,77,00,77,00,2e,00,77,00,33,00,2e,00,6f,00,72,00,67,00,2f,00,32,00,30,00,30,00,31,00,2f,00,58,00,4d,00,4c,00,53,00,63,00,68,00,65,00,6d,00,61,00,00,00

[\wcm://Microsoft-Windows-DNS-Client?version=6.1.7600.16385&language=neutral&processorArchitecture=amd64&publicKeyToken=31bf3856ad364e35&versionScope=nonSxS&scope=allUsers\metadata\complexTypes]

[\wcm://Microsoft-Windows-DNS-Client?version=6.1.7600.16385&language=neutral&processorArchitecture=amd64&publicKeyToken=31bf3856ad364e35&versionScope=nonSxS&scope=allUsers\metadata\complexTypes\DomainNameCollectionType]
"@_MemberList"=hex(1000800c):44,00,6f,00,6d,00,61,00,69,00,6e,00,4e,00,61,00,6d,00,65,00,00,00,00,00
"@_valid"=hex(10000001):00

[\wcm://Microsoft-Windows-DNS-Client?version=6.1.7600.16385&language=neutral&processorArchitecture=amd64&publicKeyToken=31bf3856ad364e35&versionScope=nonSxS&scope=allUsers\metadata\complexTypes\DomainNameCollectionType\DomainName]
"@_hint"=hex(10000006):01,00,00,00
"@_type"=hex(10000005):0c,60,00,00
"@xsd:maxOccurs"=hex(10000006):ff,ff,ff,ff
"@xsd:minOccurs"=hex(10000006):00,00,00,00
"@xsd:type"=hex(1000000c):44,00,6f,00,6d,00,61,00,69,00,6e,00,4e,00,61,00,6d,00,65,00,54,00,79,00,70,00,65,00,00,00

[\wcm://Microsoft-Windows-DNS-Client?version=6.1.7600.16385&language=neutral&processorArchitecture=amd64&publicKeyToken=31bf3856ad364e35&versionScope=nonSxS&scope=allUsers\metadata\complexTypes\InterfaceCollectionType]
"@_MemberList"=hex(1000800c):49,00,6e,00,74,00,65,00,72,00,66,00,61,00,63,00,65,00,00,00,00,00
"@_valid"=hex(10000001):00

[\wcm://Microsoft-Windows-DNS-Client?version=6.1.7600.16385&language=neutral&processorArchitecture=amd64&publicKeyToken=31bf3856ad364e35&versionScope=nonSxS&scope=allUsers\metadata\complexTypes\InterfaceCollectionType\Interface]
"@_type"=hex(10000005):10,40,00,00
"@key"=hex(1000000c):49,00,64,00,65,00,6e,00,74,00,69,00,66,00,69,00,65,00,72,00,00,00
"@xsd:maxOccurs"=hex(10000006):ff,ff,ff,ff
"@xsd:minOccurs"=hex(10000006):00,00,00,00
"@xsd:type"=hex(1000000c):49,00,6e,00,74,00,65,00,72,00,66,00,61,00,63,00,65,00,54,00,79,00,70,00,65,00,00,00

(and on for 1,355 lines)

Tip: Install a device driver in a Windows VM

Previously we looked at how to install a service in a Windows VM. You can use that technique or the RunOnce tip to install some device drivers too.

But what if Windows needs the device driver in order to boot? This is the problem we faced with converting old Xen and VMWare guests to use KVM. You can’t install viostor (the virtio disk driver) which KVM needs either on the source Xen/VMWare hypervisors (because those don’t use the virtio standard) or on the destination KVM hypervisor (because Windows needs to be able to see the disk first in order to be able to boot).

Nevertheless we can modify the Windows VM off line using libguestfs to install the virtio device driver and allow it to boot.

(Note: virt-v2v will do this for you. This article is for those interested in how it works).

There are three different aspects to installing a device driver in Windows. Two of these are Windows Registry changes, and one is to install the .SYS file (the device driver itself).

So first we make the two Registry changes. Device drivers are a bit like services under Windows, so the first change looks like installing a service in a Windows guest. The second Registry change adds viostor to the “critical device database”, a map of PCI addresses to device drivers used by Windows at boot time:

# virt-win-reg --merge Windows7x64

;
; Add the viostor service
;

[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\viostor]
"Group"="SCSI miniport"
"ImagePath"=hex(2):73,00,79,00,73,00,74,00,65,00,6d,00,33,00,32,00,5c,00,64,\
  00,72,00,69,00,76,00,65,00,72,00,73,00,5c,00,76,00,69,00,6f,00,73,00,74,00,6f,\
  00,72,00,2e,00,73,00,79,00,73,00,00,00
"ErrorControl"=dword:00000001
"Start"=dword:00000000
"Type"=dword:00000001
"Tag"=dword:00000040

[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\viostor\Parameters]
"BusType"=dword:00000001

[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\viostor\Parameters\MaxTransferSize]
"ParamDesc"="Maximum Transfer Size"
"type"="enum"
"default"="0"

[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\viostor\Parameters\MaxTransferSize\enum]
"0"="64  KB"
"1"="128 KB"
"2"="256 KB"

[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\viostor\Parameters\PnpInterface]
"5"=dword:00000001

[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\viostor\Enum]
"0"="PCI\\VEN_1AF4&DEV_1001&SUBSYS_00021AF4&REV_00\\3&13c0b0c5&2&20"
"Count"=dword:00000001
"NextInstance"=dword:00000001

;
; Add viostor to the critical device database
;

[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\CriticalDeviceDatabase\PCI#VEN_1AF4&DEV_1001&SUBSYS_00000000]
"ClassGUID"="{4D36E97B-E325-11CE-BFC1-08002BE10318}"
"Service"="viostor"

[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\CriticalDeviceDatabase\PCI#VEN_1AF4&DEV_1001&SUBSYS_00020000]
"ClassGUID"="{4D36E97B-E325-11CE-BFC1-08002BE10318}"
"Service"="viostor"

[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\CriticalDeviceDatabase\PCI#VEN_1AF4&DEV_1001&SUBSYS_00021AF4]
"ClassGUID"="{4D36E97B-E325-11CE-BFC1-08002BE10318}"
"Service"="viostor"

Comparatively speaking, the second step of uploading viostor.sys to the right place in the image is simple:

# guestfish -i Windows7x64
><fs> upload viostor.sys /Windows/System32/drivers/viostor.sys

After that, the Windows guest can be booted on KVM using virtio. In virt-v2v we then reinstall the viostor driver (along with other drivers like the virtio network driver) so that we can be sure they are all installed correctly.

Tip: Install a service in a Windows VM

Previously I discussed how to get a script to run the first time a user logs in. This tip goes further and demonstrates how to install a service into a Windows VM using guestfish, virt-win-reg and a new open source program written by my colleague Yuval Kashtan called RHSrvAny¹.

First, compile RHSrvAny from source. You can do this using our completely free Fedora Windows cross-compiler stack. Just:

# yum install mingw32-gcc

Clone the RHSrvAny git repo and compile it:

$ mingw32-configure
$ make

Second we’ll copy the files we need into the Windows guest. Note: The Windows VM must be shut off.

# guestfish -i Windows7x64
Welcome to guestfish, the libguestfs filesystem interactive shell for
editing virtual machine filesystems.

Type: 'help' for a list of commands
      'man' to read the manual
      'quit' to quit the shell

><fs> upload RHSrvAny/rhsrvany.exe /rhsrvany.exe
><fs> upload test.exe /test.exe
><fs> exit

“test.exe” is a little program I wrote which writes the date into C:\TEST.LOG but you can also use the batch file from the last tip or any JScript or VBScript you happen to have (via cscript.exe).

Third we need to add some Windows Registry keys to tell Windows about the new service:

# cat service.reg
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\services\RHSrvAny]
"Type"=dword:00000010
"Start"=dword:00000002
"ErrorControl"=dword:00000001
"ImagePath"="c:\\rhsrvany.exe"
"DisplayName"="RHSrvAny"
"ObjectName"="LocalSystem"

[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\services\RHSrvAny\Parameters]
"CommandLine"="c:\\test.exe"
"PWD"="c:\\Temp"
# virt-win-reg --merge Windows7x64 service.reg

The magic numbers in the registry entries let you do things like boot with the service disabled. See this MSDN article.

Edit: See Yuval’s comment about alternatives to using "ObjectName"="LocalSystem".

Now boot your Windows guest, and observe the log file to prove that test.exe was run, and/or look at the list of services in the control panel.

><fs> cat /TEST.LOG
Hello
Thu Apr 29 18:39:13 2010

¹ Actually you could install any service, but I’m using RHSrvAny because it can turn ordinary Windows programs and scripts into services. It takes care of the Windows “Service Control Protocol” for us.

Tip: Get a Windows VM to run a batch file at boot

With the virt-win-reg tool built on top of libguestfs and hivex it’s now relatively straightforward to modify a Windows virtual machine so that it runs a batch file, script or program at next boot.

Note: The Windows VM must be shut down before you attempt this.

The plan is that we upload the batch script to some place in the VM, and then add a “RunOnce” key in the Windows Registry (explained in this MSDN article and this article). First let’s just take a look at what’s in the key. In most cases it will be empty:

# virt-win-reg Windows7x64 \
    'HKLM\Software\Microsoft\Windows\CurrentVersion\RunOnce'
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce]

Now we’ll prepare our batch file and upload it:

# cat test.bat
ECHO HELLO > C:\TEST.LOG
TIME /T >> C:\TEST.LOG
# guestfish -i Windows7x64

Welcome to guestfish, the libguestfs filesystem interactive shell for
editing virtual machine filesystems.

Type: 'help' for a list of commands
      'man' to read the manual
      'quit' to quit the shell

><fs> upload test.bat /test.bat
><fs> ^D

And finally we modify the RunOnce registry key:

# virt-win-reg --merge Windows7x64
[HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunOnce]
"Test"="c:\\test.bat"
^D

One potential gotcha: You must be running hivex ≥ 1.2.2.

Now you can boot your Windows guest and check that the script runs after the user logs in. Look for the file C:\TEST.LOG:

><fs> cat /TEST.LOG
HELLO 
09:21

Because we’re using the RunOnce key, the script will run just one time. If you want it to run every time, use the Run key.

Now, how do we make the script work without the user needing to log in? (Clue: The answer is not RunServicesOnce — this does not work in Windows 7). What’s surprising (coming from a Linux background) is the huge amount of incomplete, contradictory and simply false information contained in MSDN about this topic.

Use hivex to unpack a Windows Boot Configuration Data (BCD) hive

Thanks to “TJ” for tipping me off about another use of the Registry “hive” format in recent versions of Windows.

There are scant details available, but if you have a version of Windows Vista or later, then the boot loader is no longer configured through a plain text file (“BOOT.INI”) but via a binary blob. Microsoft provides a tool called “BCDEDIT.EXE” that you are supposed to use to edit this, but the blob is a hive so you can use hivex to display or modify it.

We first use guestfish to download the blob:

$ guestfish --ro -a /dev/vg_trick/Windows7x64 -m /dev/sda1

Welcome to guestfish, the libguestfs filesystem interactive shell for
editing virtual machine filesystems.

Type: 'help' for help with commands
      'quit' to quit the shell

><fs> ll /
total 392
drwxrwxrwx  1 root root   4096 Dec 15 04:48 .
dr-xr-xr-x 20 root root      0 Mar 30 13:30 ..
-rwxrwxrwx  1 root root   8192 Dec 15 12:47 BOOTSECT.BAK
drwxrwxrwx  1 root root   4096 Dec 15 12:47 Boot
drwxrwxrwx  1 root root      0 Dec 15 04:48 System Volume Information
-rwxrwxrwx  1 root root 383562 Jul 13  2009 bootmgr
><fs> ll /Boot/
total 596
drwxrwxrwx 1 root root   4096 Dec 15 12:47 .
drwxrwxrwx 1 root root   4096 Dec 15 04:48 ..
-rwxrwxrwx 1 root root  24576 Mar 25 12:25 BCD
-rwxrwxrwx 1 root root  21504 Mar 25 12:25 BCD.LOG
-rwxrwxrwx 2 root root      0 Dec 15 12:47 BCD.LOG1
-rwxrwxrwx 2 root root      0 Dec 15 12:47 BCD.LOG2
-rwxrwxrwx 1 root root  65536 Dec 15 12:47 BOOTSTAT.DAT
[snipped]
><fs> download /Boot/BCD /tmp/BCD
><fs> ^D

Then we can dump the contents out using hivexregedit. (We could also browse the contents with hivexsh).

$ hivexregedit --export /tmp/BCD '\' > /tmp/BCD.reg

In typical Microsoft style, the contents themselves are obscure, consisting of plenty of subkeys that look like this:

[\Objects\{1afa9c49-16ab-4a5c-901b-212802da9460}\Elements\14000006]
"Element"=hex(7):7b,00,37,00,65,00,61,00,32,00,65,00,31,00,61,00,63,\
  00,2d,00,32,00,65,00,36,00,31,00,2d,00,34,00,37,00,32,00,38,00,2d,00,\
  61,00,61,00,61,00,33,00,2d,00,38,00,39,00,36,00,64,00,39,00,64,00,30,\
  00,61,00,39,00,66,00,30,00,65,00,7d,00,00,00,00,00

(Note that “type 7” is a list of strings, and the whole thing is encoded in UTF-16LE, so this requires some further work to parse).

There’s scope here to extend virt-inspector to understand this stuff, or even to write a BCDEDIT-style tool to modify the way Window VMs boot. Apparently the current BCDEDIT tool is half-arsed, so here’s another opportunity to beat Microsoft’s own tooling.

virt-inspector now works better with Windows guests

Yesterday we improved virt-inspector so it can now fetch information about Windows guests by reading their Registries. In the XML output, this provides the ProductName and Windows internal version:

$ virt-inspector --xml Win2003x32
[...]
    <name>windows</name>
    <product_name>Microsoft Windows Server 2003</product_name>
    <arch>i386</arch>
    <major_version>5</major_version>
    <minor_version>2</minor_version>
[...]

In the raw output you get even more details from the Registry:

$ virt-inspector --perl Windows7x64
[...]
'arch' => 'x86_64',
'windows_registered_owner' => 'rjones',
'windows_current_type' => 'Multiprocessor Free',
'windows_system_hive' => '/Windows/System32/config/SYSTEM',
'windows_installation_type' => 'Client',
'os_major_version' => '6',
'os_minor_version' => '1',
'systemroot' => '/Windows',
'windows_software_hive' => '/Windows/System32/config/SOFTWARE',
'windows_software_type' => 'System',
'windows_registered_organization' => '',
'windows_current_build' => '7600',
'windows_edition_id' => 'Enterprise',
'product_name' => 'Windows 7 Enterprise',
[...]

Why the Windows Registry sucks … technically

It’s quite popular to bash the Windows Registry in non-technical or lightly technical terms. I’ve just spent a couple of weeks reverse engineering the binary format completely for our hivex library and shell which now supports both reading and writing to the registry. So now I can tell you why the Registry sucks from a technical point of view too.

1. It’s a half-arsed implementation of a filesystem

It’s often said that the Registry is a “monolithic file”, compared to storing configuration in lots of discrete files like, say, Unix does under /etc. This misses the point: the Registry is a filesystem. Sure it’s stored in a file, but so is ext3 if you choose to store it in a loopback mount. The Registry binary format has all the aspects of a filesystem: things corresponding to directories, inodes, extended attributes etc.

The major difference is that this Registry filesystem format is half-arsed. The format is badly constructed, fragile, endian-specific, underspecified and slow. The format changes from release to release of Windows. Parts are undocumented, seemingly to the Windows developers themselves (judging by the NT debug symbols that one paper has reproduced). Parts of the format waste space, while in other parts silly “optimizations” are made to save a handful of bytes (at the cost of making access much more complex).

2. Hello Microsoft programmers, a memory dump is not a file format

The format is essentially a dump of 32 bit C structures in a C memory heap. This was probably done originally for speed, but it opens the format to all sorts of issues:

1. You can hide stuff away in unused blocks.
2. You can create registries containing unreachable blocks or loops or pointers outside the heap, and cause Windows to fail or hang (see point 3).
3. It’s endian and wordsize specific.
4. It depends on the structure packing of the original compiler circa 1992.

3. The implementation of reading/writing the Registry in Windows NT is poor

You might expect, given how critical the Registry is to Window’s integrity, that the people who wrote the code that loads it would have spent a bit of time thinking about checking the file for consistency, but apparently this is not done.

1. All versions of Windows tested will simply ignore blocks which are not aligned correctly.
2. Ditto, will ignore directory entries which are not in alphabetical order (it just stops reading at the first place it finds a subdirectory named B > next entry A).
3. Ditto, will ignore file entries which contain various sorts of invalid field.

The upshot of this is you can easily hide stuff in the Registry binary which is completely invisible to Windows, but will be apparent in other tools. From the point of view of other tools (like our hivex tool) we have to write exactly the same bits that Windows would write, to be sure that Windows will be able to read it. Any mistakes we make, even apparently innocuous ones, are silently punished.

Compare this to using an established filesystem format, where everyone knows the rules, and consistency (eg. fsck/chkdsk) matters.

Writing sucks too, because the programmers don’t correctly zero out fields, so you’ll find parts (particularly the Registry header) which contain random bits of memory, presumably kernel memory, dumped into the file. I didn’t find anything interesting there yet …

I also found Registries containing unreachable blocks (and not, I might add, ones which I’d tried modifying). I find it very strange that relatively newly created Windows 7 VMs which don’t have any sort of virus infection, have visible Registry corruption.

4. Types are not well specified

Each registry field superficially is typed, so REG_SZ is a string, and REG_EXPAND_SZ is, erm, also a string. Good, right? No, because what counts as a “string” is not well-defined. A string might be encoded in 7 bit ASCII, or UTF-16-LE. The only way to know is to know what versions of Windows will use the registry.

Strings are also stored in REG_BINARY fields (in various encodings), but also raw binary data is stored in these fields.

Count yourself lucky if you only access official Microsoft fields though because some applications don’t confine themselves to the published types at all, and just use the type field for whatever they feel like.

And what’s up with having REG_DWORD (little-endian of course) and REG_DWORD_BIG_ENDIAN, and REG_QWORD, but no REG_QWORD_BIG_ENDIAN?

5. Interchange formats are not well specified

A critical part of installing many drivers is making registry edits, and for this a text format (.REG) is used along with the REGEDIT program. The thing is though that the .REG format is not well-specified in terms of backslash escaping. You can find examples of .REG files that have both:

"Name"="\Value"

and

"Name"="\\Value"

In addition the encoding of strings is again not specified. It seems to depend on the encoding of the actual .REG file, as far as anyone can tell. eg. If your .REG file itself is UTF-16-LE, then REGEDIT will encode all strings you define this way. Presumably if you transfer the .REG file to a system that changes the encoding, then you’ll get different results when you load the registry.

6. The Registry arrangement is a mess

Take a look at this forensic view of interesting Registry keys (PDF). List of mounted drives? HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices. But what the user sees is stored in HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2\CPC\Volume\. Unless you mean USB devices which might be in the above list, or in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USBSTOR. And the entries in those lists are by no means obvious — containing impenetrable binary fields and strange Windows paths.

If you browse through the Registry some time you’ll see it’s a giant accreted mess of non-standardized, overlapping information stored in random places. Some of it is configuration, much of it is runtime data. This is a far cry from /etc/progname.conf in Linux.

7. The Registry is a filesystem

Back to point 1, the Registry is a half-assed, poor quality implementation of a filesystem. Importantly, it’s not a database. It should be a database! It could benefit from indices to allow quick lookups, but instead we have to manually and linearly traverse it.

This leads to really strange Registry keys like:

\ControlSet001\Control\CriticalDeviceDatabase\pci#ven_1af4&dev_1001&subsys_00000000

which are crying out to be implemented as indexed columns in a real database.

8. Security, ha ha, let’s pretend

Despite the fact that the Registry is just a plain file that you can modify using all sorts of external tools (eg. our hivex shell), you can create “unreadable” and “unwritable” keys. These are “secure” from the point of view of Windows, unless you just modify the Registry binary file directly.

Windows also uses an unhealthy dose of security-through-obscurity. It hides password salts in the obscure “ClassName” field of the Registry key. The “security” here relies entirely on the fact that the default Windows REGEDIT program cannot view or edit the ClassName of a key. Anyone with a binary editor can get around this restriction trivially.

9. The Registry is obsolete, sorta

Well the good news is the Registry is obsolete. The bad news is that Vista has introduced another, incompatible way to store application data, in AppData/Local and AppData/LocalLow directories, but that Windows Vista and Windows 7 continue to rely on the Registry for all sorts of critical data, and it doesn’t look like this mess is going to go away any time soon.

* * *

libguestfs on Fedora now provides the tools you need to manage the Registry in Windows virtual machines. For more details, see hivexsh and virt-win-reg documentation.

Update

Thanks to all who commented. There is further discussion here on Reddit and here on Hacker News (including discussion of inaccuracies in what I wrote). If you want to look at our analysis code, it’s all here in our source repository. For further references on the Registry binary format, follow the links in the hivex README file.

libhivex: Windows Registry hive extractor library

Several people managing Windows virtual machines have told me that libguestfs/virt-cat isn’t enough for them. They’d like to be able to get at Windows Registry entries in the guest.

A typical example is the imaginary [as of now] virt-win-reg command that lets you interrogate the Registry in a guest:

$ virt-win-reg MyWinGuest '\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion'
"ProductName"="Microsoft Windows Server 2003"
"RegisteredOwner"="Richard Jones"
"CurrentVersion"="5.2"
"CurrentBuildNumber"="3790"
[etc]

Right now you can only do this indirectly, by laboriously downloading the registry hives and decoding them with tools such as reged. I outlined how to do that here but there’s no doubt that it should be made a lot easier.

The first step is a more reliable way to query registry files themselves. The files come from foreign, buggy, possibly malicious guests, and so code that touches them must be written carefully and conservatively to avoid security problems.

Another problem is that the tools in this area tend to convert the binary, proprietary “hive” format into a regedit-compatible text format. The problem is that regedit itself is no easier to parse. What we would like is a more compatible format — XML or a library.

There are several existing tools to do this. The best is certainly Petter Nordahl’s chntpw utility which we’ve been carrying in Fedora for a while. Unfortunately Petter hasn’t been answering our queries about issues in the code and we are concerned that the code isn’t cautious enough to deal with an onslaught of malicious registry files. Another is the BSD-licensed dumphive program written in Pascal.

To address our concerns I have spent the last three days writing a simpler version of Petter’s program called libhivex. This library and associated programs are able to extract the contents of Windows Registry “hive” files, and make this available through a simple C API or as XML. The library is written very defensively and should deal with malicious files. The scope of the library is also being kept intentionally small: we won’t use it to modify these files ever, just to extract data from them.

I hope to publish a patch series for this soon for libguestfs, followed by some useful command line tools to let sysadmins get data from their Windows virtual machines.

Got a suggestion for a useful libguestfs-related tool? Let me know in the comments.

Explore the Windows registry with libguestfs

Using libguestfs we can dump out the Windows registry as plain files. Here’s how.

You will need Petter Nordahl-Hagen’s Windows registry tools (Fedora package chntpw).

On NT-derived versions of Windows, the registry is stored in several binary files under the path /WINDOWS/system32/config. This document explains what’s in what file and Wikipedia explains how the registry is logically arranged.

For this example, I downloaded /WINDOWS/system32/config/software which maps to the Windows registry node HKEY_LOCAL_MACHINE\SOFTWARE:

guestfish -a /dev/mapper/Guests-Win2K3FV -m /dev/sda1 \
  download /WINDOWS/system32/config/software software

Using the reged tool from chntpw, I simply dumped out everything in this file into a human-readable format:

reged -x software HKEY_LOCAL_MACHINE\\SOFTWARE \\ software.reg > /dev/null

The output file, software.reg, contains thousands of plaintext entries like this (chosen at random):

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Jet\4.0\Engines\Excel]
"win32"="C:\WINDOWS\system32\msexcl40.dll"
"DisabledExtensions"="!xls"
"ImportMixedTypes"="Text"
"FirstRowHasNames"=hex:01,00
"AppendBlankRows"=dword:00000001
"TypeGuessRows"=dword:00000008

I’m now going to add this functionality to virt-inspector.