将端口映射到 PID 以实现瞬时 Windows TCP 连接

发布于 2024-11-26 10:50:08 字数 514 浏览 2 评论 0原文

我正在尝试对第三方 TCP 客户端/服务器 Windows XP、SP 3 应用程序进行逆向工程,但我没有可用的源代码。我的主要攻击路线是使用WireShark来捕获TCP流量。

当我在客户端发出某个 GUI 命令时,客户端会创建一个到服务器的 TCP 连接,发送一些数据,然后断开该连接。服务器端口为1234,客户端端口由操作系统分配,因此有所不同。

WireShark 显示与我发出的 GUI 命令相对应的消息被发送了两次。这两个消息具有不同的源端口,但它们具有相同的目标端口(1234,如前所述)。

客户端实际上由多个进程组成,我想确定哪些进程正在发送这些消息。这些进程的寿命很长,因此它们的 PID 是稳定且已知的。然而,所涉及的 TCP 连接是暂时的,仅持续几毫秒左右。虽然我已经在 WireShark 中捕获了客户端端口号,并且知道所有涉及的 PID,但连接是瞬态的这一事实使得很难确定哪个 PID 打开了端口。 (如果连接是长期存在的,我可以使用 netstat 将端口号映射到 PID。)是否有人对我如何确定哪些进程正在创建这些临时连接有任何建议?

I am trying to reverse engineer a third-party TCP client / server Windows XP, SP 3 app for which I have no source available. My main line of attack is to use WireShark to capture TCP traffic.

When I issue a certain GUI command on the client side, the client creates a TCP connection to the server, sends some data, and tears down the connection. The server port is 1234, and the client port is assigned by the OS and therefore varies.

WireShark is showing that the message corresponding to the GUI command I issued gets sent twice. The two messages bear a different source port, but they have the same destination port (1234, as mentioned previosuly).

The client side actually consists of several processes, and I would like to determine which processes are sending these messages. These processes are long-lived, so their PIDs are stable and known. However, the TCP connections involved are transient, lasting only a few milliseconds or so. Though I've captured the client-side port numbers in WireShark and though I know all of the PIDs involved, the fact the connections are transient makes it difficult to determine which PID opened the port. (If the connections were long-lived, I could use netstat to map port numbers to PIDs.) Does anybody have any suggestions on how I can determine which processes are creating these transient connections?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

晒暮凉 2024-12-03 10:50:08

我能想到两件事:

  1. 尝试 sysinternals 的 tcpview 程序。它给出了系统中所有进程打开的所有 TCP 连接的详细列表。如果一个进程创建了连接,您将能够在 tcpview 中看到它们闪烁(连接和断开连接都会闪烁),您就会知道要开始查看哪些进程。

  2. 尝试在调试器下运行二进制文件。 Windbg 支持多进程调试(我认为 Visual Studio 也是如此)。您可能只能使用导出符号,但这仍然适用于对系统 dll 的调用。尝试中断任何您知道进程将调用的可疑 Windows API 来创建连接。 MSDN 应该记录了大多数系统 API 的相关 dll。

从这里开始...如果您再次遇到困难,请发布后续内容。

I can think of two things:

  1. Try sysinternals' tcpview program. It gives a detailed listing of all tcp connections opened by all the processes in the system. If a process creates connections, you will be able to see them flash (both connect and disconnect are flashed) in tcpview and you will know which processes to start looking into.

  2. Try running the binary under a debugger. Windbg supports multi-process debugging (so does visual studio I think). You may have only export symbols to work with but that should still work for calls made to system dlls. Try breaking on any suspected windows APIs you know will be called by the process to create the connections. MSDN should have the relevant dlls for most system APIs documented.

Start here... post a follow-up if you get stuck again.

恋你朝朝暮暮 2024-12-03 10:50:08

我最终创建了一个批处理文件,该文件在紧密循环中运行 netstat 并将其输出附加到文本文件中。我在运行系统时运行了这个批处理文件,并通过梳理所有 netstat 转储,我能够找到包含与端口关联的 PID 的转储。

I ended up creating a batch file that runs netstat in a tight loop and appends its output to a text file. I ran this batch file while running the system, and by combing through all of the netstat dumps, I was able to find a dump that contained the PIDs associated with the ports.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文