私は現在、著作権侵害に対する最初の防衛線としてLVLとProguardの組み合わせを使用しています。
しかし、リソース文字列はどうですか?たとえば、「ライセンスチェックに失敗しました」のようなリソース文字列がある場合、海賊はそのリソースIDをコードで使用された場所までさかのぼって追跡する必要はありませんか?実際、これは、文字列が「devに連絡してください」のような一般的なものである場合にも当てはまります。
最善のアプローチは何ですか?
私は現在、著作権侵害に対する最初の防衛線としてLVLとProguardの組み合わせを使用しています。
しかし、リソース文字列はどうですか?たとえば、「ライセンスチェックに失敗しました」のようなリソース文字列がある場合、海賊はそのリソースIDをコードで使用された場所までさかのぼって追跡する必要はありませんか?実際、これは、文字列が「devに連絡してください」のような一般的なものである場合にも当てはまります。
最善のアプローチは何ですか?
リソース文字列を定義する場合、おそらく次の場所で定義または使用します。
コンパイル後、リソース文字列、その名前、およびその整数コードは次のようになります。
ProGuard はR$string.class を完全に削除しますが、Android 逆コンパイラはresources.arscからすべての情報を再構築できます。まだ少し手間がかかりますが、文字列は実際にコードの目的を示唆している可能性があります (特定の API 呼び出しと共に)。
Google のプレゼンテーションEvading Pirates and Stopping Vampiresで提案されているように、コード内の文字列を暗号化/難読化し、リフレクションを使用して特定の API にアクセスすることで、これを改善できます。
Android 用の ProGuard のクローズド ソース兄弟であるDexGuardは、(API 呼び出しとクラス全体と共に) 文字列を暗号化できます。これは、ソース コードに負担をかけずに、手動で達成するよりもおそらく効率的です。
(私は ProGuard と DexGuard の開発者です)
Android で重要な文字列を隠したいときは、それらを ac/c++ ライブラリに入れます。次に、JNI 呼び出しを使用してそれらを取得します。Cライブラリでは、さらに進んで、文字列を16進数に変換し、同じ文字列を取得するときに、16進数から整数に再度変換します。ハッカーが c/c++ ライブラリを表示しようとすると、秘密の文字列を見つけるのが非常に難しくなります (特に 16 進数に変換されている場合)。
これは素晴らしい記事であり、それを始める方法です。