简介：面向需要理解易赛通数据泄露防护客户端加密机制的技术人员，这份docx文档从程序结构与驱动层Hook方式切入，重点梳理应用层透明加解密条件下的文件恢复思路。内容围绕主进程模块、辅助守护进程与Filelock.sys驱动的关系展开，分析进程名列表和扩展名列表的匹配规律，并给出借助进程名与扩展名切换实现解密的流程框架，可作为终端数据防护研究、同类问题排查与方案验证的参考，也可为安全从业者评估终端加密边界提供线索。资源包仅含1个docx，约29KB，篇幅精炼，便于快速通读并按主题定位关键概念。目前已有2082人学习，说明该方向在终端加密与文件恢复场景中关注度较高；读者可从中获得机制拆解、判断逻辑与验证路径，减少在零散资料中反复检索的成本。

1. 文件被数据泄露防护客户端加密后：先别急着找解密算法

一个做财务系统的朋友找我，说公司电脑统一装了数据泄露防护客户端，本机上 .xlsx、.docx 打开一切正常，可文件一旦拷到没装客户端的机器上，要么满屏乱码，要么直接提示文件损坏。他第一反应是逆向加密算法、把密钥挖出来，折腾了一个多星期，连密钥存在哪都没摸到。后来换了个方向，一个进程名就把事办了。这篇讲的就是这条路：客户端的三层结构各自负责什么、加密判定到底看哪几个变量、“进程名 × 扩展名”那张二维表怎么测出来、四步复现怎么落地，以及五个几乎人人都会翻车的地方。做安全评估的可以照着复现，做运维和防守的顺着看这套模型漏在哪。

2. 拆开客户端看信任边界：三个模块谁在替你做加解密

在动手之前先花半天把客户端的模块分工摸清楚，比直接上调试器划算得多。这类数据泄露防护客户端基本是同一个套路：一个用户态主程序负责界面和策略，一个守护进程负责让主程序死不掉，一个内核态文件过滤驱动负责真正的加解密。三者的权限和职责差别很大，搞错重点就会一直在外围打转。

判断“哪一层才是关键路径”有个很朴素的办法：把用户态的东西一个一个干掉，看加密行为还在不在。如果主程序和守护进程都结束了，文件写出去照样是密文，那说明策略和密钥路径已经下沉到内核，用户态只是配置面板。这一步判断直接决定了后面所有工作该往哪个方向使劲。

2.1 用户态主程序：它管的是名单，不是数据

主程序负责图形界面、账号登录、策略拉取和更新，界面上能看到的那几项配置——哪些进程受管、哪些扩展名受管、外发要不要审批——都从服务端下发到这里。它维护的正是后面要用到的两张名单：一张进程名白名单，一张与进程对应的扩展名管辖列表。名单变更后，主程序通过设备控制通道把新策略推给驱动，驱动更新自己的匹配表。

这里有个容易误判的点：很多人以为“把主程序退出，加密就停了”。实际测下来，主程序退出后策略仍然生效，因为策略早已下发并缓存在内核侧，用户态只是个下发通道。也就是说，主程序的价值在于“它知道规则是什么”，而不在于“它在执行规则”。想摸清规则，盯主程序是有意义的；想绕过执行，盯主程序毫无意义。

2.2 守护进程：为什么结束主程序没有意义

守护进程干的事情很单一：轮询或者注册进程创建回调，一旦发现主程序不在了，几秒内把它拉起来。有的实现还会注册服务恢复策略，连服务被停都能自愈。实测一下就知道，任务管理器里结束主程序，五秒之内它自己回来了，顺带在系统日志里留一条记录。

所以“杀进程”这条路在成本收益上完全不划算：既拦不住加密，又会留下明显的异常痕迹。真正值得关注的是它反过来的信息——守护进程存在，说明这套产品把“策略持续在线”当成核心指标，那么策略表大概率是常驻内核内存的，这为后面“用行为验证规则”提供了前提。

2.3 文件过滤驱动：真正干活的那一层，也是唯一值得盯的一层

加解密发生在文件系统过滤驱动里，挂在文件创建、读取、写入、属性修改这几个关键 IRP 上；也有产品额外对若干应用层 API 做 hook。驱动在内核里能看到的信息其实很有限：发起这次 IO 的进程对象（映像名、映像路径、发布者签名、父进程）、目标文件的完整路径和扩展名、以及这次 IO 的类型和长度。加解密在 IRP 的完成例程里做掉，应用层拿到的永远是明文。

