PowerShell检测PowerPoint 2003密码保护文件遇匹配异常求助

问题原因 #

1. 文本模式读取二进制文件导致内容失真
   PowerPoint 2003的.ppt是二进制格式文件，你用Get-Content -Encoding Unicode以文本模式读取时，会把二进制字节强行按Unicode编码解析，很容易出现乱码、截断或者字符映射错误。这就导致明明存在的加密标识字符串，却没法被正则匹配到；而且哪怕是相同内容的测试文件，二进制存储的细微差异也会让部分文件匹配成功、部分失败。

2. 匹配逻辑存在漏洞
   当前代码里，如果$header为空（读取失败）或者匹配到目标字符串，都会返回$hasPassword = $true——但读取失败的情况会被误判成加密文件；同时，当编码异常导致字符串无法识别时，-notmatch的逻辑会错误地把加密文件判定为非加密。

解决办法 #

改成二进制读取方式直接搜索加密标识的字节序列，避开文本编码转换的坑，同时优化判断逻辑：

修正后的密码检测函数 #

function Test-OfficeFilePasswordProtected {
    param([string]$officeFile)

    if (!(Test-Path -Path $officeFile -PathType Leaf)) {
        Write-Error "File $officeFile does not exist"
        return $null
    }

    $fileExt = (Get-Item $officeFile).Extension
    # 检测OOXML格式（2007及以后版本）的Office文件
    if ($fileExt -in ".docx", ".xlsx", ".pptx", ".docm", ".xlsm", ".pptm") {
        try {
            $content = Get-Content $officeFile -Raw -ErrorAction Stop
            $hasPassword = $content -match "http://schemas.microsoft.com/office/2006/keyEncryptor/password"
        }
        catch {
            # 文件损坏或读取失败时返回null
            return $null
        }
    }
    # 检测旧版二进制格式（2003及更早）的Office文件
    else {
        $targetString = "Microsoft Enhanced Cryptographic Provider"
        # 把目标字符串转换成旧Office文件用的UTF-16LE字节序列
        $targetBytes = [System.Text.Encoding]::Unicode.GetBytes($targetString)
        $fileStream = [System.IO.File]::OpenRead($officeFile)
        $buffer = New-Object byte[] $targetBytes.Length
        $found = $false

        try {
            # 逐字节读取文件，匹配目标字节序列
            while ($fileStream.Read($buffer, 0, $buffer.Length) -eq $buffer.Length) {
                if ([System.Linq.Enumerable]::SequenceEqual($buffer, $targetBytes)) {
                    $found = $true
                    break
                }
                # 缓冲区向前移动1字节，继续匹配
                $fileStream.Position = $fileStream.Position - $buffer.Length + 1
            }
        }
        finally {
            $fileStream.Close()
        }

        $hasPassword = $found
    }

    return $hasPassword
}

关键优化点 #

• 二进制匹配更准确：直接操作文件字节流，搜索目标字符串对应的UTF-16LE字节序列，完全避免文本编码转换带来的失真，确保加密标识能被稳定检测到。
• 格式判断更精准：直接枚举OOXML格式的扩展名，替代原来靠Extension.Length判断的逻辑，避免特殊扩展名导致的误判。
• 异常处理更稳妥：给OOXML文件的读取加了异常捕获，遇到文件损坏等情况时返回$null，不会直接报错中断脚本。
• 匹配效率更高：用SequenceEqual对比字节数组，逐字节滑动匹配，既不会漏检，也不用读取整个大文件。

额外小建议 #

如果要进一步提升速度，可以限制二进制文件的读取范围（比如只读前10KB），因为加密标识一般都在文件头部附近，没必要读完整文件。

内容的提问来源于stack exchange，提问作者batman1975