search

Gallopsled / pwntools

CTF framework and exploit development library
http://pwntools.com
Other
11.99k stars 1.7k forks source link

Fix `gdb.attach` not working properly in x-terminal-emulator #2363

Closed cnitlrt closed 5 days ago

cnitlrt commented 7 months ago

fix: #2362

peace-maker commented 6 months ago

Hey, was the issue solved externally?

cnitlrt commented 6 months ago

nop... Perhaps my proposed solution may not be the most efficient or elegant. Should I close the pull request and issue, or would it be advisable to consider reopening them?

peace-maker commented 6 months ago

I'm afraid of race conditions when just adding one. Can we get the new pid more deterministically? We can at least check the proc.children() of the parent terminal somehow?

cnitlrt commented 6 months ago

I'm afraid of race conditions when just adding one. Can we get the new pid more deterministically? We can at least check the proc.children() of the parent terminal somehow?

Hello, I've made some modifications to the code. Now, it can address my issue without impacting https://github.com/Gallopsled/pwntools/pull/1922

peace-maker commented 6 months ago

Can you explain your reasoning behind this change please?

cnitlrt commented 6 months ago

Can you explain your reasoning behind this change please?

Certainly, when debugging, I found that unlike tmux, gnome-terminal does not provide a method to directly retrieve the window pid (gdb_pid) such as through '-F' '#{pane_pid}', '-P'. When initialized using subprocess, gnome-terminal immediately pops up the window which has already been launched by the time wait_for_debugger is invoked. Consequently, at this juncture, the gdb_pid that we obtain through the p.pid method is actually the pid of the window, which is already operational. Henceforth, all we need to do is to ensure a successful trace to the process pid without disrupting the execution logic of tmux #1922 To achieve this, I switched 'break' to 'continue'. The system will subsequently keep invoking trace(pid) until it's not None, indicating that the process has been correctly traced.

peace-maker commented 5 days ago

The idea of that loop was to stop waiting for the debugger to attach to the process when the debugger exits itself. So this patch isn't the way to go.

I've recently faced a similar problem with launching gdb under WSL2 and fixed it in #2470 by waiting for the youngest new gdb process with a newer pid than the terminal we just started. It appears to be a good-enough and that logic could be reused here too?

cnitlrt commented 5 days ago

Hello sir, I installed the latest version of pwntools via pip in a new environment and retested. The issue is no longer present. However, I noticed that the pip-installed pwntools hasn't yet merged #2470 , so I'm unsure if it's related to my environment. Nonetheless, the issue is resolved. Thank you!

peace-maker commented 5 days ago

You updated to 4.13.X? #2470 is only active when running in WSL2, so it shouldn't help in your case on Ubuntu. Do you still use gnome-terminal? It's weird that this fixed itself, but I'll take it. If you run into this problem again, please open a new issue 👍