F3 闪存防伪检测完整指南：一文读懂如何测出 U 盘真实容量

F3 闪存防伪检测完整指南：一文读懂如何测出 U 盘真实容量

【免费下载链接】f3F3 - Fight Flash Fraud项目地址: https://gitcode.com/gh_mirrors/f3/f3

你买了一块 1TB 闪存盘，拷到 200GB 时旧文件开始损坏？问题多半是"扩容"：设备标称的容量远大于真实容量。F3（Fight Flash Fraud，即"打击闪存欺诈"）是一个开源的闪存容量测试工具：它把设备写满再逐扇区校验，让假容量无处遁形。

它解决什么问题：一块 256GB U 盘"只剩 27GB"的故事

前阵子有同事拿着 U 盘来求助。他买了块 256GB 的 USB 3.0 盘做备份，头一周一切正常，拷到 30GB 左右发现怪事：同一个视频拷进去两次，第二次拷完，之前的旧文件消失了。

我起初怀疑驱动问题。他换了台电脑复现，症状一模一样。于是我们做了唯一可靠的事：验证设备的真实容量。

扩容盘的问题不是"慢"，而是"说谎"。小容量芯片通过固件改写，对外谎报 256GB。只要写入量没超过真实容量，它表现得和正品毫无区别——这正是多数人发现时数据已损坏的原因，而且损坏的数据无法恢复。

关键点在于：系统里显示的容量数字，是设备自己报上来的。操作系统没有手段核实。唯一可靠的办法，是沿着真实容量写到底，让设备露出马脚。

核心能力一览：4 个命令与各自适用前提

F3 由 4 个同名前缀的命令组成，分工明确：

1. f3write + f3read（完整读写校验）：把设备写满 1GB 的伪随机测试文件，再逐扇区核对。输出包括真实容量、损坏扇区数、读写速度。适用前提：设备已格式化并挂载到文件系统，不需要 root。
2. f3probe（快速容量探测）：直接操作裸块设备，用算法在几分钟内定位真实容量，适合大容量盘。适用前提：仅 Linux，需要 root 权限，设备须挂在 USB 口上；默认会破坏盘上数据（可加参数保留数据，但更慢）。
3. f3fix（重建分区表）：按真实容量创建一个刚好贴合的分区，让系统从此不再写到"不存在的空间"。适用前提：手上要有 f3probe 输出的"实际最后一个扇区号"。
4. f3brew（块级调试工具）：按块写入、重置设备、再读回比对，主要供开发者研究扩容芯片行为。适用前提：Linux + root，普通用户可以忽略，实现见 src/f3brew.c。

首次上手：从克隆源码到完成第一次测试

第 1 步，克隆并编译。源码是纯 C，Linux 下两条命令搞定：

git clone https://gitcode.com/gh_mirrors/f3/f3 cd f3 make sudo make install

第 2 步，找到设备。插 U 盘前后各运行一次lsblk，对比多出来的那一行，记下类似/dev/sdb的块设备名。注意区分整盘（sdb）和分区（sdb1）：f3probe 要整盘，f3write/f3read 要挂载点。

第 3 步，在挂载点做完整读写校验：

f3write /media/你/TEST f3read /media/你/TEST

注意：不要在存有重要数据的卡上直接跑 f3write。测试文件会占满全部空闲空间，遇到扩容盘时，旧数据可能被设备自己覆盖掉。

第 4 步，或者用 f3probe 快速探测（裸设备，需要 root）：

sudo f3probe --destructive --time-ops /dev/sdb

注意：--destructive表示允许 f3probe 覆盖盘上已有数据，换取探测速度。只在空卡或已备份数据上使用。

编译 f3probe 和 f3fix 还依赖 libudev 与 libparted，缺了就先装（Ubuntu 下为libudev-dev、libparted-dev），再用make extra && sudo make install-extra构建这两个额外命令。

工作原理：用"编号书籍"揪出假闪存

核心思路一句话：写入可以"自证"的数据，再读回来对答案。

