简介面向需要理解易赛通数据泄露防护客户端加密机制的技术人员这份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 rD:\work\shell.exe dst_exe rD:\work\viewer.exe # 借用白名单内的名字 shutil.copy2(src_exe, dst_exe) # 用新名字启动并把读哪个文件、写到哪作为参数传进去 # 参数化是关键后面每次换样本都不用重新编译 subprocess.run([dst_exe, rD:\data\report.xlsx, rD:\out\report.tmp], checkTrue) print(done:, os.path.exists(rD:\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 04PDF 是%PDFPNG 是89 50 4E 47。密文通常没有这些魔数一比对就知道。import sys MAGIC { bPK\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改名时数据还在页缓存里落盘时被重新处理。解决写入阶段一律用不受管的后缀改名交给另一个进程写入后强制flushos.fsync确认文件大小与预期一致再进行下一步。改名脚本里不要顺手打开文件看一眼看一眼可能就触发一次受管 IO。5.3 换了白名单名字仍然拿到密文现象进程名已经改成白名单里的了读受管文件还是乱码魔数对不上。原因匹配规则不止看文件名。有的产品匹配完整安装路径必须在系统程序目录下有的校验发布者签名有的看父进程链还有的按进程创建时间做了一次性缓存——你的进程启动时机不对就没进缓存。解决先确认匹配维度。拿一个已知在白名单里的正牌软件做对照把它的可执行文件复制到你的目录下运行如果它能解密、你的不能差异就在路径或签名上。逐个排除换到系统程序目录、用带签名的程序、从受管的父进程拉起。每改一个条件跑一次别一次改三个。5.4 批量跑完发现部分文件 0 字节或打不开现象单文件测试全过写个循环跑整个目录跑完一看有几个文件大小是 0有几个大小对但打不开。原因一是循环里没做异常处理某个文件读失败后句柄没关后续写入全乱二是文件名里有空格、中文、超长路径参数传递时被截断三是部分文件本身就是损坏的或者加密状态和预期不同比如已经是明文。解决每个文件独立 try/except失败记录下来继续跑不要整体中断路径统一用绝对路径并加引号跑之前先抽样检查源文件的加密状态把已经是明文的挑出来跳过。跑完做一次全量校验比对源文件和输出文件的数量、魔数、大小三项。5.5 单目录成功、整盘失败现象在 D 盘某个目录下跑得好好的换成整个盘或者网络盘就大面积失败。原因跨卷导致重命名退化成复制网络盘的文件系统过滤层和本地不同驱动的行为可能不一致权限不足导致部分目录写不进去。解决临时输出目录强制和源文件同卷用os.path.splitdrive判断一下卷标再决定路径网络盘单独测别和本地混在一起跑写之前先做一次目录可写性探测避免跑到一半才发现权限问题。6. 从绕过到加固这套判定模型该怎么补以及我给自己划的线回过头看这个思路之所以成立不是因为客户端做得糙而是因为它把安全决策压在了两个可伪造的弱身份上进程名和扩展名。这两个东西在内核里都只是字符串构造成本几乎为零。换任何一个同类产品只要判定模型还是“进程名 后缀”结论都一样。站在防守侧补的方向其实很明确。进程侧不要只认文件名把数字签名、安装路径、父进程链绑在一起校验白名单收窄到真正需要的少数几个文件侧不要只看后缀按内容魔数判类型对“白名单进程写出非受管后缀”这种组合直接告警行为侧抓真正有价值的信号——同一进程短时间内大量读取受管文件、然后向可移动介质或网络位置集中写出这才是该拦的动作。密钥层面密钥不下用户态、文件级密钥加审计留痕能大幅抬高成本。最后说说我自己。早些年做类似验证图快直接在生产机上跑脚本结果一次误操作把几个正在用的文件覆盖了事后追溯花了整整两天。从那以后我每次做这类验证都强制走一遍流程拿到书面授权、在隔离机器上做、先单文件跑通并校验、再谈批量、全程留操作记录。这五步一步都不能省省哪一步都可能把技术问题变成事故。希望帮到你。本文还有配套的精品资源点击获取
简介面向需要理解易赛通数据泄露防护客户端加密机制的技术人员这份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 rD:\work\shell.exe dst_exe rD:\work\viewer.exe # 借用白名单内的名字 shutil.copy2(src_exe, dst_exe) # 用新名字启动并把读哪个文件、写到哪作为参数传进去 # 参数化是关键后面每次换样本都不用重新编译 subprocess.run([dst_exe, rD:\data\report.xlsx, rD:\out\report.tmp], checkTrue) print(done:, os.path.exists(rD:\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 04PDF 是%PDFPNG 是89 50 4E 47。密文通常没有这些魔数一比对就知道。import sys MAGIC { bPK\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改名时数据还在页缓存里落盘时被重新处理。解决写入阶段一律用不受管的后缀改名交给另一个进程写入后强制flushos.fsync确认文件大小与预期一致再进行下一步。改名脚本里不要顺手打开文件看一眼看一眼可能就触发一次受管 IO。5.3 换了白名单名字仍然拿到密文现象进程名已经改成白名单里的了读受管文件还是乱码魔数对不上。原因匹配规则不止看文件名。有的产品匹配完整安装路径必须在系统程序目录下有的校验发布者签名有的看父进程链还有的按进程创建时间做了一次性缓存——你的进程启动时机不对就没进缓存。解决先确认匹配维度。拿一个已知在白名单里的正牌软件做对照把它的可执行文件复制到你的目录下运行如果它能解密、你的不能差异就在路径或签名上。逐个排除换到系统程序目录、用带签名的程序、从受管的父进程拉起。每改一个条件跑一次别一次改三个。5.4 批量跑完发现部分文件 0 字节或打不开现象单文件测试全过写个循环跑整个目录跑完一看有几个文件大小是 0有几个大小对但打不开。原因一是循环里没做异常处理某个文件读失败后句柄没关后续写入全乱二是文件名里有空格、中文、超长路径参数传递时被截断三是部分文件本身就是损坏的或者加密状态和预期不同比如已经是明文。解决每个文件独立 try/except失败记录下来继续跑不要整体中断路径统一用绝对路径并加引号跑之前先抽样检查源文件的加密状态把已经是明文的挑出来跳过。跑完做一次全量校验比对源文件和输出文件的数量、魔数、大小三项。5.5 单目录成功、整盘失败现象在 D 盘某个目录下跑得好好的换成整个盘或者网络盘就大面积失败。原因跨卷导致重命名退化成复制网络盘的文件系统过滤层和本地不同驱动的行为可能不一致权限不足导致部分目录写不进去。解决临时输出目录强制和源文件同卷用os.path.splitdrive判断一下卷标再决定路径网络盘单独测别和本地混在一起跑写之前先做一次目录可写性探测避免跑到一半才发现权限问题。6. 从绕过到加固这套判定模型该怎么补以及我给自己划的线回过头看这个思路之所以成立不是因为客户端做得糙而是因为它把安全决策压在了两个可伪造的弱身份上进程名和扩展名。这两个东西在内核里都只是字符串构造成本几乎为零。换任何一个同类产品只要判定模型还是“进程名 后缀”结论都一样。站在防守侧补的方向其实很明确。进程侧不要只认文件名把数字签名、安装路径、父进程链绑在一起校验白名单收窄到真正需要的少数几个文件侧不要只看后缀按内容魔数判类型对“白名单进程写出非受管后缀”这种组合直接告警行为侧抓真正有价值的信号——同一进程短时间内大量读取受管文件、然后向可移动介质或网络位置集中写出这才是该拦的动作。密钥层面密钥不下用户态、文件级密钥加审计留痕能大幅抬高成本。最后说说我自己。早些年做类似验证图快直接在生产机上跑脚本结果一次误操作把几个正在用的文件覆盖了事后追溯花了整整两天。从那以后我每次做这类验证都强制走一遍流程拿到书面授权、在隔离机器上做、先单文件跑通并校验、再谈批量、全程留操作记录。这五步一步都不能省省哪一步都可能把技术问题变成事故。希望帮到你。本文还有配套的精品资源点击获取
