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

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

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

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

一、定位問題的發生

在咱們出現問題的時候，每每須要定位在那個部分出現了錯誤，首先咱們在客戶端和服務端都須要進行跟蹤調試，首先咱們須要在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控制器反序列化對象的時候丟掉值的可能，而是客戶端根本沒有提交數據過來。

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

那麼咱們回到對刪除操做的統一處理方法裏面看看，有Delete和Delete2操做相似，分別對應不一樣類型處理。

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

以權限系統模塊，用戶刪除操做爲例，它的界面端處理代碼以下所示。

 以上代碼我增長了一行用來記錄是否得到ID的內容的，經過日誌記錄，能夠看到有ID傳遞給接口處理了。

 這樣看到，問題出如今接口的處理裏面，也就是可能因爲我對DLL採用了混淆操做，致使的匿名類解析出現了問題了。

咱們首先重寫一下具體類的刪除接口操做，跟蹤一下問題。

 

  爲了有效驗證咱們的問題出如今這裏，咱們對比勾選和取消了紅色勾選，編譯後的代碼進行測試。

對比處理結果，咱們能夠看到混淆先後，接口得到的數據不一樣，所以能夠知道是混淆致使匿名類處理出現了問題。

 因而，咱們對全部相關的DLL，取消對應的這個混淆選項，運行能夠獲得正確的結果。

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

因爲對DLL混淆致使的錯誤問題，通常來講不易推斷，因此儘量多的列出可能影響的因素，逐一測試解決，慢慢縮小範圍便可得到解決問題的辦法。