打个比方。仓库管理员（闪存主控）声称仓库有 1 万个货位。你不信，就让他在每个货位放一本书，书的封面上写"第 N 本书只属于第 N 个货位"。之后你抽查：每本书的编号都对得上，仓库是真的；从"第 3000 位"抽出来的书封面写着"第 200 位"，说明第 3000 位根本不存在——仓库其实只有 2000 个货位，写满之后它悄悄把书塞回前面的空位。这个"绕回开头"的行为，就是扩容盘的典型特征，叫回绕（wraparound）。

对应到 F3 的实现：

• 扇区（512 字节）是闪存的读写最小单位，相当于仓库的一个货位。f3read 能算出每个扇区"本来该是什么内容"，实际读回来对不上，就计入损坏、轻微改动或覆盖三类。
• 测试数据是伪随机的：看起来像乱码，实则由固定算法生成。写和读两端用同一套算法，所以 f3read 不必另存一份底稿就能重新算出答案——这就是 1TB 设备也能被完整填测的原因。
• f3probe 更聪明，它不填满全盘，而是基于对扩容芯片行为模型（容量边界 + 内部缓存大小）的判断，只写"最有用"的那部分数据。就像测井深：不必灌满整口井，一根带刻度的绳子就够。对一块 15GB 的扩容盘，它有时只写约 0.01% 的数据量，就能给出精确的真实容量和缓存大小，算法在 src/libprobe.c。

场景实战：把一块 16GB U 盘修成可用的 7.86GB

现象。一块 16GB U 盘，系统显示 15.33GB。拷完一批文件后，旧文件打不开，提示格式无法识别。

排查。先用lsblk确认它是/dev/sdb，然后以 root 运行f3probe --destructive --time-ops /dev/sdb。1 分 13 秒后，结果出来：设备是假盘（limbo 型，最常见的扩容类型），可用容量只有 7.86GB，标称 15.33GB。整个过程中它只写了 2158 个块，约 1MB 数据，就摸到了底。

结果。按 f3probe 给出的建议修复并重新格式化：

sudo f3fix --last-sec=16477878 /dev/sdb sudo mkfs.vfat /dev/sdb1

注意：f3fix 会重写分区表，务必二次确认设备号没拿错；如果提示内核没有加载新分区表，把 U 盘拔下再插上即可。

之后对新分区再跑一遍 f3write/f3read：8 个测试文件全部通过，Data OK 7.84GB，损坏为 0。这块 U 盘不再是 16GB，但从那天起它不会再悄悄毁掉任何数据。

避坑清单：5 个高频错误与正确做法

生态与延伸：GUI、容器与社区入口

• 🧰图形界面：F3-Gui（Linux，Flatpak 封装，含 4 个命令并支持修复后自动格式化）、F3 QT（Linux）、F3XSwift（macOS）、Fake-USB-Tester（Linux，Python + Qt5）。不想碰命令行，从这几个入口进。
• 容器化：仓库自带 Dockerfile，执行make docker可构建本地镜像；社区也有现成镜像，用--device参数把 U 盘透传进容器即可测试。
• 格式兼容：3.0 版本起，f3write 生成的测试文件与 Windows 端知名工具 H2testw 使用同一种.h2w格式，两端可以互相校验对方的产物。
• 配套脚本：仓库scripts/下有两个即用脚本——log-f3wr一键连跑 f3write + f3read 并把输出写入日志，f3write.h2w会把测试文件尺寸调整成 H2testw 兼容值。
• 姐妹工具：卡容量为真但偶发损坏（"flaky flash"）时，社区项目 Flakyflash 可以在 FAT 文件系统上定位坏簇并标记，争取延长使用，但建议尽早更换。
• 参与贡献：项目由社区力量共同维护，贡献指南见 doc/contribute.rst。里面列了明确的参与方式：提 PR、写使用博客、甚至捐赠你手中的扩容盘作为测试样本。

你的下一步：运行lsblk找到那块 U 盘，克隆仓库、编译，10 分钟内跑完第一次扩容盘探测。如果拿到 Data LOST 的报告，别继续用它——保存 f3probe 的输出当证据，找卖家要回你的钱。

【免费下载链接】f3F3 - Fight Flash Fraud项目地址: https://gitcode.com/gh_mirrors/f3/f3