Share via

In Windows 11, is it possible to write raw data to \\.\Physicaldisk0 using POWERSHELL?

MovelessMove-0585 110 Reputation points
2026-04-05T13:31:31.6666667+00:00

Hello,

In Windows 11 version 25h2, is it possible to write to \.\Physicaldisk0 (i.e., C:, the boot disk) in raw format using the PowerShell tool, or not?

Is there anything to prove this? Also, I was able to read \.\Physicaldisk0 in raw (read-only) form. Is it possible to write to this raw location, or is it not?

I'm only saying this for CMD/PowerShell. How does it work in other scenarios? Within administrator privileges.

Windows development | Windows API - Win32
0 comments No comments

Answer accepted by question author
  1. Marcin Policht 85,250 Reputation points MVP Volunteer Moderator
    2026-04-05T13:35:53.2966667+00:00

    AFAIK, this is generally not possible through PowerShell itself. PowerShell, by default, interacts with the system using high-level cmdlets from the Storage module, like Set-Disk or Initialize-Disk, which manage disk attributes such as partition styles or read-only flags but do not facilitate raw write operations.

    The ability to write to \\.\PhysicalDrive0 is controlled by the Windows storage stack and the underlying security model. Whether or not the disk can be written to is determined by the Windows APIs, particularly through functions like DeviceIoControl with the IOCTL_DISK_IS_WRITABLE control code. This API checks whether a disk is writable or not. If the disk is read-only, such as a system or boot disk, or if the disk's attributes are set to prevent writes, attempts to write raw data will be blocked.

    In PowerShell, you can change the read-only status of a disk using cmdlets like Set-Disk:

    Set-Disk -Number 5 -IsReadonly $False
    

    This cmdlet removes the read-only attribute from the disk, making it writable at the disk level. However, this does not allow for arbitrary raw writes - it only manages the disk's attributes. PowerShell doesn't directly expose a method to write raw bytes to a disk. Such operations require low-level API calls, such as CreateFile and DeviceIoControl, which you could invoke through PowerShell via .NET interop or similar methods. Even then though, any raw write operations would still be subject to:

    1. The disk's writable state as reported by the IOCTL_DISK_IS_WRITABLE API.
    2. Read-only attributes managed by Set-Disk or other disk management tools.
    3. Administrative permissions and OS protections on system or boot disks.

    To call Windows APIs from PowerShell, you can use the .NET Add-Type cmdlet to load unmanaged code, or you can use P/Invoke (Platform Invocation Services) to call functions from DLLs such as kernel32.dll, ntdll.dll, or winioctl.h—all of which provide functions for interacting with hardware at a low level.

    Here's a general idea of how this would work in PowerShell:

    1. CreateFile API: This is used to open a handle to a physical disk or device. It allows you to open \\.\PhysicalDrive0 with different access modes (read, write, or both).
    2. DeviceIoControl API: After obtaining a handle to the device, you can issue control codes to perform various operations, such as checking if the disk is writable (using IOCTL_DISK_IS_WRITABLE), reading raw data, or performing writes.

    Here's a simplified example of how you might use PowerShell to call these APIs:

    # Add necessary .NET types for P/Invoke
    Add-Type @"
    using System;
    using System.Runtime.InteropServices;
    public class DiskIoControl {
        [DllImport("kernel32.dll", SetLastError = true, CharSet = CharSet.Auto)]
        public static extern IntPtr CreateFile(
            string lpFileName,
            uint dwDesiredAccess,
            uint dwShareMode,
            IntPtr lpSecurityAttributes,
            uint dwCreationDisposition,
            uint dwFlagsAndAttributes,
            IntPtr hTemplateFile);
    
        [DllImport("kernel32.dll", SetLastError = true)]
        public static extern bool DeviceIoControl(
            IntPtr hDevice,
            uint dwIoControlCode,
            IntPtr lpInBuffer,
            uint nInBufferSize,
            IntPtr lpOutBuffer,
            uint nOutBufferSize,
            ref uint lpBytesReturned,
            IntPtr lpOverlapped);
    
        [DllImport("kernel32.dll", SetLastError = true)]
        public static extern bool CloseHandle(IntPtr hObject);
    }
    "@
    
    # Define necessary constants
    $GENERIC_READ = 0x80000000
    $GENERIC_WRITE = 0x40000000
    $FILE_SHARE_READ = 0x00000001
    $OPEN_EXISTING = 3
    $IOCTL_DISK_IS_WRITABLE = 0x00074080
    
    # Open a handle to the physical disk (e.g., \\.\PhysicalDrive0)
    $diskHandle = [DiskIoControl]::CreateFile("\\.\PhysicalDrive0", $GENERIC_READ, $FILE_SHARE_READ, [IntPtr]::Zero, $OPEN_EXISTING, 0, [IntPtr]::Zero)
    
    if ($diskHandle -eq [IntPtr]::Zero) {
        Write-Host "Failed to open disk handle"
    } else {
        Write-Host "Disk handle opened successfully"
    
        # Check if the disk is writable
        $bytesReturned = 0
        $result = [DiskIoControl]::DeviceIoControl($diskHandle, $IOCTL_DISK_IS_WRITABLE, [IntPtr]::Zero, 0, [IntPtr]::Zero, 0, [ref]$bytesReturned, [IntPtr]::Zero)
    
        if ($result) {
            Write-Host "Disk is writable"
        } else {
            Write-Host "Disk is not writable"
        }
    
        # Close the disk handle when done
        [DiskIoControl]::CloseHandle($diskHandle)
    }
    

    The CreateFile API is used to open a handle to \\.\PhysicalDrive0. This requires specifying access rights like GENERIC_READ and GENERIC_WRITE, which determine whether you can read and/or write to the disk. The DeviceIoControl function is used to issue the IOCTL_DISK_IS_WRITABLE control code, which checks whether the disk is writable. Finally, the handle to the disk is closed using CloseHandle.

    This is a simplified example, and in practice, you would need to expand this approach to handle the raw read and write operations. For instance, to perform actual raw writes, you'd need to allocate buffers and issue different control codes, such as IOCTL_DISK_WRITE.

    Keep in mind though that using raw disk write operations can have serious consequences if not done correctly. Writing arbitrary data to a disk, especially the boot disk (\\.\PhysicalDrive0), can cause data corruption or make your system unbootable. Always ensure you have backups and understand the risks involved in low-level disk operations.


    If the above response helps answer your question, remember to "Accept Answer" so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.

    hth

    Marcin

    1 person found this answer helpful.

