3

用語が正しいかどうかはわかりませんが、バイナリ/アセンブリを変更してチェックをバイパスすることを困難にするために、どのようなコード プラクティスを使用できますか。

たとえば、ソースコードで。

bool verificationResult = verify();
if (verificationResult){
 allow_Something();
}else{
 prevent_Something();
}

上記のコードの逆アセンブル バージョンを見ている人が、検証結果が false の場合でも、'jump opcodes(?)' を変更して allow_Something を実行できる場合。

同様のことがここでカバーされてい ます http://www.codeproject.com/Articles/18961/Tamper-Aware-and-Self-Healing-Code#pre0

Android の NDK 経由で使用するために、C++ でバイナリを作成していることに注意してください。

4

4 に答える 4

6

これまでのところ、一般的なコンセンサスは、APK を「クラッキング」しようと躍起になっている人を防ぐことは不可能です。難読化技術は、APK を一度「クラック」するために必要な複雑さを増すだけです。無料で APK をホストすることを提案する無数のサイトにアップロードされた後は、Android 初心者の「初心者」から離れて Google 検索するだけです。

また、あいまいさによるセキュリティは、あなたを遠くに連れて行くことはありません.

APK をハッキングから保護することに関しては、Android での APKのライセンス検証の現状について説明している次の記事をお勧めします。ここで説明されている手法により、保護する必要がある一般的な攻撃ベクトルについてのアイデアが得られるはずです。

Proguardは、 APK の難読化を開始するのに適した場所です。

難読化された APK を取得したら、次のツールを使用して実行し、逆コンパイルされたソースを確認してください。これらはすべて無料でオープンソースのツールであり、非常に人気があり、まともな「クラッカー」が最初に試すことは間違いありません
。 1. baksmali
2. apktool
3. Dex2Jar + JD-Gui

上記のツールの出力がかなり複雑で意味をなさないことに満足するまで、難読化のレイヤーをコードに追加し続けます。(コーラとピザとDVM オペコードの知識で武装した大卒者が週末に達成できることを過小評価しないでください)。

あなたが共有したリンクで説明されている手法については、.dexAndroid でを保護するためにそれらを実装する方法がわかりません。そして、検証ロジックを個別に実装することになった場合.so、「クラッカー」が行う必要があるのは、Java コード内の呼び出しを.so.

アップデート：

を保護するための追加の難読化手順.so。

1. 多かれ少なかれ直線的な経路をたどらないでください。
あちこちにジャンプを追加すると、保護がバイパスされた場合に個別に変更してパッチを適用し、検証する必要がある非常に多くの潜在的なターゲットが「クラッカー」に殺到することで機能します。

2. タイミング チェックを追加する これは主に、デバッグ時と実際の実行時にコードが異なるパスをたどるようにすることで、「クラッカー」を排除するためです。2 つのポイント間の時間が通常よりも長い場合は、プログラムがデバッグされていることを明確に示しています。つまり、世界のピアノの数を計算するジャンク コードの部分に飛び込むときです。

3. 自己修正コードを書く
これも静的解析の妨げになります。たとえば、検証関数へのジャンプがバイナリに存在しないが、.so.

上記のすべての手法 (およびその他の手法) については、アンチデバッグ手法に関する次の記事で例を挙げて説明しています。

より包括的なガイドは、Peter Ferrie による Ultimate Anti Debugging Referenceです。

于 2013-07-04T07:47:21.033 に答える
1

Dexguardは Proguard と同じ人によって作成されていますが、さらに細かいオプションが可能です。とはいえ、Proguard は多かれ少なかれ Android 難読化の業界標準です。ただし、上で述べたように、ノウハウを持つ誰かがあなたのアプリをクラックしたい場合、愛やお金で保護することはできません.

于 2013-07-03T17:49:39.817 に答える
1

単純な真実: できません。

オブジェクト コードを難読化するためのユーティリティを購入できますが、それらはすべて、わずかに動機付けられた攻撃者によって簡単にバイパスされます。ユーザーがプログラム イメージ (ディスク上またはメモリ内) に書き込むことができる場合、難読化によってそれを防ぐことはできません。

非常に重要な場合は、重要なコンポーネントを制御するデバイスに移動し、それにアクセスするための何らかの形式のチャレンジ/レスポンス コードを提供することをお勧めします。人々がそれを解読するのを防ぐことはできませんが、それに対してはるかに重要な障壁を築くことができます.

于 2013-07-04T04:16:28.997 に答える
1

透明すぎるチェックは使用しないでください。基本的なワークフローの難読化 (たとえば、結果の XOR 処理) を試してください。これは、単純なオペコードの置き換えを防ぐのに役立ちます。しかし、誰かがあなたをクラックしたい場合、あなたの保護の複雑さに関係なく、彼はそれを行うことができることを保証します.

于 2013-06-29T20:36:22.273 に答える