[Bug已解决] 未签名可执行文件被 Windows Defender 误报为木马代码签名与信任解决方案一、现象长什么样你发布了一个 Windows 可执行文件比如一个「计算机操作 / 自动化」工具codex-computer-use.exe。用户一运行Windows Defender 直接弹Trojan:Win32/ClickFix.DE!MTB——把它当木马隔离了。即 GitHub Issues (openai/codex) #31419Windows Defender flags unsigned codex-computer-use.exe command line as Trojan:Win32/ClickFix.DE!MTB。本质是这个 exe 没有数字签名unsigned而 Defender 的启发式尤其针对「能操控鼠标键盘/弹窗诱导点击」类行为的程序对未签名二进制更敏感于是误报为木马。这是个通用的「Windows 代码签名 / 防误报」问题不是你代码真有恶意。本文聚焦通用技术Windows Authenticode 代码签名、为什么未签名会被启发式误报、如何对 exe 做可信签名、以及发布前的信任建设SmartScreen/信誉。用真实可操作的命令说明不依赖具体产品。二、背景为什么未签名 exe 容易被误报Windows 对可执行文件有一套信任链Authenticode 签名用受信任 CA 颁发的代码签名证书给 exe 加数字签名。系统能验证「这文件来自某身份、未被篡改」SmartScreen 信誉微软云信誉系统根据「下载量、签名者、投诉」给文件打分陌生未签名文件常被拦防病毒启发式Defender 等看行为特征。像「模拟点击 / 弹窗诱导用户点按钮ClickFix」这类行为正是木马常用手法所以 Defender 有专门检测如ClickFix家族。一个未签名的、又会操控 UI 的 exe极易撞上这条启发式。具体到这个 bug程序叫computer-use行为是「操作计算机鼠标键盘/点击」。Defender 的ClickFix.DE检测专门抓「诱导用户点击的木马」。你的程序行为相似 未签名无身份背书于是被误判。三、为什么「未签名」是放大器签名不仅是「防伪」更是向系统证明身份有签名Defender 能关联「签名者 X 发布过很多干净文件」降低误报概率未签名Defender 看不到可信身份只能纯靠行为启发式判断误报率显著升高ClickFix.DE!MTB这类带!MTBmachine learning / 云查后缀的往往是「行为相似 无签名信誉」触发的 ML 判定。所以签名 积累信誉是消除这类误报的正道。四、最小可运行检查 exe 是否已签名PowerShell下面用 PowerShell 演示「如何检查一个 exe 的签名状态」以及签名验证逻辑真实命令Windows 环境# 检查文件是否有 Authenticode 签名 Get-AuthenticodeSignature -FilePath codex-computer-use.exe # 输出 Status 字段 # Valid - 签名有效且链可信 # NotSigned - 未签名易被误报 # HashMismatch - 签名后文件被改 # UnknownError - 证书链不受信需信任 CA # 用 sigcheckSysinternals看更详细 # sigcheck -v codex-computer-use.exePython 也可读取 PE 签名头示意import subprocess # 调系统工具判断跨平台 CI 上也可在 Windows runner 跑 def is_signed(path): out subprocess.run( [powershell, Get-AuthenticodeSignature, -FilePath, path], capture_outputTrue, textTrue, ).stdout return Status : Valid in out print(is_signed(codex-computer-use.exe))要点发布前必须确认Status: Valid否则就是「未签名」状态易误报。五、解决方案一用代码签名证书给 exe 签名核心正确做法购买/获取代码签名证书Code Signing Certificate用signtool对 exe 签名# 用 signtoolWindows SDK / Visual Studio 自带签名 signtool sign /fd SHA256 /td SHA256 /tr http://timestamp.digicert.com /sha1 证书指纹 codex-computer-use.exe # 参数说明 # /fd SHA256 文件摘要算法 # /tr URL RFC3161 时间戳服务让签名在证书过期后仍有效 # /sha1 thumbprint 用证书指纹指定签名身份签名后exe 带上「谁发布的、未被篡改」的可信标记Defender 误报率大幅下降。注意现代代码签名证书通常要求硬件安全模块HSM/ 密钥不导出EV 或标准但密钥存于 HSM这是 CA/Browser 基线要求提升签名可信度。六、解决方案二积累 SmartScreen 信誉即使签名了全新签名者首次发布仍可能被 SmartScreen 拦「未知发布者」。积累信誉的方法持续用同一证书签名发布下载量上来后微软云信誉会把你的签名者标记为可信EV 代码签名证书扩展验证证书初始信誉更高发布即较少被拦提交误报反馈让用户/你在 Microsoft 安全智能提交「误报」样本加速信誉修正保持二进制稳定频繁改 exe 哈希会拖慢信誉积累。七、解决方案三减少触发启发式的行为特征既然ClickFix检测针对「诱导点击」行为发布前审视程序行为避免更像木马不要模拟「弹窗骗用户点按钮」的 UI 模式自动化操作需明确、可审计、用户授权而非隐蔽操控在文档/UI 里清楚说明「这是自动化工具、需要用户明确启动」避免与已知木马重叠的行为签名如从剪贴板/网页自动执行命令。这既能降误报也更符合安全规范用户明确授权、行为透明。八、解决方案四CI 里自动签名 验证把签名做成发布流水线一步并验证# 示意CI 发布阶段 - name: Sign executable run: | signtool sign /fd SHA256 /tr http://timestamp.digicert.com /sha1 ${{ secrets.CODE_SIGN_THUMBPRINT }} dist/codex-computer-use.exe - name: Verify signature run: | powershell Get-AuthenticodeSignature -FilePath dist/codex-computer-use.exe # 断言 Status: Valid 才允许发布这样每次发布都是签名态不会漏发未签名版本这正是 #31419 的根因——发了一个未签名构建。九、排查清单Defender 误报未签名 exe运行 exe 被 Defender 标Trojan:Win32/ClickFix.DE!MTB且程序本身无害 → 未签名 行为启发式误报#31419 类。检查签名Get-AuthenticodeSignature看Status若为NotSigned即根因。签名用代码签名证书signtool sign签 exe加 RFC3161 时间戳。积累信誉同一证书持续发布、考虑 EV 证书、提交误报反馈。降启发式审视行为避免 ClickFix 类诱导点击特征行为透明可授权。CI 签名发布流水线自动签名 验证Status: Valid杜绝漏发未签名版。十、小结Windows Defender flags unsigned codex-computer-use.exe command line as Trojan:Win32/ClickFix.DE!MTBopenai/codex #31419的本质是该 exe 未做 Authenticode 代码签名而 Defender 针对「操控 UI/诱导点击ClickFix」类行为的启发式对无身份背书的未签名二进制高度敏感于是把「行为相似 无签名信誉」的程序误判为木马。通用解决方案适用于任何 Windows 可执行文件发布代码签名用代码签名证书signtool sign签 exeSHA256 RFC3161 时间戳向系统证明身份积累信誉同一证书持续发布、考虑 EV 证书、向微软提交误报反馈提升 SmartScreen 信任降启发式让自动化行为透明、需用户明确授权避免 ClickFix 类诱导点击特征CI 签名验证发布流水线自动签名并断言Status: Valid杜绝漏发未签名构建。记住未签名 敏感行为 Windows 防病毒误报高发组合。代码签名是向系统「证明身份」的最直接手段能显著降低启发式误报。这是 Windows 软件发布安全里「Authenticode 签名 / SmartScreen 信誉」的标准实践也符合安全规则中的「签名与信任」要求。