PowerShell 反混淆

粘贴一段混淆的 PowerShell 命令或脚本。它会在浏览器里逐层解码——不上传、不执行——结果以惰性文本显示，可疑模式则作为待核查的线索列出。

PowerShell 混淆把脚本的真实行为藏在一层层编码后面：Base64 编码的 -EncodedCommand、gzip 压缩、字符码、字符串拼接、-f 格式化运算符和反引号转义——逐层剥开，直到剩下可读文本，或者到达静态还原的终点。本工具一次剥一层，并展示每一步，让你不用运行脚本就能看清它在说什么。如果脚本来自 Windows 事件日志，EVTX 查看器可以读取 .evtx 文件并标记 4104 事件；其他文本日志则用日志解析器找出关键行。配套文章如何反混淆 PowerShell 脚本用文字讲清了这些层次和安全的工作流程。

最后更新: 2026年11月14日

🔒 你的脚本只在浏览器里还原，绝不离开你的设备。无需账号、不上传、不调用服务器——而且这里的任何东西都不会被执行。

你粘贴的脚本会怎样处理

什么都不会离开你的浏览器。脚本由本页的 JavaScript 在本地还原：不上传、不调用服务器、不存储、无需账号。这很重要，因为可疑脚本绝不应该粘贴到聊天窗口里——聊天窗口可能运行它、引用它或保存它——也不应该为了看它做什么而运行它。关闭页面即丢弃。

干净的结果不能证明什么

结果干净不等于安全。它只表示没有已知的层次适用、没有指标命中——动态构建的字符串、加密的载荷或只在运行时存在的值，静态还原是解不开的；没有任何指标的脚本仍然可能是恶意的。

命中指标不等于恶意。下载摇篮、IEX 和编码命令在管理和部署中都有合法用途；每一次命中都是结合上下文核查的线索，不是结论。

永远不要为了搞清一个未知脚本在做什么而运行它。先惰性解码，把结果交给你的 EDR 或沙箱，并对解码后的文本保持与编码形式同样的怀疑——它是证据，不是安全证明。

还原是怎么工作的

本工具按顺序尝试八个层次，一步一层，并不断重复，直到没有层次适用或已剥开十层：-EncodedCommand 提取（Base64 转 UTF-16LE，失败则转 UTF-8）；裸 Base64 密文；gzip 或 deflate 解压（输入可以先包一层 Base64）；[char] 与 [char[]] 字符码序列；跨混合引号与多行的字符串拼接；-f 格式化运算符；反引号转义去除；以及 ${...} 与 $变量占位符的列表——占位符永远不会被解析，因为它们的值只在运行时存在。每一步都会展示还原前后的文本和字符数。

本工具不做什么：它绝不执行任何东西——结果是惰性文本，页面即使意外也无法运行它。它解不开动态构建的字符串、加密载荷或只在运行时存在的值，也不判断脚本是否安全：指标只是模式匹配；一个让所有层次都失效的脚本会被报告为“无法继续还原”，绝不会被说成干净。

脚本块日志（事件 4104）记录了 PowerShell 实际运行的脚本内容，但长脚本会被拆成约 4 KB 的片段，每个片段带有 ScriptBlockId、MessageNumber 和 MessageTotal。重组标签页按 ScriptBlockId 分组、按 MessageNumber 排序、拼接，并标记缺失的部分——一个 3 段中缺第 2 段的分组就是不完整的，缺失的文本无法猜测。重组后的文本会送入同一个反混淆器。

常见问题

为什么结果显示为惰性文本，而不是可运行的脚本？

因为反混淆的目的是读懂可疑脚本，而不是运行它。解码后的文本仍可能下载并执行载荷——以惰性文本加复制按钮的形式展示，你可以检查它、把它交给 EDR 或沙箱，而永远不用冒双击的风险。

工具停在“无法继续还原”，接下来怎么办？

剩下的文本用了本工具不认识的层次、在运行时构建字符串，或是加密的——静态还原已经到头了。不要为了搞清楚而运行它：把编码形式和部分解码结果交给 EDR 或沙箱，并把未知的层次视为怀疑的理由，而不是干净的结果。

这些指标该怎么用？

把每一个都当作问题，而不是答案。下载摇篮要问 URL 指向哪里、那个主机是否在预期之中；AMSI 绕过模式要问脚本为什么想让扫描器失明；编码命令要问编码藏起了什么。在 EDR、日志和脚本来源的那台机器上结合上下文逐一核查，确认之后再下结论。