Xamarin 项目中的混淆

Posted 2023-04-13

【中文标题】Xamarin 项目中的混淆

【英文标题】：Obfuscation in Xamarin Projects

【发布时间】：2016-07-25 04:44:21

【问题描述】：

如您所知，Xamarin 项目被编译为 dot net dll 程序集，并将打包到 apk 文件中，并且可以很容易地被 DotPeek 等反射器反映。

我的第一个问题是： 我们如何保护我们的代码？

我的第二个问题是： SmartAssembly 之类的混淆器工具是否可以在 Xamarin 项目中使用，或者 Xamarin 项目不支持它们？

【问题讨论】：

大多数（全部？）混淆器都可以工作，因为您正在谈论基于 CIL 的程序集（与任何 .Net/Mono 环境具有相同的优点/缺点）。对于 Xamarin.android，如果您是 VS Enterprise 用户，您还可以启用“在本机代码中启用程序集”。这会将程序集嵌入到基于 NDK 的运行时库中。逆向工程师将不得不花费更多时间寻找要提取的指向/结束点，但就像任何基于 CIL 的混淆一样，任何想要花时间进行 RE 的人都可以，无论您使用哪种混淆。

为什么要使用 ios 标签？ Xamarin.iOS 已经使用 AOT 编译为本机。

@LexLi 感谢提及。我刚刚删除了标签。

Java 也可以很容易地从 Android .apk 中反编译。因此，如果您想达到与 Android 提供的类似的“安全性” - 您已经拥有它。

【参考方案1】：

保护 APK 的 .NET 代码 (.DLLS) 的最佳方法是启用 Ahead Of Time (AOT) 编译：

AOT 编译会将您的应用程序 IL 代码 (.dll) 编译为本机指令。打包到 APK 中的最终代码是 X86、arm 等指令，而不是托管的 IL 代码。

AOT 编译仅适用于 Enterprise 和更高版本的许可证。

虽然 AOT 增加了逆向工程的难度，但它仍然不是 100% 万无一失的。最终的二进制文件仍然可以从有根设备中提取，并使用 IDA pro 等软件进行逆向工程。这比使用 DotPeek 困难得多，但仍然可以。

注意启用 AOT 编译的不利方面也很重要。应用程序构建时间显着增加，因为您的应用程序引用的每个程序集都需要编译；我的经验表明，启用 AOT 后，构建时间应该会增加 200%-300%。

另外，AOT 编译会增加最终的 APK 大小。

【讨论】：

众所周知，AOT 编译仅适用于 Enterprise 许可证。现在 Xamarin 是免费的，那么它可以在 Visual Studio 社区中使用吗？

感谢您强调，AOT 确实仅适用于企业许可证。正在更新答案。

据此：developer.xamarin.com/guides/android/… 生成的本机代码与未编译的程序集一起包含在 APK 中。这是否意味着编译和未编译的版本都包括在内，而 AOT 并不能真正帮助混淆？

@matthewrdev 我们可以使用下面描述的任何混淆器并启用 AOT 编译吗？这会让逆向工程变得困难吗？

我在启用 AOT 的反编译代码中没有任何变化... VS 2019。有什么想法吗？

【参考方案2】：

Dotfuscator 支持 Xamarin，在线说明（Dotfuscator Professional 或免费的Community Edition）了解如何集成它。本质上，流程是：

将构建配置为通过 AfterBuild 目标运行 Dotfuscator 配置Dotfuscator：
指定输入 像往常一样/根据需要从重命名中排除某些内容 仅使用与 Mono 兼容的转换（仅限专业版）
配置复制任务或构建后事件以将经过混淆的二进制文件复制回其原始位置 构建、验证混淆和测试

完全披露：我为 PreEmptive Solutions 工作。

【讨论】：

更新：现在使用 Dotfuscator Professional 更容易。只需 copy the appropriate configuration into your .csproj 并在发布模式下构建 - Dotfuscator 将完成剩下的工作。 Dotfuscator 社区仍然works the old way，但它最终也会更新。

是否还有计划将社区版迁移到这种新的配置方式？

是的；我们仍计划将新方式迁移到社区，但我还不能确定具体的时间表。

【参考方案3】：

对于您的第一个问题，可以使用一些工具来混淆您的 Xamarin 代码。例如，Crypto Obfuscator、Babel Obfuscator 和 Dotfuscator

对于您的第二个问题，SmartAssembly 混淆似乎是可能的。检查 Windows Phone 部分here。

【参考方案4】：

您无法完全 100% 保护您的代码不被反编译和查看。

您可能会花费大量时间对所有方法和变量进行哈希处理，然后再花费大量时间创建某种应用程序解释器来理解您的混淆代码，但即便如此，也会被调查、调查并最终破解。

另见：How can I protect my .NET assemblies from decompilation?

Protect .NET code from reverse engineering?