WPF/Silverlight深度解決方案：(二)Silverlight源碼之自我保護

Silverlight應用程式發布時會將所有本地資源及類庫dll打包進xap檔案中，好處是可以非常方便的在網頁中部署及案頭化使用；但是同時帶來了高度的源碼泄露風險。眾所周知，xap檔案可以被zip等解壓軟體順利開啟，裡面的dll及各種素材資源一目瞭然； 然後通過****Reflector等工具即可完美的反編譯這些dll，就連xaml中的內容也能反射得一清二楚，這不禁讓我想起了Flash。網頁中的swf可以被眾多的下載工具下載，並利用類似**閃客精靈等工具反編譯得到甚至具體到每一幀，同樣的一切資源將變得毫無遮掩。

在法律體系健全的國家，對智慧財產權的保護是無微不至的；而在中國這個抄襲盛行的年代，我們該如何應對？

保護Silverlight源碼的最終目標只有一個：保護xap檔案。下面是一些我總結的保護方案，希望能對大家有所協助：

方法一：禁止關鍵檔案或檔案夾頁面緩衝

以IIS為例，我們可以將架設Silverlight應用程式的網站ClientBin目錄設定為禁止頁面緩衝：
   
    這樣，Silverlight應用程式ClientBin目錄下的xap檔案將不會被緩衝到如C:\Documents and Settings\Administrator\Local Settings\Temporary Internet Files目錄，其他人將無法通過瀏覽器緩衝拷貝出xap檔案。但是，通過“查看源檔案”並找到ClientBin/****.xap這句代碼，然後使用迅雷等下載工具將網頁地址+這句代碼粘貼進去，無論許可權及連接埠如何限制，均很難阻止xap檔案被下載的厄運；更重要的是，不緩衝將導致使用者每次訪問時均需要重新下載xap檔案，不僅增大了伺服器負擔，同時也是非常不友好體驗的表現。

方法二：使用Javascript加密關鍵的html部分代碼

為了不暴露ClientBin/****.xap這句代碼，我們可以做的事情有很多。例如禁止查看源檔案、禁止頁面另存新檔、禁止使用某些快速鍵及滑鼠右鍵等等，然而這樣做同樣是非常不友好的，且非常容易被破解，畢竟方法太過古老。這時我們不妨考慮使用一些欺詐手段：如使用Javascript加密html代碼。關於Javascrpit加密的方法非常之多，大家可以自行搜尋關鍵句：“Javascript加密解密”。其中最簡單且直接的方式就是使用JScript.Encode加密方式跟escape方式了：

    然後我們再偽造出一個假的xap載體控制項，最終的頁面將是如下代碼：

    大家注意看，僅僅是多了一行javascript代碼其他的幾乎一模一樣，從而成功的將真實的AK47.xap檔案偽裝成了假的Silver.xap檔案，甚至您還可以在ClientBin目錄下真實的放置一個亂七八糟的Silver.xap檔案，讓下載它的朋友一頭霧水，從而達到完美的代碼偽裝。

通過此方法可以騙過很多人（當然，看過我文章的朋友除外啦 ^ ^），甚至一些還沒怎麼接觸Silverlight的.NET高手；然而一旦遇到Javascript好手，escape這個單詞將立即暴露出html的偽裝本質，接著輕鬆的解密更易如反掌。

方法三：通過iframe+Javascript阻止使用者接觸到關鍵頁面

此方法需要準備一個額外的頁面作為首頁，該頁面使用iframe來載入包含有Silverlight應用程式的頁面，例如：

<iframe src="MyGame.aspx" width="820" height="580" frameborder="no" border="0"  />

並且，同樣的按照方法二的手段將之加密偽裝。接著就是此方法的關鍵，在MyGame.aspx頁面中添加如下一段Js：

<script type="text/javascript">

if (self.location == top.location) { self.location = "http://www.cnblogs.com/alamiye010" }

</script>

這種處理方式原理很簡單：通過判斷MyGame.aspx是否為子頁面來實現頁面保護。大家不妨直接在瀏覽器地址欄中輸入該頁面地址，將會發現頁面直接跳轉到了一個我們預先設定的頁面: http://www.cnblogs.com/alamiye010，從而達到了MyGame.aspx關鍵頁面不被直接開啟的目的。同樣的，大家可以將此方法結合方法一與方法二更深層次的進行頁面保護，就算用戶端使用者想盡一切辦法禁用了瀏覽器的Js，我們同樣可以將<object>…</object>這段內容在Behind代碼中的Page_Load方法中通過類似RegisterStartupScript方式來動態載入，從而使得<object>…</object>這段代碼與瀏覽器Js完美捆綁，你行我行，你禁我禁。

然而強中更有強中手，現在已經有很多工具或外掛程式可以直接提取頁面記憶體中的xap，可以輕鬆的將裡面的血肉乃至每一個細胞匯出得乾乾淨淨。這些傢伙的名字我真不想提，個人理解為這是對神聖技術的玷汙，它們的存在根本體現不了社會的進步，難道穿透別人的心臟能讓你感覺到無上的快感？

方法四：源碼混淆之乾坤大挪移

針對以上惡劣的恐怖主義行經，我們不得不使出殺手澗：傳統且最具防禦性的方法----代碼混淆。

.NET代碼混淆的工具有很多，VS中整合的Donfuscator Community Edition即是一款簡單且實用的代碼混淆工具：

    但是目前最新版本的Donfuscator Community Edition仍然無法直接對Silverlight發布的dll直接進行混淆處理，因為裡麵包含的xaml檔案資源讓其暫時表現得束手無策。當然還有第三方混淆工具可以使用的，例如：DeepSea，它可以直接混淆XAP檔案，很強大。下面是我通過反編譯軟體查看混淆後的Silverlight應用程式dll：


    不知道大家是否還能看得懂整個項目的架構與方法邏輯？ ^ ^

利用方法四，前面的3種方法均可以忽略不計，可謂Silverlight源碼的終極保護方案。然而，由於目前還沒有一款現成且非常成熟的針對Silverlight的混淆工具，這往往無形的增加了項目開發的工作總量。

下一節，我將為大家講解WPF/Silverlight應用程式效能最佳化與提升技巧，敬請關注。

作者：深藍色右手
出處：http://alamiye010.cnblogs.com/
本系列目錄及源碼下載：點擊進入(歡迎加入WPF/Silverlight小組　WPF/Silverlight部落格團隊)
本文著作權歸作者和部落格園共有，歡迎轉載。但未經作者同意必須保留此段聲明，且在文章頁面顯著位置給出原文串連，否則保留追究法律責任的權利。