Windows phone 應用開發[13]-源碼保護

關於源代碼的保護.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：

http://www.preemptive.com/windowsphone7.html

直接能夠在當前頁申請.:

如今申請流程已經大大簡化了.基本在申請成功後能夠收到官方發過來的一封說明郵件以下:

郵件中提供對應的軟件下載地址.對應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: }

.csharpcode, .csharpcode pre { font-size: small; color: black; font-family: consolas, "Courier New", courier, monospace; background-color: #ffffff; /*white-space: pre;*/ } .csharpcode pre { margin: 0em; } .csharpcode .rem { color: #008000; } .csharpcode .kwrd { color: #0000ff; } .csharpcode .str { color: #006080; } .csharpcode .op { color: #0000c0; } .csharpcode .preproc { color: #cc6633; } .csharpcode .asp { background-color: #ffff00; } .csharpcode .html { color: #800000; } .csharpcode .attr { color: #ff0000; } .csharpcode .alt { background-color: #f4f4f4; 100%; margin: 0em; } .csharpcode .lnum { color: #606060; }

運行效果以下:

這時有了一個簡單功能的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工具執行源代碼混淆操做?

...