このようなクラス変数:
@property (strong, nonatomic) NSString *privateValue;
メモリにある間に誰かがその変数の値を読み取ることができますか? Apple docsでこれについて何も見つけることができず、理解も不足しています。誰かが攻撃の可能性についてヒントを教えてくれますか?
はい、アプリの外部からiOSクラス変数を読み取ることができます。投獄されたデバイスまたはジェイルブレイクされたデバイスに対する見方と傾向に応じて、実行時またはメモリ内でそれらを読み取る方法がいくつか見つかる場合があります。
ランタイムを介して、ジェイルブレイクされたデバイス上で、NCC Groupなどのツール Introspy は、正式なリバースエンジニアリングの公開や経験を必要としない開発者向けのツールです。
IOSシミュレータまたはiOSデバイスでメモリにアクセスするために、lldbおよびgdbを使用して、アプリの現在のメモリ状態をダンプできます。ダンプするプロセスを特定し、プロセスのダンプを含む自己変更コードまたは自己チェックコードをおそらく克服する必要があります。通常、これにはUnixまたはリバースエンジニアリングのバックグラウンドが必要です。より軽いアプローチとして、 Xcodeは提供する デバッガー、通知スパイ、およびDTraceインターフェースを提供します。デバッガーなしでメモリにアクセスする一般的な方法の1つは、アプリをクラッシュさせてから、Xcode Organizerで見つかったアーティファクトを調べることです。 iOSシミュレータのもう1つの方法は、メニューオプションの[ハードウェア]に移動し、[メモリ警告のシミュレーション]オプションを選択することです。
リバースエンジニアリングの経験とジェイルブレイクされたデバイスをお持ちの方は、上記のIntrospyが提供するよりもさらに進んだ一流のツールとして、必ず Snoop-IT をチェックしてください。 Snoop-ITは、「モバイルアプリケーションハッカーのハンドブック」および「iOS侵入テストの学習」の本でも大きく取り上げられています。ただし、gdbの経験がある人に対する私の一番の推奨事項は、 NetSPIで概説されているテクニック に従って、アプリのヒープ全体にアクセスすることです。その他の手法には、ジェイルブレイクされたデバイスで sing lldbdebugserver を使用する more-detailedmSecLabブログ 、ただし versprite 、 isa56k 、および lldbpy via lifeform-labs についてもカバーします。ジェイルブレイクされたデバイス(または任意のOS Xインストール)について言及する最後の手法は、KDebugメカニズムを利用する kdvツール ですが、- readkmemなどの他のカーネルメモリダンプオプションも利用できます。 。 [〜#〜] memscan [〜#〜] とRadare(CydiaへのRadareリポジトリの追加に関するNetSPIブログ投稿を参照)は、iOSのジェイルブレイクされたデバイス上のプロセスメモリの検索またはダンプにも使用できます。
IOSシミュレーターで実行できるいくつかの手法があります。最近の著書 『iOS Application Security』では、これらの多くについて詳しく説明しています。また、iOSにも適用されるため、OS Xで一般的に行われているものなど、いくつかのアンチアンチリバーステクニックを確認することをお勧めします。たとえば、OS X用のゲームトレーナー ビットスライサー とその基礎となる技術をマッピングできます。デバッグに関する基本的な問題(たとえば、上記のNetSPI gdbテクニックが機能しない場合)は、この作者が MyWi反転中のアンチデバッグ の作業で問題に遭遇したときに見られるように、idapythonで解決できます。この anti-anti-debuggingに関する記事 が示唆しているように、 pang と呼ばれるGitHubプロジェクトとして形式化されたテクニックのカタログは、 Onyx-という名前の別のGitHubプロジェクトによってバイパスできます。 the-Black-Cat 。他にも多くの逆の課題があるので、 ReverseEngineering.StackExchangeタグセットfor iOS または同様のリソースを確認することをお勧めします。
投獄されたデバイスについては、 repackaging apps with cycriptおよび/または Frida を調べることをお勧めします。リモートCycriptシェルを取得できる場合は、ジェイルブレイクされたデバイスで行うように、 アプリのメモリを分析するためのmSecLabメソッド を使用できます。
アプリケーションで使用されるすべての変数は、メモリに格納されます。ただし、メモリは、iOSアプリのサンドボックスの影響を受けるものの一部ではありません。アプリサンドボックスは、アクセスできるファイルを考慮して、侵害が及ぼす影響を制限します。
とにかく、あるアプリケーションが別のアプリケーションのメモリにアクセスすることはできません。オペレーティングシステムがメモリを管理し、すべてのプロセスにvirtual address spaceを提供するため、これは不可能です。つまり、すべてのプロセスは、他のプロセスが存在しないかのようにメモリを調べます。
別のプロセスのメモリにアクセスするには、ユーザーはroot(UNIX)または管理(Windows)特権が必要です。これらの権限を持つユーザーは、OSが提供するメソッドを使用して、任意のプロセスのメモリをダンプできます。攻撃者がメモリ全体をダンプしたい場合、デフォルトではそのようなツールはありませんが、ドライバに注入するか(Windows)、カーネルモジュールをインストールして(UNIX)メモリに直接アクセスできます。
したがって、実行できるアクションはいくつかあります一般に。私はApple iOS開発者ではないので、これらのすべての攻撃が実行可能かどうかはわかりません。リバースエンジニアリングの戦術の概要を提供しようとしています。
Debugger。XCodeに標準で付属しているようなデバッガー(LLDBG)または別のデバッガーを接続すると、攻撃者がプログラムの値を表示できる可能性があります。もちろん、デバッグシンボルなどがないと、意味のある情報を見つけるのが非常に難しくなります。しかし、十分な時間、忍耐、そして解決策があれば、この価値を見つけることができます。もちろん、これはアプリが電話ではなく、エミュレーション環境のような開発環境で実行されることを意味します。しかし、それはAppleの開発ツールチェーンで簡単に調整できます。
ソースコード/バイナリ変更。これはデバッガに似ています。アセンブリとバイトコードを簡単に解明できる人がいます。それが起こったら、バイナリを変更してプライベートな値を出力することは彼らの手段の範囲内にあるでしょう。 .ipaファイル(アプリのバイナリ)を取得するには、デバイスのiTunesライブラリを参照します。詳細は次のとおりです Think Different Answer。
メモリエディタ。これらのプログラムは、プロセスに割り当てられたメモリアドレスを調べることができます。これらのツールは通常、システムレベルのアクセスを必要としますが、Appleデバイスの場合は「脱獄」が存在します。アプリに割り当てられたメモリスペースを確認して確認するメモリエディタアプリを誰かが作成する可能性がありますプライベート変数の場合、これを行うには高度な技術知識が必要です。
デバイスストレージを検索しています。その変数を任意の時点でディスクにキャッシュすると、フォレンジック手法を使用してデバイスストレージを読み取り、キャッシュされたデータを確認できます。以下は、このテクニックを使用して、人気のメッセージングアプリであるSignalによってキャッシュされたデータを確認する人の サンプル写真 です。 フルツイートへのリンク。
SANSは、iPhone向けの非常に有益なフォレンジックガイドを公開しています 彼らのウェブサイトに 。ここでは関連する部分(セクション1.1.6)を再現しますが、詳細と個人的な開発のために読むことを強くお勧めします。
ITunesストアからアプリケーションを取得すると、新しいディレクトリがMobile/Applicationフォルダーに自動的に作成されます。このディレクトリには、各アプリケーションに関連付けられたファイルが保持され、Apple(例:GA07A3WW-0E39-33OJ-B947-9CAA16688G22)によって32文字の英数字の一意の識別子が割り当てられます。この一意のIDはすべてのiOSデバイスで一貫しています。通常、各アプリケーションフォルダーにはいくつかの共通サブフォルダーがあります。そのアプリケーションに関連するファイルのドキュメントフォルダー、一時ランタイムファイルの一時フォルダー、設定のライブラリフォルダー、およびキャッシュデータです。共通ファイルは、ほとんどのアプリケーションフォルダー内にあります。 info.plist、resourcerules.plist、applestores.dbとして。アプリケーションに応じて、さまざまな構成ファイル、plistファイル、XMLデータが見つかります。審査官は、証拠の提供に役立つユーザー名とパスワードのデータ、Cookie、または画像をときどき見つけることができます調査のため©2012 TheSANSInstitute
#1と#2の技術的な実装についての参考資料: