# 【AI 工作流手记 #2】把 .exe 改名成 .jpg 也骗不过它：用 Python 读文件头识别真实类型，9665 个文件实测 + 5 个坑

## 起因

给一个自动化流程加一道「上传校验」：别人递过来的文件，说是图片就得是图片，说是压缩包就得是压缩包。第一版实现是查扩展名——两行代码，两天就被打脸：把一个可执行文件直接改名成 `.jpg`，校验一路绿灯。

扩展名只是文件系统里的一串元数据，改它比改文件名还容易。真正改不掉的是**文件开头那几个字节**：它是格式规范的一部分，读图的程序认它，不认你的扩展名。

于是重写：只读文件头，判断真实类型。

## 关键发现：文件头确实能自证，但它只覆盖一半

先用"造样本"的办法把结论摸清楚——每种格式用标准库手搓一个最小的真文件，再故意改成别的扩展名：

| 真身 | 故意写成的扩展名 | 读头判定 | 结果 |
|---|---|---|---|
| PNG | `.jpg` | png | 识破 |
| JPEG | `.png` | jpeg | 识破 |
| PDF | `.docx` | pdf | 识破 |
| GZIP | `.zip` | gzip | 识破 |
| SQLite | `.db.bak` | sqlite | 识破 |
| ZIP | `.docx` | zip | 识破 |
| 纯文本 | `.png` | 无签名 | 判不出 |

有签名的 10 个样本**全部识破**，一个没漏。但同一套方法拿去扫 9665 个真实文件（系统目录 + 公共组件目录，只读、只做聚合统计），局面立刻变了：

- 判得出真身：**4647 个（48.1%）**
- 判不出（开头没有任何已知签名）：**5018 个**——其中 **4694 个**能正常按 UTF-8 解码，也就是说**近一半文件是纯文本，天生没有魔数**

结论有点反直觉：**文件头识别是个「半场工具」**。它能一眼拆穿伪装成二进制的文件，但对 `.txt` / `.json` / `.py` / `.csv` 这类文本文件完全无能为力——它们本来就没有签名。想覆盖这一半，得靠后置的启发式（能不能按文本编码解出来、控制字符占比），而不是堆更大的签名表。

## 实现：一张表 + 一个函数

核心只有两样东西。表放「签名 → 类型」，函数从头 4KB 里找第一个匹配：

```python
SIGS = [
    ("png",    b"\x89PNG\r\n\x1a\n"),
    ("jpeg",   b"\xff\xd8\xff"),
    ("pdf",    b"%PDF"),
    ("gzip",   b"\x1f\x8b"),
    ("7z",     b"7z\xbc\xaf\x27\x1c"),
    ("pe",     b"MZ"),
    ("ole2",   b"\xd0\xcf\x11\xe0\xa1\xb1\x1a\xe1"),
    ("sqlite", b"SQLite format 3\x00"),
    ("zip",    b"PK\x03\x04"),
]


def sniff(data: bytes):
    """只匹配「偏移 0」的签名；带偏移的格式另说，见下文。"""
    for name, sig in SIGS:
        if data[:len(sig)] == sig:
            return name
    return None
```

注意 `pe` 的签名只有 `MZ` 两个字节——它管的是「这是个 PE 可执行文件」，而不是「这是个 `.exe`」。同一种真身可以对应一堆扩展名：`.exe / .dll / .sys / .ocx / .cpl`，甚至 `.efi`。**这就是后面第一个坑的根源。**

偏移不为 0 的格式要单独处理，别硬塞进表里：

```python
def sniff(data: bytes):
    ...
    if data[4:8] == b"ftyp":        # MP4 / MOV：类型标识在偏移 4
        return "mp4/" + data[8:12].decode("latin-1", "replace")
    if data[:4] == b"RIFF":         # WAV / WEBP / AVI：靠第 8 字节再区分
        return "riff/" + data[8:12].decode("latin-1", "replace")
    if data[257:262] == b"ustar":   # tar：签名在偏移 257
        return "tar"
    return None
```

## 分层：魔数分不开的那一类，要往里再看一层

`.docx / .xlsx / .pptx` 的魔数跟 `.zip` **一模一样**，都是 `PK\x03\x04`——Office 文档本来就是 zip。实测把两个文件丢进去：

| 文件 | 魔数判定 | 内部条目（`zipfile.namelist`） |
|---|---|---|
| 普通 zip | zip | `['a.txt']` |
| docx | zip | `['[Content_Types].xml', 'word/document.xml']` |

所以判断必须分两层：先认容器（是不是 zip），再拆开看目录结构（有没有 `[Content_Types].xml`、`word/`、`xl/`）。同理 `tar.gz` 的第一层是 gzip，解开一层才会露出偏移 257 的 `ustar`：

```python
import io
import zipfile


def classify_zip(data: bytes):
    """第一层已确定是 zip，再靠内部条目区分 Office 家族。"""
    names = zipfile.ZipFile(io.BytesIO(data)).namelist()
    if "[Content_Types].xml" in names:
        if any(n.startswith("word/") for n in names):
            return "docx"
        if any(n.startswith("xl/") for n in names):
            return "xlsx"
        if any(n.startswith("ppt/") for n in names):
            return "pptx"
    return "zip"
```

