简介：这份资源是专为Windows平台打造的星号密码查看工具，面向系统管理员、开发人员及需要核对密码的普通用户，可在忘记或不确定密码时快速还原被星号掩盖的明文。压缩包内含2个文件：1个exe主程序负责调用系统底层API捕获并解析密码输入，1个htm说明文档提供使用说明与环境支持信息，整体仅375KB，轻量便携。工具经实测支持Windows 7、Windows 10及Windows Server，并已在XShell中成功查看密码，能够有效提升远程维护场景下的工作效率。目前已有313人学习下载。需要留意的是，此类工具兼具便利与风险，建议仅在本人设备或可控环境中使用，避免密码被恶意窃取。对于频繁接触服务器与终端工具的IT从业者来说，这份资源提供了一条快速自查密码的可行途径，同时也能帮助理解Windows密码框背后的显示机制。
1. 星号密码查看工具到底是什么：当「••••••」挡住密码时，我们在处理哪一类问题
「星号密码查看工具」这类绿色小工具，解决的问题非常具体：界面上密码框只显示一串圆点或星号，而你突然需要这个密码，比如路由器管理页进不去、旧客户端里保存的账号密码想导出来，或者 Wi-Fi 密码当时设得太随意、现在想找回来。它做的工作只有一件事——把“星号”背后的明文还原出来，让不再有「看到却拿不到」的憋屈感。
这类工具的适用对象是普通从业者和个人用户：你自己机器上、你自己账号下保存的凭据，因为某处不再显示明文而需要恢复。它不适用于偷取别人会话、绕过授权这类场景，老实说那些场景下通用工具也帮不上忙，因为系统对跨用户、跨权限的密码读取做了大量隔离。理解了这个边界，后续选型才不会跑偏。
我一般会把这类工具定位成「本地凭据恢复器」而不是「万能解密器」：它读的是系统允许你读的数据，走的是控件消息、凭据文件解密这些正经路线。下面从原理讲清楚，再给三个可以直接抄下来用的方案，最后说几个最容易翻车的点。
2. 星号背后的机制与 zip 文件结构：三条技术路线和一套静态分析方法
2.1 密码框为什么只显示星号：ES_PASSWORD 与控制消息
传统 Win32 程序里的密码框，本质上是一个普通文本框控件，只是被加了一个样式位：ES_PASSWORD。这个样式的作用是让控件在绘制时把用户输入的字符替换成掩码字符，默认是圆点或星号。注意一个关键点——替换只发生在绘制（显示）阶段，控件内部缓冲区里存的仍然是完整明文。这就是所有「星号查看」思路得以成立的根基：显示层打了码，但数据层没打码。
操作系统对密码框有一层基础保护：外部进程用 GetWindowText 去取密码框内容，会拿回空字符串。早期系统还宽松些，Vista 之后对跨进程读取做了收紧，尤其是权限低的进程去读权限高的进程，会被 UIPI（用户界面特权隔离）直接拦掉。但控件消息这条路没有完全堵死，因为控件本身提供了几个和密码相关的消息，比如 EM_SETPASSWORDCHAR，它用来设置掩码字符。如果把掩码字符设为 0，等于告诉控件「别打码了」，之后配合重绘和 WM_GETTEXT，经典工具就是这么干的。
另外还有一个容易被误解的点：不少人以为星号工具是「截屏识别」，把星号图片做图像识别还原。实际不是，也没有必要。星号本身不含任何信息，识别星号图永远得不到密码；真正有价值的是窗口句柄和控件内部的文本缓冲区。理解这一点，后面排错时思路会清晰得多。
2.2 三条路线对比：控件消息、进程内存、凭据文件解密
我把见过的星号查看工具按实现方式分成三类，它们面对的场景完全不同。
第一类是控件消息路线。程序先定位到目标密码框的窗口句柄，然后向它发送 EM_SETPASSWORDCHAR、WM_GETTEXT 这类消息，让控件自己把文本交出来。优点是代码量小、不需要注入目标进程；缺点是只对标准 Edit 控件有效，遇到自绘控件、浏览器内部控件、新一代 UI 框架的密码框就抓瞎。这类工具也是杀毒软件重点标记对象，因为「跨进程发操纵性消息」本身就不是正常业务该干的事。
第二类是进程内存路线。工具用 ReadProcessMemory 读取目标进程的地址空间，在堆内存里搜索密码框的文本缓冲区。优点是对控件类型不敏感，缺点是位宽必须一致：64 位工具读 64 位进程，32 位工具读 32 位进程，交叉读取大概率失败。还有更激进的做法是挂钩子，拦截 TextOut 或密码框重绘事件，在绘制前把明文截获。这类实现开始接近恶意软件行为，报毒几乎是必然的。
第三类是凭据文件解密路线。很多密码根本不显示在普通控件里，而是躺在系统或应用的存储文件中：Wi-Fi 密码存在 WLAN 配置里，浏览器密码存在 Login Data 里，Windows 凭据存在凭据管理器的加密库里。这条路不碰任何控件，直接把文件读出来再解密。它的优势是现代应用基本不吃控件消息那一套，但凭据文件是统一格式、有成熟解法；缺点是需要处理 DPAPI、AES-GCM 这些加密细节，对当前登录用户之外的数据无能为力。
| 路线 | 核心思路 | 典型成功率 | 风险 | 适用场景 |
|---|---|---|---|---|
| 控件消息 | 取句柄、清掩码、读文本 | 只对标准控件高，现代 UI 低 | 中，会被安全软件标记 | 旧客户端、MFC/VB 程序 |
| 进程内存 | 读目标进程堆内存找明文 | 中，受位宽和内存布局影响 | 高，报毒概率大 | 功能机型的最后手段 |
| 凭据文件 | 解析 WLAN/Login Data 等文件 | 高，但限当前用户 | 低，接近系统原生命令 | Wi-Fi、浏览器、系统凭据 |
我给从业者的建议很直接：优先走第三条路线。它最接近「系统本来就会做的事」，误报率低、可解释性强；控件消息路线只用来处理确实还跑在 Win32 控件上的老程序；进程内存路线除非你愿意整天跟杀毒软件打架，否则别碰。
2.3 解压之前先做静态判断：zip 里的文件结构透露了工具的真实行为
拿到一个「星号密码查看工具.zip」，第一步绝对不是双击运行。先把压缩包当证据文件处理，观察它里面装了什么。常见结构是这样：一个主程序 exe，可能带一份说明文本，还可能附带语言文件、图标资源或动态库。如果压缩包里只有一个裸 exe，反而要多留个心眼——正规开发者通常会写使用说明；什么都不写，要么是个人小工具，要么是发布者刻意不留痕迹。
对主程序做三个静态检查，每步都有现成命令。第一是算哈希，留存证据也方便后续比对：
Get-FileHash .\PwdViewer.exe -Algorithm SHA256记录下哈希值，再拿到 VirusTotal 这类多引擎扫描站查一下。第二是看数字签名：
Get-AuthenticodeSignature .\PwdViewer.exe | Select-Object Status, StatusMessage, SignerCertificate如果 Status 不是 Valid，说明文件没有有效签名，或者签名已被破坏。这不是说它一定有问题，但可信度要降一档。第三是看 PE 头里的位数和导入表：用任意 PE 查看工具打开主程序，看它依赖哪些系统 DLL。如果导入表里有 user32.dll 的 SendMessageW、crypt32.dll 的 CryptUnprotectData，说明它走的是控件消息加 DPAPI 解密，行为可预期；如果出现大量进程注入相关 API，比如 WriteProcessMemory、CreateRemoteThread，那就不仅仅是「查看星号」这么简单了，应该直接弃用。
还要注意加壳。UPX 这类壳在个人工具里很常见，作者图的是压缩体积而不是隐藏恶意。但壳的存在会让杀毒软件难以静态分析，杀软宁可误报也不放过。所以「报毒 = 恶意」这个等式不成立，但「报毒 = 高风险」是成立的。判断依据是你的使用场景和工具来源，信任度不够就自己写方案，下一章就给三个能直接抄的替代品。
3. 自己动手做最小可用版本：三个可以直接抄的脚本
3.1 系统自带方案：用 netsh 恢复 Wi-Fi 密码
先给最简单的方案。Windows 把已连接过的 Wi-Fi 密码存在 WLAN 配置里，用 netsh 就能列出来，不需要装任何第三方工具。第一步看机器上存过哪些 Wi-Fi 配置：
netsh wlan show profiles输出里「所有用户配置文件」下面的名字就是这台机器连过的热点。第二步针对某个配置导出明文密码：
netsh wlan show profile name="HomeWiFi" key=clear重点在 key=clear 这个参数。不加它，输出里只会显示「当前密码」字段的占位符；加了它，系统直接把配置里的明文密钥打印出来，结果在「安全设置」一节下。这个命令需要管理员权限，普通窗口跑会报错或者不给明文，原因在避坑章节细说。
这条命令的价值不光是 Wi-Fi 本身。它说明了一个非常重要的做事方式：系统自带工具永远是你的第一选择。它的行为有文档可查、不会在后台偷偷干别的、杀毒软件也不会报警。与其在网上下载来路不明的 exe，不如先想「系统有没有原生能力」。绝大多数密码恢复场景，答案都是有。
3.2 控件消息方案：用 PowerShell 定位窗口并清掉掩码字符
如果你确实要处理某个老式客户端程序里的密码框，可以用 PowerShell 写一个最小版的「控件型查看器」。核心思路：鼠标悬停在密码框上，脚本取到该控件的窗口句柄，然后发送 EM_SETPASSWORDCHAR 消息把掩码字符清零，再让控件重绘，最后读文本。
Add-Type -AssemblyName System.Windows.Forms Add-Type @" using System; using System.Runtime.InteropServices; using System.Text; public struct POINT { public int X; public int Y; } public class Win32Helper { [DllImport("user32.dll")] public static extern IntPtr WindowFromPoint(POINT p); [DllImport("user32.dll", CharSet = CharSet.Unicode)] public static extern IntPtr SendMessage(IntPtr hWnd, int msg, IntPtr wParam, IntPtr lParam); [DllImport("user32.dll", CharSet = CharSet.Unicode)] public static extern IntPtr SendMessage(IntPtr hWnd, int msg, IntPtr wParam, StringBuilder lParam); [DllImport("user32.dll")] public static extern bool GetWindowRect(IntPtr hWnd, out RECT rect); public struct RECT { public int Left, Top, Right, Bottom; } } "@ # 消息常量 $WM_GETTEXT = 0x000D $WM_GETTEXTLENGTH = 0x000E $EM_SETPASSWORDCHAR = 0x00CC $WM_PAINT = 0x000F Write-Host "3 秒内把鼠标移到目标密码框上，期间不要移动..." -ForegroundColor Yellow Start-Sleep -Seconds 3 $pt = New-Object POINT $pt.X = [System.Windows.Forms.Cursor]::Position.X $pt.Y = [System.Windows.Forms.Cursor]::Position.Y $hWnd = [Win32Helper]::WindowFromPoint($pt) if ($hWnd -eq [IntPtr]::Zero) { Write-Host "未命中任何窗口，请确认鼠标确实停在密码框上" -ForegroundColor Red exit } # 1) 清掉掩码字符，密码内容会短暂可见 [Win32Helper]::SendMessage($hWnd, $EM_SETPASSWORDCHAR, [IntPtr]::Zero, [IntPtr]::Zero) | Out-Null # 2) 触发重绘，让界面及时刷新 [Win32Helper]::SendMessage($hWnd, $WM_PAINT, [IntPtr]::Zero, [IntPtr]::Zero) | Out-Null Start-Sleep -Milliseconds 200 # 3) 取文本长度再取文本 $len = [Win32Helper]::SendMessage($hWnd, $WM_GETTEXTLENGTH, [IntPtr]::Zero, [IntPtr]::Zero) $sb = New-Object System.Text.StringBuilder ($len + 1) [Win32Helper]::SendMessage($hWnd, $WM_GETTEXT, [IntPtr]($sb.Capacity), $sb) | Out-Null if ($sb.ToString().Length -gt 0) { Write-Host "读取到明文: $($sb.ToString())" -ForegroundColor Green } else { Write-Host "读到空值，密码框可能不是标准 Edit 控件，或系统阻止了本次读取" -ForegroundColor Red }逻辑说明：脚本先把鼠标坐标转成 POINT 结构，WindowFromPoint 是 user32 提供的函数，能根据屏幕坐标直接命中窗口或子控件，这比遍历窗口树省事得多。拿到句柄后，发送 EM_SETPASSWORDCHAR 且 wParam 为 0，含义是「掩码字符设置为空」，这是 Win32 控件官方支持的消息。随后 WM_PAINT 强制控件重绘，屏幕上会短暂显示出密码原文，这是该方案无法避免的副作用。
参数说明：WM_GETTEXTLENGTH 返回的是字符数，不是字节数，所以给 StringBuilder 分配容量时要加 1 给结尾空字符；SendMessage 跨进程传递 StringBuilder 时，系统会负责把目标进程的文本复制回来，不需要自己开共享内存。如果最终读到空值，最常见的原因是控件不是标准 Edit 类，或者目标进程权限更高、消息被 UIPI 拦截。简单说，这脚本对 Win XP/7 时代的老程序成功率不错，Win10/11 上挑控件，别把它当万能工具。
3.3 凭据文件方案：用 Python 解密浏览器 Login Data
浏览器保存的密码才是大多数人真正想找回的。以 Chromium 内核浏览器为例，密码文件叫 Login Data，放在用户目录下的 User Data 里，数据库表结构是标准的 SQLite 三列：域名、用户名、密码密文。密文用 DPAPI 包了一层主密钥，拿到主密钥后再用 AES-GCM 解开。这段代码可以直接跑：
import base64, json, os, sqlite3, shutil from pathlib import Path try: import win32crypt # pip install pywin32 except ImportError: win32crypt = None try: from cryptography.hazmat.primitives.ciphers.aead import AESGCM except ImportError: AESGCM = None if win32crypt is None or AESGCM is None: raise SystemExit("缺少依赖，先执行: pip install pywin32 cryptography") browser_root = Path(os.environ["LOCALAPPDATA"]) / "Edge" / "User Data" def get_master_key(): with open(browser_root / "Local State", "r", encoding="utf-8") as f: enc_key = base64.b64decode(json.load(f)["os_crypt"]["encrypted_key"]) # 去掉 "DPAPI" 前缀后用当前用户主密钥解开，结果就是 AES-GCM 的 key return win32crypt.CryptUnprotectData(enc_key[5:], None, None, None, 0)[1] def decrypt_password(blob, key): # Chromium 80+ 密文格式: v10/v11 前缀(3) + nonce(12) + ciphertext + tag(16) nonce, ciphertext = blob[3:15], blob[15:-16] return AESGCM(key).decrypt(nonce, ciphertext, None).decode("utf-8") master_key = get_master_key() login_db = browser_root / "Default" / "Login Data" tmp_db = Path(os.environ["TEMP"]) / "login_copy.db" # 直接读 Login Data 会被 SQLite 锁住，先复制到临时目录 shutil.copy2(login_db, tmp_db) conn = sqlite3.connect(tmp_db) for origin, user, blob in conn.execute( "SELECT origin_url, username_value, password_value FROM logins"): if not blob: continue try: pwd = decrypt_password(blob, master_key) print(f"{origin}\t{user}\t{pwd}") except Exception as e: print(f"{origin}\t{user}\t<解密失败: {e}>") conn.close()逻辑说明：整个链路是 DPAPI 解主密钥、AES-GCM 解密文。Local State 里的 encrypted_key 是一段被 DPAPI 加密的二进制，前缀有 5 个字节的 "DPAPI" 标识，去掉之后用 CryptUnprotectData 解密，CryptoAPI 会自动使用当前进程所属用户的登录凭据来解。拿到主密钥后，每条密码记录的 password_value 不是标准密文格式，它有 3 个字节的前缀（标记版本），紧接着 12 字节 nonce，然后是密文和 16 字节 GCM 校验标签，所以切片时要注意位置。
参数说明：浏览器根目录要根据实际内核和版本调整，代码里写的 "Edge" 目录可以直接换成同内核浏览器的目录名；profile 路径同理，默认是 Default，如果用户建过多 Profile，要逐目录扫描。这段代码只能在你自己的 Windows 会话里跑，换用户、换机器都解不开，因为 DPAPI 主密钥和用户身份强绑定。想拿这个去解别人的密码，趁早放弃。
4. 参数怎么定、回显怎么读：使用这类工具的通用约定
4.1 模式、目标、输出三组参数的选型逻辑
市面上的星号查看工具虽然各有各的界面，但核心参数逃不出三组：运行模式、目标范围、输出方式。我自己拿到一个工具，先看它的命令行帮助或者配置文件，通常会有类似下面这张表的结构：
| 参数组 | 常见键 | 取值示例 | 选型逻辑 |
|---|---|---|---|
| 运行模式 | --mode / -m | wifi / control / profile / dump | 先明确目标类型再选模式，不要一上来就全量 dump |
| 目标范围 | --pid / --class / --hwnd | 1234 / Edit / 0x000A0B2C | 范围越窄越不容易误伤，也越不容易被杀软盯上 |
| 取样间隔 | --delay / -d | 200-500ms | 太短会让目标进程 UI 卡顿，太长等得心焦 |
| 输出格式 | --out / -o | plain / csv / json | 要入库就选 json，人看就选 plain |
| 输出路径 | --base | ./result_20250101 | 按日期归档，方便事后追溯 |
先说运行模式。wifi 模式就是包装了 netsh，control 模式走控件消息，profile 模式读取浏览器或系统配置。如果你要处理的是 Wi-Fi 密码，那就直接用系统原生命令，根本不用下载工具；如果你要处理的是老客户端密码框，再考虑 control 模式。模式选错是最大的浪费，很多人的翻车都是从「想拿 Wi-Fi 密码却点了个 dump 全量导出」开始的。
再说目标范围。凡是工具支持 --pid 或 --class 参数的，务必用上。比如你想处理某老程序的密码框，先看进程 PID，再限定到这个进程的窗口，不要对所有窗口广播。广播式操作有两层坏处：一是拿到的结果里混入无关窗口的文本，要花时间筛；二是无差别遍历窗口树的行为特征太明显，安全软件很容易报警。
最后是输出格式和时间间隔。interval 设 200-500 毫秒对多数标准控件够用，设置太短，消息发得过于密集，目标进程界面会明显掉帧甚至无响应；输出尽量用带字段分隔的格式并追加到文件，别只打在屏幕上——恢复密码这种事，往往是一次性的，回显刷过去再想找就难了。
4.2 安全运行顺序：先静态、再隔离、最后最小权限试点
正确使用这类工具的流程，我总结成四步，一步都不能省。
第一步还是静态检查。用第 2 章说的方法做哈希、签名、导入表分析。这里的重点是「先给工具定性再运行」，绝不能在没搞清它行为的情况下直接双击。
第二步是隔离运行。条件允许的话，在虚拟机里先跑一遍，观察它对系统做了什么改动。注意看两件事：是否写入了自启动项，是否创建了额外进程。虚拟机里跑完如果没有异常，再考虑在真实环境用。虚拟机不是万能，有些工具会检测虚拟环境，但对付大多数个人小工具足够了。
第三步是最小权限试点。不要用管理员身份直接跑完整功能。第一次运行只给普通权限、只指定一个窄目标，比如一个特定的 Edit 控件。行得通再用起来；行不通就从参数和日志里查原因。管理员权限是把双刃剑：它能突破 UIPI 拿到更多句柄，但也意味着工具拥有读写你整个系统的能力。
第四步是用后清理。恢复出来的密码建议转存到你自己信赖的密码管理器，不要以明文文件长期放在桌面上；工具本体在完成任务后从目标机器上删除，减少残留风险。这不是小题大做，这类工具本身就是安全软件的敏感对象，留着只会惹麻烦。
4.3 回显结果的验证与归档
工具输出结果别急着信，先验证再归档。验证方法很朴素：找一个你知道答案的密码去试。比如你自己刚设了一个 Wi-Fi 密码，故意不记在纸上，用工具恢复一遍，看结果和自己记忆的密码是否一致。这一条放在所有验证方法的第一位，因为只有已知值才能暴露工具的内部逻辑错误。
归档格式我一般这么定：来源设备名、恢复时间、目标类型（wifi/browser/control）、明文内容、使用的工具或命令、哈希值。前三个字段是溯源信息，后两个字段是复现信息。这样做的好处是，半年后你想不起来某个密码是从哪个环境恢复的，翻记录能直接定位。
顺手提醒一句隐私边界：恢复出来的凭据等同于密码明文，归档文件本身要加密存放。用压缩工具带密码打包，或者直接存进加密柜，都比随手放一个 txt 安全得多。尤其在企业环境里，明文凭据文件的存放位置和保留期限都是有合规要求的，别因为图省事给自己埋雷。
5. 避坑：星号工具最常见的 5 个翻车现场
5.1 解压就被杀毒软件清除
现象：下载的 zip 刚解压完，exe 文件瞬间没了，安全中心提示检测到 HackTool 类程序。很多用户会怀疑是下载源有问题，换一个网站重新下，结果还是一样。
原因：这类工具的行为特征太明显——跨进程发送控制消息、读取其他进程内存、调用 DPAPI 解密，这些操作单独看都不违法，组合起来就是安全软件眼中标准的「潜在不需要的程序」。另外个人开发者习惯用 UPX 加壳，加壳本身进一步拉高了误报概率。
解决：先别跟杀毒软件较劲。回到第 3 章，Wi-Fi 用 netsh 恢复，浏览器密码用 Python 脚本解码，老程序密码框用 PowerShell 发消息。这三条路都不需要下载任何第三方 exe，自然也就不存在报毒问题。如果非要用现成工具，就只在隔离虚拟机里用，并提前把目标机器网络断开。
5.2 工具位数和目标程序不一致，消息发过去石沉大海
现象：64 位系统上运行 32 位版工具，WindowFromPoint 能命中窗口，但发给密码框的 EM_SETPASSWORDCHAR 没有效果，WM_GETTEXT 也不返回内容。
原因：64 位系统里，32 位进程和 64 位进程有不同的消息通道。32 位工具通过窗口句柄向 64 位进程发送消息时，系统在多数情况下不会传递控件专用消息的预期效果，尤其涉及文本缓冲区时，位宽不一致会导致参数解析错位。
解决：确认目标客户端程序的位数，再选择对应位数的工具。怎么看目标程序位数？任务管理器里「详细信息」页签能看到进程位数标识；或者在文件属性里看 PE 头。我的习惯是：桌面上能跑到的新程序默认 64 位，历史遗留的财务软件、OA 客户端则大概率 32 位。两者用同一位数的工具去读，成功率会高很多。
5.3 没有管理员权限，控制句柄根本拿不全
现象：普通权限运行脚本，WindowFromPoint 能取到句柄，但 SendMessage 返回值一直为 0，或者控件列表里少了好几个窗口，尤其读不到其他管理员进程里的密码框。
原因：Vista 之后 Windows 引入了 UIPI，完整性级别低的进程不能向级别高的进程发送窗口消息，更不能读取它们管理的窗口内容。很多系统服务、管理工具都运行在更高完整性级别下，普通权限的工具根本够不到。
解决：用管理员身份重新运行你的工具或脚本。PowerShell 里可以这样提权：
Start-Process powershell -Verb RunAs -ArgumentList '-File .\read-control.ps1'但注意，管理员权限意味着工具也可以做更多破坏性操作，所以提权运行的脚本要确保是你自己写的、你清楚每一行在干什么。另外个别系统进程即使在管理员权限下也读不了，那是系统核心保护，不是工具的问题。
5.4 浏览器和新兴框架的密码框不响应经典控件消息
现象：把鼠标移到浏览器网页的密码框上，脚本能命中窗口，但清掩码消息发出去毫无反应，屏幕上还是圆点。
原因：网页密码框由浏览器内核绘制，不是传统的 Win32 Edit 控件。Chromium 内核在渲染密码输入时使用自绘合成，窗口体系里根本没有一个可以接收 EM_SETPASSWORDCHAR 的控件存在。同样的道理适用于 Electron 应用、新版 WPF 应用、游戏内嵌输入框。
解决：对这类目标，控件消息路线直接放弃。浏览器保存的密码走 Login Data 解密，也就是第 3 章的 Python 方案；应用内保存的密码优先在应用自己的「设置-密码」页面导出。这条路走不通，就接受现实——不是所有界面上的星号都能本地恢复，很多现代应用把密码放在安全芯片或远程服务器上，本地根本没有明文副本。
5.5 把加密凭据文件拷到别的机器解密，结果一场空
现象：把 Login Data 和 Local State 打包拷到另一台电脑，或者在自己的另一个 Windows 用户下运行解密脚本，CryptUnprotectData 抛异常，或者解出来的数据乱码。
原因：DPAPI 的主密钥和当前用户的安全标识、登录密码、机器凭据绑定。同一用户在同一台机器上解密是正常路径；换机器、换用户、甚至重置过账号密码，主密钥就对不上了。
解决：解密必须在凭据生成时所在的环境里、以那个用户的身份进行。这不算 Bug，而是有意设计——不然任何拷走文件的人都能解出密码，那凭据存储的安全性就崩塌了。所以应用这类工具的前提是：你能登录目标用户的会话并以该用户身份运行脚本。锁屏状态下也不行，会话还没解锁，主密钥在内存里未被激活，解出来的东西同样是错的。
6. 进阶：用「已知值」验证工具，并把恢复流程脚本化
6.1 验证工具是否可靠：三个已知值测试
任何工具第一次使用，先做一次「已知值验证」。我的做法是在虚拟机里搭三个对照场景，全部填入已知密码，再分别用工具恢复，比对结果。
第一个场景是 Wi-Fi：给虚拟网卡建立一个测试连接配置，设一个随机密码，用 netsh key=clear 恢复，确认与设定值一致。第二个场景是标准控件：用记事本写一个小对话框程序，或者直接找一个老式 MFC 工具，密码框里输入已知字符串，用 PowerShell 脚本读取。第三个场景是浏览器：在测试配置的浏览器里保存一个站点密码，然后跑 Login Data 解密脚本。三个场景全部通过，才算对工具建立了基本信任。
6.2 把 Wi-Fi 批量导出变成一条命令
手动逐个恢复太慢，netsh 支持直接导出本机所有 Wi-Fi 配置，一条命令解决：
netsh wlan export profile folder=C:\temp\wifi_backup key=clear这条命令会把所有已存在的 WLAN 配置导出成 XML 文件，key=clear 表示密钥以明文形式写进 XML，字段是keyMaterial。管理员权限下执行，输出目录里会多出对应热点名的 XML。这个方案的优点是全量、格式统一、便于归档；缺点同样明显：XML 是明文，目录权限一定要收紧，用完删除或转存到加密容器。
有了这个技巧，helped me 在需要批量重装办公环境的场景里省了大量时间——提前导出一批配置，装完系统直接导入，比逐个手动连 Wi-Fi 再输密码高效太多。
6.3 一个教训
最后说一个真实经历。某次在客户现场，为了恢复一个老业务系统的登录密码，我顺手在网上下了一个号称「万能星号查看器」的加壳工具，结果解压瞬间被安全中心隔离，还触发了一轮全盘扫描，客户脸色很难看。后来我用系统自带的 netsh 和一段 PowerShell，十几分钟就把问题解决了。从那以后我给自己立了个规矩：凡是涉及凭据恢复，先查系统原生命令，再写脚本，最后才考虑第三方工具——工具只是手段，拿到结果的方式越简单、越透明，越不容易翻车。希望帮到你。
本文还有配套的精品资源，点击获取