这也是为什么“从应用层找算法”是条死路：你在用户态调试、抓包、看内存，看到的全是解密后的数据，密文根本没经过你手里。密钥通常在服务端，本地最多有个受保护的句柄。判断这一点不需要逆向，做个对照实验就够——同一份文件，在受管机器上读到的字节和在干净机器上读到的字节不一样，而受管机器上任何应用读到的都一样，那加解密必然在应用层之下。

提示：判断“加密发生在哪一层”，最快的办法是在两台机器之间对比同一文件的头部字节，而不是在受管机器上想办法看内存。

3. 加密与否的判定逻辑：进程名和扩展名组成的二维表

摸清了分层，下一步是把“什么时候加密、什么时候不加密”这件事变成一张可以验证的表。这一步是整个思路的核心，也是最容易被跳过的一步——很多人凭感觉认为“装了客户端就全加密”，实际测下来完全不是这么回事。

3.1 先把观察方法固定下来：三个变量做交叉

要做交叉验证，先得把变量控制住。这里涉及三个维度：进程名是否在白名单里、目标扩展名是否在管辖列表里、这次操作是“新建写入”还是“读取已有文件”。每次只改一个变量，其余固定。

具体的观察方法：准备一段已知内容的测试数据（比如一串固定字节），在受管机器上执行一次操作，然后把结果文件拷到一台没装客户端的机器上，用十六进制工具看头部字节。之所以要换机器看，是因为在受管机器上你看到的永远是解密后的明文，看不出任何东西。这一步是整套方法的地基，地基不牢，后面全是玄学。

还有一个细节常被忽略：新建文件和读取已有文件，驱动走的判定分支可能不一样。有的实现在文件创建时就为这个文件句柄打上“受管/不受管”的标记，后续读写都按这个标记走；有的实现每次 IO 都重新判定。所以要分别测“写一个新文件”和“读一个已存在的加密文件”，两组数据都要。文件名、目录层级、是否跨卷这些也建议顺手测一遍，后面批量处理时会用到。

3.2 四个格子的实测结论

把三个变量交叉完，结论收敛得很快。以读取一个已经处于加密状态的文件为例：

表格里最关键的是第二行和第三行的对比。只有当“进程在白名单”且“扩展名在管辖列表”两个条件同时成立时，驱动才会走解密分支；缺任何一个，驱动就把磁盘上的原始字节原样交给调用方。这解释了一个日常现象：同一个 .txt 文件，用系统自带的文本编辑器打开是正常内容，用一个自己写的小工具打开就是乱码——不是文件坏了，是小工具不在白名单里，驱动根本没给它解密。

举个具体的例子会更清楚。假设系统自带的文本编辑器在白名单里，它读写 .txt 时会拿到解密服务，但让它去读一个 .abc 后缀的文件，驱动就不认这个扩展名，直接给密文。反过来，一个不在白名单里的自研程序，无论读写什么后缀，都拿不到解密服务。这两条规律合起来，就是后面所有操作的立足点。

3.3 这套模型为什么天生有缝：判定依据全部来自可伪造的身份

把这张表看明白，就能看出这套模型的根子问题：它依赖的两个判定依据，都是可以被轻易构造出来的弱身份。

进程名来自映像文件在磁盘上的名字，把可执行文件复制一份改个名就有了，内核拿到的就是这个字符串。扩展名是文件路径字符串的一部分，改个后缀就有了。内核没有“你是谁”的强身份概念，除非产品额外校验数字签名、安装路径、父进程链，否则这两项本质上都是用户可以自由指定的。

商用产品为了兼容性，通常会把白名单放得很宽——常见办公软件、压缩软件、图片查看器基本都在里面，不然用户天天遇到“文件打不开”的工单。名单越宽，可利用面越大。这就是这套模型绕不过去的矛盾：要好用就得放宽，要严格就没人用。

注意：这类透明加解密产品的密钥一般在服务端，逆向用户态基本拿不到。先花半天验证“密钥是否在本地”，比花一周逆算法划算得多。

4. 复现这条路：把“借刀”拆成四步并逐段验证

原理清楚之后，落地其实是四步：让进程报出白名单里的名字、用这个身份读出明文、把明文写到不受管的扩展名上、再用另一个进程把扩展名改回去。听起来简单，但每一步都有细节，任何一处不到位都会让你拿到一堆仍然打不开的文件。

4.1 第一步：让进程报出白名单里的名字

映像名匹配的是磁盘上的文件名，所以最直接的做法是写一个只做最小读写的壳程序，编译成单文件，复制一份并改成白名单里某个软件的名字。不建议直接拿大软件本体改名，很多程序依赖自身文件名或路径去加载资源，改完可能起不来。

先确认一件事：你的壳程序改名之后，究竟有没有被当成白名单进程。验证方法很简单，让它去读一个受管的 .txt 文件，如果读到的是可读文本，说明身份已经生效；如果还是乱码，说明匹配规则不止看文件名。