## 实测：五个坑

下面每一条都是我真实跑出来的，不是"据说会这样"：

| 坑 | 现象（实测） | 解法 |
|---|---|---|
| 用一个扩展名白名单判"伪装文件" | 首版校验器报出 **143 个"扩展名与内容不符"**，逐个人工看下来**全是误报**：`.ax / .tlb / .acm / .com / .ime / .tsp / .drv / .efi` 这些名字本身就是 PE 二进制 | 一个真身对应一个**扩展名族**，不是单一扩展名；误报率取决于表的完备性 |
| 只读 4KB 头 | ISO9660 的签名在偏移 **0x8001**（第 32769 字节），读 4KB、甚至 32KB 都判不出，一律返回"无签名" | 要么把读取长度提到 64KB，要么对这类格式单独 seek |
| 以为"文件头能判所有文件" | 9665 个真实文件里 **5018 个没有签名**，其中 4694 个是纯文本 | 无签名 ≠ 损坏；文本类走编码启发式，不要报错 |
| 全量读文件再判类型 | 120 个文件共 240 MB：全读 **240 ms**，只读 64KB 头 **16 ms**，差 **15 倍**（搬运 7.5 MB vs 240 MB） | 只读头；按这个方式扫 4531 个文件只要 **667 ms** |
| 相信"系统文件都是规规矩矩的" | 两个 `.dll`（一个 0 字节、一个 8 字节）扩展名承诺是 PE，内容里根本没有 PE 头——它们是**占位 DLL**，真身藏在系统资源里 | 空签名单独报"异常待查"，而不是直接判"损坏"或"恶意" |

补一条不在表里的：**魔数只能证伪，不能证实**。头部对上，只能说明它"自称是这种格式"——一个手工拼出来的文件完全可以自己写一个合法的 PNG 头。要做内容级校验，得继续往后走（校验和、结构长度、解码试读），那已经不是"读 4KB"能解决的事了。

## 效果

- **识别率**：13 个故意改错扩展名的样本，10 个有签名的全部识破；3 个纯文本如实返回"无签名"，没有被误判成别的格式；
- **成本**：只读 64KB 头，4531 个文件 **667 ms**（每文件 0.147 ms）；相比全量读，数据搬运量降到约 1/32；
- **误报**：把"真身 → 扩展名族"写全（PE 一族 8 种、zip 一族 11 种）之后，143 个误报归零；
- **可复现**：上面每个数字都有确定的输入——手搓的最小样本文件 + 系统目录只读扫描，跑一次就能复核。

## 你可以怎么用

1. **上传校验的第一道闸门就用它**：扩展名 + 文件头双检，改扩展名骗不过去，成本只有每文件 0.15 ms。
2. **别指望它覆盖所有文件**：真实语料里近一半根本没有魔数（文本、CSV、日志、脚本）。设计上要把"判不出"当成正常输出，交给第二条路（编码探测、结构解析）。
3. **把一个真身映射成"扩展名族"，而不是单一扩展名**：这是误报率的分水岭。表里没有 `.ax`、`.efi`，就会把一堆合法文件报成伪装。
4. **带偏移的签名单独处理**：`ftyp` 在偏移 4、`ustar` 在 257、ISO9660 在 32769——把它们硬塞进"偏移 0"的表，只会得到一堆"判不出"。
5. **记住它的边界**：魔数能证伪、不能证实。它的价值是快速筛掉明显不对劲的输入，而不是替代安全检测。

---

> **关于作者**：10 年跨境电商老兵，拥抱 AI 时代。这里记录我踩过的坑和跑通的方法。

---

给一个自动化流程加一道「上传校验」：别人递过来的文件，说是图片就得是图片，说是压缩包就得是压缩包。第一版实现是查扩展名——两行代码，两天就被打脸：把一个可执行文件直接改名成 .jpg，校验一路绿灯。

【AI 工作流手记 #2】把 .exe 改名成 .jpg 也骗不过它：用 Python 读文件头识别真实类型，9665 个文件实测 + 5 个坑

只读前 64KB 就能判出文件真实类型。13 个改错扩展名的样本全部识破，但 9665 个真实文件里只有 48% 带可识别签名，143 个"伪装文件"其实全是误报。

编程语言

安全

开发工具

AI工作流手记：用Python文件头识别真实文件类型，9665个文件实测。魔数签名能拆穿改扩展名的伪装文件，但近半数纯文本无签名需编码启发式补足。PE、ZIP等格式需映射扩展名族，带偏移签名单独处理。只读64KB头667ms扫4531文件，上传校验首道闸门首选，误报率归零。

文件系统

代码解释

容器

SQLite

Python

JSON

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

【AI 工作流手记 #2】把 .exe 改名成 .jpg 也骗不过它：用 Python 读文件头识别真实类型，9665 个文件实测 + 5 个坑-腾讯云开发者社区-腾讯云

【AI 工作流手记 #2】把 .exe 改名成 .jpg 也骗不过它：用 Python 读文件头识别真实类型，9665 个文件实测 + 5 个坑

【AI 工作流手记 #2】把 .exe 改名成 .jpg 也骗不过它：用 Python 读文件头识别真实类型，9665 个文件实测 + 5 个坑

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