VMP 保護がすべての機能をカバーすべきではない理由

機能の数ではなく、攻撃者の利益から始める

リバースエンジニアリングや各機能の変更によって攻撃者が何を得るのかを尋ねます。認可ロジック、独自のアルゴリズム、プロトコル解析、資格チェック、およびローカルでの重要な決定には、多くの場合、最も明確な保護価値があります。

インターフェイス バインディング、汎用ユーティリティ、および頻繁に変更される統合コードは、同じ保護コストや回帰コストを正当化できないほど多数存在する可能性があります。スコープは、リポジトリのサイズではなく、潜在的なビジネス損失に従う必要があります。

• リカバリは重要なルールを回避できますか
• 変更により直接損失が発生する可能性があります
• サーバーが決定を下すことができるか
• パスを単独でテストできますか

アプリケーションの起動や頻繁に実行されるパスは慎重に扱う

アプリケーションの起動、クラスの初期化、レンダリング ループ、および高頻度の暗号化機能は、遅延や障害の影響を受けやすくなります。広範囲にわたる高コストの保護により、起動の遅延、競合、診断の困難さが増幅される可能性があります。

頻繁に実行される機能は自動的に除外されません。範囲を拡大する前に、保護されていないベースラインと、関数呼び出し頻度、関数呼び出しあたりのコスト、フォールバック動作、影響を受けるユーザーの測定が必要です。

レイヤーを使用して障害半径を小さく保つ

名前の難読化、制御フローの処理、Java からネイティブへの変換、および VMP は、さまざまなコストでさまざまな問題に対処します。価値の低いコードには低コストの制御を使用し、貴重な関数の小規模なセット用に VMP を予約します。

一度に 1 つの説明可能な機能グループを展開し、構成のバージョンを作成します。クラッシュやリグレッションが発生した場合、チームはコード、保護設定、サードパーティの依存関係を区別できます。

• 資産価値別の階層範囲
• 構成ごとにバージョンを付ける
• それぞれのスコープの変更について説明する
• ロールバックパスを保持する

承認を実際の候補者に結び付ける

1 つの候補 ID で、インストール、アプリケーションの起動、重要なビジネス パス、クラッシュ、パッケージ サイズ、リソースの動作、ターゲット システムを検証します。成功したデモンストレーションは、反復可能な回帰の代わりにはなりません。

現在の候補者がいない場合は、選考方法を述べてチェックを入れます。パフォーマンス コスト、互換性、保護の結果を事前に約束しないでください。