iOS Pentesting
最后更新于
最后更新于
使用Trickest轻松构建和自动化工作流程，使用全球最先进的社区工具。 立即获取访问权限：
在此页面中，您可以找到关于iOS模拟器、模拟器和越狱的信息：
iOS Testing Environment在测试过程中会建议执行多个操作（连接到设备、读取/写入/上传/下载文件、使用一些工具...）。因此，如果您不知道如何执行这些操作中的任何一个，请开始阅读页面：
iOS Basic Testing Operations在以下步骤中，应该已经在设备上安装了应用程序，并且已经获得了应用程序的IPA文件。 阅读基本iOS测试操作页面以了解如何执行此操作。
建议使用工具MobSF对IPA文件执行自动静态分析。
识别二进制文件中存在的保护措施：
PIE（位置无关可执行文件）：启用后，应用程序每次启动时都会加载到随机内存地址，使得难以预测其初始内存地址。
堆栈Canaries：为了验证堆栈的完整性，在调用函数之前在堆栈上放置一个“canary”值，并在函数结束时再次验证。
ARC（自动引用计数）：防止常见的内存腐败缺陷
加密二进制文件：二进制文件应该是加密的
识别敏感/不安全函数
弱哈希算法
不安全的随机函数
不安全的‘Malloc’函数
不安全和易受攻击的函数
查看MobSF执行的动态分析。您需要浏览不同视图并与其交互，但它将挂接多个类并执行其他操作，并在完成后准备报告。
使用命令frida-ps -Uai来确定已安装应用程序的捆绑标识符：
学习如何枚举应用程序的组件以及如何使用 objection 轻松hook方法和类：
iOS Hooking With ObjectionIPA 文件的结构本质上是一个压缩包。通过将其扩展名更改为 .zip，可以对其进行解压以显示其内容。在这个结构中，Bundle代表一个完全打包好准备安装的应用程序。在其中，您会找到一个名为 <NAME>.app 的目录，其中封装了应用程序的资源。
Info.plist：此文件保存应用程序的特定配置详细信息。
_CodeSignature/：此目录包含一个包含签名的 plist 文件，确保捆绑包中所有文件的完整性。
Assets.car：存储像图标这样的资源文件的压缩存档。
Frameworks/：此文件夹包含应用程序的本机库，可能是 .dylib 或 .framework 文件的形式。
PlugIns/：这可能包括应用程序的扩展，称为 .appex 文件，尽管它们并不总是存在。
Core Data：用于保存应用程序的永久数据以供离线使用，缓存临时数据，并在单个设备上为应用程序添加撤消功能。为了在单个 iCloud 帐户中的多个设备之间同步数据，Core Data 会自动将您的模式镜像到 CloudKit 容器中。
PkgInfo：PkgInfo 文件是指定应用程序或捆绑包的类型和创建者代码的另一种方式。
en.lproj, fr.proj, Base.lproj：是包含这些特定语言资源的语言包，以及在不支持某种语言的情况下的默认资源。
安全性：_CodeSignature/ 目录通过数字签名验证所有捆绑文件的完整性，在应用程序的安全性方面起着关键作用。
资产管理：Assets.car 文件使用压缩来高效管理图形资产，这对于优化应用程序性能并减小其整体大小至关重要。
框架和插件：这些目录突显了 iOS 应用程序的模块化，允许开发人员包含可重用的代码库（Frameworks/）并扩展应用功能（PlugIns/）。
本地化：该结构支持多种语言，通过为特定语言包含资源来促进全球应用程序覆盖范围。
Info.plist
Info.plist 作为 iOS 应用程序的基石，以键-值对的形式封装关键配置数据。这个文件不仅对应用程序是必需的，对于打包在其中的应用程序扩展和框架也是必需的。它以 XML 或二进制格式结构化，并包含从应用程序权限到安全配置等关键信息。要详细探索可用键，可以参考Apple Developer Documentation。
对于希望以更易访问的格式处理此文件的人，可以通过 macOS 上的 plutil（在版本 10.2 及更高版本中本地可用）或 Linux 上的 plistutil 轻松实现 XML 转换。转换的命令如下：
对于 macOS：
对于 Linux：
在Info.plist文件中可以泄露大量信息，其中一些显著条目包括应用程序权限字符串（UsageDescription）、自定义URL schemes（CFBundleURLTypes）以及App Transport Security的配置（NSAppTransportSecurity）。这些条目以及其他条目，如导出/导入的自定义文档类型（UTExportedTypeDeclarations / UTImportedTypeDeclarations），可以通过检查文件或使用简单的grep命令轻松定位：
数据路径
在iOS环境中，目录专门用于系统应用和用户安装的应用。系统应用位于/Applications目录下，而用户安装的应用则放置在/var/mobile/containers/Data/Application/目录下。这些应用被分配一个称为128位UUID的唯一标识符，由于目录名称的随机性，手动定位应用文件夹的任务变得具有挑战性。
由于iOS中的应用必须进行沙箱化，每个应用还将在**$HOME/Library/Containers目录下拥有一个以应用的CFBundleIdentifier**命名的文件夹。
然而，这两个文件夹（数据和容器文件夹）都有一个名为**.com.apple.mobile_container_manager.metadata.plist**的文件，该文件在键MCMetadataIdentifier中链接了这两个文件。
为了便于发现用户安装的应用的安装目录，objection工具提供了一个有用的命令env。这个命令会显示有关所讨论应用的详细目录信息。以下是如何使用这个命令的示例：
或者，可以使用find命令在/private/var/containers中搜索应用程序名称：
命令如 ps 和 lsof 也可用于识别应用程序的进程和列出打开的文件，从而提供有关应用程序活动目录路径的见解：
Bundle directory:
Bundle目录:
AppName.app
这是应用程序包，如之前在IPA中看到的，其中包含基本应用程序数据、静态内容以及应用程序的编译二进制文件。
该目录对用户可见，但用户无法对其进行写入。
该目录中的内容不会被备份。
该文件夹的内容用于验证代码签名。
Data directory:
Documents/
包含所有用户生成的数据。应用程序最终用户启动创建这些数据。
对用户可见，用户可以对其进行写入。
该目录中的内容会被备份。
应用程序可以通过设置NSURLIsExcludedFromBackupKey来禁用路径。
Library/
包含所有非特定于用户的文件，如缓存、首选项、cookies和属性列表（plist）配置文件。
iOS应用程序通常使用Application Support和Caches子目录，但应用程序可以创建自定义子目录。
Library/Caches/
包含半持久性缓存文件。
对用户不可见，用户无法对其进行写入。
该目录中的内容不会被备份。
当应用程序未运行且存储空间不足时，操作系统可能会自动删除该目录中的文件。
Library/Application Support/
包含运行应用程序所需的持久性文件。
对用户不可见，用户无法对其进行写入。
该目录中的内容会被备份。
应用程序可以通过设置NSURLIsExcludedFromBackupKey来禁用路径。
Library/Preferences/
用于存储属性，这些属性可以在应用程序重新启动后持久存在。
信息以未加密的方式保存在应用程序沙盒中的名为[BUNDLE_ID].plist的plist文件中。
使用NSUserDefaults存储的所有键/值对都可以在此文件中找到。
tmp/
使用此目录来写入不需要在应用程序启动之间持久存在的临时文件。
包含非持久性缓存文件。
对用户不可见。
该目录中的内容不会被备份。
当应用程序未运行且存储空间不足时，操作系统可能会自动删除该目录中的文件。
让我们更仔细地查看iGoat-Swift的应用程序包(.app)目录，位于Bundle目录内(/var/containers/Bundle/Application/3ADAF47D-A734-49FA-B274-FBCA66589E67/iGoat-Swift.app)：
在 <application-name>.app 文件夹中，您会找到一个名为 <application-name> 的二进制文件。这是将被执行的文件。您可以使用工具 otool 对二进制文件进行基本检查：
检查应用是否已加密
查看是否有任何输出：
反汇编二进制文件
反汇编文本部分：
要打印示例应用程序的Objective-C段，可以使用：
为了获得更紧凑的 Objective-C 代码，您可以使用 class-dump 工具：
然而，拆解二进制文件的最佳选项是：Hopper 和 IDA。
使用 Trickest 来轻松构建和自动化工作流程，利用世界上最先进的社区工具。 立即获取访问权限：
要了解 iOS 如何在设备中存储数据，请阅读此页面：
iOS Basics应该在安装应用程序后立即检查以下存储信息的位置，在检查应用程序的所有功能之后，甚至在从一个用户注销并登录到另一个用户之后。 目标是查找应用程序（密码、令牌）、当前用户和先前登录用户的未受保护的敏感信息。
plist 文件是结构化的 XML 文件，包含键值对。这是一种存储持久数据的方式，因此有时您可能会在这些文件中找到敏感信息。建议在安装应用程序后和在大量使用应用程序后检查这些文件，以查看是否写入了新数据。
在 plist 文件中持久保存数据的最常见方式是通过使用NSUserDefaults。此 plist 文件保存在应用程序沙盒中的**Library/Preferences/<appBundleID>.plist**
NSUserDefaults 类提供了与默认系统交互的编程接口。默认系统允许应用程序根据用户偏好自定义其行为。由 NSUserDefaults 保存的数据可以在应用程序包中查看。此类将数据存储在plist 文件中，但它旨在与少量数据一起使用。
这些数据无法直接通过受信任的计算机访问，但可以通过备份访问。
您可以使用 objection 的 ios nsuserdefaults get 来转储使用 NSUserDefaults 保存的信息。
要查找应用程序使用的所有 plist，可以访问 /private/var/mobile/Containers/Data/Application/{APPID} 并运行：
要将文件从**XML或二进制（bplist）**格式转换为XML，可以根据您的操作系统使用不同的方法：
对于 macOS 用户： 使用 plutil 命令。这是 macOS（10.2+）中的一个内置工具，专门用于此目的：
**对于Linux用户：**首先安装libplist-utils，然后使用plistutil来转换您的文件：
在 Objection 会话中： 用于分析移动应用程序的特定命令允许您直接转换 plist 文件：
Core Data 是一个用于管理应用程序中对象模型层的框架。Core Data可以使用SQLite作为其持久存储，但框架本身不是一个数据库。
CoreData默认不加密其数据。然而，可以向CoreData添加额外的加密层。查看GitHub Repo获取更多详细信息。
您可以在路径/private/var/mobile/Containers/Data/Application/{APPID}/Library/Application Support中找到应用程序的SQLite Core Data信息。
如果您可以打开SQLite并访问敏感信息，则表示您发现了一个配置错误。
YapDatabase 是建立在 SQLite 之上的键/值存储。 由于 Yap 数据库是 SQLite 数据库，您可以使用上一节中提到的命令找到它们。
应用程序通常会创建自己的 SQLite 数据库。它们可能在其中存储敏感数据并将其保留为未加密。因此，检查应用程序目录中的每个数据库始终是一件有趣的事情。因此，请转到保存数据的应用程序目录 (/private/var/mobile/Containers/Data/Application/{APPID})。
开发人员可以通过Firebase实时数据库在NoSQL云托管数据库中存储和同步数据。数据以JSON格式存储，并实时同步到所有连接的客户端。
您可以在此处找到如何检查配置错误的Firebase数据库：
Firebase DatabaseRealm Objective-C 和 Realm Swift 提供了一个强大的数据存储替代方案，苹果没有提供。默认情况下，它们以未加密的方式存储数据，可以通过特定配置进行加密。
这些数据库位于：/private/var/mobile/Containers/Data/Application/{APPID}。要查看这些文件，可以使用如下命令：
要查看这些数据库文件，建议使用Realm Studio工具。
要在Realm数据库中实现加密，可以使用以下代码片段：
Couchbase Lite被描述为一种轻量级和嵌入式数据库引擎，遵循面向文档（NoSQL）的方法。设计为原生支持iOS和macOS，提供了无缝同步数据的能力。
要识别设备上可能存在的Couchbase数据库，应检查以下目录：
iOS 将应用程序的 cookies 存储在每个应用程序文件夹内的 Library/Cookies/cookies.binarycookies 中。然而，开发人员有时会决定将它们保存在 keychain 中，因为上述 cookie 文件可以在备份中访问。
要检查 cookies 文件，您可以使用此 Python 脚本或使用 objection 的 ios cookies get.
您还可以使用 objection 将这些文件转换为 JSON 格式并检查数据。
默认情况下，NSURLSession将数据，如HTTP请求和响应存储在Cache.db数据库中。如果令牌、用户名或任何其他敏感信息已被缓存，该数据库可能包含敏感数据。要查找缓存的信息，请打开应用的数据目录（/var/mobile/Containers/Data/Application/<UUID>），然后转到/Library/Caches/<Bundle Identifier>。WebKit缓存也存储在Cache.db文件中。Objection可以使用命令sqlite connect Cache.db打开并与数据库交互，因为它是一个普通的SQLite数据库。
建议禁用缓存这些数据，因为请求或响应中可能包含敏感信息。以下列表显示了实现此目的的不同方法：
建议在注销后删除缓存的响应。可以使用苹果提供的名为removeAllCachedResponses的方法来执行此操作。您可以按如下方式调用此方法：
URLCache.shared.removeAllCachedResponses()
此方法将从Cache.db文件中删除所有缓存的请求和响应。
如果您不需要使用cookies的优势，建议只使用URLSession的.ephemeral配置属性，这将禁用保存cookies和缓存。
苹果文档：
一个临时会话配置对象类似于默认会话配置（请参阅default），不同之处在于相应的会话对象不会将缓存、凭据存储或任何会话相关数据存储到磁盘。相反，会话相关数据存储在RAM中。临时会话仅在您告诉它将URL的内容写入文件时才会将数据写入磁盘。
通过将缓存策略设置为.notAllowed也可以禁用缓存。这将禁止以任何方式存储缓存，无论是在内存中还是在磁盘上。
每当您按下主屏幕按钮时，iOS都会拍摄当前屏幕的快照，以便能够更流畅地切换到应用程序。然而，如果当前屏幕中存在敏感数据，它将被保存在图像中（这将持续 跨 重启）。这些快照也可以通过双击主屏幕来访问，以在应用程序之间切换。
除非iPhone已越狱，攻击者需要访问 未锁定 的设备才能查看这些屏幕截图。默认情况下，最后一个快照存储在应用程序的沙盒中的Library/Caches/Snapshots/或Library/SplashBoard/Snapshots文件夹中（受信任的计算机无法从iOS 7.0访问文件系统）。
防止这种不良行为的一种方法是在拍摄快照之前使用ApplicationDidEnterBackground()函数放置空白屏幕或删除敏感数据。
以下是一个设置默认屏幕截图的示例修复方法。
Swift:
Objective-C：
这会在应用程序进入后台时将背景图像设置为overlayImage.png。它可以防止敏感数据泄露，因为overlayImage.png将始终覆盖当前视图。
要访问和管理iOS钥匙串，可以使用像Keychain-Dumper这样的工具，适用于越狱设备。此外，Objection提供了ios keychain dump命令，用于类似的目的。
NSURLCredential类非常适合直接将敏感信息保存在钥匙串中，无需使用NSUserDefault或其他包装器。要在登录后存储凭据，可以使用以下Swift代码：
从iOS 8.0开始，用户可以安装自定义键盘扩展，可在设置 > 通用 > 键盘 > 键盘下进行管理。虽然这些键盘提供了扩展功能，但存在记录按键和将数据传输到外部服务器的风险，尽管用户会收到通知，指出需要网络访问的键盘。应用程序可以并且应该限制对自定义键盘用于输入敏感信息。
安全建议:
建议禁用第三方键盘以增强安全性。
注意默认iOS键盘的自动更正和自动建议功能，可能会将敏感信息存储在Library/Keyboard/{locale}-dynamic-text.dat或/private/var/mobile/Library/Keyboard/dynamic-text.dat中的缓存文件中。应定期检查这些缓存文件以查找敏感数据。建议通过设置 > 通用 > 重置 > 重置键盘字典来清除缓存数据。
拦截网络流量可以揭示自定义键盘是否远程传输按键。
UITextInputTraits协议提供了管理自动更正和安全文本输入的属性，对于防止敏感信息缓存至关重要。例如，通过禁用自动更正和启用安全文本输入，可以实现：
另外，开发人员应确保文本字段，特别是用于输入诸如密码和个人识别码（PIN）等敏感信息的字段，通过将 autocorrectionType 设置为 UITextAutocorrectionTypeNo 并将 secureTextEntry 设置为 YES 来禁用缓存。
调试代码通常涉及使用日志。这存在风险，因为日志可能包含敏感信息。在iOS 6及更早版本中，日志对所有应用程序都是可访问的，存在敏感数据泄漏的风险。现在，应用程序被限制只能访问自己的日志。
尽管存在这些限制，拥有解锁设备的物理访问权限的攻击者仍然可以通过将设备连接到计算机并读取日志来利用这一点。需要注意的是，即使在应用程序卸载后，日志仍然保留在磁盘上。
为了减轻风险，建议与应用程序进行全面交互，探索其所有功能和输入，以确保没有意外记录敏感信息。
在审查应用程序源代码以查找潜在泄漏时，要查找使用关键字如NSLog、NSAssert、NSCAssert、fprintf等内置函数的预定义和自定义日志记录语句，以及任何提及Logging或Logfile的自定义实现。
应用程序记录各种可能敏感的信息。要监控这些日志，可以使用工具和命令，如：
另外，Xcode 提供了一种收集控制台日志的方法：
打开 Xcode。
连接 iOS 设备。
导航至 Window -> Devices and Simulators。
选择您的设备。
触发您正在调查的问题。
使用 Open Console 按钮在新窗口中查看日志。
对于更高级的日志记录，连接到设备 shell 并使用 socat 可以提供实时日志监控：
跟随以下命令观察日志活动，这对于诊断问题或识别日志中的潜在数据泄漏非常宝贵。
使用 Trickest 可轻松构建并通过全球最先进的社区工具自动化工作流程。 立即获取访问权限：
自动备份功能已集成到 iOS 中，通过 iTunes（在 macOS Catalina 之前）、Finder（从 macOS Catalina 开始）或 iCloud 可轻松创建设备数据副本。这些备份几乎包含所有设备数据，但不包括高度敏感的元素，如 Apple Pay 详细信息和 Touch ID 配置。
备份中包含已安装应用及其数据引发了潜在数据泄漏问题，以及备份修改可能会改变应用功能的风险。建议不要在明文中存储敏感信息，以减轻这些风险。
默认情况下，Documents/ 和 Library/Application Support/ 中的文件会被备份。开发人员可以使用 NSURL setResourceValue:forKey:error: 和 NSURLIsExcludedFromBackupKey 从备份中排除特定文件或目录。这一做法对于保护敏感数据不被包含在备份中至关重要。
要评估应用的备份安全性，首先通过 Finder 创建一个备份，然后根据苹果的官方文档中的指导找到备份。分析备份中的敏感数据或配置，以确定可能会影响应用行为的内容。
可以使用命令行工具或应用程序如 iMazing 查找敏感信息。对于加密备份，可以通过检查备份根目录中的 "Manifest.plist" 文件中的 "IsEncrypted" 键来确认是否加密。
对于处理加密备份，DinoSec的GitHub存储库中提供的Python脚本，如backup_tool.py和backup_passwd.py可能会很有用，尽管可能需要调整以与最新的iTunes/Finder版本兼容。另一个访问受密码保护备份中文件的选择是iOSbackup工具。
通过备份修改来改变应用程序行为的示例在Bither比特币钱包应用中展示，其中UI锁定PIN存储在net.bither.plist中的pin_code键下。从plist中移除此键并恢复备份将删除PIN要求，提供无限制访问。
处理存储在应用程序内存中的敏感信息时，限制此数据的暴露时间至关重要。有两种主要方法来调查内存内容：创建内存转储和实时分析内存。这两种方法都有其挑战，包括在转储过程或分析过程中可能错过关键数据的风险。
对于越狱和非越狱设备，诸如objection和Fridump之类的工具允许转储应用程序的进程内存。一旦转储完成，分析这些数据需要使用各种工具，具体取决于您要搜索的信息的性质。
要从内存转储中提取字符串，可以使用诸如strings或rabin2 -zz之类的命令：
对于更详细的分析，包括搜索特定数据类型或模式，radare2 提供了广泛的搜索功能：
r2frida 提供了一个强大的替代方案，可以实时检查应用程序的内存，而无需进行内存转储。该工具使得可以直接在运行应用程序的内存上执行搜索命令：
一些开发人员会将敏感数据保存在本地存储中，并使用在代码中硬编码/可预测的密钥对其进行加密。这样做是不应该的，因为一些逆向工程可能会使攻击者提取机密信息。
开发人员不应该使用已弃用的算法来执行授权检查，存储或发送数据。一些这些算法包括：RC4，MD4，MD5，SHA1...例如，如果要使用哈希来存储密码，应该使用抗哈希暴力破解的哈希算法，并加盐。
要执行的主要检查包括查找代码中是否存在硬编码的密码/密钥，或者这些密码/密钥是否是可预测的，以及代码是否使用某种弱的加密算法。
有趣的是，您可以使用objection自动监视一些加密****库，方法是：
有关iOS加密API和库的更多信息，请访问https://mobile-security.gitbook.io/mobile-security-testing-guide/ios-testing-guide/0x06e-testing-cryptography
本地身份验证在通过加密方法保护远程端点的访问时发挥着至关重要的作用。关键在于，如果没有适当的实现，本地身份验证机制可能会被绕过。
苹果的本地身份验证框架和钥匙串为开发人员提供了强大的API，以便于用户身份验证对话框和安全处理秘密数据。安全区域为Touch ID提供指纹ID，而Face ID依赖面部识别而不会泄露生物特征数据。
要集成Touch ID/Face ID，开发人员有两个API选择：
LocalAuthentication.framework 用于高级用户身份验证，无法访问生物特征数据。
Security.framework 用于较低级别的钥匙串服务访问，使用生物特征身份验证保护秘密数据。各种开源包装器使钥匙串访问更简单。
然而，LocalAuthentication.framework和Security.framework都存在漏洞，因为它们主要返回布尔值，而不会传输用于身份验证过程的数据，使其容易受到绕过攻击（参见Don't touch me that way, by David Lindner et al）。
为了提示用户进行身份验证，开发人员应该在**LAContext类中使用evaluatePolicy**方法，在以下选项之间进行选择：
deviceOwnerAuthentication：提示使用Touch ID或设备密码，如果两者都未启用，则失败。
deviceOwnerAuthenticationWithBiometrics：仅提示使用Touch ID。
从**evaluatePolicy**返回的布尔值表示成功的身份验证，突显了潜在的安全漏洞。
在iOS应用程序中实现本地身份验证涉及使用钥匙串API安全存储诸如身份验证令牌之类的秘密数据。该过程确保数据只能由用户使用其设备密码或Touch ID等生物特征身份验证来访问。
钥匙串提供了设置带有SecAccessControl属性的项目的功能，该属性限制对项目的访问，直到用户通过Touch ID或设备密码成功进行身份验证。这一功能对于增强安全性至关重要。
以下是Swift和Objective-C中的代码示例，演示如何将字符串保存到钥匙串中并从中检索出来，利用这些安全功能。这些示例特别展示了如何设置访问控制以要求Touch ID身份验证，并确保数据仅在设置的设备上可访问，前提是配置了设备密码。
Objective-C是iOS应用程序开发中常用的编程语言。在iOS渗透测试中，了解Objective-C语法和特性非常重要，因为许多iOS应用程序仍然使用Objective-C编写。
1. 使用Objective-C进行反向工程
通过学习Objective-C语法和特性，可以更好地理解iOS应用程序的内部工作原理。这对于进行反向工程和发现潜在漏洞非常有帮助。
2. 分析Objective-C代码
分析Objective-C代码可以帮助渗透测试人员识别应用程序中的安全漏洞和弱点。深入了解代码逻辑和结构有助于发现潜在的攻击面。
3. 利用Objective-C运行时特性
Objective-C的运行时特性使得在运行时动态修改类和对象成为可能。渗透测试人员可以利用这一特性来进行应用程序的修改和调试。
以下是一个简单的Objective-C示例代码，用于演示Objective-C语法和特性：
通过学习和分析Objective-C代码，渗透测试人员可以更好地理解iOS应用程序的内部结构和运行机制。
现在我们可以从钥匙串中请求保存的项目。钥匙串服务将向用户显示身份验证对话框，并根据是否提供了合适的指纹来返回数据或nil。
Objective-C is the primary programming language used for iOS app development. When performing iOS pentesting, it is essential to understand Objective-C code to identify security vulnerabilities and potential attack vectors.
Key Points:
Objective-C Syntax: Familiarize yourself with Objective-C syntax, including classes, methods, properties, and memory management.
Security Features: Understand security features provided by Objective-C, such as data encryption, secure coding practices, and secure communication protocols.
Common Vulnerabilities: Be aware of common security vulnerabilities in Objective-C code, such as buffer overflows, format string vulnerabilities, and insecure data storage.
Static Analysis: Use static analysis tools to identify security issues in Objective-C code, suchjson as insecure coding patterns, memory leaks, and potential vulnerabilities.
Dynamic Analysis: Perform dynamic analysis to identify runtime security issues, such as insecure network communication, sensitive data exposure, and runtime manipulation.
By mastering Objective-C fundamentals and security best practices, you can effectively assess the security posture of iOS applications and provide recommendations for improving their security.
应用程序中使用的框架还可以通过分析应用程序二进制文件的共享动态库列表来检测。可以使用 otool 来完成此操作：
如果应用程序中使用了 LocalAuthentication.framework，输出将包含以下两行（请记住 LocalAuthentication.framework 在底层使用 Security.framework）:
如果使用Security.framework，只会显示第二个。
通过位于此 GitHub 页面的Objection生物识别绕过，可以使用一种技术来绕过LocalAuthentication机制。这种方法的核心是利用Frida来操纵evaluatePolicy函数，确保它始终产生True结果，而不考虑实际的身份验证成功与否。这对于规避存在缺陷的生物识别身份验证流程特别有用。
要激活此绕过，使用以下命令：
这个命令启动一个序列，Objection注册一个任务，有效地改变了evaluatePolicy检查的结果为True。
来自DVIA-v2应用程序中对**evaluatePolicy**的使用示例：
为了实现本地认证的绕过，编写了一个 Frida 脚本。该脚本针对 evaluatePolicy 检查，拦截其回调以确保其返回 success=1。通过改变回调的行为，认证检查被有效地绕过。
以下脚本被注入以修改 evaluatePolicy 方法的结果。它将回调的结果更改为始终指示成功。
要注入Frida脚本并绕过生物识别身份验证，使用以下命令：
重要的是检查是否发生未加密的通信，并且应用程序是否正确验证服务器的TLS证书。 要检查这类问题，可以使用像Burp这样的代理：
iOS Burp Suite Configuration验证TLS证书的一个常见问题是检查证书是否由受信任的CA签名，但未检查证书的主机名是否为正在访问的主机名。 为了使用Burp检查此问题，在iPhone上信任Burp CA后，您可以为不同主机名使用Burp创建新证书并使用它。如果应用程序仍然正常工作，则存在漏洞。
如果应用程序正确使用SSL Pinning，则应用程序仅在证书符合预期时才能正常工作。在测试应用程序时，这可能是一个问题，因为Burp将提供自己的证书。 为了绕过此保护，在越狱设备内部，您可以安装应用程序SSL Kill Switch或安装Burp Mobile Assistant。
您还可以使用objection的ios sslpinning disable
在**/System/Library**中，您可以找到手机上系统应用程序使用的框架
用户从App Store安装的应用程序位于**/User/Applications**内
**/User/Library**包含用户级应用程序保存的数据
您可以访问**/User/Library/Notes/notes.sqlite**以阅读应用程序内保存的笔记。
在已安装应用程序的文件夹内（/User/Applications/<APP ID>/），您可以找到一些有趣的文件：
iTunesArtwork：应用程序使用的图标
iTunesMetadata.plist：App Store中使用的应用程序信息
/Library/*：包含首选项和缓存。在**/Library/Cache/Snapshots/***中，您可以找到应用程序在发送到后台之前执行的快照。
开发人员可以远程立即修补其应用程序的所有安装，而无需重新提交应用程序到App Store并等待批准。 为此，通常使用JSPatch。 但也有其他选项，如Siren和react-native-appstore-version-checker。 这是一种危险的机制，可能会被恶意第三方SDK滥用，因此建议检查使用哪种方法进行自动更新（如果有）并进行测试。 您可以尝试下载应用程序的先前版本以进行此目的。
第三方SDK的一个重要挑战是对其功能的缺乏细粒度控制。开发人员面临选择：要么集成SDK并接受其所有功能，包括潜在的安全漏洞和隐私问题，要么完全放弃其好处。通常，开发人员无法自行修补这些SDK中的漏洞。此外，随着SDK在社区中获得信任，一些可能开始包含恶意软件。
第三方SDK提供的服务可能包括用户行为跟踪、广告显示或用户体验增强。然而，这带来了风险，因为开发人员可能不完全了解这些库执行的代码，从而导致潜在的隐私和安全风险。限制与第三方服务共享的信息至必要内容，并确保不会暴露敏感数据，这一点至关重要。
第三方服务的实施通常有两种形式：独立库或完整SDK。为了保护用户隐私，与这些服务共享的任何数据都应匿名化，以防止泄露个人可识别信息（PII）。
要识别应用程序使用的库，可以使用**otool**命令。应该针对应用程序及其使用的每个共享库运行此工具，以发现其他库。
OWASP iGoat https://github.com/OWASP/igoat <<< Objective-C 版本 https://github.com/OWASP/iGoat-Swift <<< Swift 版本
使用 Trickest 可以轻松构建和 自动化工作流，使用全球 最先进 的社区工具。 立即获取访问权限：
