APKファイルのリバースエンジニアリングを回避する方法

Android向けの支払い処理アプリを開発していますが、ハッカーがAPKファイルのリソース、アセット、ソースコードにアクセスできないようにしたいと考えています。

誰かが.apk拡張子を.zipに変更すると、解凍してアプリのすべてのリソースとアセットに簡単にアクセスでき、dex2jarとJavaデコンパイラーを使用して、ソースコードにもアクセスできます。Android APKファイルのリバースエンジニアリングは非常に簡単です。詳しくは、Stack Overflowの質問APKファイルからプロジェクトへのリバースエンジニアリングをご覧ください。

Android SDKに付属のProguardツールを使用しました。署名付きキーストアとProguardを使用して生成されたAPKファイルをリバースエンジニアリングすると、難読化されたコードが表示されます。

ただし、Androidコンポーネントの名前は変更されず、アプリで使用されるKey-Valueなどの一部のコードは変更されません。Proguardのドキュメントに従って、このツールはマニフェストファイルに記載されているコンポーネントを難読化できません。

今私の質問は：

1. Android APKのリバースエンジニアリングを完全に防ぐにはどうすればよいですか？これは可能ですか？
2. ハッカーがAPKファイルをハッキングできないように、アプリのすべてのリソース、アセット、ソースコードをどのように保護できますか？
3. ハッキングをより困難または不可能にする方法はありますか？APKファイルのソースコードを保護するには、他に何ができますか？

 1. Android APKのリバースエンジニアリングを完全に回避するにはどうすればよいですか？これは可能ですか？

AFAIK、リバースエンジニアリングを完全に回避するためのトリックはありません。

また、@ inazarukが非常によく言っています。あなたがコードに対して行うことは何でも、潜在的な攻撃者は、彼女または彼がそれを実行可能であると考える方法でそれを変更することができます。基本的に、アプリケーションが変更されるのを防ぐことはできません。そして、そこに置いた保護は無効化/削除することができます。

 2.ハッカーがAPKファイルをハッキングできないように、アプリのすべてのリソース、アセット、ソースコードをどのように保護できますか？

ただし、ハッキングを難しくするためにさまざまなトリックを実行できます。たとえば、難読化を使用します（Javaコードの場合）。これは通常、リバースエンジニアリングを大幅に遅くします。

 3.ハッキングをより困難または不可能にする方法はありますか？APKファイルのソースコードを保護するには、他に何ができますか？

誰もが言うように、そしてご存じのとおり、100％のセキュリティはありません。しかし、Googleが組み込んだAndroidの出発点はProGuardです。共有ライブラリを含めるオプションがある場合、C ++に必要なコードを含めて、ファイルサイズや統合などを確認できます。ビルドごとにAPKのライブラリフォルダーに外部ネイティブライブラリを追加する必要がある場合は、それを使用できます。以下の提案によって。

ライブラリをネイティブライブラリパスに配置します。デフォルトでは、プロジェクトフォルダーの「libs」に設定されています。「armeabi」ターゲットのネイティブコードをビルドした場合は、それをlibs / armeabiの下に配置します。armeabi-v7aでビルドした場合は、libs / armeabi-v7aの下に 置きます。

<project>/libs/armeabi/libstuff.so

申し訳ありませんが、/ resディレクトリ内のファイルは、現在保護されている以上保護できません。

ただし、ソースコードを保護するために実行できる手順、または少なくともすべてではない場合に実行できる手順があります。