1 additional answer

Sort by: Most helpful
  1. Q&A Assist
    2026-04-05T13:31:49.19+00:00
    AI generated content. This question contains an answer created with AI from Q&A Assist. Learn more

    Raw access to a disk (including \\.\PhysicalDrive0) is controlled by the Windows storage stack and security model, not by PowerShell itself. PowerShell can only write raw data to a disk if the underlying Windows APIs and disk state allow the disk to be writable.

    From the Windows API side, writability of a disk device is determined by calls such as DeviceIoControl with the IOCTL_DISK_IS_WRITABLE control code. This IOCTL “determines whether the specified disk is writable.” If that call reports the disk as writable, then code running with sufficient privileges can open the device and perform write operations at the raw level.

    In PowerShell, disk-level operations are typically done through the Storage module cmdlets. For example, Set-Disk can change a disk’s read-only attribute, and the documentation explicitly shows making a disk writable:

    Set-Disk -Number 5 -IsReadonly $False
    

    “This example takes a disk that is read-only and makes it writeable.” Once a disk is not read-only and the process has administrative rights, raw writes are technically possible via appropriate APIs or tools.

    However, Initialize-Disk and Set-Disk are high-level management cmdlets; they do not themselves expose a direct “write arbitrary raw bytes” interface. They operate by configuring partition style, signatures, GUIDs, and attributes. Any lower-level raw write would have to go through APIs such as CreateFile/DeviceIoControl or similar mechanisms, invoked from PowerShell (for example, via .NET interop), and would still be subject to:

    • The disk’s writable state as reported by IOCTL_DISK_IS_WRITABLE.
    • Any read-only attributes managed by Set-Disk.
    • Required administrative permissions and OS protections on the system/boot disk.

    So:

    • Reading \\.\PhysicalDrive0 in raw mode is possible when opened with read access.
    • Writing raw data to \\.\PhysicalDrive0 is only possible if the disk is not read-only (per IOCTL_DISK_IS_WRITABLE and disk attributes) and the caller has sufficient privileges. PowerShell does not bypass these checks; it can only use what the OS allows.

    References:

    0 comments No comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.