要搞清楚Themida导入表保护怎么配置，以及导入表保护之后DLL加载出现异常该怎么处理，这一类问题在Windows原生EXE或DLL加固之后经常遇到。这里说的导入表保护，重点并不是把程序依赖的那些DLL给删掉，而是要加大外部工具直接去识别API调用关系的难度。在Themida当中，跟这个需求关系比较大的功能，就是Advanced API-Wrapping，它会对程序用到的API做一层包装。但是，程序在启动的阶段、插件加载的过程，还有延迟加载这些逻辑，它们本身就已经比较敏感了，如果保护的强度一下子开得太高，就可能会出现DLL找不到、入口点异常，或者模块加载之后马上就退出的情况。
一、Themida导入表保护怎么配置
在进行配置以前，需要先保留一份能够正常启动、能够把全部DLL都正常加载起来的原始程序。不要在程序自身还存在依赖问题的时候就直接动手加固，不然的话，保护之后出现的异常，就很难判断到底是Themida引起的，还是原始程序的环境本来就没有配置完整。
1、先建立最小保护基线
头一次进行处理的时候，只保留Themida的基础保护设置，不要同时去开启API包装、入口点虚拟化、XBundler，还有大量的虚拟机宏。先确认只加了基础保护的EXE或DLL能够正常加载，然后再一项一项地往上增加功能。这么做的话，一旦出现了异常，就能直接知道，是新加进去的哪一项设置影响到了模块的加载，而不必在十几个选项里面反复地去尝试。
2、启用API包装功能
进入【Protection Options】→【Advanced API-Wrapping】，把API包装启用之后，重新执行一次保护操作。
这个选项，会对被保护程序所用到的API调用进行包装，让调用关系不再按照原来导入信息的那种方式直接暴露出来。它一般是适合原生EXE和DLL的，但如果程序在启动阶段会很高频率地调用某些API，就可能带来一定的启动或者运行开销。另外，有一部分比较特殊的程序，还可能会跟API包装之间存在兼容性的问题，所以不太建议在没有完成测试的情况下，就直接用它去覆盖正式的版本。
3、分层增加其他保护选项
等到导入关系的保护确认稳定了以后，再去增加压缩加密、字符串保护，还有代码虚拟化。入口点、DLL的初始化函数，以及跟加载器有关的那些代码，不太适合一上来就进行高强度的处理，因为这些位置执行的时间很早，依赖的系统环境也相对复杂。每增加一组设置，都应当重新去测试一下程序的启动、插件的加载、功能的调用，还有能不能正常退出。
二、Themida导入表保护后DLL加载异常怎么办
DLL加载出现异常，不能光盯着系统弹出来的“模块无法加载”这个提示去看。有些情况，确实是依赖的文件缺失了，但另外一些情况，则是DLL已经进入到了内存当中，只不过在入口函数、API解析，或者初始化代码执行的时候失败了。排查的时候，要先把保护选项一层一层地拆开，然后再去检查原始的依赖环境。
1、先关闭入口点虚拟化
进入【Protection Options】→【Entry Point Virtualization】，临时把这个选项取消掉，然后重新生成一份保护文件。
入口点虚拟化这个功能，它并不是适合所有程序的，尤其是DLL的入口函数、插件模块，还有那些带有特殊初始化流程的组件。假如关闭之后模块就恢复正常了，那就说明问题集中在启动入口的附近，也就不必再继续去修改普通的业务函数了。这个时候，可以把其他的保护保留下来，只绕开跟入口点相关的处理。
2、单独测试Advanced API-Wrapping
进入【Protection Options】→【Advanced API-Wrapping】，把勾选取消掉之后，再次进行保护，然后去测试一下DLL的加载情况。
如果关闭这个选项以后DLL就能够正常载入了，那问题通常就出在某个被频繁调用，或者是采用了特殊调用方式的API上面。这种时候，不要马上就把所有的保护都给关掉，可以先想办法把问题的范围缩小，去确认异常到底是在主程序加载DLL的时候发生的，还是DLL去加载其他依赖的时候发生的，又或者是在插件初始化调用系统API的时候出现的。在Themida的兼容性排查顺序当中，也是把关闭Advanced API-Wrapping作为原生程序保护之后无法运行时，一个很重要的检查步骤。
3、检查字符串保护和XBundler
当程序使用了虚拟机宏的时候，字符串加密这个功能，有可能对初始化阶段用到的ANSI或者Unicode字符串产生影响；而在使用XBundler去嵌入DLL的时候，模块的架构、写盘的方式，还有依赖的顺序，也都有可能影响到加载。
可以先把【Encrypt Strings in VM macros】给关上，再临时取消【XBundler】，拿来做一下对比测试。如果程序只用到了Unicode字符串，就不要同时再去开启那些不需要的ANSI处理。假如把XBundler关掉之后就恢复正常了，那就需要接着去检查被嵌入的DLL的位数、它自身的依赖项，以及这个DLL是不是非得从一个真实的磁盘路径才能加载。
三、DLL仍然加载失败怎么继续排查
保护选项都已经逐项测试过了，DLL还是加载失败的时候，就需要回到Windows模块依赖和项目构建本身去找原因了。Themida是没办法自动去补齐那些缺少的运行库的，也不能去解决原来程序当中就已经存在的位数、路径，还有入口函数方面的问题。
1、确认主程序与DLL架构一致
去检查一下主程序、目标DLL以及它所依赖的那些模块，到底是x86的还是x64的。32位的进程是不能直接去加载64位DLL的，64位的进程同样也不能直接去加载32位的DLL。原始程序在开发的电脑上面可以跑，有可能只是因为那台机器上面碰巧安装了对应的依赖，等换到了测试机上面之后，缺少运行库的问题才会一下子暴露出来。
2、检查动态加载参数
当程序通过LoadLibrary这类方式去动态加载DLL的时候，需要检查一下传进去的路径、工作目录、文件名，还有后面获取函数地址的那一步，是不是都正确。保护过之后，输出文件的位置有可能发生了变化，如果程序比较依赖相对路径，说不定就会跑到一个错误的目录下面去找DLL。要是错误发生在获取函数地址的阶段，那还得去确认一下导出的名称和序号，有没有被改动过。
3、用最小配置逐步恢复
去建立一份新的Themida项目，只把目标文件和基础保护加进去，等确认能够运行了之后，再按照API包装、压缩加密、入口点保护、字符串处理，还有XBundler，这么个顺序，一项一项地往回恢复。每次只去改动一个设置，并且把每一次生成的输出文件都单独保存下来。这么做，要比在原来那个项目里面同时去开关好几个选项，更容易把异常的来源给确定下来，也能够保留下一个随时都可以往回退的兼容配置。
总结
Themida导入表保护怎么配置，还有Themida导入表保护之后DLL加载出现异常该怎么处理，这里面最关键的地方，是要把Advanced API-Wrapping和其他的保护功能，分开来测试。在进行配置的时候，先建立一个可以运行的基础版本，再去启用API包装，然后再逐步去增加入口点、字符串还有打包方面的保护。DLL加载出现异常的时候，应当按顺序去检查入口点虚拟化、Advanced API-Wrapping、字符串加密，还有XBundler，然后再去核对模块的位数、运行库、相对路径，以及动态加载的参数。保护的强度，并不是选项开得越多就越好，那种能够稳定地启动、稳定地加载，并且能够正常退出的配置，才适合进入到正式的发布流程中去。