1. ProGuardなどのツールを使用します。これらはコードを難読化し、不可能ではないにしても、逆コンパイルすると読みにくくなります。
2. サービスの最も重要な部分をアプリの外に移動し、PHPなどのサーバー側言語の背後に隠されたWebサービスに移動します。たとえば、作成に100万ドルもかかるアルゴリズムがあるとします。あなたは明らかに人々があなたのアプリからそれを盗むことを望まない。アルゴリズムを移動してリモートサーバー上のデータを処理させ、アプリを使用してデータを提供するだけです。または、NDKを使用してそれらをネイティブに.soファイルに書き込みます。これは、apkよりも逆コンパイルされる可能性がはるかに低くなります。今のところ、.soファイルの逆コンパイラは存在しないと思います（存在しても、Java逆コンパイラほど良くありません）。さらに、@ nikolayがコメントで述べたように、サーバーとデバイス間のやり取りにはSSLを使用する必要があります。
3. デバイスに値を保存するときは、未加工の形式で保存しないでください。たとえば、ゲームがあり、SharedPreferencesにユーザーが持っているゲーム通貨での金額を保存している場合です。10000コインだとしましょう。10000直接保存する代わりに、などのアルゴリズムを使用して保存し((currency*2)+1)/13ます。したがって、ではなく、SharedPreferencesに10000保存1538.53846154します。ただし、上記の例は完全なものではなく、丸め誤差などで通貨が失われないような方程式を考え出す必要があります。
4. サーバー側のタスクでも同様のことができます。例として、実際に支払い処理アプリを見てみましょう。ユーザーがの支払いを行う必要があるとします$200。生の$200値をサーバーに送信する代わりに、一連の小さい事前定義された値を送信し$200ます。これらの値は合計でになります。たとえば、単語と値を同等にするファイルまたはテーブルをサーバーに配置します。では、とにCharlie対応するとしましょう。したがって、を送信する代わりに、4回送信し、$47John$3$200CharlieJohn四回。サーバーで、それらの意味を解釈し、合計します。これにより、ハッカーがサーバーに任意の値を送信することが防止されます。これは、ハッカーがどの値がどの値に対応するかを知らないためです。セキュリティの追加測定として、これについてもポイント3と同様の方程式を作成しn、日数ごとにキーワードを変更できます。
5. 最後に、ランダムに役に立たないソースコードをアプリに挿入して、ハッカーが干し草の山から針を探すようにすることができます。インターネットからのスニペットを含むランダムなクラス、またはフィボナッチ数列のようなランダムなものを計算するための関数のみを挿入します。これらのクラスがコンパイルされることを確認してください。ただし、アプリの実際の機能では使用されません。これらの誤ったクラスを十分に追加すると、ハッカーは実際のコードを見つけるのに苦労するでしょう。

全体として、アプリを100％保護する方法はありません。あなたはそれを難し​​くすることができますが、不可能ではありません。Webサーバーが侵害される可能性があり、ハッカーは複数のトランザクション金額とそのために送信するキーワードを監視することでキーワードを把握でき、ハッカーはソースを入念に調べて、どのコードがダミーであるかを把握できます。

あなたは反撃しかできませんが、勝つことはできません。

コンピューティングの歴史のどの時点でも、ソフトウェアの作業コピーを攻撃者に渡したときに、ソフトウェアのリバースエンジニアリングを防止することは不可能でした。また、ほとんどの場合、それは不可能です。

それが理解できれば、明白な解決策があります。秘密を攻撃者に教えないでください。あなたはAPKの内容を保護することはできませんが、何をすることができます守ることは、あなたが配布していないものです。通常、これはアクティベーション、支払い、ルール適用、その他のコードのジューシーなビットに使用されるサーバー側のソフトウェアです。貴重な資産をAPKで配布しないことで保護できます。代わりに、アプリからのリクエストに応答し、アセットを「使用」して（意味が何であれ）サーバーを設定して、結果をアプリに送り返します。このモデルが想定しているアセットに対して機能しない場合は、戦略を再考することをお勧めします。

また、 アプリの海賊行為を防止することが主な目的の場合は、気にしないでください。この問題については、著作権侵害対策によって救われる可能性があるよりも多くの時間とお金を費やしています。この問題を解決するための投資収益率は非常に低いため、それについて考えても意味がありません。

アプリのセキュリティの最初のルール：攻撃者が無制限の物理的または電子的アクセスを取得するすべてのマシンは、実際にどこにいても、何に支払ったかに関係なく、攻撃者に属します。

アプリのセキュリティの2番目のルール：物理的な境界を離れ、攻撃者が侵入できないソフトウェアは、コーディングに費やした時間に関係なく、攻撃者に属します。

3番目のルール：攻撃者が侵入できない同じ物理的境界を離れる情報は、どれほど価値があるかに関係なく、攻撃者に属します。

情報技術セキュリティの基盤は、これらの3つの基本原則に基づいています。本当に安全な唯一のコンピューターは、ファラデー箱の内部、鋼鉄の檻の中の金庫に閉じ込められたものです。この状態でサービスのほとんどの寿命を過ごすコンピューターがあります。年に1回（またはそれ以下）、彼らは信頼されたルート証明機関の秘密キーを生成します（カメラが置かれている部屋の隅々までカメラで記録している多くの目撃者の前で）。

