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

Question

我是iOS和Android游戏的开发人员。在发布了多个更新之后，我们发现了一些提供被黑版游戏的网站，从而给玩家带来了不公平的优势。由于此游戏包含玩家对玩家元素，因此理想情况下，我们希望停止使用这些被黑客入侵的版本，因为它会破坏那些不作弊的玩家的体验。

我们已经找到了一些方法可以解决Android上的此问题，但是到目前为止，我们还没有找到应对iOS的好方法。

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

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

iOS应用已以某种方式进行了修改(IPA文件包含额外的代码或已修改的文件)。我们不确定iOS应用是否有可能“了解”自己安装的文件并在运行时识别更改？

未通过App Store安装iOS应用。同样，也许我们可以在运行时检测到某些东西？我想，在某些情况下，非黑客入侵的应用可能会发生这种情况。

(貌似)对iOS应用进行了重新签名或使用其他配置文件。至少，检测到该应用程序使用的签名与最初提交给应用程序商店的签名不同，这似乎是我们绝对不允许的。

诚然，我对iOS应用程序编程并不十分熟悉(我们主要使用跨平台游戏引擎)。因此，我不确定其中是否容易检测到，或者iOS是否“正式”支持这些方法中的任何一种来检测不安全或被黑的应用程序。

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

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

Answer 1

另一个仪器框架

我们最近发现了一种黑客，其中涉及使用“Cydia Impactor”将被入侵的IPA侧面加载...

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

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

应用内决策

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

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

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

iOS DeviceCheck

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

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

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

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

但是，重要的是要注意，识别设备状态的责任，即它是否已经兑现了奖励，是否表现出辱骂性行为，是否犯了欺诈罪等，是开发商的责任:

...或标记您确定为欺诈的设备。通过DeviceCheck API，您还可以验证收到的 token 来自已下载应用程序的真实Apple设备。

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

因此，DeviceCheck可以说出有关设备真实性的信息，但是不能说出有关移动应用程序真实性的信息，它是您的移动应用程序与您上传到Apple商店的移动应用程序完全相同的东西，它是由Frida这样的框架进行检测的，它是中间人(MitM)攻击？所有这些都不在DeviceCheck的范围之内，也包括您要防范的事物。

可能的解决方案

有没有人有经验或成功检测到以上任何情况？

借助外部移动应用程序证明解决方案，可以以非常高的置信度来检测移动应用程序的真实性/完整性，该解决方案又称服务，它将不会在移动应用程序或其运行的设备中做出决定，而是会使用外部服务器做出决定，该决定将向移动应用程序发送随机询问，以确定其真实性/完整性。您可以在我写的文章中，特别是在The role of Mobile App Attestation部分中了解更多信息:

在深入探讨移动应用证明服务的作用之前，我们首先需要了解什么和谁在访问API服务器之间的区别。本文将对此进行详细讨论，我们可以阅读:


向API服务器发出请求的是什么。它确实是您的移动应用程序的真正实例，还是机器人，自动脚本还是攻击者使用诸如Postman之类的工具手动在您的API服务器上闲逛？

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


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

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

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

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

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

走得更远

我总是喜欢推荐OWASP的优秀资源OWASP Mobile Security Testing Guide:

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