バイナリの自己検証?

Question

私の質問は非常に単純です。あなたは、「アクセス許可」または「アクセス拒否」を出力する実行可能ファイルであり、悪意のある人は、あなたに常に「アクセス許可」と言わせるために、あなたのアルゴリズムを理解したり、あなたの内部にパッチを当てようとします。

この紹介の後、あなたは私が何をしているのか非常に疑問に思っているかもしれません。Diablo3が発売されたら、彼はクラックするつもりですか？私はあなたの心配を和らげることができます、私はそれらのクラッカーの一人ではありません。私の目標はクラックです。

Crackmes は、たとえば、www.crackmes.de で見つけることができます。Crackme は、（ほとんどの場合）シリアルを検証し、シリアルに応じて「アクセス許可」または「アクセス拒否」を出力する小さなアルゴリズムを含む小さな実行可能ファイルです。目標は、この実行可能出力を常に「アクセスが許可された」状態にすることです。使用が許可されているメソッドは、作成者によって制限されている場合があります (パッチ適用なし、逆アセンブルなし)、またはバイナリ、objdump、および 16 進エディタで実行できるすべてのものが含まれている場合があります。クラックをクラックするのは間違いなく楽しみの一部ですが、プログラマとしては、難しいクラックをどのように作成できるか疑問に思っています。

基本的に、Crackme は 2 つの主要な部分で構成されていると思います。特定のシリアル認証とその周囲のコード。

アセンブリを使用するだけでシリアル検証を追跡するのが困難になる可能性は非常に高いです。たとえば、シリアルを受け入れさせるためには、最終的に特定の状態になる必要があるシミュレートされたマイクロプロセッサの入力としてシリアルを取得するというアイデアがあります。一方で、安く成長して、この部分を保護するための暗号的に強力な方法についてさらに学ぶかもしれません。したがって、これを攻撃者に実行可能ファイルにパッチを当てようとするのに十分に頑張っても、それほど難しくないはずです。

ただし、より難しいのはバイナリを保護することです。どういうわけか元に戻すことはできない、完全に安全なシリアル検証を想定してみましょう (もちろん、それが元に戻せることはわかっていますが、疑わしい場合は、クラックしようとするバイナリから一部を取り出し、受け入れられるまでランダムなシリアルを投げます)。攻撃者がバイナリに何でも受け入れさせるためにバイナリ内のジャンプをオーバーライドすることを防ぐにはどうすればよいでしょうか?

このトピックについて少し調べてみましたが、バイナリ セキュリティ、バイナリの自己検証などに関する検索結果のほとんどは、侵害されたバイナリを使用したオペレーティング システムへの攻撃を防止しようとする記事に行き着きます。特定のバイナリに署名し、カーネルでそれらの署名を検証します。

現在の私の考えは次のとおりです。

• バイナリ内の明示的な位置がジャンプであるかどうかを確認します。
• バイナリの一部をチェックサムし、実行時に計算されたチェックサムとそれらのチェックサムを比較します。
• コード内の関数に対して肯定的および否定的な実行時チェックを行います。シリアル検証に副作用あり。:)

潜在的な攻撃者をより長く困らせるための他の方法を考えることができますか?（もちろん、彼を永遠に遠ざけることはできません。プログラム自体にプログラムの正しいチェックサムを埋め込むことができてチェックサムジェネレーターを突破できない限り、いつかすべてのチェックが破られるでしょう、へへ）

Answer 1

「アンチリバーステクニック」に入っています。そしてそれは基本的に芸術です。さらに悪いことに、たとえ初心者を踏みつけても、olly と IDA Pro には「アンチアンチリバース プラグイン」があり、ダウンロードすれば対策の多くを回避できるのです。

対抗策には、トラップ デバッガー API によるデバッガーの検出、または「シングル ステッピング」の検出が含まれます。デバッガーのブレークインを検出した後も機能し続けますが、プログラムのずっと後からランダムなタイミングで動作し始めるコードを挿入できます。本当にいたちごっこで、クラッカーがかなり優勢です。

チェックアウト...http://www.openrce.org/reference_library/anti_reversing - そこにあるもののいくつか。

http://www.amazon.com/Reversing-Secrets-Engineering-Eldad-Eilam/dp/0764574817/ - この本には、非常に優れたアンチリバース情報とそのテクニックが記載されています。全体的に反転したい場合は、始めるのに最適な場所です。

Answer 2

これらのことは一般に、価値があるというよりも面倒なことが多いと思います。

バイナリを保護するコードの作成には多大な労力を費やします。悪者は、それを解読するのにそれほど労力を費やさず（通常、彼らはあなたよりも経験が豊富です）、その後クラックを解放して、誰もがあなたの保護を回避できるようにします。あなたが迷惑するのは、あなたの保護によって不便を感じている正直な人たちだけです。

