デバッグモードを有効にしてAndroidアプリケーションを公開しないでください)というセキュリティ慣行があります。
攻撃者はapktoolを使用してアプリケーションを逆コンパイルできますが、AndroidManifest.xmlでデバッグフラグを有効にして再コンパイルしますが、実際にアプリケーションをデバッグモードで公開しないとどうなりますか?
有用であるためには、それを逆コンパイル防止技術と組み合わせる必要がありますか?
後でデバッグフラグを逆コンパイルして有効にするときにアクセスできない、デバッグモードのアプリケーションに追加情報が含まれていますか?
これは、C/C++プログラムを_-g
_フラグでリリースしたくないのと同じ理由である可能性があります。不要なシンボルは取り除かれるか、難読化される可能性があります。ビルドシステムは、アプリケーションのデバッグを大幅に容易にする特定のセキュリティ対策を省略する場合があります。プロガードビルドスクリプトは、デバッグビルドに含まれていない可能性があります。
以下は、構成に応じてデバッグビルドに保持できるさまざまなタイプのデータです。うまくいけば、これらがアプリケーションのリバースエンジニアリングを検討している人に役立つ理由を理解できます。
デバッグシンボル
デバッグシンボルは、デバッグバイナリ内に格納される情報の一部です。すべての関数名、ファイル名、場合によっては行番号も含まれます。これは、プログラムがクラッシュしてデバッガーがアタッチされたときに、この情報のすべてをスタックトレースに含めることができるようにするためです。これにより、プログラマはバグの原因となっているコード行を特定できます。デバッグスタックトレースは次のようになります( この回答から取得 )。
_Exception in thread "main" Java.lang.NullPointerException
at com.example.myproject.Book.getTitle(Book.Java:16)
at com.example.myproject.Author.getBookTitles(Author.Java:25)
at com.example.myproject.Bootstrap.main(Bootstrap.Java:14)
_
デバッグシンボルのないプログラムは、ライブラリ定義のみを認識します。次のように:
_Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff7fd3700 (LWP 22532)]0x00007fffe10002b4 in ?? ()
(gdb) bt
#0 0x00007fffe10002b4 in ?? ()
#1 0x0000000000000202 in ?? ()
#2 0x00007fffe1000160 in ?? ()
#3 0x00007ffff66bd1a9 in execute_internal_vm_tests () at /home/bionix/Openjdk8/hotspot/src/share/vm/prims/jni.cpp:5128
#4 0x00007ffff7fd2550 in ?? ()
#5 0x00007ffff6b08bf8 in VM_Version::get_cpu_info_wrapper () at /home/bionix/Openjdk8/hotspot/src/cpu/x86/vm/vm_version_x86.cpp:395
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
_
Androidビルドスクリプト(Gradle)内には、ProGuardへの参照があります。ProGuardは、バイナリサイズの最適化、縮小、コードの難読化に使用されます。Java =完全に逆コンパイルできますAndroid ProGuardを使用してコードを難読化します。ProGruardで難読化されたコードの例を次に示します:
_// Before
btnNew = changeButtonLabel(btnNew, language.getText("new"));
btnOpen = changeButtonLabel(btnOpen, language.getText("open"));
// After
d = a(d, n.a("new"));
e = a(e, n.a("open"));
_
完全なチュートリアル とソースコードへのリンクを表示できます。
Androidドキュメントから:
ProGuardはAndroidビルドシステムに統合されているため、手動で呼び出す必要はありません。ProGuardは、アプリケーションをリリースモードでビルドするときにのみ実行されるため、難読化されたコードを処理する必要はありませんアプリケーションをデバッグモードでビルドしたとき。
ProGuardは技術的にオプションですが、Android Studioを使用する場合、リリースビルドではデフォルトで有効になっています。
デバッグログ
リリースアプリケーションからデバッグメッセージを削除するためのメカニズムを常にコードに含める必要があります。デバッグメッセージはバイナリ内に文字列として保存され、難読化されません。つまり、Log.d("Key " + super_secrey_key);
のようなメッセージがある場合、バイナリを分析する人は_"Key "
_が参照されている場所を知ることができます。これで、コンテキストと、分析を開始するための興味深い場所が提供されました。
デバッグログを削除する方法はいくつかありますが、そのうちの1つは、ProGuardがそれらを取り除くように構成することです。 その他のライブラリ も使用できます ロギングをラップする 。どちらの方法でも、ログメッセージのデバッグとリリースを区別することが重要です。
アプリのリバースエンジニアリングを簡単にしたくありません。特に、バックエンドのパスワードや秘密鍵の資料などの機密データが含まれている場合。安全を確保するためには、アプリにそのような秘密情報を含めるべきではないことに同意しますが、現実は難しい場合があります。
あなたはそれを述べました:
攻撃者はapktoolを使用してアプリケーションを逆コンパイルできますが、AndroidManifest.xmlでデバッグフラグを有効にして再コンパイルできますが、実際にデバッグモードでアプリケーションを公開しないとどうなりますか?
アプリに改ざん防止対策が講じられている場合(たとえば、独自の整合性をチェックする場合)、攻撃者はこれを回避することができない可能性があります。
そのため、改ざん対策を無効にできない限り、デバッグモードを無効にしてアプリを公開すると、アプリをデバッグモードで実行できなくなります。