针对关键的代码逻辑，Obsidium代码虚拟化技术能够起到主要的保护作用，其运行原理是把被选中的代码，转变成供虚拟CPU执行的字节码，在程序运行时，这些字节码再被虚拟机解释并执行。因为这种机制让逆向分析以及随意修改的难度都被增加了，所以它也带来了一些代价，也就是被虚拟化过的代码在速度上，通常比原生的机器码要慢很多，所以该技术并不适合把整个程序都一股脑地覆盖掉。

　　一、Obsidium代码虚拟化怎么开启

　　1、确认版本是否支持代码虚拟化

　　在进行具体使用之前，使用者必须先对安装的版本进行确认，看其是否为正式可用的版本。因为Obsidium的评估版本里有很多功能的限制，代码虚拟化功能不可用这一情况就包含在内，所以，如果使用者在软件界面里找不到相关的选项，或者是把配置弄好后却发现没办法保存、没办法生效，此时不要先把项目设置当成怀疑对象，而应该先检查软件是不是受到了评估版的限制。

　　2、先建立保护项目

　　当Obsidium被打开之后，需要被保护的EXE文件或者DLL文件要先被导入进去，接着对应的保护项目才可以被建立起来。在这一步里，笔者建议不要直接在原始的发布文件上面反反复复地做试验，最好是把文件分成三份，即一份是没有被保护的原始程序，一份是用来测试的保护程序，还有一份是正式发布出去的程序。

　　3、选择真正需要保护的函数

　　在把代码虚拟化开启的时候，其核心的要点并不是“勾选的数量越多就越安全”，而是要把函数选对。比较适合被虚拟化的代码，通常是授权验证的逻辑、核心的算法、关键的业务判断、序列号的校验，以及价格或权限的计算等部分。

　　4、按函数逐步开启并测试

　　比较稳妥的办法，是把保护范围控制在小规模内并逐步开启。可以先把1到3个关键的函数挑选出来，在保护文件被生成之后进行运行测试；当启动、授权以及核心功能都被确认是正常的时候，保护的范围才可以被逐步扩大。

　　二、Obsidium代码虚拟化后程序变慢怎么办

　　1、先判断慢在哪里

　　当程序变慢的时候，需要先把它拆开来进行观察，不能只用“整体变慢”这一句话来概括。常见的情况包括：启动的过程慢、某个功能被打开时慢、检查授权时慢、界面出现卡顿，或者是批量处理时慢。在不同的位置上，其处理的手段也是不一样的。

　　2、减少热点代码的虚拟化范围

　　最管用的解决办法，通常不是去调整参数，而是把虚拟化覆盖的范围给减少。代码虚拟化技术比较适合对关键的判断进行保护，而对于高频的循环，它是不适合的。

　　3、把保护手段分层使用

　　并不是所有的代码，都必须要用虚拟化这一种手段来保护。Obsidium软件还把代码和数据加密、运行时代码加密、字符串保护、完整性校验、许可证相关保护等功能给提供出来，不同的功能适合在不同的地方使用。

　　比较切合实际的做法是：把少量的代码虚拟化用在授权验证和核心算法上；普通的业务代码则被加密、压缩或者混淆类保护来处理；敏感的字符串可以使用字符串保护功能；关键的文件再配合上完整性校验。通过这种方式，保护的强度就能变得更均衡，也不容易把性能拉低得太明显。

　　4、对比保护前后的性能数据

　　在对性能问题进行排查的时候，未保护的版本、基础保护的版本，以及开启了虚拟化的版本，这三组程序最好都要被保留下来。启动的时间、关键功能的耗时、内存的占用以及CPU的占用情况，都要被分别进行测试。

　　三、实际配置时怎样平衡保护和运行速度

　　1、先保护“值钱的逻辑”

　　真正值得被虚拟化技术对待的，一般不是代码量最大的地方，而是最容易被别人绕过去、最能把软件价值体现出来的段落。比如授权的判断、核心算法的入口、关键参数的计算，还有版本权限的控制等。这些代码即使运行速度慢了一点，用户通常也是不容易明显察觉到的。

　　2、不要把虚拟化当成默认选项

　　有的开发团队会认为，既然代码虚拟化功能摆在那里，就应该把所有的东西都开启。这种想法并不是很妥当。虚拟化更像是一个笨重的工具，它被用在核心的位置上时是非常有价值的，但如果被用得太多了，启动的速度、运行的顺畅度以及后期的排查工作反而都会被负面影响。

　　3、建立两套保护配置

　　“测试配置”和“发布配置”这两套东西，是可以被同时准备出来的。测试配置里只把基础保护开启，它是被用来排查程序自身毛病的；而发布配置里，代码虚拟化、字符串保护以及许可证检查等内容才会都被加入进去。在后续的流程中，如果客户那边有异常被反馈过来，旧的配置也能被快速回退以进行对比。

　　总结

　　关于Obsidium代码虚拟化的正确使用方式，是将关键的函数进行少量且精准的保护，而不是把整个程序都盲目地全部虚拟化。在开启之前，版本是否支持、项目配置是否正常、目标程序的架构是否匹配，这些情况都要被确认；在开启的时候，要按照函数去逐步地进行测试。这样一来，保护的难度既能被提高，软件原本该有的正常运行速度也能被尽量保留。