在运行时检测iOS应用程序是否被侧载、重新签名或修改，是否可能？

Question

在运行时检测iOS应用程序是否被侧载、重新签名或修改，是否可能？

3

我是一名iOS和Android游戏开发者。在发布几个更新之后，我们发现有一些网站提供了修改过的游戏版本，使玩家获得不公平的优势。由于这个游戏具有玩家对玩家的元素，我们希望能够阻止使用这些修改过的版本，因为这会破坏那些没有作弊的玩家的游戏体验。

我们已经找到了一些方法来解决Android上的这个问题，但至今还没有找到解决iOS上的好方法。

最近，我们发现了一种黑客攻击方式，即使用“Cydia Impactor”侧载一个修改过的IPA，并安装自定义的配置文件。我们希望能够检测到这种情况，以便我们可以禁止这些玩家污染玩家对玩家的生态系统。

在这种情况下，似乎有三件事情是可能被检测到的：

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

2. iOS应用程序不是通过App Store安装的。同样，在运行时可能会检测到某些有效场景下，非黑客应用程序也可能出现这种情况。

3. iOS应用程序被重新签名或使用不同的配置文件。至少，检测到应用程序正在使用与其最初提交到应用商店时不同的签名似乎是我们绝不想允许的事情。

诚然，我对iOS应用程序编程并不是非常熟悉（我们主要使用跨平台游戏引擎）。因此，我不确定这些问题是否容易被检测到，或者iOS是否“官方”支持任何这些方法来检测不安全或黑客攻击的应用程序。

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

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

- kromenak

你有找到一种检测侧载应用的方法吗？ - Austris Cirulnieks

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Exadra37 · Accepted Answer

另一个仪器化框架

我们最近发现了一种黑客方法，涉及使用“Cydia Impactor”侧载黑客IPA...

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

将自己的脚本注入到黑盒子进程中。钩住任何功能，监视加密API或跟踪私有应用程序代码，无需源代码。编辑，点击保存，即可立即看到结果。所有操作都不需要编译步骤或程序重启。

应用内决策

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

不幸的是，攻击者始终可以通过使用相同的技术使IsHacked始终返回false来返回相同的标识符/校验和/指纹。通常情况下，这是通过使用一个仪器化框架实现的，该框架会在运行时钩入代码，并始终返回真正移动应用的标识符/校验和/指纹。

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

iOS DeviceCheck

因此，我不确定这些方法中是否有任何易于检测的内容，或者iOS是否“官方”支持任何这些方法来检测不安全或被黑客攻击的应用程序。

我看到很多开发人员转向iOS DeviceCheck来解决这类问题，但通常他们忽略了DeviceCheck的重点和目标：

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

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

但是，需要注意的是，设备状态的识别责任，即它是否已经兑换了奖励，是否表现出滥用行为，是否有欺诈行为等，属于开发人员的责任。

“... 或者标记您已确定为欺诈的设备。DeviceCheck API 还可以让您验证您收到的令牌来自于一个真正的苹果设备，在该设备上下载了您的应用程序。”

“很好，我们可以验证 DeviceCheck 令牌来自于一个真正的 iOS 设备，但开发人员不应低估识别设备所需的额外工作量，特别是那些涉及滥用和欺诈的设备，因为可能无法检测到或绕过 DeviceCheck 的已提及的工具包。”

“因此，DeviceCheck 可以说明设备的真实性，但不能说明移动应用程序的真实性。您的移动应用程序是否与您上传到 Apple 应用商店的完全相同，它是否被像 Frida 这样的框架仪器化，它是否成为中间人攻击的对象？这些都超出了 DeviceCheck 的范围，而您正在寻求保护。”

“可能的解决方案”

“有没有人在检测到以上任何情况方面有经验或成功？”

使用外部移动应用程序认证解决方案可以非常高度地确保移动应用程序的真实性/完整性，即服务不会在移动应用程序或其运行设备上做出决策，而是使用外部服务器来做出决策，并向移动应用程序发送随机挑战以确定其真实性/完整性。您可以阅读我撰写的文章中的相关部分，特别是移动应用认证的作用：

在深入了解移动应用认证服务的角色之前，我们首先需要了解访问API服务器的是什么和谁。在本文中，我们可以阅读到以下内容：

“什么”是指向API服务器发出请求的东西。它是否真的是您的移动应用的真实实例，还是一个机器人、自动脚本或攻击者使用Postman等工具手动探测您的API服务器？

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

移动应用认证服务的作用是验证正在发送请求的“什么”，因此只响应来自真实移动应用实例的请求，并拒绝所有未经授权来源的请求。

为了知道是什么向API服务器发送请求，移动应用认证服务在运行时将确定您的移动应用是否存在，并以高可信度确认其完整性，未被篡改/重新打包，在未root的设备上运行，并未被检测到Frida、xPosed、Cydia等工具的hook，并且不是中间人攻击（MitM）的目标。这是通过在后台运行SDK并与在云中运行的服务通信来实现的，以验证移动应用及其运行设备的完整性。

在成功验证移动应用的完整性后，会发出短暂的JWT令牌，并使用API服务器和云中移动应用认证服务所知道的秘密进行签名。如果验证失败，则JWT令牌将使用不正确的秘密进行签名。由于移动应用认证服务使用的秘密在运行时是未知的，即使应用程序已被篡改，在root设备上运行或通过MitM攻击进行通信，也无法对其进行反向工程。

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

当您自己实现移动应用程序认证时，请始终牢记，您与移动应用程序一起提供的SDK不得做出任何决策，并且必须在与启动挑战并做出决策的服务器进行通信的通信渠道中使用证书固定。

走出舒适区

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

移动安全测试指南（MSTG）是一本关于移动应用程序安全开发、测试和反向工程的综合手册。