APKファイルのリバースエンジニアリングを回避する方法
Android用に支払い処理アプリケーションを開発しています。ハッカーが _ apk _ ファイルからリソース、アセット、またはソースコードにアクセスできないようにします。 。
誰かが.apk拡張子を.Zipに変更すると、それを解凍してアプリケーションのすべてのリソースとアセットに簡単にアクセスでき、 dex2jar とJavaデコンパイラを使用してソースコードにもアクセスできます。 Android APKファイルをリバースエンジニアリングするのは非常に簡単です。詳細については、Stack Overflow questionを参照してください。 APKファイルからプロジェクトへのリバースエンジニアリング。
Android SDKに付属のProguardツールを使用しました。署名付きキーストアとProguardを使用して生成されたAPKファイルをリバースエンジニアリングすると、難読化されたコードが生成されます。
ただし、Androidコンポーネントの名前は変更されておらず、アプリで使用されているKey-Valueなどのコードも変更されていません。 Proguardのドキュメントによると、このツールはマニフェストファイルに記載されているコンポーネントを難読化することはできません。
今私の質問は次のとおりです。
- どうすればAndroid APKのリバースエンジニアリングを完全に防ぐことができますか？これは可能ですか？
- ハッカーがAPKファイルをハッキングできないように、アプリのすべてのリソース、アセット、およびソースコードを保護するにはどうすればよいですか。
- ハッキングをさらに困難に、または不可能にさえする方法はありますか？APKファイルのソースコードを保護するために、さらに何ができますか？
1. Android APKのリバースエンジニアリングを完全に回避するにはどうすればよいですか。これは可能ですか？
私の知る限りでは、リバースエンジニアリングを完全に回避するためのトリックはありません。
あなたのコードに対して何をしたとしても、潜在的な攻撃者はそれを実行可能な方法で変更することができます。あなたのアプリケーションを変更から保護することはできません。そしてあなたがそこに入れたどんな保護も無効にされるか、取り除かれることができます。
2.ハッカーがAPKファイルをハッキングできないように、アプリのすべてのリソース、アセット、およびソースコードを保護するにはどうすればよいですか。
あなたはハッキングをより困難にするためにあなたは異なるトリックをすることができます。たとえば、難読化を使用します（Javaコードの場合）。これは通常リバースエンジニアリングをかなり遅くします。
3.ハッキングをさらに困難にする、または不可能にする方法さえありますか。 APKファイルのソースコードを保護するために他に何ができますか？
誰もが言うように、そしておそらくご存知のとおり、100％のセキュリティはありません。しかし、グーグルが構築したアンドロイドの出発点はProGuardです。 共有ライブラリ を含めるオプションがある場合は、ファイルサイズ、統合などを検証するために必要なコードをC++に含めることができます。ビルドごとにAPKのライブラリフォルダに外部ネイティブライブラリを追加する必要がある場合は、あなたは以下の提案によってそれを使うことができます。
プロジェクトフォルダー内のデフォルトの "libs"になるネイティブライブラリパスにライブラリを配置します。 'armeabi' ターゲット用のネイティブコードをビルドした場合は、 libs/armeabi の下に置きます。 armeabi-v7a でビルドされた場合は、 libs/armeabi-v7aの下に置きます。
<project>/libs/armeabi/libstuff.so
私の知るところでは、/ resディレクトリ内のファイルは、現在保護されている以上に保護することはできません。
しかしながら、あなたのソースコードを保護するためにあなたが取ることができるステップ、または少なくともそれがすべてではないにしても何ができるかがあります。
- ProGuardなどのツールを使用してください。不可能ではないにしても、これらはあなたのコードを難読化し、逆コンパイル時に読みにくくします。
- サービスの最も重要な部分をアプリの外に移動し、PHPのようなサーバー側の言語の背後に隠れているWebサービスに移動します。例えば、あなたが書くのにあなたが百万ドルを要するアルゴリズムを持っているならば。あなたは明らかに他の人があなたのアプリからそれを盗んで欲しくはありません。アルゴリズムを移動してリモートサーバー上のデータを処理し、アプリを使用してデータを単純に提供します。あるいは、NDKを使用してネイティブに.soファイルに書き込むこともできます。これは、apksよりも逆コンパイルされる可能性がはるかに低いです。私は、.soファイル用のデコンパイラーが今のところ存在しているとは思わない（そして、たとえそれが存在したとしても、それはJavaデコンパイラーほどには良くない）。さらに、コメントで@nikolayが述べたように、サーバーとデバイス間でやり取りするときはSSLを使用する必要があります。
- デバイスに値を保存するときは、生のフォーマットで保存しないでください。たとえば、あなたがゲームを持っていて、ユーザーが持っている金額をゲーム通貨でSharedPreferencesに保存しているとします。それが
10000コインだと仮定しましょう。直接10000を保存する代わりに、((currency*2)+1)/13のようなアルゴリズムを使用して保存してください。そのため、10000の代わりに、1538.53846154をSharedPreferencesに保存します。しかし、上の例は完璧ではありません、そして丸め誤差などに通貨を失うことのない方程式を考え出すためにあなたは努力しなければなりません。 - サーバーサイドのタスクについても同様のことができます。例として、実際にあなたの支払い処理アプリを取りましょう。ユーザーが
$200の支払いをしなければならないとしましょう。生の$200値をサーバーに送信する代わりに、合計で$200になる一連の小さい事前定義済みの値を送信します。たとえば、サーバー上にファイルとテーブルを配置して、単語と値を同じものにします。Charlieは$47に、Johnは$3にそれぞれ対応するとしましょう。そのため、$200を送信する代わりに、Charlieを4回、Johnを4回送信することができます。サーバー上で、それらが意味するものを解釈し、それを合計します。これは、どのWordがどの値に対応しているのかわからないため、ハッカーがサーバーに任意の値を送信するのを防ぎます。追加のセキュリティ対策として、これについてもポイント3と同様の式を使用し、n日数ごとにキーワードを変更できます。 - 最後に、ハッカーが干し草の山の中で針を探しているように、ランダムな無駄なソースコードをアプリに挿入することができます。インターネットからの断片を含むランダムなクラスを挿入するか、あるいはフィボナッチ数列のようなランダムなものを計算するための関数だけを挿入します。これらのクラスがコンパイルされていることを確認してください。ただし、アプリの実際の機能では使用されません。これらの偽のクラスを十分に追加すると、ハッカーはあなたの本当のコードを見つけるのに苦労するでしょう。
全体として、アプリを100％保護する方法はありません。難しくすることはできますが、不可能ではありません。あなたのWebサーバは危険にさらされるかもしれません、ハッカーは複数の取引金額とあなたがそれのために送るキーワードを監視することによってあなたのキーワードを見つけることができます.
あなただけが反撃することができますが、決して勝つことはできません。
コンピューティングの歴史のどの時点でも、ソフトウェアの作業用コピーを攻撃者に渡すときに、ソフトウェアのリバースエンジニアリングを防ぐことはできませんでした。また、ほとんどの場合、不可能になる。
それを理解すると、明らかな解決策があります：攻撃者に秘密を明かさないでください。APKのコンテンツを保護することはできませんが、あなたがcan保護するものはあなたが配布しないものです。通常、これはアクティベーション、支払い、ルール施行、その他のジューシーなコードなどに使用されるサーバー側のソフトウェアです。貴重な資産を保護するには、APKでnot配布します。代わりに、アプリからのリクエストに応答するサーバーをセットアップし、アセットを「使用」して（意味が何であれ）、結果をアプリに送り返します。念頭に置いている資産に対してこのモデルが機能しない場合は、戦略を再考する必要があります。
また、アプリの著作権侵害を防止することが主な目的の場合：迷惑をかけないでください。海賊版対策があなたを救うことを望んでいた以上に、あなたはすでにこの問題に多くの時間とお金を費やしました。この問題を解決するための投資収益率は非常に低いため、それについて考えることすら意味がありません。
アプリのセキュリティに関する最初のルール：攻撃者が無制限の物理的または電子的アクセスを取得したコンピュータは、実際の場所や料金に関係なく、攻撃者に属します。
アプリのセキュリティに関する第2の規則：攻撃者が侵入できない物理的境界を超えるソフトウェアは、コーディングに費やした時間に関係なく、攻撃者に属します。
3つ目のルール：攻撃者が侵入できない同じ物理的境界を離れた情報は、あなたにとってどれだけ価値のあるものであっても、あなたの攻撃者に帰属します。
情報技術セキュリティの基盤は、これら3つの基本原則に基づいています。本当に安全な唯一のコンピュータは、ファラデーケージの中、スチールケージの中の金庫にロックされているものです。ほとんどのサービス寿命をこの状態で過ごすコンピューターがあります。 1年に1回（またはそれ以下）、信頼できるルート証明機関の秘密鍵を生成します（自分たちが居る部屋の各インチをカメラで記録している証人のホストの前で）。
現在、ほとんどのコンピュータはこのような環境では使用されていません。彼らは物理的に屋外にいて、無線の無線チャネルでインターネットに接続されています。要するに、彼らは彼らのソフトウェアと同様に脆弱である。したがって彼らは信頼されるべきではありません。コンピュータとそのソフトウェアが有用であるために知っていなければならないことや、する必要があることを確実にする必要があります。 ）.
あなたはすでにこれらすべてを知っていました。それがあなたがあなたのアプリケーションのコードを保護しようとしている理由です。しかし、そこには最初の問題があります。難読化ツールを使用すると、人間がコードを掘り下げることができなくなりますが、プログラムを実行する必要があります。つまり、アプリの実際のロジックフローとそれが使用するデータは難読化の影響を受けません。ちょっとした粘り強さを考えれば、攻撃者は単にコードを難読化解除することができます。それは、自分が探しているものが他に何もできない場合がある場合でも、必要ではありません。
その代わりに、攻撃者がコードの明確なコピーを入手するのがどれほど簡単であっても、攻撃者が自分のコードを操作できないようにする必要があります。つまり、ハードコーディングされた秘密はありません。コードが開発された建物を離れてすぐに秘密になることはないからです。
ハードコーディングしたこれらのKey-Valueは、アプリケーションのソースコードから完全に削除する必要があります。代わりに、それらは3つの場所のうちの1つにあるべきです。デバイス上の揮発性メモリ。攻撃者がオフラインコピーを入手するのは困難ですが、不可能ではありません。恒久的にサーバークラスタにアクセスし、そこへのアクセスを鉄拳で制御します。あるいは、物理カードやユーザーのメモリなど、デバイスやサーバーとは無関係の2番目のデータストアに保存します（最終的には揮発性メモリに保存されますが、長期間保存する必要はありません）。
次のスキームを検討してください。ユーザーはアプリの認証情報をメモリからデバイスに入力します。残念ながら、ユーザーのデバイスがキーロガーやトロイの木馬によって既に侵害されていないことを信頼する必要があります。この点に関してあなたができる最善のことは、ユーザーが使用したデバイスに関する偽りにくい識別情報（MAC/IP、IMEIなど）を覚え、少なくとも1つの追加チャンネルを提供することによって、多要素セキュリティを実装することです。なじみのないデバイスへのログイン試行を検証できます。
認証情報は、いったん入力されると（セキュアハッシュを使用して）クライアントソフトウェアによって難読化され、プレーンテキストの認証情報は破棄されます。彼らは彼らの目的を果たしました。難読化された資格情報は、セキュリティで保護されたチャネルを介して証明書認証サーバーに送信され、 再び がハッシュされて、ログインの有効性を検証するためのデータが生成されます。このようにして、クライアントは実際にデータベース値と比較されるものを知ることはなく、アプリケーションサーバーは検証のために受け取るものの背後にある平文の資格情報を知ることがなく、データサーバーは検証用に格納するデータの生成方法を知りません。安全なチャネルが危険にさらされていても、真ん中はぎこちなく見えます。
検証されると、サーバーはチャネルを介してトークンを送り返します。このトークンは安全なセッション内でのみ有効で、ランダムノイズまたはセッション識別子の暗号化された（したがって検証可能な）コピーで構成され、クライアントアプリケーションはこのトークンをリクエストの一部として同じチャネルでサーバーに送信する必要があります。何かをするために。クライアントアプリケーションはこれを何度も実行します。なぜなら、お金、機密データ、またはそれ自体で損害を与える可能性のあるその他のことを含むことはできないからです。代わりにサーバーにこのタスクを実行するように依頼する必要があります。クライアントアプリケーションは、少なくともプレーンテキストではなく、機密情報をデバイス自体の固定メモリに書き込むことはありません。クライアントは、ローカルチャネルを暗号化するための対称鍵をセキュアチャネル経由でサーバに要求することができます。これはサーバが記憶しています。後のセッションで、クライアントは揮発性メモリで使用するためにデータを復号化するために同じキーをサーバに要求できます。そのデータも唯一のコピーではありません。クライアントストアが何らかの形でサーバーに送信する必要もあります。
明らかに、これはあなたのアプリケーションをインターネットアクセスに強く依存させます。クライアント装置は、サーバへの適切な接続およびサーバによる認証がなければ、その基本機能のいずれも実行することができない。本当にFacebookと変わらない。
クライアントのアプリやデバイスではなく、攻撃者が望むコンピュータがあなたのサーバーです。なぜなら、それはクライアントのアプリやデバイスではなく、彼にお金を稼ぐことや他の人々を苦しませることができるからです。それで大丈夫です;あなたは、すべてのクライアントを保護しようとするよりも、サーバーを保護するためにお金と努力を費やすあなたの支出のためにはるかに強打を得ます。サーバーは、あらゆる種類のファイアウォールやその他の電子セキュリティの背後に配置することができ、さらにスチール、コンクリート、キーカード/ピンアクセス、および24時間のビデオ監視の背後に物理的に保護することができます。サーバーに直接アクセスするには、攻撃者が非常に高度な知識を持っている必要があります。その場合は、すぐに知っておく必要があります。
攻撃者ができる最善の方法は、ユーザーの電話番号と資格情報を盗み取り、クライアントの限られた権限でサーバーにログインすることです。クレジットカードを紛失したのと同じように、これが発生した場合は、正規のユーザーに800番の電話をかけるように指示する必要があります。彼らはあなたの顧客サービスに直接それらを接続することができますアクセスできる任意の携帯電話から）モバイルデバイスと一緒に盗まれた。彼らは、自分の電話が盗まれたこと、基本的な一意の識別子を提供すること、アカウントがロックされていること、攻撃者が処理できたトランザクションはすべてロールバックされ、攻撃者は正方形に戻ることを示します。
1. Android APKのリバースエンジニアリングを完全に回避するにはどうすればよいですか？これは可能ですか？
これは不可能です
2.ハッカーがAPKファイルをハッキングできないように、アプリのすべてのリソース、アセット、およびソースコードを保護するにはどうすればよいですか？
誰かが.apk拡張子を.Zipに変更すると、解凍後、誰かがすべてのリソース（Manifest.xmlを除く）を簡単に取得できますが、APKtoolマニフェストファイルの実際のコンテンツも取得できます。繰り返しますが、いいえ。
3.ハッキングをさらに困難にする、または不可能にする方法はありますか？ APKファイルのソースコードを保護するために、さらに何ができますか？
繰り返しますが、あるレベルまで防止できます。つまり、
- Webからリソースをダウンロードし、暗号化プロセスを実行します
- コンパイル済みのネイティブライブラリ（C、C++、JNI、NDK）を使用する
- 常にいくつかのハッシュを実行します（ MD5 / SHA キーまたはその他のロジック）
Smaliであっても、人々はあなたのコードで遊ぶことができます。全体として、不可能ではありません。
Android APKのリバースエンジニアリングを100％回避することはできませんが、ソースコード、APKからのアセット、およびリソースなど、これ以上データを抽出しないようにすることができます。
ProGuardを使用してアプリケーションコードを難読化する
_ ndk _ using CおよびC++ を使用して、アプリケーションのコア部分と安全なコード部分を
.soファイルに入れます。リソースを保護するために、重要なリソースすべてをAPKのアセットフォルダーに含めないでください。初回起動時にこれらのリソースをダウンロードしてください。
開発者は次のようにしてAPKが盗難されるのを防ぐことができます
最も基本的な方法は、コードを難読化するために
ProGuardのようなツールを使用することですが、今までは、誰かがアプリケーションを逆コンパイルするのを完全に防ぐことは非常に困難でした。また、私はツールについて聞いたことがある HoseDex2Jar 。
Dex2Jarを混乱させ、無効にし、コードを逆コンパイルから保護するAndroid APKに無害なコードを挿入することでDex2Jarを阻止します。ハッカーがAPKを読みやすいJavaコードに逆コンパイルするのを妨げる可能性があります。必要な場合にのみアプリケーションと通信するために、サーバー側のアプリケーションを使用してください。それは重要なデータを防ぐのを助けるかもしれません。
まったく、潜在的なハッカーからコードを完全に保護することはできません。どういうわけか、あなたはそれを困難にし、彼らがあなたのコードを逆コンパイルするのを少しいらだらせる仕事にすることができます。最も効率的な方法の1つは、ネイティブコード（C/C++）で書き込み、それをコンパイル済みライブラリとして保存することです。
1. Android APKのリバースエンジニアリングを完全に回避するにはどうすればよいですか。これは可能ですか？
不可能
2.ハッカーがAPKファイルをハッキングできないように、アプリのすべてのリソース、アセット、およびソースコードを保護するにはどうすればよいですか。
不可能
3.ハッキングをさらに困難にする、または不可能にする方法さえありますか。 APKファイルのソースコードを保護するために他に何ができますか？
もっとタフ - 可能だが、実際にはガイドをハッキングするためにグーグルしている普通のユーザーにとっては、もっとタフになるだろう。誰かがあなたのアプリを本当にハックしたいのなら - 遅かれ早かれハックされるでしょう。
1. Android APKのリバースエンジニアリングを完全に回避するにはどうすればよいですか。これは可能ですか？
それは不可能です
2.ハッカーがAPKファイルをハッキングできないように、アプリのすべてのリソース、アセット、およびソースコードを保護するにはどうすればよいですか。
開発者はProGuardのようなツールを使用してコードを難読化するなどの対策を講じることができますが、これまでは、誰かがアプリを逆コンパイルするのを完全に防ぐことは非常に困難でした。
これは非常に優れたツールであり、コードのフットプリントを縮小しながらコードを「元に戻す」ことの難しさを増す可能性があります。
統合されたProGuardのサポート：ProGuardはSDK Toolsに同梱されています。開発者は自分のコードをリリースビルドの統合部分として難読化することができます。
3.ハッキングをさらに困難にする、または不可能にする方法さえありますか。 APKファイルのソースコードを保護するために他に何ができますか？
調べているうちに、 HoseDex2Jar について知るようになりました。このツールはコードを逆コンパイルから保護しますが、コードを完全に保護することは不可能のようです。
参考リンクのいくつかは、あなたがそれらを参照することができます。
- Proguard、Android、およびLicensing Server
- Android LVLアプリケーションの保護
- Stack Overflow question リバースエンジニアリングからAndroidアプリを保護することは本当に不可能ですか？
- Stack Overflow question Android APKファイルのリバースエンジニアリングを防止してコードを保護する方法？
これがあなたが試すことができるいくつかの方法です：
- 難読化 および ProGuard のようなツールを使用してください。
- ソースとデータの一部を暗号化します。
- 改ざんを検出するには、アプリで独自の作り付けのチェックサムを使用します。
- デバッガにロードされないようにコードを導入します。つまり、デバッガを検出してデバッガを終了または終了させることができるようにします。
- 認証をオンラインサービスとして分離します。
- 用途 アプリケーションの多様性
- デバイスを認証する前に、異なるサブシステムからのデバイスのハードウェアシグニチャなどにフィンガープリント技術を使用します。
ここでの主な質問は、dexファイルを逆コンパイルすることができ、そして答えはそれらが「一種の」である可能性があるということです。 dedexer および smali のような逆アセンブラがあります。
正しく設定されたProGuardはあなたのコードを難読化します。 ProGuardの商用拡張バージョンであるDexGuardは、もう少し役立つかもしれません。しかし、あなたのコードはそれでもSmalliに変換することができ、リバースエンジニアリングの経験を持つ開発者はあなたがSmalliから何をしているのか把握することができます。
たぶん良いライセンスを選択し、可能な限り最善の方法で法律によってそれを強制します。
あなたのクライアントは、彼らがしていることを知っていて、正しい決断を下すことができてあなたを指導することができる誰かを雇うべきです。
バックエンドでトランザクション処理システムを変更する能力を持っていることについては上で話しています - あなたはそのようなアーキテクチャの変更をすることを許されるべきではないので、できることを期待しないでください。
これに関する私の論理的根拠：
あなたのドメインは支払い処理なので、PCI DSSやPA DSS（および州/連邦法の可能性）があなたのビジネスにとって重要であると仮定しても問題ありません。あなたが安全であることを示さなければなりません。安全でないことを確かめるには、（テストを通じて）セキュリティが適切なレベルで検証されるまで修正、再テストなどを行います。高価で、遅く、リスクの高い成功への道。適切なことをするために、一生懸命考え、経験豊かな才能を仕事に投入し、安全な方法で開発し、そしてセキュリティが適切なレベルで検証されるまでテスト、修正（少ない）、など（少ない）成功への低リスクの方法。
1つのモバイルペイメントアプリケーション（MyCheck）など、ペイメントプラットフォームに幅広く取り組んでいる人として、この振る舞いをサーバーに委任する必要があると思います。ペイメントプロセッサのユーザー名またはパスワード（どちらでも）は保存しないでください。あなたがコードを難読化したとしてもソースは理解されることができるので、モバイルアプリケーションでハードコードされていて、それはあなたが望む最後のものです。
また、クレジットカードや支払いトークンをアプリケーションに保存しないでください。すべてを再び構築したサービスに委任する必要があります。また、後で利用できるようになり、より簡単にPCIに準拠できるようになります。首に息をしないでください（彼らが私たちのためにやったように）。
リバースエンジニアリングを（ほぼ）不可能にしたい場合は、アプリケーションを耐タンパー性の高いチップに置き、機密性の高いものをすべて内部で実行し、何らかのプロトコルと通信してホスト上でGUIの制御を可能にします。不正開封防止チップでも100％クラック防止できません。彼らは単にソフトウェアの方法よりもはるかに高い水準に設定しています。もちろん、これは不便です。アプリケーションには、チップをデバイスに挿入するための小さなUSBイボが必要です。
この質問は、このアプリケーションを嫉妬して保護したいという動機を明らかにしていません。
目的がアプリケーションのセキュリティ上の欠陥（既知またはその他）を隠すことによって支払い方法のセキュリティを向上させることである場合、それはまったく間違った見方です。実現可能であれば、セキュリティに敏感な部分は実際にはオープンソースであるべきです。あなたは、あなたのアプリケーションをレビューするセキュリティ研究者がそれらのビットを見つけ、それらの動作を精査し、そしてあなたに連絡するのをできるだけ簡単にするべきです。支払いアプリケーションには埋め込み証明書を含めないでください。つまり、工場からの固定証明書を持っているという理由だけでデバイスを信頼するサーバーアプリケーションは存在しないはずです。アプリケーション、プラットフォーム、またはネットワークなどを信頼できないように正しく設計されたエンドツーエンドの認証プロトコルを使用して、支払いトランザクションをユーザーの資格情報だけで行う必要があります。
その改ざん防止チップを除いて、クローン作成を防止することが目的であれば、プログラムをリバースエンジニアリングやコピーから保護するためにできることは何もないので、互換性のある支払い方法を自分のアプリケーションに組み込んで、 「不正なクライアント」になります。許可されていないクライアントを開発するのを困難にする方法があります。 1つは、プログラムの完全な状態のスナップショットに基づいてチェックサムを作成することです。 GUI、ロジック、なんでも。クローンプログラムは、まったく同じ内部状態を持ちません。確かに、それは（入力と出力によって観察されることができるように）類似の外部から見える状態遷移を持つが、ほとんど同じ内部状態を持たないステートマシンです。サーバーアプリケーションはプログラムに問い合わせることができます：あなたの詳細な状態は何ですか？ （つまり、あなたの内部状態変数すべてのチェックサムを教えてください）。これは、本物の状態遷移を経て、サーバー上で並行して実行されるダミーのクライアントコードと比較できます。サードパーティのクローンは、正しい応答をするために本物のプログラムの関連する状態の変更をすべて複製しなければならず、それが開発を妨げることになります。
ここでの他の支持された答えは正しいです。私はただ別の選択肢を提供したいのです。
あなたが重要だと思う特定の機能のためにあなたはあなたのアプリで WebView コントロールをホストすることができます。その後、機能はWebサーバーに実装されます。アプリケーションで実行されているように見えます。
ソフトウェアアプリケーションを攻撃から保護するを参照することをお勧めします。それは商業的なサービスです、しかし、私の友人の会社はこれを使いました、そして、彼らはそれを使ってうれしいです。
Android NのAPK署名スキームv2
PackageManagerクラスは、APK署名方式v2を使用したアプリの検証をサポートします。 APK署名方式v2は、APKファイルへの不正な変更を検出することで検証速度を大幅に向上させ、整合性保証を強化するファイル全体の署名方式です。
下位互換性を維持するために、APKはv2署名スキームで署名される前にv1署名スキーム（JAR署名スキーム）で署名されなければなりません。 v2署名スキームでは、v2スキームで署名した後に追加の証明書でAPKに署名すると、検証は失敗します。
APK署名方式v2のサポートは、N開発者向けプレビューの後半で利用可能になる予定です。
http://developer.Android.com/preview/api-overview.html#apk_signature_v2
REを完全に回避することはできませんが、内部的に複雑にすることにより、攻撃者がアプリの明確な操作を見にくくし、攻撃ベクトルの数を減らすことができます。
アプリケーションが機密性の高いデータを処理する場合、コードのリバースエンジニアリングの複雑さを増す可能性のあるさまざまな手法が存在します。 1つの手法は、C/C++を使用して、攻撃者による簡単なランタイム操作を制限することです。非常に成熟しており、AndroidがJNIを簡単に統合できる十分なCおよびC++ライブラリがあります。攻撃者は、アプリケーションを低レベルで攻撃するために、最初にデバッグの制限を回避する必要があります。これにより、攻撃がさらに複雑になります。 Androidアプリケーションでは、アプリケーションマニフェストにAndroid：debuggable =” false”を設定して、攻撃者またはマルウェアによる実行時の簡単な操作を防止する必要があります。
トレースチェック –アプリケーションは、現在デバッガーまたはその他のデバッグツールによってトレースされているかどうかを判断できます。トレースされる場合、アプリケーションは、ユーザーデータを保護するための暗号化キーの破棄、サーバー管理者への通知、または自己防衛を試みるその他のタイプの応答など、考えられる攻撃応答アクションをいくつでも実行できます。これは、プロセスステータスフラグを確認するか、ptrace接続の戻り値の比較、親プロセス、プロセスリスト内のブラックリストデバッガーの確認、プログラムのさまざまな場所のタイムスタンプの比較などの他の手法を使用して判断できます。
最適化-高度な数学的計算や他のタイプの複雑なロジックを隠すために、コンパイラー最適化を活用すると、obfuscate攻撃者が簡単に分解できないようにオブジェクトコードを助けることができます攻撃者が特定のコードを理解することはより困難です。 Androidでは、NDKでネイティブにコンパイルされたライブラリを利用することで、これをより簡単に実現できます。さらに、LLVM難読化ツールまたはプロテクターSDKを使用すると、マシンコードの難読化が向上します。
バイナリの除去 –ネイティブバイナリの除去は、アプリケーションの低レベル機能の構成を表示するために、攻撃者に必要な時間とスキルレベルを増加させる効果的な方法です。バイナリを削除すると、バイナリのシンボルテーブルが削除されるため、攻撃者はアプリケーションを簡単にデバッグしたり、リバースエンジニアリングしたりできません。sstripingやUPXの使用など、GNU/Linuxシステムで使用されている手法を参照できます。
そして最後に、難読化とProGuardなどのツールについて注意する必要があります。
こちら@Muhammad Saqibに同意： https://stackoverflow.com/a/46183706/2496464
そして@Mumairは良いスタートステップを与える： https://stackoverflow.com/a/35411378/474330
ユーザーのデバイスに配布するすべてのものがユーザーに属していると見なすのが常に安全です。簡潔でシンプル。あなたはあなたの知的財産を暗号化するために最新のツールと手順を使うことができるかもしれませんが、決心した人があなたのシステムを「研究する」ことを妨げる方法はありません。たとえ現在の技術が彼らが望まないアクセスを得ることを困難にするかもしれないとしても、明日、あるいはちょうど次の1時間でさえある簡単な方法があるかもしれません！
したがって、ここで方程式が来ます：
When it comes to money, we always assume that client is untrusted.
ゲーム内経済のように単純なものでも。 （特にゲームでは！もっと '洗練された'ユーザーがいて、抜け穴が数秒で広がります！）
どのように私たちは安全を保ちますか？
すべてではないにしても、ほとんどの主要処理システム（そしてもちろんデータベース）はサーバー側にあります。そしてクライアントとサーバーの間には、暗号化された通信、検証などがあります。それがシンクライアントの考え方です。
APKのリバースエンジニアリングを完全に回避する方法はありません。アプリケーション資産、リソースを保護するために、暗号化を使用できます。
- 暗号化すると、復号化せずに使用するのが難しくなります。強力な暗号化アルゴリズムを選択すると、クラッキングが難しくなります。
- クラッキングをより困難にするために、メインロジックにいくつかのなりすましコードを追加します。
- 重要なロジックを任意の母国語で書くことができ、それが確実に逆コンパイルを難しくする場合。
- Quixxi のようなサードパーティ製セキュリティフレームワークを使用する
基本的には不可能です。それは不可能になるでしょう。しかし、希望はあります。 難読化プログラム を使用すると、一般的な攻撃を実行するのがはるかに困難になります。
- メソッド/クラスの名前を変更する（つまり、逆コンパイラでは
a.aのような型になります） - 難読化された制御フロー（したがって、逆コンパイラではコードは読みにくくなります）
- 文字列とおそらくリソースを暗号化する
他にもあると思いますが、それが主なものです。私はPreEmptive Solutionsという会社で .NET obfuscatorに取り組んでいます。彼らはまた、Android用に動作するJava難読化ツール、および DashO を持っています。
ただし、難読化には常に代償が伴います。特に、パフォーマンスは通常劣っています、そしてそれは通常リリースのまわりで余分な時間をいくらか必要とします。しかし、あなたの知的財産があなたにとって非常に重要であるならば、それは通常それが価値があります。
そうでなければ、あなたの唯一の選択はあなたのAndroidアプリケーションがあなたのアプリケーションのすべての本当のロジックをホストするサーバーにパススルーするようにすることです。アプリを使用するにはユーザーがインターネットに接続する必要があることを意味するため、これには独自の問題があります。
また、この問題があるのはAndroidだけではありません。すべてのApp Storeで問題になります。パッケージファイルに到達するのがどれほど難しいかということだけです（たとえば、iPhoneではそれほど簡単ではないと思いますが、それでも可能です）。
TPMチップ（Trusted Platform Module）が保護されたコードを管理することになっていませんか？それらはPC（特にAppleのもの）で一般的になりつつあり、それらは今日のスマートフォンチップに既に存在するかもしれません。残念ながら、それを利用するためのOS APIはまだありません。うまくいけば、Androidはこの1日のサポートを追加するでしょう。これは、コンテンツのDRMをクリーンにするための鍵でもあります（GoogleがWebMのために取り組んでいます）。
エンドユーザーの手に渡って安全な方法はありませんが、一般的な方法で攻撃者がデータを盗むのが困難になることがあります。
- メインロジック（アルゴリズム）をサーバーサイドに置きます。
- サーバーとクライアントと通信します。サーバーとクライアントの通信がSSLまたはHTTPSで保護されていることを確認してください。または他の手法のキーペア生成アルゴリズム（ECC、RSA）を使用する。機密情報がエンドツーエンドで暗号化されたままであることを確認してください。
- セッションを使用し、特定の時間間隔の後にそれらを期限切れにします。
- リソースを暗号化し、オンデマンドでサーバーからそれらを取得します。
- または
webviewを介してシステムにアクセスするハイブリッドアプリをサーバー上のリソース+コードから保護することができます
複数のアプローチこれはあなたが performance および security の間で犠牲にしなければならないのは明らかです
あなたのアプリがこれに敏感であるならば、あなたはサーバー側の支払い処理部分を考慮する必要があります。支払い処理のアルゴリズムを変更してみてください。 Androidアプリを使用するのは、ユーザー情報（アカウントの残高など）を収集して表示するためだけでなく、Javaコード内で支払いを処理するためではなく、暗号化されたパラメーターを使用した安全なSSLプロトコルを使用してサーバーに送信します。サーバーと通信するための完全に暗号化された安全なAPIを作成します。
もちろん、これもハッキングされる可能性があり、ソースコード保護とは無関係ですが、ハッカーがあなたのアプリをだますのをより困難にするために別のセキュリティレイヤを考慮してください。
ハッカーがAPKファイルをハッキングできないように、アプリのすべてのリソース、アセット、およびソースコードを保護するにはどうすればよいですか。
APKファイルは SHA-1 アルゴリズムで保護されています。 APKの META-INF フォルダにいくつかのファイルがあります。 APKファイルを抽出してその内容を変更して再度Zip圧縮し、Androidマシンでその新しいAPKファイルを実行すると、SHA-1ハッシュが一致しなくなるため機能しません。
あなたのコードを保護するための100％解決策はないと思いますが、試してみるには HoseDex2Jar のv3が有効になりました。
ソースコードとリソースの100％セキュリティは、Androidでは不可能です。しかし、リバースエンジニアにとっては少し難しくなる可能性があります。あなたは以下のリンクでこれに関するより多くの詳細を見つけることができます：
安全に定数値を保存する および https://www.agicent.com/blog/mobile-app-security-best-practices/
彼らは自分の携帯電話にアプリを持っているとき、彼らはそれの記憶へのフルアクセスを持っています。そのため、ハッキングされないようにしたい場合は、デバッガを使用して静的メモリアドレスを直接取得できないようにすることができます。書き込み先があり、制限があると、スタックバッファオーバーフローが発生する可能性があります。ですから、もし彼らが何かを書くとき、もしあなたが限界を超えなければならないなら、もし彼らが限界より多くの文字を送るなら、（入力>限界）を無視し、そして彼らはそこにアセンブリコードを置くことはできません。
ツール：あなたのアプリケーションでProguardを使うことはあなたのアプリケーションをリバースエンジニアリングすることに制限されることができます
私はこのスレッドでその良い答えを見ることができます。あなたはfacebook redexを使ってコードを最適化することができます。 redexは.dexレベルで機能します。proguardは.classレベルとして機能します。