Windows上验证Authenticode签名须用WinVerifyTrust并启用吊销检查，解压替换需原子操作与错误隔离，且须协调进程生命周期管理。
如何在 Windows 上用 C++ 验证下载文件的 Authenticode 签名
不能只靠文件哈希——攻击者可篡改文件后重算哈希。Windows 原生支持的 WinVerifyTrust 才是验证发布者身份和签名完整性的正确方式。
关键点：必须用 WINTRUST_DATA 指定 WTD_REVOKE_CHECK 和 WTD_REVOCATION_CHECK，否则无法检测已被吊销的证书；还要检查 dwUIChoice = WTD_UI_NONE 避免弹窗阻塞自动更新流程。
- 调用前确保文件已完全写入磁盘（
FlushFileBuffers），否则签名验证可能失败（返回TRUST_E_NOSIGNATURE） - 若程序运行在低完整性级别（如受保护的 IE 进程或沙箱中），
WinVerifyTrust可能因权限不足静默失败，建议提前用GetTokenInformation检查TokenIntegrityLevel - 验证通过后，仍需比对
WINTRUST_CERT_INFO中的psCertChain里颁发者 CN 是否为你信任的 CA（例如"YourCompany Inc."），避免依赖系统根证书列表的宽松策略
用 libzip 安全解压并原子覆盖主程序文件
直接 fopen(..., "wb") 覆盖正在运行的 EXE 会失败（Windows 锁定）；而先删后写又存在窗口期——进程可能在删除后、写入前崩溃，导致程序不可用。
正确做法是：解压到临时目录 → 验证所有目标文件签名 → 用 MoveFileEx 带 MOVEFILE_REPLACE_EXISTING | MOVEFILE_WRITE_THROUGH 原子替换。
立即学习“C++免费学习笔记（深入）”；
-
libzip解压时务必设置ZIP_AFL_ENCRYPTION_STRONG校验 ZIP 中每个 entry 的 CRC32（防止 zip bomb 或传输损坏） - 解压路径必须使用绝对路径且不含
..（防止 zip slip），用PathCchCanonicalize规范化后再检查是否以预期根目录开头 - 主程序 EXE 文件必须放在 ZIP 根目录（如
app.exe），不能嵌套在子目录；否则MoveFileEx替换时可能因路径长度或权限失败
为什么不能跳过「暂停服务/进程」直接替换正在运行的 EXE
Windows 不允许写入或删除被映射为可执行映像的文件。即使你用 TerminateProcess 杀掉主进程，如果它启用了 Windows 服务、托盘常驻或崩溃后自重启，新旧版本可能短暂共存，引发 DLL 版本混乱或注册表残留。
- 推荐方案：更新进程（updater.exe）启动时，向主程序发送自定义 WM_COPYDATA 消息，触发其执行
ExitProcess(UPDATE_PENDING)并等待 3 秒；超时则强制终止 - 若主程序是服务，必须用
ControlService发送SERVICE_CONTROL_STOP，而非仅杀进程；且要在WaitForServiceStatus确认状态为SERVICE_STOPPED后再继续 - 替换完成后，不要立即
CreateProcess启动新 EXE——先用GetBinaryType确认文件确实是 Win32 GUI/Console 类型，避免执行到损坏的 PE 头
签名验证 + 解压 + 替换整个流程的错误隔离设计
把校验、解压、移动三个阶段拆成独立函数，并各自返回明确错误码（如 ERR_SIG_INVALID / ERR_ZIP_CORRUPT / ERR_MOVE_FAILED），而不是统一 throw exception —— 自动更新必须能区分“可重试”（网络超时）和“需人工介入”（签名失效）的错误。
- 每步完成后都调用
GetLastError()并记录（尤其MoveFileEx失败时，ERROR_ACCESS_DENIED通常意味着防病毒软件拦截，ERROR_SHARING_VIOLATION表示文件仍被占用） - 临时解压目录应使用
GetTempPath2+CreateDirectory生成唯一 GUID 子目录，避免多实例并发更新冲突 - 整个流程必须有超时控制（如总耗时 > 120s 强制中止），防止卡死在签名 OCSP 查询等外部依赖上
真正棘手的不是单个 API 调用，而是签名链验证与进程生命周期管理之间的耦合——比如证书吊销检查超时，该继续还是回滚？这需要结合你的部署环境做取舍，没有银弹。