現在、ほとんどのコンピューターはこれらのタイプの環境では使用されていません。彼らは物理的に屋外にいて、ワイヤレスラジオチャネルを介してインターネットに接続しています。つまり、ソフトウェアと同様に脆弱です。したがって、彼らは信頼されるべきではありません。コンピュータとそのソフトウェアが役立つために知っているか行う必要がある特定の事項がありますが、損傷を引き起こすのに十分なことを認識または実行できないように注意する必要があります（少なくとも、その単一のマシンの境界外に永久的な損傷はありません） ）。

あなたはすでにこれをすべて知っていました。そのため、アプリケーションのコードを保護しようとしています。しかし、そこには最初の問題があります。難読化ツールを使用すると、人間がコードを掘り下げて混乱させる可能性がありますが、プログラムを実行する必要があります。つまり、アプリの実際のロジックフローとアプリが使用するデータは、難読化の影響を受けません。少し粘り強さを考えると、攻撃者はコードを難読化解除するだけでよく、攻撃者が探しているものは探しているもの以外にあり得ない特定のケースでは必要ありません。

代わりに、攻撃者がコードの明確なコピーを取得するのがいかに簡単であっても、攻撃者がコードを使用して何もできないことを確認する必要があります。つまり、ハードコードされたシークレットはありません。これらのシークレットは、コードが開発した建物を出るとすぐにシークレットにならないためです。

ハードコーディングしたこれらのKey-Valueは、アプリケーションのソースコードから完全に削除する必要があります。代わりに、それらは3つの場所のいずれかにある必要があります。デバイス上の揮発性メモリ。攻撃者がオフラインコピーを取得するのは困難です（ただし不可能ではありません）。鉄拳でアクセスを制御するサーバークラスタに永続的に。または、物理カードやユーザーのメモリなど、デバイスやサーバーとは無関係の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からのアセット、リソースなどのデータの抽出を回避できます。

1. ProGuardを使用してアプリケーションコードを難読化する

2. CおよびC ++を使用してNDKを使用し、アプリケーションコアとコードの安全な部分をファイルに配置する.so

3. リソースを保護するには、重要なリソースをすべてAPKのアセットフォルダに含めないでください。アプリケーションの初回起動時にこれらのリソースをダウンロードしてください。

開発者は次の手順を実行して、APKを盗難から防ぐことができます。

• 最も基本的な方法はProGuard、コードを難読化するようなツールを使用することですが、これまでは、誰かがアプリを逆コンパイルするのを完全に防ぐことは非常に困難でした。

• また、私はHoseDex2Jarツールについて聞いたことがあります。Dex2JarAndroid APKに無害なコードを挿入することで停止し、コードを混乱させ、無効Dex2Jarにし、コードを逆コンパイルから保護します。どういうわけか、ハッカーがAPKを読み取り可能なJavaコードに逆コンパイルするのを防ぐことができます。

• サーバー側のアプリケーションを使用して、必要な場合にのみアプリケーションと通信します。重要なデータを防ぐのに役立ちます。

潜在的なハッカーからコードを完全に保護することはできません。どういうわけか、あなたは彼らがあなたのコードを逆コンパイルすることを難しくして少しイライラさせる仕事をすることができました。最も効率的な方法の1つは、ネイティブコード（C / C ++）で記述して、コンパイル済みライブラリとして保存することです。

ここにあなたが試すことができるいくつかの方法があります：

1. 難読化とProGuardなどのツールを使用する。
2. ソースとデータの一部を暗号化します。
3. アプリで独自の組み込みチェックサムを使用して改ざんを検出します。
4. デバッガーでの読み込みを回避するコードを導入します。つまり、アプリがデバッガーを検出して、デバッガーを終了/強制終了できるようにします。
5. 認証をオンラインサービスとして分離します。
6. アプリケーションの多様性を利用する
7. デバイスを認証する前に、さまざまなサブシステムからのデバイスのハードウェア署名などの指紋技術を使用します。

 1. Android APKのリバースエンジニアリングを完全に回避するにはどうすればよいですか？これは可能ですか？

