これは人々が何年も追い求めてきた問題であり、十分にやる気のあるスキルを持つ人なら誰でも、あなたが知りたくない情報を見つける方法を見つけることができます。その情報がデバイスに保存されていれば、 .
脱獄しなくても、購入またはダウンロードしたバイナリを使用してアプリを逆アセンブルすることができます。これは静的検査であり、標準の分解ツールを使用すると容易になります。ただし、リンカーからシンボルを追加し、何が起こっているのかを理解できるようにメソッド呼び出しを十分に理解できるツールが必要です。これがどのように機能するかを知りたい場合は、hopperをチェックしてください。これは、非常に優れた分解/リバース エンジニアリング ツールです。
特に問題の安全なログに関しては、動機のある攻撃者がいる場合、より大きな問題があります: システムベースの中間者攻撃です。この場合、攻撃者はシステムで使用されているネットワーク コードをシムアウトし、標準のネットワーク経由で送信されるものをすべて見ることができます。したがって、暗号化されていないデータを OS またはライブラリ レベルで「安全な」パイプに送信できることに依存して、それが表示されないことを期待することはできません。少なくとも、データをパイプに入れる前に暗号化する必要があります (つまり、プレーン テキストを標準の SSL ライブラリに送信することに依存することはできません)。独自の SSL ライブラリ セットをコンパイルしてアプリに直接リンクすることができます。これは、システム パフォーマンスとセキュリティの強化が時間の経過とともに得られないことを意味しますが、必要に応じて SSL ライブラリを手動でアップグレードできます。
ただし、これはすべて、攻撃者が十分な動機を持っていることを前提としています。簡単に達成できる問題を取り除けば、カジュアルなハッカーがシステムを簡単に突き止めようとするのを防ぐことができるかもしれません。避けるべきいくつかのこと:
- 暗号化の両側に平文の暗号鍵を保存する
- 特定の名前のリソースにキーを保存する (名前が付けられたファイル
serverkey.textまたは名前が含まれる plist に保存されたキーkeyは両方ともクラシックです)
- 可能な限り単純なパスワードを避ける
ただし、最も重要なのは、アプリケーション自体に格納されているキー (存在する場合) が、ユーザーが自分で (直接、または OAUTH などのシステムを介して間接的に) 入力しなければならない情報なしでは役に立たないシステムを作成することです。サーバーは、信頼できるユーザーと何らかの対話を行うことなく、重要な操作についてクライアントを信頼するべきではありません。
Apple のキーチェーンは、OAUTH シーケンス中に取得されたトークンなどの認証トークンを格納するのに適した場所を提供します。API は少し使いにくいですが、システムはしっかりしています。
結局のところ、問題は、あなたが何をしようとも、対策を破るのに必要な作業量を増やしているだけだということです。攻撃者は方程式のすべての重要な部分を制御できるようになるため、最終的にはデバイス上のすべてのものを無効にします. サーバーを保護して悪用を監視するのに対して、クライアントを保護するためにどれだけの労力を費やすかを決定する必要があります。攻撃者はデバイス上のすべてのカードを保持しているため、より良いアプローチは、目標を強化するためにサーバーに実装できる方法になります。