import shutil, subprocess, os # 把编译好的壳程序复制一份，改成白名单里的进程名 # 注意：目标名必须真实存在于客户端的进程白名单中 src_exe = r"D:\work\shell.exe" dst_exe = r"D:\work\viewer.exe" # 借用白名单内的名字 shutil.copy2(src_exe, dst_exe) # 用新名字启动，并把"读哪个文件、写到哪"作为参数传进去 # 参数化是关键：后面每次换样本都不用重新编译 subprocess.run([dst_exe, r"D:\data\report.xlsx", r"D:\out\report.tmp"], check=True) print("done:", os.path.exists(r"D:\out\report.tmp"))

这段的重点不在逻辑，而在“参数化”和“单文件”。参数化让你能批量换样本，单文件避免依赖缺失导致的假失败。如果你的壳程序还要读取自身目录下的配置文件，改名之后路径一变就可能找不到，这类问题会伪装成“驱动没给解密”，白折腾半天。

4.2 第二、三步：读出明文，落到不受管的扩展名上

壳程序做两件事：按原路径打开源文件读，把读到的字节写到目标路径。源文件扩展名必须是受管的，否则驱动不解密；目标扩展名必须是不受管的，否则写出去又会被自动加密。

后缀怎么挑？挑一个明确不可能出现在业务名单里的，比如 .tmp、.dat，或者自造的三字母后缀。别用 .bak，不少策略会把备份后缀一起纳管，这个坑很常见。

import sys, os src, dst = sys.argv[1], sys.argv[2] # 1) 读：源扩展名受管 + 当前进程名在白名单 -> 驱动返回明文 with open(src, "rb") as f: data = f.read() # 2) 写：目标扩展名不受管 -> 驱动不做处理，明文字节直接落盘 tmp = dst + ".part" with open(tmp, "wb") as f: f.write(data) f.flush() os.fsync(f.fileno()) # 必须 fsync，避免驱动在 close 时补加密 os.replace(tmp, dst) print("bytes:", len(data))

fsync这一行不是可选项。有些实现在文件句柄关闭时才做加密判定并写回，如果你没等数据真正落盘就改名，可能拿到一个长度对但尾部残缺的文件。写入用临时文件加原子替换也是同样的道理，避免中途失败留下半截文件，后面批量跑的时候很难定位问题。

4.3 第四步：换一个不受管的进程把扩展名改回去

为什么不能在同一步里直接写成原扩展名？因为在白名单进程手里，写一个受管后缀的文件，驱动会按“写”的分支给你加密回去，前面全白干。重命名本身通常不写数据，一般不触发加密，但少数实现会在属性修改或关闭时按新后缀重建加密上下文，保险起见交给另一个进程做。

这一步用不在白名单里的普通进程执行，比如系统自带的命令行或者一段独立的脚本，且不要在这个进程里读写文件内容，只改名。

import os, sys # 用不受管的进程执行本脚本：只改名，不碰内容 src, dst = sys.argv[1], sys.argv[2] # 同一卷内 rename 是元数据操作，不会重新写数据 # 跨卷会退化成"复制 + 删除"，复制时又落回受管进程，务必确认同卷 os.rename(src, dst) print("renamed ->", dst)

跨卷这一点值得单独说：如果临时目录在 C 盘、原文件在 D 盘，os.rename会失败或者退化成复制删除，复制动作如果在受管进程里发生，文件又被加密一遍。所以临时输出目录一定要和原文件在同一个卷上。

4.4 验证：怎么确认拿到的是真明文

别凭“能双击打开”就认为成功。Office 的 .docx、.xlsx 本质是 ZIP 容器，头部四个字节是50 4B 03 04；PDF 是%PDF；PNG 是89 50 4E 47。密文通常没有这些魔数，一比对就知道。

import sys MAGIC = { b"PK\x03\x04": "zip 容器（docx/xlsx/pptx）", b"%PDF": "pdf", b"\x89PNG": "png", b"\xff\xd8\xff": "jpeg", } with open(sys.argv[1], "rb") as f: head = f.read(8) for k, v in MAGIC.items(): if head.startswith(k): print("plaintext ok ->", v) break else: print("not plaintext, head =", head.hex())

除了魔数，还要核对大小。解密后的长度一般和原始明文一致，和密文可能有细微差异（头部、对齐填充）。如果大小明显对不上，说明读到的是被截断的数据，回去检查是不是读写没走完整流程。单文件跑通之后再谈批量，批量阶段每一百个抽一个验魔数，能省掉大量返工。

5. 避坑清单：复现这条路上最容易翻车的五个地方

