宿主程序在接入DLL插件之后，平时运行一直很正常，可一旦用Themida做完保护，插件列表就变成空的、模块怎么都加载不上、配置文件也找不着了，这类问题在实际项目里并不少见。出现这些情况的时候，先不要急着去改程序代码，而是要顺着插件是怎么被扫描出来的、加载的时候走的是什么路径、保护之后文件放在哪里了，这几个方向一步步去排查，通常能找到问题的根子。Themida本身可以对Windows应用程序做代码加壳和反调试保护，同时也提供了XBundler这个功能，能把DLL和各种数据文件直接嵌进受保护的程序里面。但打包方式一变，原来那些直接读文件、写配置、动态加载模块的逻辑，也就得跟着一起重新调整。

　　一、Themida插件保护后为什么会失效

　　遇到插件失效的时候，最先要分清楚的，是宿主程序压根儿就没找到插件文件，还是插件文件虽然被找到了，但是在加载或者初始化的过程当中崩掉了。这两种情况表现出来的现象可能差不多，但排查的方向完全不一样。

　　1、相对路径依赖了当前工作目录

　　原来的程序很可能就是简单地从软件目录里的一个plugins文件夹下面去扫描DLL，平时直接双击打开，工作目录正好就是程序自己的目录，所以一切正常。但是保护之后，如果启动的目录、快捷方式里面设的工作目录，或者XBundler把文件释放到的临时目录发生了变化，原来那条相对路径就有可能指到别的地方去了。宿主程序本身还是能启动的，只是一圈扫下来，什么插件也找不到。

　　2、插件的依赖文件没有一块儿处理

　　一个插件DLL背后，很可能还跟着它自己需要的一堆配置文件、运行时库、资源文件，甚至其他的DLL。如果在用XBundler打包的时候，只把主插件这一个文件给嵌了进去，它的那些二级依赖却还留在外面没有跟着走，那到了加载的时候，照样会因为缺少这些依赖而失败。排查的时候不能只看插件本身，还得把插件目录里那些配套的东西一块儿理清楚。

　　3、虚拟文件这种方式不适合当前的插件

　　XBundler可以把文件嵌到保护后的程序里，也能根据需要把它释放到磁盘上。官方的帮助文档里也写了，如果选了“永不提取到磁盘”这种模式，嵌入的文件就只能按只读的方式来用，运行的时候不能直接修改。如果插件需要往配置文件里写东西、生成缓存，或者还要去加载跟自己在同一个目录底下的其他依赖，那这种时候就最好还是让它老老实实地释放到磁盘上，用真实的物理路径去访问。

　　4、DLL异常处理的兼容性不够

　　插件明明已经被找到了，但是刚一加载就崩溃，或者初始化到一半就中断了，这种时候可以在XBundler的设置里面，去看一看“DLL中的异常支持”这一项。官方帮助里也把它列出来了，就是在嵌入DLL出现兼容性问题的时候拿来处理用的。

　　二、Themida插件加载路径应该怎么处理

　　处理加载路径的时候，最好不要依赖用户从哪个目录启动程序，也别假设当前工作目录一定在程序的安装位置。更稳当的做法，是把文件位置分成程序安装目录和用户数据目录这两块来分别对待。

　　1、插件的本体放在程序的目录底下

　　那些只读的、不需要改动的插件DLL，可以直接放在程序安装目录下的plugins或者modules文件夹里。在宿主程序里面加载之前，先获取主程序自己的所在目录，再拿这个目录去拼接出插件的完整路径。不要只在代码里面写一个光秃秃的“plugin.dll”，也别指望系统会自动去当前工作目录里面搜索。

　　2、需要写入的文件放到用户数据目录里面去

　　插件如果需要更新自己的配置文件、往外面写日志，或者生成缓存，就不要把这些东西往Program Files那种受限的目录里面写了。XBundler支持用一些预设的目录常量来指定位置，比如APP_FOLDER、USER_DOCS、LOCAL_APP_DATA、COMMON_APP_DATA和TEMP_FOLDER这些。如果软件是给普通用户用的，那更适合把那些需要改写的文件放到LOCAL_APP_DATA里面去。

　　3、嵌入的文件要把提取策略区分清楚

　　插件的DLL还有那些非要从磁盘上读不可的资源，就选择把它们提取到磁盘里面去。那些只读的图片、固定的模板和写死的配置，可以继续用虚拟文件的方式嵌在里面就行。至于那些需要被修改的文件，得给它选一种合适的写入策略，比如文件还不存在的时候才去写入，免得每次启动都把用户已经改过的东西又给覆盖回去。

　　三、Themida插件保护异常怎么排查

　　在正式开始排查之前，有件事一定要记住，就是不要一口气把所有的保护选项全都打开。先把功能调到最小，做出一个能跑起来的基础版本，然后再一点点地往上加保护配置，这样定位问题会清楚很多。

　　1、先验证一下没有嵌入插件的情况

　　第一步可以只保护宿主程序本身，插件还是让它们乖乖地待在原来的目录里面。如果这个时候宿主程序能正常加载插件，那就说明问题主要集中在XBundler和路径的配置上。如果连这一步都还是失败，那就得回过头去查宿主程序自己加载插件的逻辑，还有已经打开的那些保护选项是不是影响到了这部分功能。

　　2、再一个一个地把插件往里面加

　　不要一次就把所有的DLL、配置文件、资源文件一股脑儿全塞进工程里面。先只加一个插件进去，确认它能被正常加载，然后再去加它依赖的那些文件。这样一来，一旦加载的时候冒出异常，就可以很快地锁定到底是哪一个文件，或者是哪一种提取策略造成了问题。

　　3、检查一下提取目录的权限够不够

　　如果在程序的安装目录底下提取文件失败了，那就要看看当前用户是不是真的有在那个目录里面写东西的权限。官方帮助里也提到过，如果受到系统权限的限制，可以改成往用户文档或者其他的特殊目录里面放。正式部署到普通办公电脑上面之前，一定得拿一个非管理员的普通账号，从头到尾跑一遍。

　　4、把保护前后的日志都保留好

　　每次运行的时候，把插件扫描了哪些目录、最终是从哪条路径加载的、缺了什么文件、初始化走到哪一步了，这些信息都记录下来。受保护的程序跑起来报了错，先去看插件到底有没有被发现，然后再看DLL有没有被成功加载，最后才去检查初始化那一步的回调。不要一看到插件出了问题，就急着把原因全推到Themida身上。

　　总结

　　Themida保护后插件失效该怎么排查，加载路径又要怎么处理，整件事情梳理下来可以这么看：先确认宿主程序到底能不能找到插件，再去区分哪些文件适合留在虚拟层，哪些文件必须落盘，接着把插件的依赖关系、写入权限，还有DLL异常处理这些环节一个一个地查清楚。插件本身尽量用拼接完整路径的方式来加载，需要写东西的配置和缓存就丢到LOCAL_APP_DATA这类用户目录里面。每次只往工程里面添加一组保护配置，出了问题也更容易回退和定位，不会出现一开保护全盘皆乱的情况。