软件在加壳保护的时候，导入表这块区域，通常是最容易被分析人员盯上的地方。要想把Themida的导入表保护功能给用起来，一般需要在保护工程里面，把那些跟导入表、API包装，还有相关的高级保护选项有关的设置都打开，让程序在实际跑起来的时候，能够把关键的API调用给隐藏起来、重新定向，或者包裹起来。根据Themida官方文档的说明，保护器会在程序正式运行之前，提前接管整个执行流程，同时还会去检查当前环境里有没有调试器、反编译器这类工具；而对导入表和API调用做保护，本身也是一种非常常见的防护思路。

　　一、Themida导入表保护怎么启用

　　在对程序开启导入表保护之前，最好先拿未加保护的原始版本，做一轮完整的运行测试。如果原程序本身就存在缺DLL、延迟加载机制不正常，或者跟某些系统版本存在兼容问题，那么在加上保护之后就更加难定位了。

　　1、先把保护工程建起来

　　先把Themida启动起来，然后把需要保护的EXE或DLL文件加载进去，再设置好输出文件的存放路径，输出的文件最好是输出到一个独立的文件夹里，而不要直接把原来的文件给覆盖掉，这样后面就能拿来同时跟未保护的版本做个对比。

　　2、把跟导入表相关的保护给启用起来

　　在保护选项或者高级选项当中，去找一找跟导入表、API包装、导入保护这一类有关的设置项。不同的版本在界面文字上可能会有一点点差别，所以实际操作的时候，还是要以当前手头这个版本显示出来的名称为准。把这些选项启用了以后，Themida就会对导入表，还有API的解析过程，进行专门的保护处理，这样一来，静态分析的难度就会增加不少。

　　3、头一次先用默认的强度去跑

　　第一次做保护的时候，不要一下子就把所有高级选项全部拉到最高的强度。官方的帮助文件里也提到过，如果程序的导入表原本就非常大，在默认保护下一般不会有太大的影响，但导入表特别庞大的程序，启动的时候可能会感觉变慢。所以，比较好的办法是先拿默认的保护设置，去验证一下启动流程和核心功能是否正常，确认没有问题了，再一点点地往上增加强度。

　　4、如果是保护DLL的话就要单独测一下

　　如果这次保护的目标是一个DLL文件，那就得要确认一下宿主程序加载它的流程能不能走得通。Themida的更新记录里面曾经提到过，加入了对于空导入表的DLL的支持，这也说明DLL的导入结构差别，是会影响到保护的兼容性的。在保护DLL的时候，最好是准备一个最小化的宿主程序，专门拿来做加载测试。

　　二、Themida导入表保护异常该怎么排查

　　导入表保护出现异常的时候，常常会有这么几种表现：程序启动直接失败、系统提示缺少某个DLL、点开某些功能就崩溃，又或者只是在某几款Windows版本上报错。排查的时候要先把范围缩小，不要同时去动好几个保护选项。

　　1、先把导入表保护关掉，做个对比

　　可以先把其他的保护选项都保留着，单单把跟导入表，或者API包装有关的设置给关掉，重新生成一个版本。如果程序就这么恢复正常了，那就差不多可以确定，问题就是集中在导入表保护，或者API包装这条链路上。

　　2、去查一下缺失的DLL和系统版本

　　有一些程序会导入当前这个系统上压根就不存在的DLL或API。Themida的高级选项当中，有一项跟缺失DLL错误提示有关的兼容设置，官方说明里写到过，有些应用会导入某些Windows版本里根本找不到的DLL，加了保护以后，就可能会弹出错误信息。碰到这类问题，要先确认好目标系统版本还有运行库是不是都配齐了。

　　3、检查一下延迟加载和插件机制

　　如果程序在跑起来之后，会动态地去加载插件、驱动、脚本扩展，或者是第三方的模块，那么导入表保护就可能会改变API解析的时机。可以先在不加载任何插件、功能最小化的状态下跑一遍，然后再一个一个地把模块加回去，看看到底是哪一类依赖触发了异常。

　　4、看看是不是钩子或者安全软件冲突了

　　因为API包装会直接改变调用的路径。从Themida的更新记录里也能看到，它曾经去改进过API-Wrapper跟系统级钩子之间的兼容性，也出过跟Wine环境下API-Wrapper兼容问题的修复记录。如果异常只出现在装了安全软件、输入法、注入型插件，或者兼容层环境的机器上，那就得把这些外部因素也纳入到排查范围里面来。

　　三、Themida导入表保护上线前怎么验证

　　光是启动成功一次，还远远不够，因为很多API只会在用到某些具体功能的时候才会被调用，所以必须把核心的业务流程都覆盖到，才能算通过验证。

　　1、到干净的环境里面去做测试

　　找一台没有装过开发环境、没有装过Themida、也没有额外调试工具的电脑，在这个环境里把保护好的版本跑起来。然后把启动、登录、文件的读写、网络通信、打印、授权验证，还有插件加载这些关键环节，全都试一遍。

　　2、把日志和崩溃转储文件拿来对比一下

　　如果保护后还是会出现崩溃，那就先要把保护日志、系统事件日志，还有崩溃dump都给保留下来。Themida的高级选项里也有跟保留调试信息相关的设置，这就很适合拿来做受保护程序崩溃转储的分析。

　　3、分批地把高级保护一层层地开起来

　　导入表保护、压缩、资源保护、反调试、虚拟机保护这些选项，不要一口气全都拉到高强度。每次只动一个选项，生成一个版本，然后把结果记录下来，这样万一出现异常，就能很快地回退到之前的状态去。

　　4、把保护配置的基线给建好

　　可以把这次用的Themida版本、都选了哪些保护选项、输出文件的名字、测试用的系统、运行库的版本，还有最后的验证结论，全都记录好。后面如果Themida升级了，或者换过编译器，就可以拿这套记录出来，比对一下到底是哪一项配置导致了兼容性的变化。

　　总结

　　Themida里面启用导入表保护，主要就是在保护工程这边，把导入表、API包装这些相关的选项打开，而且最好是从默认的强度开始一步步测试。碰到导入表保护异常的时候，建议先把这一项关掉做个对比，然后再去查缺失的DLL、系统版本、延迟加载、插件机制，还有跟钩子的冲突这些地方。导入表保护本身属于对兼容性比较敏感的功能模块，所以在正式发布以前，一定要拿到干净的系统环境里，沿着核心业务流程完整地跑一遍，这样才能真正把风险给降下来。