下面这几条都是实打实踩过的，按“现象、原因、解决”写清楚，遇到对号入座就行。

5.1 改完名程序起不来或行为怪异

现象：壳程序改成白名单名字后，双击没反应，或者起来就崩，命令行运行报找不到某某文件。

原因：一是程序内部有对自身文件名的硬编码检查；二是它依赖同目录下的配置、DLL 或资源文件，改名后相对路径解析变了；三是某些安全软件对“知名进程名但路径异常”的组合直接拦截。

解决：别拿现成软件改名，自己写一个只做文件读写的单文件程序，把所有外部依赖去掉。编译时静态链接运行时库，运行时不读任何配置文件，参数全部走命令行。这样改名只影响一个字符串，不会牵动其它逻辑。

5.2 读出来是明文，写出去再打开又成乱码

现象：中间产物用十六进制看明明是明文，魔数也对，但把它改成 .xlsx 之后双击还是打不开。

原因：写入时用了受管后缀，驱动在关闭句柄时按新后缀补了一次加密；或者写入没做 fsync，改名时数据还在页缓存里，落盘时被重新处理。

解决：写入阶段一律用不受管的后缀，改名交给另一个进程；写入后强制flush+os.fsync，确认文件大小与预期一致再进行下一步。改名脚本里不要顺手打开文件看一眼，看一眼可能就触发一次受管 IO。

5.3 换了白名单名字仍然拿到密文

现象：进程名已经改成白名单里的了，读受管文件还是乱码，魔数对不上。

原因：匹配规则不止看文件名。有的产品匹配完整安装路径（必须在系统程序目录下），有的校验发布者签名，有的看父进程链，还有的按进程创建时间做了一次性缓存——你的进程启动时机不对，就没进缓存。

解决：先确认匹配维度。拿一个已知在白名单里的正牌软件做对照，把它的可执行文件复制到你的目录下运行，如果它能解密、你的不能，差异就在路径或签名上。逐个排除：换到系统程序目录、用带签名的程序、从受管的父进程拉起。每改一个条件跑一次，别一次改三个。

5.4 批量跑完发现部分文件 0 字节或打不开

现象：单文件测试全过，写个循环跑整个目录，跑完一看有几个文件大小是 0，有几个大小对但打不开。

原因：一是循环里没做异常处理，某个文件读失败后句柄没关，后续写入全乱；二是文件名里有空格、中文、超长路径，参数传递时被截断；三是部分文件本身就是损坏的，或者加密状态和预期不同（比如已经是明文）。

解决：每个文件独立 try/except，失败记录下来继续跑，不要整体中断；路径统一用绝对路径并加引号；跑之前先抽样检查源文件的加密状态，把已经是明文的挑出来跳过。跑完做一次全量校验，比对源文件和输出文件的数量、魔数、大小三项。

5.5 单目录成功、整盘失败

现象：在 D 盘某个目录下跑得好好的，换成整个盘或者网络盘就大面积失败。

原因：跨卷导致重命名退化成复制；网络盘的文件系统过滤层和本地不同，驱动的行为可能不一致；权限不足导致部分目录写不进去。

解决：临时输出目录强制和源文件同卷，用os.path.splitdrive判断一下卷标再决定路径；网络盘单独测，别和本地混在一起跑；写之前先做一次目录可写性探测，避免跑到一半才发现权限问题。

6. 从绕过到加固：这套判定模型该怎么补，以及我给自己划的线

回过头看，这个思路之所以成立，不是因为客户端做得糙，而是因为它把安全决策压在了两个可伪造的弱身份上：进程名和扩展名。这两个东西在内核里都只是字符串，构造成本几乎为零。换任何一个同类产品，只要判定模型还是“进程名 + 后缀”，结论都一样。

站在防守侧，补的方向其实很明确。进程侧不要只认文件名，把数字签名、安装路径、父进程链绑在一起校验，白名单收窄到真正需要的少数几个；文件侧不要只看后缀，按内容魔数判类型，对“白名单进程写出非受管后缀”这种组合直接告警；行为侧抓真正有价值的信号——同一进程短时间内大量读取受管文件、然后向可移动介质或网络位置集中写出，这才是该拦的动作。密钥层面，密钥不下用户态、文件级密钥加审计留痕，能大幅抬高成本。

最后说说我自己。早些年做类似验证，图快，直接在生产机上跑脚本，结果一次误操作把几个正在用的文件覆盖了，事后追溯花了整整两天。从那以后我每次做这类验证都强制走一遍流程：拿到书面授权、在隔离机器上做、先单文件跑通并校验、再谈批量、全程留操作记录。这五步一步都不能省，省哪一步都可能把技术问题变成事故。希望帮到你。

本文还有配套的精品资源，点击获取