關於源代碼的保護.Windows phone在2010年10月份發布第一個RTM版本時. 相信國內最早進入Windows phone開發者都應該知道.在2010年11月Windows phone剛剛發布一個多月時.國外的一個網址為winmobile7.apphab.com的網站不知用什么方法獲得了微軟官方MarketPlace應用的直接下載地址，當時直接導致很多WP7的游戲和應用的.XAP安裝包被泄露出去.當然那個時候應用量才3000多個.這對於剛剛推出Windows phone平台不久即遭到開發者知識產權保護漏洞.那時開發者還不多.但也在一定程度照成開發者對於微軟平台安全性遭到質疑和不信任.
Windows phone同樣也是采用XAP安裝包.而XAP其實可以通過強制修改文件格式轉換成.rar.即可以通過解壓工具獲取XAP打包的DLL文件.通過逆向工程反編譯工具.NET REflector是可以查看到源代碼的.
當然官方團隊意識到這個問題.很快完善修補該漏洞.並對於.XAP安裝包中的文件可被直接破解反編譯的問題.對開發者提出可以使用Dotfuscator這類的代碼混淆工具來保護自己的源代碼.即使XAP在第三方情況被惡意破解泄露.但也不會至源碼會被直接暴漏出來.
針對這個問題微軟官方很快就在2010年11月6日就宣布PreEmptive Solutions 合作推出 Runtime Intelligence for Windows Phone，這是一款面向 Windows Phone 7 的應用統計與分析工具.在2011年PreEmptive Solutions也相繼推出專門針對Windows phone 應用程序源碼混淆的免費工具PreEmptive Protection For Windows phone 7.
本篇將從Dotfuscator工具的角度來切入Windows phone應用的源碼保護.
<1>源碼保護現狀
源碼保護這個已經不是什么新鮮主題..NET CLR的出現.衍生出Native Code和Managed Code[一說托管代碼].執行在 .Net CLR 環境下的應用程序都是屬於 Managed Code 的范圍，而 Managed Code 在編譯時會先編譯成 MSIL (Microsoft Intermediate Language)，實際執行時交由 JIT (Just-In-Time) 編譯成機器碼之后執行，而由於架構上的變更，MSIL (也就是我們的 .Net exe、dll 檔案等) 是比較容易被反編譯.[該段落引用自Wikipedia].NET代碼被編譯成IL代碼，而不是ARM匯編.對於沒有沒進行源碼混淆的應用程序Souce Code泄露的風險明顯增大.
其實對於SouceCode保護.並不僅是Windows phone平台所面臨的問題.
Android平台采用的是Java語言開發.Jave和.NET平台一樣.在各自環境執行時.並不會將代碼直接便異常機器碼.而是編譯成一種叫java字節碼的中間語言.一般的java程序編譯完成后是一個完整的Jar包.Android則使用DEX。你可以通過諸如dex2jar這樣的工具將DEX文件轉換成jar文件，然后使用諸如JD-GUI這樣的工具反編譯成Java代碼。其風險和Windows Phone平台是類似的.
iPhone/iPad使用Objective-C語言，並且將代碼直接編譯成機器碼。因此反編譯會有較大的困難。然而，市場上依然存在一些專業反向工程工具，例如IDA.
目前主流平台對比可見.各個平台情況也是參差不齊.
<2>Dotfuscator構建源碼混
PreEmptive Solutions在沒有和MS合作之前,Dotfuscator代碼混淆工具還需要額外的申請.官方需要一到兩天的審核時間.現在只需要到PreEmptive Solutions官網上找到Windows phone對應的主頁:
PreEmptive Solutions For Windows phone：
直接可以在當前頁申請.:
現在申請流程已經大大簡化了.基本在申請成功后可以收到官方發過來的一封說明郵件如下:
郵件中提供對應的軟件下載地址.對應S/N注冊碼,該S/N碼會在軟件安裝提示輸入:
安裝完成后可以看到 切換並選擇對應assemblies集合:
采用默認設置運行可見操作主頁面:
這時創建一個用於測試Windows Phone Application 命名為:SouceCodeProtect_Demo.在MainPage頁面添加一個簡單的TextBox和Button按鈕.在按鈕事件處理TextBox用戶輸入處理方法如下:
1: private void Confirm_BT_Click(object sender, RoutedEventArgs e)
2: {
3: string userInputText = this.UserInput_TB.Text.Trim();
4: if (string.IsNullOrEmpty(userInputText))
5: {
6: MessageBox.Show("Please Input Basic Message Text!");
7: this.UserInput_TB.Focus();
8: }
9: else
10: MessageBox.Show("You have been Input " + userInputText);
11: }
運行效果如下:
這時有了一個簡單功能的Windows phone 應用程序.當然此處的目的為了測試演示的目的.這時如果我們要把這個應用程序上線官方MarketPlace.一般情況需要發布一個Release版本的XAP安裝包.找到對應SouceCodeProtect_Demo.xap 強制修改xap為rar格式並解壓可以見到XAP打包的文件列表如下:
此時當前DLL並沒有任何代碼保護措施. 如果當前發布的應用程序的XAP安裝意外流出.或是遭到第三方強制破解.如果通過逆向工程反編譯工具.NET REflector查看對應SourceCodeProtect_Demo.DLL可以看到:
我們的核心代碼就會向密碼中明文一樣在沒有任何保護措施的情況下被暴露出來.這時該如何保護自主知識產權的源代碼呢.?
積極采用雲平台.把重要邏輯放到雲端:
如果Windows phone在做客戶端工作.你也可以考慮將部分重要的邏輯放到雲端，例如Windows Azure之上，尤其是那些需要很多計算資源的邏輯，例如電影編碼。手機是一個客戶端，性能和存儲空間都有限，有部分功能不適用於在手機上進行。事實上，Windows Phone自帶的一部分功能，例如朗讀文本，就需要通過微軟的雲服務才能完成。將邏輯放在雲端還有一個好處就是，各種各樣的客戶端都能夠通過訪問服務的方式使用該功能，而不需要針對每個客戶端寫專門的代碼。像部署在Windows Azure這樣的雲平台上的服務，客戶端無法直接取得程序，只能通過服務暴露出的接口間接地訪問雲端的程序邏輯，因此也不存在反編譯問題。當然，這樣做也有壞處，例如可能需要用戶支付網絡流量相關費用，而且有時候網絡傳輸可能有點慢.
使用高級編程語言特性:
C#這樣的語言有一些高級語言功能，例如lambda expression和yield return。使用這樣的功能不僅使得寫代碼變得方便，同時也會增加逆向工程反編譯的難度。因為很多使用高級語言功能撰寫的代碼會在編譯時由編譯器自動轉化成一些比較繁瑣，讀起來比較累的代碼。大多數逆向工程反編譯工具只能產生這些由編譯器生成的代碼，而看不到你的原始代碼。
使用源代碼混淆工具:
當然從成本和開發者可控的角度而言.通常的做法就是版本發布后考慮將源代碼進行混淆。這會使得反向工程后的源代碼很難被讀懂。在.NET平台上，可以使用諸如Dotfuscator這樣的工具.
如何使用Dotfuscator工具執行源代碼混淆操作?
...