Windows phone 应用开发[13]-源码保护
2012-01-30 16:20 chenkai 阅读(3230) 评论(18) 编辑 收藏 举报关于源代码的保护.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工具执行源代码混淆操作?
...
