Unexpected Raw Disk Access in Windows 11: Contradiction with Documented Storage Protections

Hello!

I have a question about whether to report a vulnerability I've found to be abnormal behavior on my Windows 11 operating system to MSCR.

---

The question is as follows:

Operating system: Windows 11 Home and Online (not Offline)

Motherboard: ASUS PRIME B550M-K ARGB

Secure Boot status: Enabled (Latest Secure Boot files for the latest Secure Boot compatibility)

PowerShell: Latest version

Disk and number of devices: 1 (Only the NVMe drive is installed. And the installed disk is the disk on which a system is installed and runs.)

The issue started as follows:

At one point, I received a PowerShell command for a test via Grok AI. This command was to test whether raw byte writing would be performed.

From a user-mode process running with administrator privileges, I obtained a disk handle that provides raw access to a physical disk device by calling .NET's System.IO.File.Open API with ReadWrite access. Although this call alone does not perform any write operations, the resulting raw disk handle allows low-level operations to be performed on the disk by disabling security layers such as Volume Manager and Partition Manager. This behavior has been tested and verified by me, even when the disk is online and hosting an active operating system.

However, other tests are those that examine whether this behavior is truly evident:

---

Ventoy - Raw byte write test

The system disk is selected using the Ventoy tool, but the operation is interrupted and Ventoy gives an error. During this time:

• Desktop items disappear,
• The taskbar is untouchable (with the cursor),

The system essentially freezes.

Therefore, a normal shutdown doesn't occur when the power button is pressed.

For this reason, a hard shutdown signal is sent to ACPI by holding down the power button for 5 seconds. When the system boots up, the disk's GUID Partition Table and partitions are undamaged. Also:

Dism /online /cleanup-image /scanhealth

Sfc /Verifyonly

Verifies that the system is healthy.

This shows that not a single byte is written to either the GPT or the system, and not even to the Master File Table.

Ventoy's official explanation:

Ventoy does not use Windows' special "ISO-USB API" when writing to USB on Windows 11. Instead:

It opens the \.\PhysicalDriveN device.

It uses WriteFile to write data.

It makes DeviceIoControl calls for disk information and layout (e.g., IOCTL_DISK_GET_DRIVE_LAYOUT_EX, IOCTL_DISK_SET_DRIVE_LAYOUT_EX).

Thus, it directly writes the MBR/GPT table, file system, and bootloader to the sectors.

In short, what Ventoy does is: raw disk I/O (raw disk access). Windows doesn't have high-level APIs; Ventoy manages everything itself.

This confirms that Ventoy, despite providing raw access, does not corrupt the GUID Partition Table like other elevated processes that directly access raw data.

---

FSUTIL - Raw byte write test

In the test, a direct write attempt was made using the GUID path of a volume.

During the test, access to the volume root was obtained, but a write attempt was made without specifying any filename or subpath.

Observed Behavior:

• The attempt to directly write to the volume GUID root failed.
• The system issued an "access denied" warning during this operation.
• This behavior was repeated consistently throughout the test.

Additional Observation:

• When a subpath or filename was specified on the same volume, the write operation was successful.
• Therefore, the problem only occurred when attempting to directly write to the volume root.

---

PowerShell and CMD - Raw Disk Write Test

Following tests on Volume GUID, the same approach was tried on PhysicalDrive using PowerShell and CMD. The aim was to observe the behavior of attempts to write directly to the disk device path.

• Tools used in the tests:
• PowerShell Set-Content
• PowerShell Out-File
• CMD redirection operator (>)
• CMD echo write attempt

In these tests, no commands or parameters were incorrect; all parameters were given in the correct format and as valid.

An attempt was made to write to the path \.<system-disk-raw-access> in PowerShell.

Observed Behavior:

• PowerShell produced an error message stating "parameter incorrect" when the command was executed.
• Despite all parameters being correct, PowerShell considered this path an invalid target.
• This behavior was repeated consistently throughout the test.

Additional Note:

• The same commands worked without problems when redirected to a normal file path.
• The problem only occurred when attempting to write to the PhysicalDrive device path.

---

CMD Test - Raw byte write test

An attempt was made to write to \.<system-disk-raw-access> using the > operator in CMD.

Observed Behavior:

• CMD considered the attempt to write to the raw disk path using the redirection operator as unsuccessful.
• An access denied warning was received during the operation.
• This behavior was also repeated consistently throughout the test.
• GPT Sector Write Test with Diskpart/PowerShell
• After the Volume and PhysicalDrive tests, an attempt was made to write directly to the GPT sector on the disk. Both DiskPart's offset-based commands and similar offset write methods via PowerShell were used.

Observed Behavior:

• All attempts targeting the sector range containing the GPT sector failed.
• Offset-based write attempts made via DiskPart resulted in errors.
• When the same operation was repeated with PowerShell, the result was the same; the operation again ended in error.
• This behavior was repeated consistently throughout the test.

Attempts to write to the GPT sector were tested not only in an online system but also in an offline Windows PE/WinRE environment. In this test, DiskPart's offset-based commands were used to attempt to write to the sector range containing the GPT sector.

Observed Behavior:

• The result was the same in offline tests.
• The operation failed despite the offset value being correctly entered.
• DiskPart invalidated the attempt to write to the GPT sector.
• This behavior was consistently repeated in all attempts.

---

DISKART - Security Breach Test

In an online Windows 11 environment, tests such as forced partition deletion, other formatting commands that reset the disk, and conversion back to GPT were attempted via DISKPART.

Observed Behavior:

• All operations were blocked, and no data loss occurred on the disk.
• Similarly, the format command also resulted in an error.

---

All testing steps have been listed above.

It is not yet certain whether this behavior should be considered a vulnerability.

However, in Microsoft Q&A, moderators and PowerShell team members have stated that such raw access should not be possible.

Their statements are correct if we assume that these scenarios were never tested internally.

But since I performed the tests myself, I reached a different conclusion: raw access to <system-raw-disk> is indeed possible, and it contradicts the expected behavior described in the official answers.

Reference links:

https://learn.microsoft.com/en-us/answers/questions/5851220/question-regarding-disk-formatting-behavior-in-win

https://learn.microsoft.com/en-us/answers/questions/5851181/in-windows-11-is-it-possible-to-write-raw-data-to