Fix attaching to a gdbserver with tuple gdb.attach(('0.0.0.0',12345))

[ckxckx]

fix for issues/2290

[Arusekk]

Alright, now I see the error is there. But the error is in a different place.

pidof((host, port)) is currently documented as finding a process that has connected to (host, port). But there is no one connected to the gdb server, so it returns nothing.

Your fix breaks all other use cases, the proper fix would be to change the pidof() functionality in GDB to use sock_match(target, None) instead of sock_match(None, target).

I think pwning servers is more common than pwning clients [citation needed™], so this logic can be inverted to find a process listening on (host,port) instead of the one connected to (host,port).
You will then need to fix the test of pidof (simply changing lport to rport should be enough).
CHANGELOG would be required then for sure.
@peace-maker WDYT, is that okay?

[ckxckx]

Actually, we meet this bug when we use gdb.attach to Qemu gdbstub ...

[peace-maker]

This went under my radar for a while :D I've hit this too this weekend and I think it's fine to assume we're looking for the server providing the port instead of a client being connected to a port.

It seems the logic in net.sock_match need to be inverted too. Right now it always expects a remote socket and optionally a local socket. When we switch the proc.pidof parameters we'll always pass None as remote and will never match anything due to the check in line 269.

pwntools/pwnlib/util/net.py

Lines 262 to 273 in 5981c72

	if local is not None:
	local = sockinfos(local, fam, typ)
	remote = sockinfos(remote, fam, typ)
	def match(c):
	laddrs = sockinfos(c.laddr, c.family, c.type)
	raddrs = sockinfos(c.raddr, c.family, c.type)
	if not (raddrs & remote):
	return False
	if local is None:
	return True
	return bool(laddrs & local)