無理だよ

 2.ハッカーがAPKファイルをハッキングできないように、アプリのすべてのリソース、アセット、ソースコードをどのように保護できますか？

無理だよ

 3.ハッキングをより困難または不可能にする方法はありますか？APKファイルのソースコードを保護するには、他に何ができますか？

より厳しい-可能ですが、実際には、ガイドをハッキングするためにググるだけの平均的なユーザーにとっては、より難しいでしょう。誰かが本当にあなたのアプリをハッキングしたいのなら、遅かれ早かれハッキングされるでしょう。

 1. Android APKのリバースエンジニアリングを完全に回避するにはどうすればよいですか？これは可能ですか？

それは不可能です

 2.ハッカーがAPKファイルをハッキングできないように、アプリのすべてのリソース、アセット、ソースコードをどのように保護できますか？

開発者は、ProGuardなどのツールを使用してコードを難読化するなどの手順を実行できますが、これまでは、誰かがアプリを逆コンパイルするのを完全に防ぐことは非常に困難でした。

これは非常に優れたツールであり、コードのフットプリントを縮小しながら、コードを「元に戻す」ことの困難さを増す可能性があります。

統合されたProGuardサポート：ProGuardがSDKツールにパッケージ化されました。開発者は、リリースビルドの統合部分としてコードを難読化できるようになりました。

 3.ハッキングをより困難または不可能にする方法はありますか？APKファイルのソースコードを保護するには、他に何ができますか？

調べているうちにHoseDex2Jarについて知りました。このツールはコードを逆コンパイルから保護しますが、コードを完全に保護することはできないようです。

役立つリンクのいくつかは、それらを参照できます。

• Proguard、Android、およびライセンスサーバー
• Android LVLアプリケーションの保護
• Stack Overflowの質問リバースエンジニアリングからAndroidアプリを保護することは本当に不可能ですか？
• Stack Overflowの質問Android APKファイルのリバースエンジニアリングを防止してコードを保護する方法

ここでの主な問題は、dexファイルを逆コンパイルできるということです。答えは、「並べ替え」できるということです。dedexerやsmaliのような逆アセンブラがあります。

適切に構成されたProGuardは、コードを難読化します。ProGuardの商用拡張バージョンであるDexGuardは、もう少し役立つかもしれません。ただし、コードは引き続きsmaliに変換でき、リバースエンジニアリングの経験がある開発者は、smaliから何を行っているかを理解できます。

たぶん、良いライセンスを選び、それを法律によって可能な限り最善の方法で施行することになるでしょう。

あなたのクライアントは彼らが何をしているかを知っている誰かを雇うべきです、彼らは正しい決定をすることができ、あなたを指導することができます。

上記の話で、バックエンドのトランザクション処理システムを変更する能力があるのはばかげています。そのようなアーキテクチャの変更を許可するべきではないので、そうすることは期待できません。

これに関する私の理論的根拠：

ドメインは支払い処理であるため、PCI DSSおよび/またはPA DSS（および潜在的な州/連邦法）がビジネスにとって重要であると想定しても安全です。準拠するには、安全であることを示す必要があります。安全でない場合は、安全でないことを（テストによって）確認し、適切なレベルでセキュリティを確認できるようになるまで修正、再テストなどを行います。成功するには、費用がかかり、遅く、リスクが高くなります。正しいことを行うには、前もってしっかりと考え、経験豊富な人材を仕事に投入し、安全な方法で開発し、セキュリティが適切なレベルで検証できるようになるまで、テスト、修正（少ない）、その他（少ない）=安価、高速、成功への低リスクの方法。

1つのモバイル決済アプリケーション（MyCheck）を含め、決済プラットフォームに幅広く取り組んだ人として、この動作をサーバーに委任する必要があると思います。決済プロセッサのユーザー名やパスワード（どちらでも）を保存したり、コードを難読化した場合でもソースを理解できるので、モバイルアプリケーションでハードコーディングされていることは、最後に必要なことです。

また、アプリケーションにクレジットカードや支払いトークンを保存しないでください。すべてが、作成したサービスに委任されている必要があります。これにより、後で簡単にPCIに準拠できるようになり、クレジットカード会社が勝ちます。 （彼らが私たちのためにしたように）あなたの首を呼吸しないでください。

