是否可以在运行时检测旁加载、重新签名或修改的 iOS 应用程序？

Question

我是 iOS 和 Android 游戏的开发人员。 在发布了几次更新之后，我们发现一些网站提供了游戏的黑客版本，以便为玩家提供不公平的优势。 由于这款游戏具有玩家对玩家的元素，我们理想情况下希望停止使用这些被黑的版本，因为它会破坏没有作弊的玩家的体验。

我们已经找到了一些在 Android 上解决这个问题的方法，但我们迄今为止还没有找到处理 iOS 的好方法。

我们最近发现了一个涉及使用“Cydia Impactor”并安装自定义配置文件的旁加载被黑客入侵的 IPA 的黑客攻击。 我们希望能够检测到这一点，以便我们可以禁止此类玩家污染玩家对玩家生态系统。

在这种情况下，我们似乎可以检测到三件事：

1. iOS 应用程序以某种方式进行了修改（IPA 文件包含额外的代码或修改后的文件）。 我们不确定 iOS 应用程序是否有可能“内省”自己安装的文件并在运行时识别更改？

2. 未通过 App Store 安装 iOS 应用程序。 再次，也许我们可以在运行时检测到什么？ 但我想，在某些有效的场景中，未受黑客攻击的应用程序可能会发生这种情况。

3. iOS 应用程序（似乎）重新签名或使用不同的配置文件。 至少，检测到应用程序使用的签名与最初提交到应用程序商店的签名不同，这似乎是我们永远不想允许的。

诚然，我对 iOS 应用程序编程不是很熟悉（我们主要使用跨平台游戏引擎）。 所以，我不确定这些是否容易被检测到，或者 iOS 是否“正式”支持这些方法中的任何一种来检测不安全或被黑客入侵的应用程序。

理想情况下，我们希望客户端能够向我们的服务器报告某种生成的标识符/校验和/指纹。 这样的事情可以避免明显的客户端黑客使“IsHacked”函数总是返回false！

有没有人有检测上述任何一种情况的经验或成功？ 如果是这样，是否有关于检测此类事情的正确方法的任何资源或文档？

Answer 1

另一个检测框架

我们最近发现了一个涉及使用“Cydia Impactor”侧面加载被黑客入侵的 IPA 的黑客攻击......

另一个在 iOS 中经常使用的工具是 Frida：

将您自己的脚本注入黑盒进程。 挂钩任何函数，监视加密 API 或跟踪私有应用程序代码，无需源代码。 编辑，点击保存，并立即查看结果。 无需编译步骤或程序重新启动。

应用内决策

理想情况下，我们希望客户端能够向我们的服务器报告某种生成的标识符/校验和/指纹。 这样的事情可以避免明显的客户端黑客使“IsHacked”函数总是返回false！

不幸的是，通过使用相同的技术使IsHacked始终返回false ，攻击者始终可以返回相同的identifier/checksum/fingerprint 。 这通常是通过使用检测框架来实现的，该框架将在运行时连接到代码中，并始终返回正版移动应用程序的identifier/checksum/fingerprint 。

任何依赖客户端决策来检查设备或移动应用程序的完整性/真实性的解决方案，都可以被检测框架绕过。

iOS设备检查

所以，我不确定这些是否容易被检测到，或者 iOS 是否“正式”支持这些方法中的任何一种来检测不安全或被黑客入侵的应用程序。

我看到许多开发人员转向 iOS DeviceCheck来解决此类问题，但通常他们错过了 DeviceCheck 的要点和目标：

Apple 的 DeviceCheck 解决方案主要旨在验证物理移动设备的身份和跟踪记录，而无需跟踪有关该设备或其用户的任何个人信息：

将 DeviceCheck API 与服务器到服务器 API 结合使用，您可以设置和查询每台设备的两位数据，同时维护用户隐私。 您可以使用此数据来识别已经利用您提供的促销优惠的设备，...

