准备的工具：
.NET Reactor破解他，当然要先安吵消装先下载地址：
.NET Generic Unpacker和SNSRemover，用来脱掉Reactor本身的壳和去去掉强名称
Reflector，这个不用说州碰信了吧…
十六进制编辑器，主要有查找、替换和保存功能就OK了。
我们安装完Reactor，发现他不是.NET程序，直接用Reflector不能反编译他，这时候我们就要用.NET Generic Unpacker，将Reactor的壳脱掉如图1。
（图1 对Reactor进行脱壳）
每次脱出来的数量都不一定相同的。好了，我们用Reflector打开他看看，如图2
（图2 用Reflector对Reactor进行反编译）
这时候，我们发现混淆后的类名竟然是乱码，这个没所谓，ilasm是支持乱码的，是不是我们也可以用ildasm进行反编译，然后修改他的代码，然后用ilasm将他重新编译呢？理论上是可以，但实际上由于反编译出来的资源文件的文件名是乱码，ilasm没办法找到那些文件，编译会失败。那怎么办，那就直接修改原程序的了。
首先用SNSRemover去掉他的强名称先。
（图3 用SNSRemover去掉Reactor的强名称）
现在你是不是有这个疑问，本来脱出来的程序就已经不能运行的了，现在去掉了强名称后，反而运行起来会提示出错。不用怕，试一下用原版的Reactor对现在去掉强名称后的Reactor进行一次加密。将加密出来的程序放在Reactor目录下运行。
（图4 重新加密后运行时发生的错误）
哈哈，看到是什么错误没有？现在这个已经不是验证强名称错误了，是一个运算错误，是某数除于0时时发生的错误。再看看他发生错误是在那里，我们通过Reflector来找出–v. –c..cctor()这个方法,由于Reactor他本身是经过混淆的，已经不能用C#来反编译，新版也做出了新的混淆，就算去掉了
L_0000: br L_0007
L_0005: pop
L_0006: ldc.i4.0
这三段代码，也不能用C#来反编译，我们只能用IL了。
（图5 用Reflector找出发生异常的方法）
熟悉IL的就会知道，除的命令是div，那我们就在这里里面搜索div，发现这段代码：
L_004f: ldc.i4 0x10
L_0054: stloc.s num
L_0056: ldloc num
L_005a: ldloc num
L_005e: sub
L_005f: conv.u1
L_0060: stloc.s num
L_0062: ldloc num
L_0066: ldloc num
L_006a: div
L_006b: conv.u1
L_006c: stloc.s num
看到这里应该知道了吧,将他换成C#的代码应该是
num = 0x10
num = num - num
num = num / num
知道错误的原因了，那我们将这个div改掉就行了，但有一个问题，为什么原版的程序就不会发生这个问题？原因很简单，你搜索一下GetPublicKeyToken()，你就会发现上面那段代码是他验证强名称失败时才会执行的，因为我们去掉了强名称，所以肯定会执行那段代码的。
我们知道了出错的原因了，但我们怎样改呢？方法很简单，因为Reflector他有提示该代码对应的十六进制，
（图6 找册轮出该代码对应的十六进制）
这时候我们是不是该想一下，其他的方法里是不是也同样也有这样的验证。好，我们随便找几个方法，发现有些方法是有，有些是没有。但有些的IL代码不一样，有点区别如：
L_003b: ldc.i4 0x24
L_0040: stloc.s num
L_0042: ldloc.s num
L_0044: ldloc.s num
L_0046: sub
L_0047: conv.u1
L_0048: stloc.s num
L_004a: ldloc.s num
L_004c: ldloc.s num
L_004e: div
L_004f: conv.u1
L_0050: stloc.s num
但运行出来的效果是一样的，只不过是他对应的十六进制不一样而已
（图7 ldloc.s对应的十六进制）
好了，如果我们一个个方法都要去看，那花的时间太多了，不如我们先处理掉一部分先，如果再发现那里的错误，我们就去那里找出来。
我们很容易通过Reflector可以知道这两段代码对应的十六进制应该是
FE0C0000FE0C000059D21300FE0C0000FE0C00005BD213和1100110059D21300110011005BD213
从Reflector那里我们可以知道，sub对应是59，div对应是5B，那我们将5B换成59那程序就不会发生异常了，用十六进制编辑器，替换FE0C0000FE0C000059D21300FE0C0000FE0C00005BD213为FE0C0000FE0C000059D21300FE0C0000FE0C000059D213，替换1100110059D21300110011005BD213为1100110059D213001100110059D213
（图8 替换代码）
现在我们又用原版的Reactor重新加密一次我们刚处理完的文件。发现现在可以正常运行了。
我们已经可以正常运行我们脱壳后的程序了，现在开始我们就要将他变成正式版。
用Reflector打开我们刚处理完的文件，使用Reflector自带的功能，跳到程序的入口点
（图9 找到入口点）
分析一下程序的，不难的可以找到
L_0662: call bool –v.–c::‘2()
这段代码就是验证的代码了，但如果在这里直接修改，难度会相当大，不如我们修改‘2()的返回值，只要他永远返回true，那就达到我们的目的了。
（图10 来到‘2()）
我们不难的找到了L_0000: br L_0007对应的地址是0x17cd28,将原来的3802改成172A
（图10 修改3802为172A）
保存后，我们在次用原版的Reactor对刚处理完的程序进行加密，将加密后的程序放在Reactor目录下运行。看看，现在是FULL VERSION了，但我们现在测试一下他，会发现出现这样的异常
（图11 修改完，运行出现的异常）
看一下他的异常，还是System.DivideByZeroException，也就是说还有一部分的强名称验证的代码还没有修改，只要重复上面的 *** 作，找出他的十六进制，将5B换成59就行了。
该版本我已经发布了他的破解版，3.3.8.0也已经发布了，3.3.8.0的破解会比这个更难，有兴趣的朋友可以来研究一下，可以拿3.3.8.9版来试一下，这个跟3.3.8.0是一样的破解。..
使用“RSAProtectedConfigurationProvider”形式来加密test.aspx程序文件基本如上，
把
section.SectionInformation.ProtectSection(“DataProtectionConfigurationProvider”)
改成
section.SectionInformation.ProtectSection(“RSAProtectedConfigurationProvider”)
但这个时候你差山访问网站的时候很有可能会出现
说明:
在处理向该请求提供服务所需的配置文件时出错。请检查下面的特定错误详细信息并适当地修改配置文件。
分析器错误信息: 未能乎庆清使用提供程序“RsaProtectedConfigurationProvider”进行解密。
提供程序返回错误信息为: 打不开 RSA 密钥容器。
这样岁前的错误,解决方法是：
进dos运行：aspnet_regiis -pa “NetFrameworkConfigurationKey”
“NT AUTHORITY\NETWORK SERVICE”
如果运行出错，需要把目录 C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727
放入环境变量path中。此时就可以成功访问网站了。
同样可以通过命令行来实现“RSAProtectedConfigurationProvider”加密
注意：你也可以不运行 aspnet_regiis -pa “NetFrameworkConfigurationKey”
“NT AUTHORITY\NETWORK SERVICE”命令来注册默认的
RsaProtectedConfigurationProvider 的RSA 密钥容器
方法如下：
1）创建一个可导出的rsa密钥容器，命名为Key
aspnet_regiis -pc “Key” -exp
2）在你要加密的信息前面指定密钥容器，如：
<configProtectedData><providers><clear /><add name=”KeyProvider” type=”System.Configuration.RsaProtectedConfigurationProvider, System.Configuration, Version=2.0.0.0,Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL” keyContainerName=”Key” useMachineContainer=”true”/></providers></configProtectedData><connectionStrings><add name=”SQLConnString” connectionString=”Data Source=yourIPInitial Catalog=testUser Id=yourIDPassword=yourPassword”providerName=”System.Data.SqlClient” /></connectionStrings>
并且确保在configuration节的xmlns属性有如下值：
3）对配置文件进行加密
aspnet_regiis -pef “connectionStrings” “E:\project\Test” -prov “KeyProvider”
参数分别为：需要加密的配置节、项目所在目录的物理路径、加密所使用的密钥容器名称
再看web.config文件，就会发现connectionStrings节已经被加密了，但
是运行程序会发现程序仍然可以正确访问数据库。
此时，只需运行：
aspnet_regiis -pdf “connectionStrings” “E:\project\Test”
就可以对web.config文件进行解密。
（注意，如果还是有错误，那可能是您没有给生成的密匙文件足够的权限，
去到C:\Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\MachineKeys
目录下，找到刚生成的密匙文件，把network service用户的读取权限赋予给它，就可以了，
直接用命令的话也可以：命令如下 aspnet_regiis -pa “Key” “NT AUTHORITY\NETWORK SERVICE” ，
可能需要重新启动iis
4）把密钥容器导出为xml文件
aspnet_regiis -px “Key” “e:\Key.xml”
这个命令只导出公钥，因此以后只能用于加密，而无法解密。
aspnet_regiis -px “Key” “e:\Keys.xml” -pri
这个则连私钥一起导出了，所以我们要用这个。
5）把密钥容器删除
aspnet_regiis -pz “Key”
删除后再运行程序，会提示出错：
分析器错误信息: 未能使用提供程序“KeyProvider”进行解密。
提供程序返回错误信息为: 打不开 RSA 密钥容器。
同理可以证明，在任何一台未安装正确的密钥容器Key的机器上，
程序都无法对connectionStrings节进行解密，因此也就无法正常运行。
6）导入key.xml文件
aspnet_regiis -pi “Key” “e:\Keys.xml”
此时，再运行程序会发现又可以解密了。证明加密与解密机制运行正常。
最后说一下这个机制所提供的安全性保障可以运用在什么方面：
对winform程序的app.config进行加密实际意义并不大，因为无论如何，
客户机都可以通过运行aspnet_regiis -pdf 来对配置文件进行解密，从而暴露敏感信息。
对于web.config进行加密的意义也仅限于，当web.config文件不小心泄露时，
不会同时泄露敏感信息，如果恶意攻击者已经取得了在服务器上运行程序的权限，
那么同app.config一样，可以很容易通过通过运行aspnet_regiis -pdf 获取明文了。
还有，通过aspnet_regiis -pa “Key” “NT AUTHORITY\NETWORK SERVICE”
控制对不同用户对密钥容器的访问权限，应该还可以进一步获取一些安全性，
比如可以控制某些用户即使登录到服务器上，也无法用aspnet_regiis -pdf对配置文件进行解密。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）