ここの他の投票された答えは正しいです。別のオプションを提供したいだけです。

重要と思われる特定の機能については、アプリでWebViewコントロールをホストできます。次に、機能がWebサーバーに実装されます。アプリケーションで実行されているように見えます。

リバースエンジニアリングを（ほとんど）不可能にしたい場合は、アプリケーションを非常に改ざんされにくいチップに配置します。チップはすべての機密情報を内部で実行し、何らかのプロトコルと通信してホストでGUIを制御できるようにします。改ざん防止チップでさえ、100％クラックプルーフではありません。彼らはソフトウェアの方法よりもはるかに高い水準を設定しました。もちろん、これは不便です。アプリケーションには、チップをデバイスに挿入するための小さなUSBイボが必要です。

この質問は、このアプリケーションを嫉妬して保護したい動機を明らかにしていません。

アプリケーションのセキュリティ上の欠陥（既知またはそれ以外）を隠すことで支払い方法のセキュリティを向上させることを目的とする場合、それは完全に誤りです。セキュリティが重要なビットは、可能であれば、実際にはオープンソースである必要があります。アプリケーションをレビューするセキュリティ研究者がこれらのビットを見つけてその動作を精査し、連絡できるように、できるだけ簡単にする必要があります。ペイメントアプリケーションには、埋め込み証明書を含めないでください。つまり、工場からの固定証明書があるという理由だけでデバイスを信頼するサーバーアプリケーションは存在しないはずです。支払いトランザクションは、アプリケーション、プラットフォーム、ネットワークなどの信頼を排除する、正しく設計されたエンドツーエンド認証プロトコルを使用して、ユーザーの資格情報のみで行われる必要があります。

改ざん防止チップを除いて、クローン作成を防ぐことを目的とする場合、プログラムがリバースエンジニアリングおよびコピーされないようにする方法はありません。そのため、互換性のある支払い方法を独自のアプリケーションに組み込んで、 「無許可のクライアント」に上昇する。無許可のクライアントの開発を困難にする方法があります。1つは、プログラムの完全な状態のスナップショットに基づいてチェックサムを作成することです。つまり、すべての状態変数です。GUI、ロジック、なんでも。クローンプログラムの内部状態はまったく同じではありません。確かに、外部から見える状態遷移（入力と出力で確認できる）は同じですが、内部状態はほとんど同じではない状態マシンです。サーバーアプリケーションはプログラムに問い合わせることができます。詳細な状態は何ですか？（すなわち すべての内部状態変数のチェックサムを教えてください）。これは、サーバー上で並行して実行され、真の状態遷移を経るダミークライアントコードと比較できます。サードパーティのクローンは、正しい応答を提供するために、本物のプログラムの関連するすべての状態変化を複製する必要があり、その開発を妨げます。

ここで@Muhammad Saqibに同意します：https：//stackoverflow.com/a/46183706/2496464

そして、@ Mumairは良い開始ステップを提供します：https ://stackoverflow.com/a/35411378/474330

ユーザーのデバイスに配布するすべてのものはユーザーのものであると想定することは常に安全です。簡潔でシンプル。最新のツールと手順を使用して知的財産を暗号化できる可能性がありますが、特定の人物がシステムを「調査」するのを防ぐ方法はありません。また、現在のテクノロジーでは不要なアクセスを取得するのが困難な場合でも、明日には簡単な方法があるかもしれません。

したがって、ここに方程式があります：

When it comes to money, we always assume that client is untrusted.

ゲーム内の経済と同じくらい簡単です。（特にゲームでは！「洗練された」ユーザーが増え、抜け穴は数秒で広がります！）

安全を保つにはどうすればよいですか？

すべてではありませんが、サーバー側にある主要な処理システム（およびもちろんデータベース）のほとんど。そして、クライアントとサーバーの間には、暗号化された通信、検証などがあります。それがシンクライアントの考え方です。

ソフトウェアアプリケーションを攻撃から保護するをご覧になることをお勧めします。商用サービスですが、友人の会社が使っていて、喜んで使ってくれました。

Android NのAPK署名スキームv2

PackageManagerクラスは、APK署名スキームv2を使用したアプリの検証をサポートするようになりました。APK署名スキームv2は、APKファイルへの不正な変更を検出することにより、検証速度を大幅に向上させ、整合性保証を強化するファイル全体の署名スキームです。

