リトリート
私の犠牲者は再びOllyDbgデバッガーでした。 バージョン2.00のリリース後、私はそれをますます好きになり始め、多くの興味深いことが現れました。 しかし、著者はプラグインシステムをプラグインシステムに統合することを断固として拒否しました。これは最も重要なことであり、デバッガを実際の作業ツールにしました。
そしてある時点で、自分でこの機能を自分で追加するときだと気づきました。
さあ始めましょう
最初の質問は、コードを追加する方法ですか？
主に2つの方法があります。
- 新しいセクションを追加し、すべてのコードをそこに配置します。
- dllのコードを引き出し、プログラムの空き領域に小さな呼び出しコードを配置します。
他のより洗練されたオプションがありますが、私はそれらを考慮しません。
プログラミングの点でより便利であり、毎回exe-shnikにコードをコピーする必要がないため、2番目のオプションを選択しました。 dllを読み込むには、エントリポイントをコードに変更するか、少し後でダウンロードします。 ただし、最初にロードする方が適切です。その後、親プロセスが使用する前にすべてのAPIにアクセスできます。
パッチを作成する必要はありませんでした。すでにパッチを見つけました。ロードするモジュールの名前のみを変更しました。
それは：
次のようになりました：
そして、私たちのコード。 最初の呼び出しの秘Theは、それが単一のコマンドであり、スタック上の行のアドレスをプッシュし、ジャンプすることです。
00401000のJmpはBorland CのOEPです
プラグインのロードスキームは一般的です。
iniのプラグインでフォルダーへのパスを読み取り、ない場合は、デフォルトのパスを取得し、GetFileAttributesを使用してフォルダーの存在を確認します。 それでは、* .dllマスクで、FindFirstFile / FindNextFileを使用して、すべてのファイルをリストします。
LoadLibraryを介してそれぞれを読み込みます。 そして、プラグインは次に、エクスポートする関数をプルします。 バージョン1.10では、すべての関数がexeからエクスポートされていたため、同じエクスポートテーブルを同じ序数で作成する必要があります。これにより、プラグインでもすべてが透過的になります。 しかし、それについては後で。
ほとんどすべてのプラグインはメニューから制御されるため、メインメニューで独自のブランチを作成して処理する必要がありました。 メッセージを処理するには、ウィンドウ関数のアドレスを取得する必要があります。 そして、どこで入手できますか？ 簡単な方法は、RegisterClassをインターセプトし、構造フィールドWNDCLASS-> lpfnWndProcからアドレスを抽出することです。 そしてもちろん、彼の代わりに、自分で書いてください。
2番目のオプションは、コード内で検索し、自分でjmpを作成することです。 もちろん、私はひねくれた方法が大好きですが、今回はそうではありません。
インポートテーブルで関数のインターセプトを直接行い、ハンドラプロシージャでAPIアドレスを自分のものに置き換えて、そこからAPIに入れます。 この方法を使用すると、デバッガーに対してすべてが透過的になり、システムを直接操作すると思います。
他の人のメモリを編集する前に、この領域に書き込み権限を設定することを忘れないでください。そうしないと、アクセスエラーが発生します。
これは、編集前のAPI呼び出しです。
しばらくしてから：
再分析を繰り返しても解決しない場合、OlyaはRegisterClassWの呼び出しがあると考えていますが、下の両方の領域で、アドレス005EEA44がAPIアドレスから遠いことを確認できます。
そのため、メッセージを処理する場所がわかったので、今度は処理対象を作成する必要があります。 これを行うために、同じ方法でAppendMenuをインターセプトします。 そしてハンドラーでは、メニューを追加することを期待しています。その前にメニューを貼り付けます。
表示されたらすぐに-メニューを作成するための幅広い選択肢があります。 しかし、今のところ、単一の項目を表示するためのオプションMF_STRING、ポップアップサブメニュー用のMF_POPUP、および区切り文字用のMF_SEPARATORに限定しています。 少し時代遅れのInsertMenuを通じて追加されたすべてのメニュー項目。 第一に、コードが少なくなり、第二に、Oleg（開発者OllyDbg）はこのメソッドを自分で使用します。
最後に、オリジナルのAppendMenu APIを自分自身と私たちに続くメニューブランチのために呼び出すことを忘れないでください。
追加全体は次のように要約されます。
OllyDbgからAppendMenu（ヘルプ）へのリクエスト-> CreateMenu（）-> InsertMenuのいくつか（）-> AppendMenu（プラグイン）-> AppendMenu（ヘルプ）リクエストを実行します。
メニューを作成するには、どのIDが無料でどのIDが交差しないかを事前に確認する必要があります。 WndProcでは、メニューのWM_COMMANDをキャッチします。 私たちだけを除外し、たとえば、ID => processor_addressで連想配列を使用して、必要なプラグインに制御を移します。
これは、私の介入前後のOllyDbg 2.00cバージョンのウィンドウの外観です。
今最も基本的な質問は、プラグインにエクスポートする必要がある関数のアドレスを見つけることです。 アプリケーションのリリースバージョンでデバッグ情報が見つかることを期待しないでください。
したがって、次の方法でIda Proをロードしてみましょう。
- エラーが発生したときに表示されるテキスト文字列を探しており、関数の目的を伝えることができます。
- 可能な限りすべてが行から絞り出された後、さまざまなメニューのハンドラーを見つけることは理にかなっています。また、検索範囲を大幅に狭めます。
- そして最後に、不快で時間のかかる方法です。 プログラムをデバッガーにロードし、低レベル固有の（またはそうではない）APIにクラックを入れます。 そして、徐々に抽象化の上位レベルに上昇し、同時にIdaをちらっと見ます。 そのため、関数について説明するまで、一般に何をするかを明確に示すことができます。 便宜上、Idaの関数に名前を付け、検出されたアドレスを個別に保存します。
Fasmでひざまずいて書いたミニプラグインマネージャー全体。 その後、数週間で、約30個の関数を選択しました。 しかし、その時点ではPDK 1.10との互換性がなかったため、デバッガーを非表示にし、IdaProによって生成されたマップファイルからシンボルをロードし、簡単なダンパーを作成することができました。
軟膏で飛ぶ
オレグはおそらく私のベンチャーに注目を集めましたが、彼は2.01 alpha 4で自分のPDKを作成しました。 しかし、いくつかのポイントがあります。 新しいビルドは過負荷で不快になり、古いプラグインはサポートされていません。
現時点では、プラグインマネージャーは、すべてのバージョンとの互換性を考慮して、C ++でゼロから完全に書き直されています。 そして、ここでいくつかの機能のインターセプトは降りません...
さて、ここでは、1日のうちにひざまずいてもコードを記述する必要がないことがわかります。
ショールズなどは知っているので、ゼロから対応しました。
fasmのソレット
更新されたバージョンは、それが終了した後です。
作者のOllyDbgとexel @ bフォーラムの参加者の積極的なサポートに感謝し、Habrovskの人々に修正を与えてくれました。