帮朋友做了一次劳动仲裁取证:一场和已删聊天记录的赛跑

郑重说明:本文所有人物均已匿名化处理,细节做过模糊化改写,不含任何可定位到具体个人或企业的信息。文中技术手段仅针对本人拥有或经当事人授权的设备与账号数据;内容仅为技术记录与经验分享,不构成法律建议,重大决策请咨询执业律师。

事情的开头

朋友找我的时候,状态不太好。

公司在准备和她”结算”:一年多前的旧账被重新翻出来,已经口头处理过的事情被重新定性,各种小问题被集中打包,目标是按”严重违纪 + 重大损失”走辞退或索赔流程。而她翻开聊天记录想找凭证时发现——今年 5 月之前的全部工作聊天记录,没了。公司方面的说法是不存在这些记录。

她问我:还能找回来吗?

我给她的第一句话是:**先别急着动手,我们先想清楚这件事的技术结构和法律结构,再决定每一步。**事实证明,这个顺序救了整件事。

先立规矩:技术线索 ≠ 法律证据

动手前,我们先达成了一个共识,这也贯穿了全程:

技术解密出来的东西,只作内部线索,用来指导”去哪里找、找什么”
正式证据链走的是另一条路:录屏 / 截图 → 可信时间戳 / 公证 → 必要时申请仲裁委调取公司后台
只碰自己拥有或经当事人授权的设备和数据,不做任何越界的事

想明白这个分工,后面所有技术动作才有边界感。

另外我们还梳理了几个法律支点(具体条文请以律师意见为准):劳动争议中用人单位对辞退决定负举证责任;对一年多前的旧账集中追责,超过合理期限;“一事不再罚”原则;以及——公司声称记录不存在,那么按证据规则,持有证据一方无正当理由拒不提供的,可以推定对方的主张成立。换句话说,删记录这件事本身,可能对删除者不利。

第一步:镜像,镜像,还是镜像

任何取证的第一铁律:先做只读全量镜像,再谈别的。所有分析都在镜像上做,原始数据永远不动。

企业微信的本地数据是 wxSQLite3 加密数据库,连带 -wal 和 -shm 文件一起,散落在好几个目录。我们对两个数据目录做了全量镜像,共 80 多个数据库文件,逐一计算 SHA-256 并生成清单——这份清单后来多次派上用场,用来证明”数据自固定以来没有被篡改”。

# 思路示例:文件级镜像 + 哈希清单
robocopy "%AppData%\Tencent\WXWork" "D:\mirror\WXWork" /E /COPY:DAT /DCOPY:T
Get-FileHash -Algorithm SHA256 (Get-ChildItem -Recurse -File).FullName

一个当时差点踩的坑:SQLite 的 WAL 文件里往往存着尚未合并的最新数据,漏拷 -wal/-shm,解出来可能就是缺了几天的残本。镜像目录结构和原目录必须严格一致。

第二步:密钥提取与解密——一次彻底的失败(也有价值)

企业微信本地库的解密密钥,公开已知可以从登录态进程的内存里提取。趁账号还登录着,我们跑了密钥扫描,也试了 Windows 凭据管理器(DPAPI)的路线。

结果是:全量扫描零命中。结合数据窗口判断,密钥大概率在账号某次重新登录时已被覆写。这台机器上的聊天文字,找不回来了。

把失败写出来,是因为它教了两件事:

时效性压倒一切。密钥、登录态、内存残留,都是”过期作废”的易逝证据。如果一开始就明白这点,顺序还会再提前
失败结论也是结论。“本机文字记录不可恢复”这个判断,让后面的精力全部转向了正确的战场,没有在死路上耗着

第三步:连 pagefile 都不放过的偏执

Swap 文件(pagefile.sys)里可能残留内存中被覆写前的密钥片段。但它被内核独占锁着,常规复制只会得到”正在使用”的错误。

解法是绕过文件系统,直接原始卷读取 NTFS 卷,按扇区把 13.8GB 的 pagefile 原样抠出来,再在镜像里做字符串扫描。这台机器上最终没有找到命中,但同机的明文缓存给了惊喜:聊天图片缓存、部分预览数据本来就是明文存储的——380 多 MB 文件、1600 多张图片,不需要任何密钥就能直接查看。一份 CSV 索引清单列出了每张图的时间和所属会话,里面有好几张关键的聊天截图。

教训:很多人以为”加密了”就是”没了”。实际上现代应用是加密数据库 + 明文缓存的混合体,缓存的取证价值经常被严重低估。

第四步:换战场——公司删不掉的地方

本机路线走到头,我们把战场换到了删除者够不着的地方。这一步的优先级判断,比任何工具都重要:

朋友自己的手机——她没被清过设备,5 月之后的记录还完整躺在里面,是全案最珍贵的幸存副本。处理方式不是导出,而是逐屏录屏 + 可信时间戳固化
朋友自己的另一台电脑——登录过同一账号的设备,数据窗口能补上本机缺失的时间段
第三方记录——银行流水、个税 APP、社保记录,这些在服务器上,公司删不到
工作成果——带时间戳的文档、邮件、代码提交,每一份都是”事情发生过”的旁证

录音的话术也提前设计了:不诱导、不捏造,只引导对方确认”对话存在过”这个事实。后来的录音里,老板亲口说出了”之前的记录都没有了”——这句话在法律上的意义,懂的都懂。

第五步:2.6 小时录音的工程化处理

朋友陆续传来 16 段手机录音,共约 2.6 小时。拿到手第一件事还是老规矩:全量 SHA-256 清单。然后发现一个坑——微信传输会重写文件的创建时间,导致文件系统时间不可信,“这段录音是什么时候录的”必须依赖手机原件证明。

转写用的是 faster-whisper(本地推理,数据不出机器):

from faster_whisper import WhisperModel
model = WhisperModel("large-v3", device="cuda")
segments, _ = model.transcribe("audio.m4a", vad_filter=True)
for seg in segments:
    print(f"[{seg.start:.1f} -> {seg.end:.1f}] {seg.text}")

核心录音用更大规模的模型精转了一遍。转写文本交叉比对后,拼出了完整的实况:口头辞退、拒绝出具书面通知、“损失全部记在你头上”的索赔表态,以及老板那句自认删除记录的关键陈述。所有”谁在什么场合说了什么”,都有了带时间戳的文字底稿。

把它做成”工具包”

过程里我意识到,这些操作对非技术者是门槛。所以最后一晚,我把整个流程封装成了一个 U 盘三步包:

一键提取:自动完成镜像 + 密钥扫描 + 明文缓存索引
删除痕迹采集:USN 日志等文件系统层面的痕迹
操作说明:什么时候该做什么、什么绝对不能做

工具自有其价值,但真正可复用的是操作纪律:原始数据只读、每步留哈希、易逝证据优先、失败也要记录在案。

复盘:这次经历教会我的

删除不等于消失。SQLite 空闲页、WAL、缓存、swap、其他设备副本、服务器侧记录……数据的生命力比想象中顽强,但也比想象中易逝——两边同时成立,所以才要快
顺序就是一切。镜像 → 密钥 → 分析,颠倒任何一步都可能污染证据
技术和法律必须各管一半。技术回答”能不能找到”,法律回答”找到了怎么用”。只有技术,是工程师的自我感动
对正在经历类似事情的人:第一时间保全自己的设备数据,别删任何东西,别抱着侥幸清理聊天记录;拿不准的,先咨询律师再动手

这场赛跑还没有终点,仲裁还在进行。但至少现在,朋友手里攥着的,不再是一句”记录都没了”就能抹掉的历史。

——写给每一个认真工作、也认真留下痕迹的人。