下位互換性を維持するには、APKをv2署名スキームで署名する前に、v1署名スキーム（JAR署名スキーム）で署名する必要があります。v2署名スキームでは、v2スキームで署名した後に追加の証明書でAPKに署名すると、検証が失敗します。

APK署名スキームv2のサポートは、後でN Developer Previewで利用できるようになります。

http://developer.android.com/preview/api-overview.html#apk_signature_v2

APKのリバースエンジニアリングを完全に回避する方法はありません。アプリケーション資産、リソースを保護するために、暗号化を使用できます。

• 暗号化を行うと、復号化を行わないと暗号化が難しくなります。強力な暗号化アルゴリズムを選択すると、解読が難しくなります。
• メインロジックになりすましコードを追加して、クラックをより困難にします。
• 重要なロジックを任意のネイティブ言語で記述でき、逆コンパイルが確実に困難になる場合。
• Quixxiなどのサードパーティのセキュリティフレームワークを使用する

基本的にそれは不可能です。それは決して可能ではありません。しかし、希望はあります。難読化ツールを使用すると、次のようなものを含め、一般的な攻撃の実行が非常に難しくなります。

1. メソッド/クラスの名前を変更する（したがって、逆コンパイラでは次のような型を取得します） a.a）
2. 制御フローを難読化する（逆コンパイラではコードが非常に読みにくい）
3. 文字列および場合によってはリソースの暗号化

他にもあると思いますが、それが主なものです。私は.NET難読化ツールのPreEmptive Solutionsという会社で働いています。また、Androidで動作するJava難読化ツールと、DashOと呼ばれるものがあります。。

ただし、難読化には常に代償が伴います。特に、パフォーマンスは通常悪くなり、通常、リリースの前後に追加の時間が必要になります。ただし、あなたの知的財産があなたにとって非常に重要である場合、通常はそれだけの価値があります。

それ以外の場合、あなたの唯一の選択は、あなたのAndroidアプリケーションがあなたのアプリケーションの実際のロジックのすべてをホストするサーバーに通過するようにすることです。これは、ユーザーがアプリを使用するためにインターネットに接続している必要があることを意味するため、独自の問題を抱えています。

また、この問題があるのはAndroidだけではありません。それはすべてのアプリストアで問題です。これは、パッケージファイルにアクセスするのがいかに難しいかという問題です（たとえば、iPhoneでは簡単ではないと思いますが、それでも可能です）。

REを完全に回避することは不可能ですが、REを内部でより複雑にすることにより、攻撃者がアプリの明確な操作を確認するのをより困難にし、攻撃ベクトルの数を減らすことができます。

アプリケーションが機密性の高いデータを処理する場合、コードのリバースエンジニアリングの複雑さを増す可能性のあるさまざまな手法が存在します。1つの手法は、C / C ++を使用して、攻撃者による簡単なランタイム操作を制限することです。非常に成熟しており、Android提供のJNIとの統合が容易なCおよびC ++ライブラリは十分にあります。攻撃者は、低レベルでアプリケーションを攻撃するために、最初にデバッグ制限を回避する必要があります。これにより、攻撃がさらに複雑になります。攻撃者やマルウェアによる実行時の簡単な操作を防ぐために、Androidアプリケーションでは、アプリケーションマニフェストにandroid：debuggable =” false”を設定する必要があります。

トレースチェック –アプリケーションは、デバッガまたは他のデバッグツールによって現在トレースされているかどうかを判断できます。追跡されている場合、アプリケーションは、暗号化キーを破棄してユーザーデータを保護したり、サーバー管理者に通知したり、他のタイプの応答を防御したりするなど、可能な攻撃応答アクションをいくつでも実行できます。これは、プロセスステータスフラグを確認するか、ptrace attachの戻り値の比較、親プロセスの確認、プロセスリストのブラックリストデバッガーの確認、プログラムのさまざまな場所のタイムスタンプの比較など、他の手法を使用して判断できます。

最適化 -高度な数学的計算やその他の種類の複雑なロジックを隠すために、コンパイラーの最適化を利用すると、オブジェクトコードを難読化して攻撃者が簡単に分解できなくなり、攻撃者が特定のコードを理解しにくくなります。Androidでは、NDKでネイティブにコンパイルされたライブラリを利用することで、これをより簡単に実現できます。さらに、LLVM難読化ツールまたはプロテクターSDKを使用すると、マシンコードの難読化が向上します。

