配置文件中的数据库连接串加密了，你以为我就挖不出来吗？
一：背景
1. 講故事
前幾天在調試物聯柜終端上的一個bug時發現 app.config 中的數據庫連接串是加密的，因為調試中要切換數據庫，我需要將密文放到專門的小工具上解密，改完連接串上的數據庫名，還得再加密貼到 app.config 中，煩的要死，內容如下：
<appSettings><!-- 數據庫連接字符串 --><add key="OLEDBConnStr" value="XfES27am6Muw48iB1GlMVqvUbq7/Pp9n4XbZJsDu19YDr/Zdb3m7KT6haD7f9HLj/ZEvIiZbmSU4O5L9g03Y5IUB6KLCZI7s3nDLwTIC+bXLf5quu/r8ZAI+rgNnsNZdwoDfquRLQy5Cf2X8/MFDOcMNaZYMpTYeHsZoEERU/TP9t3n5QllJTihrmDFbiGHLqe1kfN3uB3g1kgs0oobIEfNPr09kQ/pFgzZi/kZCrK10PLZZ0pFj1YU5ReFqBsdBlecV3D2Zl3lx1Ibls24t7w==" /></appSettings>改完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）
上面的?MethodDesc: 08ed83b0?就是方法描述符的地址。
使用 !dumpmd 導出方法描述符的詳細信息，找到 OleDbHelper類型對象 的 EEClass 地址
上面的?Class: 08ecab30?就是 OleDbHelper類型對象 在堆上的內存地址。
使用 !dumpclass 導出?Class: 08ecab30?，從而找到 OleDbHelper類的靜態字段
從上面導出信息中可以看到 OleDbHelper類中 有兩個靜態字段：?ConnectionString?和?SecurityConnectionString。
使用 !do 打印出兩個靜態字段
看到沒有，上圖中的兩個紫色框框就是明文的 ConnectionString 哈，怎么樣？????不????。
四：總結
當認識到上面的兩種脫庫方式，你應該就能想到，其實你在程序中連接數據庫，這本身就是一種錯，操作系統都能給你盜版，何況你這區區一個小軟件？個人覺得完全杜絕的方式那應該就是：滅掉本地的sqlserver，讓所有的數據獲取都由遠端的 webapi 提供，當然這又是在脫離業務聊技術啦！????????????
總結
以上是生活随笔為你收集整理的配置文件中的数据库连接串加密了，你以为我就挖不出来吗？的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Azure认知服务之表单识别器
- 下一篇： Dotnet Core Public A