.Net 4.7.2 WPF应用代码防逆向防篡改解决方案咨询

1、是否推荐使用.Net Reactor做代码防护 #

可以根据你的防护目标决定：

• 如果防护目标是普通逆向爱好者、小体量破解者：完全推荐。最新版.Net Reactor的公开脱壳工具极少，配合它自带的控制流混淆、字符串加密、native 层封装等多档防护规则开启后，绝大多数非专业人员无法完成脱壳和逆向，性价比很高。
• 如果防护目标是有专业逆向团队的商业竞争对手：不建议仅依赖.Net Reactor单一层防护。它本质仍是.NET平台专属保护壳，资深逆向人员有概率完成脱壳还原代码，需要搭配其他防护方案组合使用。

2、除代码混淆、AOT外的防逆向有效方案 #

原生代码转换类适配方案 #

.Net Framework 4.7本身不支持官方AOT，但可以通过以下方式实现核心逻辑原生编译：

• 把核心加密校验逻辑单独抽离，用C/C编写后编译为原生x86/x64动态库，WPF端通过P/Invoke方式调用。原生编译的C/C库逆向门槛远高于.NET程序集，哪怕整个.NET端被脱壳，核心加密逻辑也很难被逆向还原，是该框架下最成熟的核心逻辑防护方案，兼容性完全适配4.7.2版本。
• 配合系统自带的Ngen.exe（原生映像生成工具）把整站程序集预编译为本地镜像，搭配代码混淆和加壳使用，能进一步提高逆向解析的门槛。

其他落地性强的防逆向路径 #

• 加密逻辑拆分部署：不要把完整加密校验逻辑都放在客户端，拆出1-2个关键校验步骤放在服务端执行，客户端加密后的请求必须经过服务端的校验步骤才能返回合法响应，哪怕客户端逻辑被完全逆向，仿造服务也无法走完完整校验流程，从根源上避免被对接仿造服务倒卖。
• 多节点运行校验：在业务流程的不同节点分散埋入校验逻辑，包括校验程序集签名、哈希值，以及当前对接的服务端证书指纹、域名哈希，一旦检测到程序被篡改、服务URL被替换，直接终止运行或者返回无效加密结果，避免被逆向人员一次性找到校验逻辑批量Patch。
• 白盒加密实现替换：如果用到对称加密类算法，直接改用白盒加密实现，哪怕逆向人员拿到完整代码，也无法提取出加密密钥，逆向出来的逻辑也无法直接复用开发仿造服务。

内容的提问来源于stack exchange，提问作者Abu Bakar