然而，重要的是要注意识别设备状态的责任，即它是否已经兑换了奖励，是否表现出滥用行为，是否有欺诈行为等，由开发人员承担：

... 或者标记您确定为欺诈的设备。 DeviceCheck API 还可以让您验证收到的令牌是否来自已下载您的应用程序的正版 Apple 设备。

我们可以验证 DeviceCheck 令牌是否来自真实的 iOS 设备真是太好了，但开发人员不应低估识别设备所需的额外工作，尤其是那些从事滥用和欺诈的设备，因为已经提到的检测框架可能会未被检测到或可能绕过 DeviceCheck。

所以 DeviceCheck 可以说明设备的真实性，但不能说明移动应用程序的真实性，这是您的移动应用程序与您上传到 Apple 商店的完全相同的应用程序，它由像 Frida 这样的框架进行检测，它是一个对象中间人（MitM）攻击？ 这些都是 DeviceCheck 范围之外的事情，也是您希望防范的事情。

可能的解决方案

有没有人有检测上述任何一种情况的经验或成功？

使用外部移动应用证明解决方案，即一种不会在移动应用或其运行的设备中做出决定的服务，而是可以使用外部移动应用证明解决方案，以非常高的置信度检测移动应用的真实性/完整性服务器做出决定，这将向移动应用程序发送随机挑战，以确定其真实性/完整性。 您可以在我写的文章中阅读更多相关信息，特别是在移动应用认证的作用部分：

在我们深入研究移动应用证明服务的角色之前，我们首先需要了解访问 API 服务器的内容和人员之间的区别。 这在本文中有更详细的讨论，我们可以阅读：

向 API 服务器发出请求的内容是什么。 它真的是您的移动应用程序的真实实例，还是机器人、自动化脚本或攻击者使用 Postman 之类的工具手动浏览您的 API 服务器？

我们可以通过多种方式对移动应用程序的用户进行身份验证、授权和识别，例如使用 OpenID Connect 或 OAUTH2 流。

移动应用证明服务的作用是验证发送请求的内容，从而仅响应来自真正移动应用实例的请求，并拒绝来自未经授权来源的所有其他请求。

为了了解向 API 服务器发送请求的内容，移动应用证明服务在运行时将高度确定您的移动应用存在、未被篡改/重新打包、未在根目录中运行设备，尚未被检测框架（Frida、xPosed、Cydia 等）连接，并且不是中间人攻击 (MitM) 的对象。 这是通过在后台运行 SDK 来实现的，该 SDK 将与在云中运行的服务进行通信，以证明其运行的移动应用程序和设备的完整性。

成功证明移动应用程序的完整性后，将发布一个短期存在的 JWT 令牌，并使用只有 API 服务器和云中的移动应用程序证明服务知道的秘密进行签名。 在证明失败的情况下，JWT 令牌使用不正确的秘密进行签名。 由于移动应用证明服务使用的秘密不被移动应用知道，因此即使应用被篡改、在有根设备中运行或通过连接进行通信，也无法在运行时对其进行逆向工程这就是中间人攻击的目标。

移动应用程序必须在每个 API 请求的标头中发送 JWT 令牌。 这允许 API 服务器仅在可以验证 JWT 令牌是否已使用共享密钥签名且未过期时才提供请求。 所有其他请求将被拒绝。 换句话说，一个有效的 JWT 令牌告诉 API 服务器发出请求的是上传到 Google 或 Apple 商店的正版移动应用程序，而无效或丢失的 JWT 令牌意味着发出请求的内容没有被授权这样做，因为它可能是机器人、重新打包的应用程序或进行中间人攻击的攻击者。

在您自己实施移动应用证明时，请始终牢记您随移动应用提供的 SDK 不得做出任何决定，并且必须在与发起挑战并做出决定的服务器的通信通道中使用证书锁定。

走得更远

我总是喜欢推荐 OWASP 的优秀资源， OWASP 移动安全测试指南：

移动安全测试指南 (MSTG) 是移动应用安全开发、测试和逆向工程的综合手册。