我在 Play 商店上有一个 Android 应用程序，我想检测用户是使用从 Play 商店下载的应用程序的原始版本还是其他来源的 mod apk。
答案 0 :(得分：0)
我在 Play 商店上有一个 Android 应用程序，我想检测用户是使用从 Play 商店下载的应用程序的原始版本还是其他来源的 mod apk。
一个非常简单的问题，包含很多需要完整回答的问题，但从高层次的角度来看，您可以从移动应用程序内部或从外部解决这个问题。
从内部做这件事被称为RASP：
<块引用>运行时应用程序自我保护 (RASP) 是一种安全技术，它使用运行时工具通过利用来自正在运行的软件内部的信息来检测和阻止计算机攻击。
据说 RASP 技术通过监控其输入并阻止可能允许攻击的输入来提高软件的安全性，同时保护运行时环境免受不必要的更改和篡改。
我经常观察到的一件事是，许多开发人员不知道他们可能会添加到移动应用程序代码以尝试保护它的任何保护都可以在运行时使用检测框架绕过，即使代码本身很强大混淆。用于在运行时操作代码的众所周知的检测框架是 Frida：
<块引用>将您自己的脚本注入黑盒进程。挂钩任何函数，监视加密 API 或跟踪私有应用程序代码，无需源代码。编辑，点击保存，立即查看结果。无需编译步骤或程序重新启动。
如果开发者在他们的代码中添加了一个功能来检测应用程序是否为原始应用程序，攻击者最终会通过二进制文件的静态分析或运行时的动态分析找到它，然后使用Frida进行挂钩它改变了结果，比如总是返回一个结果，表明它是原始的。攻击者的另一种选择是重新编译没有上述功能的二进制文件，从而取消保护。
那么，我是说不要在您的移动应用上使用自我保护代码或 RASP 解决方案吗？
不，我建议你使用你能负担得起的所有机制来阻止坏人，但你也需要意识到他们可以绕过他们，并尽可能努力克服你的防御，以至于这对他们来说会很耗时，而且他们更愿意去其他地方寻找更容易的目标。
一个更好的选择是在应用程序运行或不是二进制文件的原始版本时将检测委托给应用程序外部，并且如果它在未扎根或越狱的设备中进行，这可以通过使用来完成移动应用证明概念，我在 this answer 中解释了我在关于一个可能的更好解决方案部分的如何保护移动应用的 API REST？的问题em>.
简而言之，移动应用证明是一种解决方案，它在完全实施后证明您的移动应用是否是您上传到 Play 商店的真实且未篡改的版本，并且在受信任的设备上运行，而不是越狱或扎根。
移动应用证明解决方案与 RASP 解决方案的不同之处在于，决策是在移动设备之外做出的，因此不能被检测框架操纵，而且它们还发布一个 JWT 令牌，允许移动应用的后端知道当它可以信任从它接收到的请求时。
RASP 解决方案不足，因为它们通常不会让移动 api 后端知道请求是否来自在可信环境中运行的移动设备的正版版本，也就是未扎根或越狱的设备，但是即使他们这样做，一旦这样做的逻辑在移动应用程序中运行，攻击者就可以使用 Frida 或类似工具对其进行操纵。
另一方面，移动应用证明解决方案将在移动设备之外做出决策，并允许移动 API 后端知道何时可以信任传入请求。
在回答安全问题时，我总是喜欢引用 OWASP 基金会的优秀作品。
OWASP API 安全项目旨在通过强调不安全 API 中的潜在风险并说明如何降低这些风险来为软件开发人员和安全评估人员提供价值。为实现这一目标，OWASP API 安全项目将创建和维护 10 大 API 安全风险文档，以及创建或评估 API 时最佳实践的文档门户。
OWASP Mobile Security Project - Top 10 risks
<块引用>OWASP 移动安全项目是一个集中式资源，旨在为开发人员和安全团队提供构建和维护安全移动应用程序所需的资源。通过该项目，我们的目标是对移动安全风险进行分类并提供开发控制以减少其影响或被利用的可能性。
OWASP - Mobile Security Testing Guide：
<块引用>移动安全测试指南 (MSTG) 是一本关于移动应用安全开发、测试和逆向工程的综合手册。