1

私は利用可能なソースがないサードパーティのTCPクライアント/サーバーWindows XP、SP 3アプリケーションをリバースエンジニアリングしようとしています。私の主な攻撃は、WireSharkを使ってTCPトラフィックを捕捉することです。一時的なWindows TCP接続のためのPIDへのマッピングポート

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

WireSharkは、発行したGUIコマンドに対応するメッセージがの2回に送信されることを示しています。 2つのメッセージには異なる送信元ポートがありますが、送信先ポートは同じです(先に説明したように1234)。

実際にクライアント側はいくつかのプロセスで構成されており、どのプロセスがこれらのメッセージを送信しているかを確認したいと考えています。これらのプロセスは長寿命なので、それらのPIDは安定しており、既知です。しかし、関係するTCP接続は一時的なもので、数ミリ秒程度しか持続しません。私はWireSharkのクライアント側のポート番号を取得しましたが、関連するすべてのPIDが分かっていますが、接続が一時的であるため、どのPIDがポートを開いたのかを判断することは困難です。 (接続が長生きすると、netstatを使用してポート番号をPIDにマップすることができます)。どのプロセスがこれらの一時的な接続を作成しているかをどのように判断できるかについての提案はありますか?私は二つのことを考えることができ

答えて

0

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

1

  1. は、Sysinternalsのtcpviewプログラムを試してみてください。これは、システム内のすべてのプロセスによって開かれたすべてのtcp接続の詳細な一覧を示します。プロセスが接続を作成すると、tcpviewでフラッシュ(接続と切断の両方がフラッシュされます)を見ることができ、どのプロセスを調べ始めるべきかを知ることができます。

  2. バイナリをデバッガで実行してみてください。 Windbgはマルチプロセスデバッグをサポートしています(Visual Studioもそうです)。使用するシンボルをエクスポートするだけで済みますが、システムDLLへの呼び出しでは機能するはずです。接続を作成するプロセスによって呼び出されることがわかっている疑わしいWindows APIを突破してみてください。 MSDNには、ドキュメント化されているほとんどのシステムAPIの関連dllが必要です。

ここから本文です。再開した場合はフォローアップを投稿してください。