Excel时间戳取证分析
- 2026-11-03 08:05:23
限时免费 | |
≥3年粉丝 | |
星球成员 |
现在只对常读和星标公众号才展示大图推送，建议大家把“潇湘信安”设为星标，否则可能看不到了！
U盘里的Excel文件：时间戳真的能当证据吗？
一个Excel文件里藏着四层日期，彼此可能互相矛盾。文件系统说一套，元数据说一套，ZIP容器说一套，电脑里的痕迹又说另一套。读懂它们，才能看清真相。
一、引子：你看到的"修改日期"可能在骗你
想象一个场景：劳动仲裁庭上，一方拿出一个U盘，里面有一份Excel表格，记录着所谓的"原始考勤数据"。文件属性里赫然写着"修改日期：2025年3月15日"。一方坚称这是当时的真实记录，另一方却说这是后来伪造的。
问题来了：这个日期，到底能证明什么？
大多数人打开资源管理器，看到"修改日期"那一行，就下意识地把它当成事实。但在数字取证专家眼里，这一行字背后是好几套独立运转的时钟，各有时区、各有盲区、各有漏洞。把它们混为一谈的人，一定会看错时间；了解它们的人，才知道该向鉴定人问什么问题。
本文带你一层层剥开U盘上Excel文件的时间秘密——从文件系统到内部元数据，从ZIP容器到Windows痕迹，告诉你每一层时间戳从哪里来、靠不靠谱、以及在法庭上有多大分量。
U盘里的Excel文件上，同时存在四层日期
二、Excel文件的四层时间体系
一个 .xlsx 文件至少有 四层日期，分别住在不同的地方，由不同的程序写入，遵循不同的时区规则。
docProps/core.xml 和 app.xml | ||||
关键洞察： 只有文件系统的日期会在每次复制时改变。元数据跟着文件走（所以它记录的是文档的历史，而非这一份拷贝的历史），而电脑上的痕迹根本不在U盘里。当四层时间讲述同一个故事时，重建的时间线才站得住脚；当它们互相矛盾时，矛盾本身就是重要线索。
三、Excel元数据藏在哪里？
.xlsx 文件本质上是一个 ZIP压缩包，里面装着一堆XML文件。元数据就藏在其中两个文件里：
docProps/core.xml— 作者、上次修改者、创建日期、修改日期docProps/app.xml— 使用的软件及版本号
想看这些信息，不需要用Excel打开文件——直接解压一份副本就能看到。这一点在取证中至关重要：打开Excel可能会修改元数据，污染证据。
core.xml 中的日期遵循 W3CDTF 标准（ISO 8601 的一种变体），末尾带一个 Z，表示 UTC时间。下面是一个示例（内容虚构）：
<?xml version="1.0" encoding="UTF-8" standalone="yes"?><cp:coreProperties><dc:creator>用户A</dc:creator><cp:lastModifiedBy>用户B</cp:lastModifiedBy><dcterms:created xsi:type="dcterms:W3CDTF">2025-03-04T09:12:00Z</dcterms:created><dcterms:modified xsi:type="dcterms:W3CDTF">2025-11-18T16:40:00Z</dcterms:modified></cp:coreProperties>元数据是"自述"，不是"证人"
这里有个重要的认知问题：元数据是程序写的，任何人都可以改写。 取证维基（forensics.wiki）明确提醒，姓名和日期都可能被篡改，必须与其他来源交叉验证。
一个很有说服力的例子是 Python 的 openpyxl 库。用脚本生成的Excel文件，作者字段会显示为 "openpyxl"，创建和修改日期就是脚本运行的时刻。当然，这四个字段都可以在保存前被覆盖或清空。
这带来两个实际推论：
作者显示 "openpyxl" 只能说明文件怎么来的，不能说明是谁要做的 core.xml缺失或内容异常本身也是信息——说明文件可能不是用Excel生成的
并非所有表格都出自Excel。LibreOffice会在程序字段里写入自己的名字。每一次"另存为"都可能改变文件对自身的描述——就像有些隐形水印，简单保存一下就消失了。
四、U盘的时间：文件系统的时钟游戏
不同格式，不同时钟
微软官方文档明确了文件时间的规则：
NTFS：日期以 UTC 保存。所以一个在太平洋时间下午3点保存的文件，在纽约看就是下午6点，时间是一致的。 FAT：日期以 本地时间 保存。同一个文件，在太平洋时间下午3点写的，拿到纽约看还是显示下午3点，但实际上纽约已经是下午6点了——文件时间"慢了"三小时。
精度也不一样：FAT格式下，创建时间精度是10毫秒，写入时间是2秒，访问时间只有日期（精确到天）。NTFS的上次访问时间可能延迟最多一小时才更新。
U盘通常格式化为 FAT32 或 exFAT，很少用NTFS。exFAT虽然解决了FAT的部分限制，但时间存储方式类似——DOS风格（秒数以2秒为单位）加一个10毫秒字段，还附带一个时区偏移字节。挪威科技大学（NTNU）的一项名为《"It's about time"》的研究指出，不同的exFAT实现和取证工具对这些日期的处理方式并不一致，鉴定人不能想当然地认为驱动读取的结果一定正确。
微软老员工Raymond Chen在他的博客 The Old New Thing 里举过一个软盘的例子：从NTFS复制到FAT，时间可能偏移2秒；把磁盘拿到另一个时区，文件时间看起来会"倒退"一小时——因为存的是本地时间。
夏令时 更是坑中之坑。微软文档提到，对于FAT文件，Windows的两个函数可能返回相差一小时的同一日期。一个读的是缓存值（夏令时切换时不更新，重启才修正），另一个用当前设置重新转换本地时间（即使文件是在标准时保存的）。对鉴定人来说，这意味着必须记录用什么工具、什么版本、在什么时区的电脑上读取的——因为显示的时间取决于"谁在看"。
为什么创建日期比修改日期还晚？
这是数字取证中的一个经典现象：复制文件时，"创建日期"变成了复制的时间，而"修改日期"通常保留原值。 结果就是创建日期晚于修改日期——这是文件被复制过的重要线索。
不过也有局限性：有些复制工具会保留创建日期，有些不会。而且这些属性用户无需特殊工具就能改。取证论坛 Forensic Focus 上有专家指出另一个辅助信号——修改日期的秒数总是偶数，这是FAT文件的典型特征，暗示文件可能来自FAT格式的存储介质。
这些都是"线索"，不是"铁证"。真正的工作始于：两个独立的线索指向同一个方向。
一个重建示例
下面的数字是虚构的，但逻辑是真实鉴定的逻辑——把每个原始值旁边标注上罗马时间的解读，核对时区，看故事是否自洽。
这个案例里，一切都对得上：表格最后一次保存是2025年11月18日，直到2026年1月7日才被拷到这个U盘上，而U盘正是那一分钟刚插上这台电脑的。
但关于"谁输入了这些数据"，这张表格什么也没说。 它能告诉你文件的故事，这已经大大缩小了可能性的范围。
五、ZIP容器里的"1980年"暗号
ZIP包里的每个文件条目都有自己的日期。Office软件的写法有一个明显特征。
安全分析师 Didier Stevens（SANS互联网风暴中心的研究员）发现：Office应用在ZIP记录中写入的日期是固定的 1980-01-01 00:00:00，而普通的ZIP工具会写入真实时间。他分析的文件里，有些条目是1980年，有些是2021年——由此推断，这个Word文档后来被其他工具重新处理过。
Excel似乎也遵循同样的规律。Forensic Focus 上有人测试了Excel 2010的模板文件，发现所有条目的日期都是1980-01-01，但有一个带密码保护的工作簿表现不同。
为什么是1980？因为这是DOS时代ZIP格式能表示的最早日期。
怎么用这个线索： 如果ZIP内所有日期都是清一色的1980年，说明文件可能直接出自Office且从未被其他工具动过；如果日期混杂，说明有人重新打包过。
但这个信号的价值是相对的——只能用来对比判断。需要用同版本Office、同类型文档生成的参考文件做对照，因为其他程序也可以模仿这个"1980年"模式。它适合用来提出问题，不足以单独结案。
六、电脑上的痕迹：U盘不会说的秘密
U盘只知道自己里面有什么。至于它有没有插过某台电脑，Windows在好几个地方留下了记录。取证软件厂商 Magnet Forensics 列出了主要的痕迹来源：
USBSTOR 注册表项 — 保存设备ID、首次和最后一次插入日期（FILETIME格式，UTC） MountedDevices — 将序列号与驱动器盘符关联 MountPoints2 — 在每个用户的 NTUSER.DAT 中，记录该用户见过的设备 setupapi.dev.log — 首次连接时的驱动安装日志（本地时间） 事件日志 — DriverFrameworks-UserMode/Operational 记录插拔事件
这些痕迹很宝贵，但读的时候要注意：
插过≠传过数据 — 连接记录不能证明数据传输发生过 ** attribution是间接的** — MountPoints2显示的是GUID，需要与所有用户的注册表配置单元交叉比对 时区各不相同 — 注册表用UTC，日志用本地时间，不转换就会排错时间线 盘符是最后分配的 — 不代表之前的分配情况 路径随Windows版本变化
Windows保存的东西远比用户以为的多——Windows 11的缩略图缓存、ChatGPT在Windows和iOS上留下的痕迹，都是例子。它们提醒我们：当U盘本身不够用时，知道去哪里找很重要。
七、改时间戳有多容易？
对单层时间来说，非常容易。
微软自己的文档里就有 SetFileTime 函数，可以修改文件的三个日期而不碰内容。任何程序都能调用它。
正因为如此，NTFS取证研究人员会对比两套时间戳：
$STANDARD_INFORMATION— 普通系统调用就能改$FILE_NAME— 通常需要内核级访问才能改
两套时间不一致，比一致更有说服力。开源应急响应工具 Velociraptor 的 Windows.NTFS.Timestomp 模块，就是专门找那些"创建日期在 $STANDARD_INFORMATION 里反而更早"或者"纳秒精度过于完美"的可疑文件。
当然，还要和NTFS的变更日志（USN Journal）、$LogFile 以及程序执行痕迹（ShimCache、Amcache）交叉验证。
八、法庭上，Excel文件值多少分量？
这个问题没有标准答案，但有几个原则：
单一时间戳几乎不构成证据 — 不管是文件系统的修改日期，还是元数据里的作者名，单独拿出来都太容易被质疑了。
多层印证才有力量 — 当文件系统时间、内部元数据、ZIP结构、Windows注册表痕迹都指向同一个故事时，可信度才会显著提升。
保管链比时间本身更重要 — 谁拿到的U盘、怎么做的镜像、有没有用写保护器（write-blocker）、哈希值是多少——这些程序问题决定了证据能不能被采纳。
它能排除，难以确认 — 时间戳往往更擅长证明"某个说法不对"（比如"这个文件3月就有了"但元数据显示11月才创建），而不是百分之百确认"就是这个人在那天做的"。
内容分析和元数据分析要结合 — 公式追踪、单元格编辑痕迹、修订记录（如果有），这些都能和时间戳互相补充。
九、怎么读才不污染证据？
拿到作为证据的Excel文件，第一件事绝对不是双击打开。正确的做法是：
先做镜像 — 用写保护器连接设备，制作完整的位级镜像，计算哈希值 在副本上工作 — 所有分析都在镜像副本上进行，原始介质封存 先看文件系统时间 — 用取证工具读取目录项，记录原始时间戳 解压看元数据 — 将文件复制出来一份，用解压工具打开（不是用Excel），读取 core.xml和app.xml分析ZIP结构 — 检查ZIP内部各条目的时间戳 最后才考虑打开文件 — 如果必须用Excel打开，确保在隔离环境中，并且记录操作前后的文件变化
每一步都要记录操作时间、操作人员、使用的工具和版本号。取证的黄金法则是：如果你不能证明你没改它，你可能就已经改了它。
十、五个常见的读取错误
把"修改日期"当事实 — 这是最常见的错误。修改日期只是文件系统的一个属性，可以被复制、被移动、被篡改。
忽略时区转换 — FAT用本地时间，NTFS用UTC，元数据用UTC，日志用本地时间……不统一到同一个基准，时间线一定是乱的。
以为"作者"就是实际操作的人 — 作者字段是Office里设置的名字，可能跟Windows账号对不上，也可能根本就是假的。
创建日期比修改日期晚=伪造 — 不一定是伪造，更可能是复制过。这个现象本身很正常，不能单独作为篡改证据。
用Excel打开"检查"元数据 — 打开的那一刻，元数据可能已经被改了（比如"上次修改者"、"修改日期"）。你以为是在检验证据，其实已经破坏了证据。
十一、关键要点（Key Takeaways）
📌 Excel文件有四层时间：文件系统层、OOXML元数据层、ZIP容器层、电脑痕迹层，各说各话 📌 FAT格式存本地时间，NTFS存UTC — 跨时区看FAT文件，时间会"漂移" 📌 元数据是自述，不是证词 — 可以改、可以伪造，必须交叉验证 📌 创建日期晚于修改日期 ≠ 篡改 — 更可能是文件被复制过 📌 ZIP里的1980年 — Office的典型特征，日期混杂可能意味着被重新打包 📌 单一时间戳证据力弱，多层印证才有说服力 📌 取证先做镜像，永远不在原件上操作 📌 保管链和技术分析同样重要 — 程序瑕疵可以让最铁的证据失效
十二、写在最后
U盘里的Excel文件，看起来就是一个简单的表格，实则是层层叠叠的时间迷宫。每一层时间都有它的来处、它的偏见、它的盲区。
数字取证的核心不是"找到那个正确的时间"，而是把不同来源的时间放在一起比对，看哪些对得上、哪些对不上，然后追问"为什么"。对得上的地方，给你信心；对不上的地方，指引方向。
下次再有人拿着一个U盘对你说"看，修改日期在这儿呢"，你可以微笑着问一句：
"你说的是哪一层的日期？"
关注我们
还在等什么？赶紧点击下方名片开始学习吧 
知 识 星 球
限时免费 | |
≥3年粉丝 | |
星球成员 |
推 荐 阅 读
