Agile.NET控制流保护的配置工作，以及该保护引起的异常的解决办法，这些问题在实际操作中，往往比字符串加密还要更容易让人遇到困难。控制流保护这种手段并不是去修改名称，而是把本来能够顺着阅读的代码路径，通过技术手段修改成更曲折的结构，这样一来，反编译工具所呈现出来的逻辑就不再那么清晰了。Agile.NET这个工具的控制流混淆功能，可以将原本的代码流程，转变成一种在意思上相同、但是在结构上更加复杂的形态，其目的就是为了让别人在进行逆向分析时遇到更多困难。

　　一、Agile.NET控制流保护怎么配置

Agile.NET这款软件本身具备了多种保护层次，其中包括类名方法名、资源、用户字符串、方法实现，以及系统与库调用等，同时它也支持用户对混淆的过程进行控制。在具体的实践过程中，控制流保护这种功能，其实更加适合被应用在核心的业务逻辑、授权的校验工作、算法的判断，以及关键的计算方法之中。

　　1、先准备可运行的Release版本

　　开发人员需要先利用Release模式来把程序编译出来，并且将这个没有经过混淆的版本完整地运行一次，从而去确认软件的启动、用户的登录、授权的通过、主要界面的显示、数据库的连接，以及接口的调用是不是都处于正常状态。这个未混淆的版本必须要被单独保存起来，因为如果后面在混淆之后遇到了问题，大家才可以拿这个版本来当成对照的工具。

　　2、只选择自研程序集

　　在操作时，需要把主程序exe文件以及自己开发的业务dll文件放进Agile.NET的项目当中。至于那些第三方的控件、数据库的驱动、硬件的SDK、报表相关的组件，还有加密狗的接口库等，一般来说，这些文件最好不要直接参与到控制流保护里面去；因为它们自己内部可能带有签名校验，或者存在反射调用、运行时动态生成代码的情况，若是强行对它们进行处理，反而会很容易导致系统出现异常。

　　3、开启【Control Flow Obfuscation】

　　在软件的保护选项界面里，需要把【Control Flow Obfuscation】或者对应的控制流保护选项给勾选上。在第一次进行尝试的时候，建议大家选择低等或者中等的保护强度，先不要把代码虚拟化、资源加密还有字符串加密这些功能同时叠加在一起使用；在Agile.NET的官方说明文档中，控制流混淆也被归类为代码保护的一个组成部分，它起到的作用主要是把程序原有的流程信息给隐藏起来，而不是用来代替所有其他的保护手段。

　　二、Agile.NET控制流保护导致异常怎么处理

　　当控制流保护导致系统产生异常的时候，大家不要立刻就去怀疑所有的混淆配置都做错了。因为更加普遍的情况，往往只是其中的某一个方法不适合被修改，或者是控制流保护和某种运行时的机制产生了冲突。在进行排查的时候，应该把问题的范围缩小，具体去确定是“哪一个程序集、哪一种保护类型，或者是哪一个具体的方法”出了问题。

　　1、先确认异常是不是控制流保护引起的

　　利用同一份Release代码包，可以生成出两个不同的版本：其中一个版本不开启控制流保护，只开启最基础的名称混淆；而另一个版本则在这个基础上，额外把控制流保护给打开。如果前者在运行的时候是正常的，而后者却出现了异常，那么这时候就可以初步判定，问题是由控制流保护所引起的；大家在测试时不要同时开启太多的保护选项，否则后面会很难找出问题所在。

　　2、看异常类型和发生阶段

　　如果系统在启动的阶段就直接崩溃了，那么就需要重点去查看入口方法、依赖注入的注册、配置文件的读取、插件的扫描、授权的校验，以及主窗口的初始化部分。如果是用户在点击了某一个功能之后程序才报错，那就需要重点去检查这个功能所涉及到的方法调用链；在实际情况中，常见的异常包括InvalidProgramException、VerificationException、TypeLoadException、TargetInvocationException，以及MissingMethodException等，有时候问题也会表现为界面卡死、逻辑判断出错或者程序直接闪退。

　　3、优先排查异步和迭代器方法

　　在C#语言里面，async/await以及yield return这些语法，在编译时会由编译器自动生成状态机。如果控制流保护再去对这些方法进行修改，在某些项目当中，就会很容易引发状态机的异常、堆栈的异常，或者是导致调试信息变得不清晰；遇到这一类情况的时候，建议先把异步的入口、后台的任务、定时器的回调，以及数据流的处理方法给排除在外，之后再去慢慢地恢复。

　　三、控制流保护发布前要重点检查什么

　　当控制流保护配置完成以后，大家不能只看程序能不能被打开。因为很多隐患并不是在启动的时候就会暴露出来，而是在执行某一个业务按钮、调用某一个接口，或者是在某个特定的客户环境下才会出现；所以，在软件发布之前，最好是要认真地进行一轮固定的检查工作。

　　1、检查核心业务路径

　　像登录功能、授权功能、创建项目、打开文件、保存数据、导入和导出、打印操作、数据库的读写，以及接口的请求等，这些核心的路径都需要亲自去跑一遍。如果仅仅是测试一下主界面能不能打开，这样的测试是没有太大实际意义的。

　　2、检查不同运行环境

　　同一个混淆出来的安装包，最好能够同时在开发用的电脑以及干净的测试电脑上都运行一次。因为开发用的电脑里面带有完整的SDK、调试组件以及依赖项的缓存，而客户的电脑上却不一定会有这些东西；有时候控制流保护本身并没有问题，但由于发布包里面缺少了某些依赖，就会导致问题被误判成混淆引起的异常。

　　3、检查签名和打包流程

　　如果程序集本身带有强名称签名、安装包签名，或者设计了自动更新的校验机制，那么在混淆结束之后，必须确认签名流程有没有重新被执行一次。由于方法体已经被改写了，所以原来生成的签名或者校验结果，很有可能就已经不再适用了；在发布的时候，通常需要按照“编译、混淆、签名、再打包”的先后顺序来进行处理，大家千万不要把这个顺序给弄反了。

总结　　

关于Agile.NET控制流保护的配置，核心的关键就在于不要大面积地盲目去开启，而是应该先选中自己开发的程序集，然后再从低强度开始尝试，并且对入口、异步、反射、异常处理，以及第三方框架调用等高风险的代码做好排除工作。而对于Agile.NET控制流保护引发异常的处理，大家也不应该靠主观去猜测，而是应当通过版本之间的对照、观察异常日志、逐个开关选项，以及在方法级别进行排除等方法来进行定位。控制流保护如果运用得当，确实可以显著地提升代码被分析的难度。