189 8069 5689
这篇文章主要介绍“如何解决配置文件中的数据库连接串加密了问题”，在日常操作中，相信很多人在如何解决配置文件中的数据库连接串加密了问题问题上存在疑惑，小编查阅了各式资料，整理出简单好用的操作方法，希望对大家解答”如何解决配置文件中的数据库连接串加密了问题”的疑惑有所帮助！接下来，请跟着小编一起来学习吧！
成都创新互联公司拥有一支富有激情的企业网站制作团队，在互联网网站建设行业深耕10年，专业且经验丰富。10年网站优化营销经验，我们已为上千多家中小企业提供了成都网站制作、做网站解决方案，按需求定制制作，设计满意，售后服务无忧。所有客户皆提供一年免费网站维护!
一：背景
1. 讲故事
前几天在调试物联柜终端上的一个bug时发现 app.config 中的数据库连接串是加密的，因为调试中要切换数据库，我需要将密文放到专门的小工具上解密，改完连接串上的数据库名，还得再加密贴到 app.config 中，烦的要死，内容如下：
改完bug之后，我就想这玩意能防的了谁呢?私以为搞这么麻烦也就防防君子，像我这样的 晓人，加不加密都是等于没加密，照样给你脱库。。。???
二：使用 ILSpy 去脱库
1. 从DAL/Repository层去反编译代码
要想得到明文的数据库连接串，可以从代码中反推，比如从 DAL 或者 Repository 中找连接串字段 ConnectionString，我这边的终端程序是用 wpf 写的，采用的是经典的三层架构，所以在 bin 下可以轻松找到，如下图：
接下来用 ILSPy 反编译这个 dll。
从上图中可以看出，连接串的明文是存放在: OleDbHelper.ConnectionString 中的，然后可以看到，程序中定义了一个 Decrypt 方法专门用来解密连接串，哈哈，有了这个算法，是不是就可以脱库啦???如下代码所示：
class Program { static void Main(string[] args) { var str = "XfES27am6Muw48iB1GlMVqvUbq7/Pp9n4XbZJsDu19YDr/Zdb3m7KT6haD7f9HLj/ZEvIiZbmSU4O5L9g03Y5IUB6KLCZI7s3nDLwTIC+bXLf5quu/r8ZAI+rgNnsNZdwoDfquRLQy5Cf2X8/MFDOcMNaZYMpTYeHsZoEERU/TP9t3n5QllJTihrmDFbiGHLqe1kfN3uB3g1kgs0oobIEfNPr09kQ/pFgzZi/kZCrK10PLZZ0pFj1YU5ReFqBsdBlecV3D2Zl3lx1Ibls24t7w=="; Console.WriteLine(Decrypt(str)); } public static string Decrypt(string str) { if (!string.IsNullOrEmpty(str)) { DESCryptoServiceProvider descsp = new DESCryptoServiceProvider(); byte[] key = Encoding.Unicode.GetBytes("Oyea"); byte[] data = Convert.FromBase64String(str); MemoryStream MStream = new MemoryStream(); CryptoStream CStream = new CryptoStream(MStream, descsp.CreateDecryptor(key, key), CryptoStreamMode.Write); CStream.Write(data, 0, data.Length); CStream.FlushFinalBlock(); return Encoding.Unicode.GetString(MStream.ToArray()); } return ""; } }
不过还好，数据库也是在客户那边独立部署的，不存在走外网的情况，不然就玩大了。。。接下来我们来看看如何去防范。
2. 加壳/混淆/加密狗
现在市面上商业版和免费版都提供了给C#代码进行加密和混淆，不过我没用过，我想最多在反编译代码后阅读性上增加了一些障碍，这也不过是时间问题罢了，毕竟SqlConnection，SqlCommand 这些FCL的类你是没法混淆的，我从这些类上反推可以很轻松的就能找到明文的 ConnectionString ，所以这条路我觉得是走不通的。
3. 将解密算法放在 server 端
既然 解密算法 埋在客户端你都能挖出来，那把它放在 server 端不就可以啦?在程序启动的时候，调用一下 webapi 进行解密，这样你总没辙了吧 ???哈哈，大家可以开动脑子想一想，这种方法可行不可行?诚然，解密算法搬走了，再用 ILSpy 去挖已经没有任何意义了，但这里有一个重要突破点，不管是用什么形式解密的，最后的连接串明文都是存放在 OleDbHelper.ConnectionString 这个静态变量中，对吧!接下来的问题就是有没有办法把进程中的这个静态变量给挖出来?你说的对，就是抓程序的 dump文件 用 windbg 去挖。
三：使用 windbg 去脱库
1. 思路
要想挖出 OleDbHelper.ConnectionString，其实也很简单，在 CLR via C# 第四章中关于对象类型和类型对象的解读有这么一张图，很经典。
从上图中可以看到，静态字段是在 Manager 类型对象 中，实例字段都是在 Manager 对象 中，对照这张图，我只需要通过 windbg 找到 OleDbHelper 类型对象，也就是所谓的 EEClass。
2. windbg 挖矿实战
使用 !name2ee 找到 Decrypt 方法描述符(MethodDesc)
0:000> !name2ee xxx.Utilities.dll xxx.Utilities.Database.OleDbHelper.Decrypt Module: 08ed7cdc Assembly: xxx.Utilities.dll Token: 060002aa MethodDesc: 08ed83b0 Name: xxx.Utilities.Database.OleDbHelper.Decrypt(System.String) JITTED Code Address: 048b6af0
上面的 MethodDesc: 08ed83b0 就是方法描述符的地址。
使用 !dumpmd 导出方法描述符的详细信息，找到 OleDbHelper类型对象 的 EEClass 地址
0:000> !dumpmd 08ed83b0 Method Name: xxx.Utilities.Database.OleDbHelper.Decrypt(System.String) Class: 08ecab30 MethodTable: 08ed8468 mdToken: 060002aa Module: 08ed7cdc IsJitted: yes CodeAddr: 048b6af0 Transparency: Critical
上面的 Class: 08ecab30 就是 OleDbHelper类型对象 在堆上的内存地址。
使用 !dumpclass 导出 Class: 08ecab30 ，从而找到 OleDbHelper类的静态字段
0:000> !dumpclass 08ecab30 Class Name: xxx.Utilities.Database.OleDbHelper mdToken: 02000033 File: D:\code\A18001\Source\Main\TunnelClient\bin\Debug\xxx.Utilities.dll Parent Class: 795115b0 Module: 08ed7cdc Method Table: 08ed8468 Vtable Slots: 4 Total Method Slots: 6 Class Attributes: 100081 Abstract, Transparency: Critical NumInstanceFields: 0 NumStaticFields: 2 MT Field Offset Type VT Attr Value Name 799bfd60 4000152 74 System.String 0 static 04c28270 ConnectionString 799bfd60 4000153 78 System.String 0 static 04c299e8 SecurityConnectionString
从上面导出信息中可以看到 OleDbHelper类中 有两个静态字段： ConnectionString 和 SecurityConnectionString。
使用 !do 打印出两个静态字段
看到没有，上图中的两个紫色框框就是明文的 ConnectionString 哈，怎么样??不?。
到此，关于“如何解决配置文件中的数据库连接串加密了问题”的学习就结束了，希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习，快去试试吧！若想继续学习更多相关知识，请继续关注创新互联网站，小编会继续努力为大家带来更多实用的文章！