文件扩展名与执行机制
Windows 中，文件扩展名、文件内容和打开方式共同影响一个文件如何被处理。把 demo.exe 重命名为 demo.tmp 或 demo.docx，只改变文件名，不会把程序转换成临时数据或 Word 文档，也不会删除其中的代码。
判断一个文件能否执行，需要同时看它的真实格式和启动方式。扩展名决定了很多默认打开行为，但不是可执行能力的最终边界。
两条不同的处理路径
文件关联：双击后交给谁
在资源管理器中双击文件时，Windows Shell 通常根据文件扩展名和已注册的打开操作处理文件。例如，.docx 通常关联 Word 或 WPS，.txt 通常关联文本编辑器。
双击 report.docx
↓
Windows Shell 查询 .docx 的文件关联
↓
启动 Word / WPS，或通知已经运行的应用
↓
应用将 report.docx 作为文档解析
这里被执行的是 Word / WPS，文档是传给它的数据。若 report.docx 实际只是改了后缀的 EXE，应用通常会报告格式不符、文件损坏或无法打开，不会仅因发现其中是 EXE 就自动把它当作程序执行。
ShellExecute / ShellExecuteEx 是 Windows 提供的 Shell 操作接口，可以打开程序，也可以根据文件关联打开文档；不能把它们简单理解为“无论什么后缀都直接运行”。
创建进程：把目标当作程序加载
其他程序可以明确调用 CreateProcess，指定要启动的可执行模块。这个过程不依赖 .docx 对应 Word 这样的文档关联。
某个父进程
↓
调用 CreateProcess，明确指定目标程序路径
↓
Windows 检查并加载目标可执行映像
↓
建立新进程，初始化运行环境
↓
转入程序入口点
对于有效的 Windows EXE，加载器会检查 PE 头、目标架构、节等结构。常见 PE 文件包含 MZ 标记和 PE\0\0 签名，但仅有这些字节不代表文件就是有效或安全的程序。
文件不必以 .exe 结尾，才有可能通过这条路径执行。 一个有效的 EXE 即使被改名为 .tmp 或 .docx，其他程序仍可能明确将其作为可执行模块启动。
以上以文件结构有效、系统架构兼容、权限允许，并且没有被应用控制策略或安全软件阻止为前提；这不是对所有文件都能执行的保证。
案例：把 EXE 改为 TMP 或 DOCX
假设 demo.exe 本来是可正常运行的 Windows 程序，以下只修改名称，不改变文件内容。
| 操作方式 | 改为 demo.tmp | 改为 demo.docx |
|---|---|---|
| 在资源管理器中双击 | 通常提示选择打开方式，或交给已关联的应用 | 通常交给 Word / WPS，随后因文档格式不符而报错 |
其他程序通过 CreateProcess 明确将其作为可执行模块启动 | 仍可能执行原程序 | 仍可能执行原程序 |
改回 .exe 后双击 | 恢复通常的 EXE 启动方式 | 恢复通常的 EXE 启动方式 |
具体双击结果会受本机文件关联和安全策略影响，不能将表格理解为所有 Windows 配置下都完全一致。
同一个 DOCX 后缀，两种结果
以下两个例子中的 demo.docx 都是假设由 EXE 直接改名而来。
场景 A：用户双击
explorer.exe
↓ 按文件关联打开
Word / WPS
↓ 将 demo.docx 作为文档解析
通常报格式错误，demo.docx 中的 EXE 代码没有因此被直接执行
场景 B：其他程序明确创建进程
parent.exe
↓ CreateProcess 指定 demo.docx 为可执行模块
demo.docx 对应的程序进程
↓
执行原 EXE 的代码
决定差异的是调用方式。场景 B 不要求先把文件改回 .exe，也不需要先启动 Word。
反过来，把文档改成 EXE 呢
把真正的 report.docx 改名为 report.exe，也不会把文档转换成程序。若尝试将其作为程序启动，普通 DOCX 不具有有效的 EXE 映像结构，通常会被拒绝或提示无法运行。
因此，改名不会完成“文档和程序之间的格式转换”。
命令行为什么要单独分析
“在命令行中输入路径”不是一种统一的底层操作。不同命令解释器和启动命令可能采用不同规则。
| 发起方式 | 需要关注的机制 |
|---|---|
cmd.exe 中的命令 | 内部命令、路径搜索、PATHEXT、批处理和具体调用形式 |
| PowerShell 中的命令 | 命令解析、脚本或应用识别，以及所用命令的启动方式 |
start、Start-Process 等 | 参数和具体使用场景，可能涉及 Shell 和文件关联 |
| 自定义程序或脚本 | 最终使用的是进程创建接口，还是文件关联打开接口 |
所以不能直接断言“输入 .tmp 路径就一定执行”或“一定不能执行”。排查时应查看完整命令行和实际进程事件，确认最终由谁、以什么方式启动目标。
与 DLL、脚本的区别
即使内容同属 PE 格式，EXE 和 DLL 的加载方式也不同。普通 DLL 不能仅通过改名为 .exe，就变成可独立启动的应用；通常需要宿主程序加载并调用其功能。DLL 加载与导出函数的关系见 组件与工具。
脚本则通常需要解释器。脚本后缀改为 .tmp 后，解释器如果支持明确读取这个文件，仍可能解释其中的代码。它与 Windows 直接加载 EXE 是不同机制。
安全排查中的应用
非 EXE 后缀也可能是运行中的程序
如果 EDR 或进程创建日志显示映像路径为：
C:\Users\Admin\AppData\Local\Temp\payload.tmp
不能因为它以 .tmp 结尾，就认为它只是缓存数据。它可能实际包含有效 PE，并被父进程明确启动。正常安装程序也可能使用临时名称，因此仍需结合来源判断。
调查时应区分三种记录：
- 文件写入事件：只能说明文件被创建或修改，不代表已经执行。
- 文档打开记录或父进程命令行参数：文件可能只是传入的数据。
- 进程创建事件中的映像路径：说明该路径对应的是被启动的程序，需要继续核对真实文件和进程身份。
双扩展名伪装
报告.docx.exe
这个名称最后的扩展名是 .exe。如果资源管理器隐藏已知文件类型的扩展名，用户可能只看到“报告.docx”，再配合文档图标，就容易将程序误认为文档。
它与“EXE 真正改名为 .docx”是两种情况：前者实际仍以 .exe 结尾，后者则需要结合打开方式判断是否执行。
判断依据
| 证据 | 能回答的问题 |
|---|---|
| 完整文件名及扩展名 | 是否存在双扩展名、名称伪装 |
| 文件头和 PE 结构 | 实际是 EXE、DLL、脚本、文档还是其他数据 |
| 文件哈希、签名、来源 | 文件是否与已知软件或样本一致，发布者是否可验证 |
| 父进程、完整命令行、进程创建事件 | 谁启动了它，文件是执行目标还是输入数据 |
| 后续联网、文件操作、持久化和注入行为 | 执行后做了什么，是否符合正常业务 |
改扩展名不会自动使文件无害，也不能作为可靠的隔离方法。静态分析时，可以只读取文件头、计算哈希、解析 PE 和提取字符串；不应通过双击未知文件验证它能否运行。