著作権侵害をビジネスのコストとして考えてください。すべてのサポートが料金を支払った顧客に対してのみ行われるようにすれば、海賊版ソフトウェアの追加コストはゼロになります。

Answer 3

TPM テクノロジーがあります。 ウィキペディアのtpm

これにより、バイナリの暗号化チェックサムを特別なチップに保存できるようになり、一方向の検証として機能する可能性があります。

注記:TPM は DRM に使用される可能性があるため、ある種悪い評価を受けています。しかし、この分野の専門家にとって、それは一種の不公平であり、 オープンTPM Linux ユーザーが TPM チップの使用方法を正確に制御できるようにするグループです。

Answer 4

この問題に対する最も強力な解決策の 1 つは、 トラステッド コンピューティング. 。基本的にはアプリケーションを暗号化し、復号化キーを特別なチップ ( トラステッドプラットフォームモジュール)、チップは、コンピューターが「信頼された」状態にあることを確認した場合にのみアプリケーションを復号します。メモリビューア/エディタ、デバッガなどはありません。基本的に、復号化されたプログラム コードを表示するだけでも特別なハードウェアが必要になります。

Answer 5

したがって、最初にキーを受け入れてメモリに保存し、その後ディスクからキーを取得するプログラムを作成するとします。正しいキーであれば、ソフトウェアは動作します。キーが間違っていると、ソフトウェアがクラッシュします。目的は、海賊版が有効なキーを生成することを困難にし、ライセンスのないキーで動作するようにプログラムにパッチを適用することを困難にすることです。

これは実際には特別なハードウェアなしで実現できます。私たちの遺伝コードを考えてみましょう。それはこの宇宙の物理学に基づいて機能します。私たちはそれをハッキングしたり、薬を作ったりしようと試みますが、たいていは大量の望ましくない副作用を引き起こして惨めに失敗します。なぜなら、遺伝的な「コード」が進化して機能する複雑な「世界」をまだ完全にリバースエンジニアリングしていないからです。 。基本的に、誰もがアクセスできる共通のプロセッサ (共通の「世界」) 上ですべてを実行している場合、現在のソフトウェアが簡単にクラックされてしまうことからもわかるように、そのような安全なコードを書くことは事実上不可能です。

ソフトウェアでセキュリティを実現するには、基本的に、十分に複雑な独自のプラットフォームを作成する必要がありますが、予期せぬ副作用を発生させずにコードの動作を変更するには、他の人がそのプラットフォームを完全かつ徹底的にリバース エンジニアリングする必要があります。ただし、プラットフォームをリバース エンジニアリングすると、振り出しに戻ります。

問題は、プラットフォームはおそらく一般的なハードウェアで実行されるため、プラットフォームのリバース エンジニアリングが容易になり、その結果、コードのリバース エンジニアリングも少し容易になるということです。もちろん、これはリバース エンジニアリングが十分に困難になるように、プラットフォームに必要な複雑さのレベルのハードルが少し上がっていることを意味しているだけかもしれません。

十分に複雑なソフトウェア プラットフォームはどのようなものになるでしょうか?たとえば、おそらく 6 回の加算演算ごとに、7 回目の加算では、システム初期化以降に実行された減算演算と乗算演算の合計数の差の法 5 の対数の平方根で割った PI を乗算した結果が返されます。正しい結果をデコードするには、コード自体と同様に、プラットフォームもこれらの数値を独立して追跡する必要があります。したがって、コードは、設計したプラットフォームの複雑な基礎となる動作の知識に基づいて作成されます。確かに、プロセッサ サイクルを消費しますが、適切に動作させるには、誰かがその小さな驚くべき動作をリバース エンジニアリングし、新しいコードに再構築する必要があります。さらに、独自のコードは一度作成すると変更が困難になります。各行が以前に起こったすべての内容に依存し、還元不可能な複雑さになるからです。もちろん、十分に安全なプラットフォームではさらに複雑になりますが、重要なのは、副作用を悪化させることなく、コードをリバース エンジニアリングして変更する前に、誰かがプラットフォームをリバース エンジニアリングするということです。

Answer 6

コピープロテクトとその保護に関する素晴らしい記事 海賊を寄せ付けない:Spyro のクラック保護の実装:ドラゴン年

そこに記載されている、まだ言及されていない最も興味深いアイデアは、失敗のカスケードです。チェックサムが 1 バイトを変更し、それが別のチェックサムの失敗を引き起こすというものです。最終的に、チェックサムの 1 つがシステムをクラッシュさせるか、何らかの異常な動作を引き起こします。これにより、プログラムを不正コピーしようとする試みが不安定に見え、原因がクラッシュからかなり離れたところで発生しているように見えます。