バイナリの削除 –ネイティブバイナリの削除は、アプリケーションの低レベル関数の構成を表示するために攻撃者に必要な時間とスキルレベルを増やす効果的な方法です。バイナリを削除すると、バイナリのシンボルテーブルが削除されるため、攻撃者はアプリケーションのデバッグやリバースエンジニアリングを簡単に行えなくなります。ストライピングやUPXの使用など、GNU / Linuxシステムで使用されている手法を参照できます。

そして最後に、難読化とProGuardなどのツールについて知っておく必要があります。

アプリがこれほど機密性が高い場合は、サーバー側の支払い処理部分を検討する必要があります。支払い処理アルゴリズムを変更してみてください。Androidアプリは、ユーザー情報（アカウントの残高など）を収集して表示する場合にのみ使用し、Javaコード内で支払いを処理するのではなく、暗号化されたパラメーターを使用した安全なSSLプロトコルを使用してこのタスクをサーバーに送信します。サーバーと通信するための完全に暗号化された安全なAPIを作成します。

もちろん、これもハッキングされる可能性があり、ソースコード保護とは何の関係もありませんが、ハッカーがアプリをだましにくくするために、別のセキュリティレイヤーと見なしてください。

TPMチップ（Trusted Platform Module）があなたのために保護されたコードを管理するはずではありませんか？それらはPC（特にAppleのもの）で一般的になりつつあり、今日のスマートフォンチップにすでに存在している可能性があります。残念ながら、まだそれを利用するOS APIはありません。うまくいけば、Androidがこの1日のサポートを追加するでしょう。これは、コンテンツDRM（GoogleがWebMのために取り組んでいる）をクリーンにするための鍵でもあります。

エンドユーザーの手に渡った場合、安全なものはありませんが、一般的な慣例によっては、攻撃者がデータを盗むのが難しくなる場合があります。

• メインロジック（アルゴリズム）をサーバー側に配置します。
• サーバーおよびクライアントと通信します。サーバーとクライアントの通信がSSLまたはHTTPSで保護されていることを確認します。または、他の技術の鍵ペア生成アルゴリズム（ECC、RSA）を使用します。機密情報がエンドツーエンドで暗号化されたままであることを確認します。
• セッションを使用し、特定の時間間隔の後にセッションを期限切れにします。
• リソースを暗号化し、オンデマンドでサーバーからフェッチします。
• またはwebview、サーバー上の保護リソース+コードを介してシステムにアクセスするハイブリッドアプリを作成できます

複数のアプローチ; これは、パフォーマンスとセキュリティの間で犠牲にしなければならないことは明らかです

私はこのスレッドでその良い答えを見ることができます。さらに、facebook redexを使用してコードを最適化できます。Redexは.dex、プロガードが.classレベルとして機能するレベルで機能します。

Androidでは、ソースコードとリソースの100％のセキュリティは不可能です。ただし、リバースエンジニアにとっては少し難しいかもしれません。詳細については、以下のリンクをご覧ください。

訪問の保存一定の値しっかり とhttps://www.agicent.com/blog/mobile-app-security-best-practices/

ハッカーがAPKファイルをハッキングできないように、アプリのすべてのリソース、アセット、ソースコードをどのように保護できますか？

APKファイルはSHA-1アルゴリズムで保護されています。APKのMETA-INFフォルダーにいくつかのファイルが表示されます。APKファイルを抽出してそのコンテンツを変更し、再度zip圧縮し、その新しいAPKファイルをAndroidマシンで実行すると、SHA-1ハッシュが一致しないため、機能しません。

コードを保護する100％のソリューションはないことに同意しますが、試してみたい場合は、HoseDex2Jarの v3が稼働しています。

ツール：アプリケーションでProguardを使用すると、アプリケーションのリバースエンジニアリングに制限できます

一部の銀行用アプリがDexGuardを使用していることを知っていました。これは、クラス、文字列、アセット、リソースファイル、ネイティブライブラリの暗号化だけでなく、難読化も提供します

https://www.guardsquare.com/en/products/dexguard