.Net Reactor混淆導致匿名類處理出現的問題處理分析

.Net Reactor 是一款比較不錯的混淆工具，比VS自帶的那個好用很多，一直以來也陪伴著我們的成長，雖然沒有完美的混淆工具，不過也算還是不錯的，至少能在一定程度上對DLL進行一定的保護處理。

不過最近客戶反映我們在混合框架刪除操作的時候，沒有如期的實現刪除操作，由於混合框架是基於Web API / WCF這樣的分散式開發方式，因此和普通跟蹤的方式有所不同，針對Web API的使用是比較廣泛的在雲端實現數據集中管理的一種方式，相對普通的調試來說，難度增加了一些，需要在服務端（本篇主要是Web API操作）進行調試，以及在客戶端界面進行聯合調試處理。

本篇隨筆主要介紹如何在碰到基於分散式處理數據的介面的時候，對錯誤問題的分析和逐步縮小範圍的方式進行排查，最終解決問題的分析處理過程。

1、定位問題的發生

在我們出現問題的時候，往往需要定位在那個部分出現了錯誤，首先我們在客戶端和服務端都需要進行跟蹤調試，首先我們需要在Web  API 層跟蹤對應的控制器操作是否獲得對應要刪除記錄的ID值。

我們前面功能測試的時候，發現所有刪除操作都出現了無法刪除的問題，因此很可能是沒有傳遞ID值，或者轉換過程中出現了問題。

我們伺服器端的刪除操作介面如下所示。

        /// <summary>
        /// 根據指定對象的ID,從資料庫中刪除指定對象(用於整型主鍵)
        /// </summary>
        /// <param name="key">指定對象的ID</param>
        /// <returns>執行成功返回<c>true</c>，否則為<c>false</c>。</returns>
        [HttpPost]
        public virtual CommonResult Delete(KeyInfo keyInfo, string token, string signature, string timestamp, string nonce, string appid)
        {
            //檢查用戶是否有許可權，否則拋出MyDenyAccessException異常
            base.CheckAuthorized(AuthorizeKey.DeleteKey, token, signature, timestamp, nonce, appid);

            CommonResult result = new CommonResult();
            try
            {
                if (keyInfo != null)
                {
                    result.Success = baseBLL.Delete(keyInfo.id);
                }
            }
            catch (Exception ex)
            {
                LogTextHelper.Error(ex);//錯誤記錄
                result.ErrorMessage = ex.Message;
            }
            return result;
        }

其中的KeyInfo類是我們定義的一個實體類，定義代碼如下所示。

    /// <summary>
    /// 用於刪除的ID對象
    /// </summary>
    [Serializable]
    public class KeyInfo
    {
        /// <summary>
        /// ID主鍵
        /// </summary>public object id { get; set; }
    }

我們在調試Web API控制器的時候，無法獲得KeyInfo參數的值，如下界面所示。

 那麼可能KeyInfo無法被反序列化，又或者是KeyInfo沒有傳遞過來，我們跟蹤對應的介面，方向本來應該在客戶端POST提交的ID信息，無法提交過來。

這個是針對客戶端提交操作的抓包處理，本來想用Fiddler來抓取的，不過Fiddler好像無法直接抓取localhost的請求包體，通過代理設置沒有處理成功，改用以前用的很順手的 HttpAnalyzer，直接運行就可以抓取了，非常方便。

通過上面的操作，我們發現數據沒有提交到控制器裡面，因此排除Web API控制器反序列化對象的時候丟掉值的可能，而是客戶端根本沒有提交數據過來。

2、定位具體的值丟失位置

那麼我們回到對刪除操作的統一處理方法裡面看看，有Delete和Delete2操作類似，分別對應不同類型處理。

 我們發現這裡的處理，是直接把ID傳遞過來構建一個匿名對象，然後序列化為JSON字元串提交給Web API控制器處理的。在界面上主要就是通過統一調用進行刪除的，傳遞ID給對應介面進行處理的。

以許可權系統模塊，用戶刪除操作為例，它的界面端處理代碼如下所示。

 以上代碼我增加了一行用來記錄是否獲得ID的內容的，通過日誌記錄，可以看到有ID傳遞給介面處理了。

 這樣看到，問題出現在介面的處理裡面，也就是可能由於我對DLL採用了混淆操作，導致的匿名類解析出現了問題了。

我們首先重寫一下具體類的刪除介面操作，跟蹤一下問題。

  為了有效驗證我們的問題出現在這裡，我們對比勾選和取消了紅色勾選，編譯後的代碼進行測試。

對比處理結果，我們可以看到混淆前後，介面獲得的數據不同，因此可以知道是混淆導致匿名類處理出現了問題。

 於是，我們對所有相關的DLL，取消對應的這個混淆選項，運行可以得到正確的結果。

 以上就是我們對這個.Net Reactor混淆導致匿名類處理出現的問題處理分析，其中主要涉及到了客戶端localhost地址的本地抓包處理，採用了比較方便易用的HttpAnalyzer來分析是否數據提交有問題，還是數據解析出現問題，定位問題的邊界，然後逐步對界面和介面部分進行分析。

由於對DLL混淆導致的錯誤問題，一般來說不易推斷，所以儘可能多的列出可能影響的因素，逐一測試解決，慢慢縮小範圍即可獲得解決問題的辦法。