Shadow copies become less visible

<offtopic>You may find this article interesting: Measured Boot and Malware Signatures: exploring two vulnerabilities found in the Windows loader. It’s about two registry-related vulnerabilities found in the Windows loader.</offtopic>

Many examiners use tools like Arsenal Image Mounter to access shadow copies on disk images. I don’t recommend this method, because you won’t see offline shadow copies, but many of us still rely on it.

And it seems there will be more caveats…

The issue was initially observed in some Insider Preview versions of Windows 10. Now, the same issue is also present in the leaked build of Windows 11.

Let’s take a look at two screenshots:

A disk image is mounted in the “read-only” mode, no shadow copies found
The same disk image is mounted in the “read-write” mode, multiple shadow copies were found

So, if you mount a disk image read-only, no shadow copies are found. But if you mount the same image read-write, its shadow copies become visible!

My initial thought was about a possible on-disk structure upgrade. The volsnap driver tries to update some structures, but since the volume isn’t writable, the whole process fails. This was proven to be false.

After mounting the disk image read-only, the following error is observed in the System event log:

Event ID 27: something is wrong with a critical control file
The same error as XML, note that 0xc00000a2 stands for STATUS_MEDIA_WRITE_PROTECTED

What’s going on?

The correct answer is in the “VspOpenControlBlockFile” function (in the volsnap driver). Here are two versions of this function, the first one taken from the driver version not affected by the issue (the “old” driver), the second one taken from the affected driver (the “new” driver).

Decompiled pseudocode from the unaffected (“old”) driver
Decompiled pseudocode from the affected (“new”) driver

As you can see, the older version ignores the return value from the “VspCreateStartBlock” function. The newer version bails out if any error is returned by that function. The “VspCreateStartBlock” function tries to write to the underlying volume (it does so in any case, there was no format update as I originally thought) and fails.

Thus, the “VspOpenControlBlockFile” function returns the same error too. This breaks the discovery of shadow copies, making them invisible to the operating system.

So, an NTFS volume mounted as read-only will have its shadow copies hidden behind that write error. This also affects drives attached using a write blocker (unless that write blocker exposes a drive as writable with write errors being suppressed).

Currently, only some Insider Preview versions of Windows 10 share this behavior (even Windows 10 “21H1” isn’t affected). But Windows 11 is coming…

One thought on “Shadow copies become less visible

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s