1

ソースが利用できないサードパーティのTCPクライアント/サーバーWindowsXP、SP3アプリをリバースエンジニアリングしようとしています。私の主な攻撃ラインは、WireSharkを使用してTCPトラフィックをキャプチャすることです。

クライアント側で特定のGUIコマンドを発行すると、クライアントはサーバーへのTCP接続を作成し、データを送信して、接続を切断します。サーバーポートは1234であり、クライアントポートはOSによって割り当てられるため、異なります。

WireSharkは、発行したGUIコマンドに対応するメッセージが2回送信されることを示しています。2つのメッセージの送信元ポートは異なりますが、宛先ポートは同じです（前述のとおり、1234）。

クライアント側は実際にはいくつかのプロセスで構成されており、これらのメッセージを送信しているプロセスを特定したいと思います。これらのプロセスは長寿命であるため、それらのPIDは安定しており、既知です。ただし、関連するTCP接続は一時的なものであり、数ミリ秒程度しか持続しません。WireSharkでクライアント側のポート番号を取得し、関連するすべてのPIDを知っていますが、接続が一時的であるため、どのPIDがポートを開いたかを判断するのが困難です。（接続が長続きした場合は、netstatを使用してポート番号をPIDにマップできます。）これらの一時的な接続を作成しているプロセスを特定する方法について、誰か提案がありますか？

4

2 に答える 2

1

私は2つのことを考えることができます：

  1. sysinternalsのtcpviewプログラムを試してください。これは、システム内のすべてのプロセスによって開かれたすべてのtcp接続の詳細なリストを提供します。プロセスが接続を作成する場合、tcpviewでそれらがフラッシュされるのを見ることができ（接続と切断の両方がフラッシュされる）、どのプロセスが調査を開始するかがわかります。

  2. デバッガーでバイナリを実行してみてください。Windbgはマルチプロセスデバッグをサポートしています（ビジュアルスタジオもサポートしていると思います）。使用するエクスポートシンボルのみがある場合がありますが、それでもシステムdllへの呼び出しでは機能するはずです。接続を作成するプロセスによって呼び出されることがわかっている疑わしいWindowsAPIを壊してみてください。MSDNには、ほとんどのシステムAPIに関連するdllが文書化されている必要があります。

ここから始めてください...再び行き詰まった場合は、フォローアップを投稿してください。

于 2011-07-26T03:24:28.727 に答える
0

タイトなループでnetstatを実行し、その出力をテキストファイルに追加するバッチファイルを作成することになりました。システムの実行中にこのバッチファイルを実行し、すべてのnetstatダンプを組み合わせることで、ポートに関連付けられたPIDを含むダンプを見つけることができました。

于 2011-07-26T16:30:41.397 に答える