hugsy
Add support for registers in `target remote` post hook
Type of feature request
New architecture support/Existing architecture improvement
Misc
No response
Summary Description
I've been doing exploit development with pwntools and GEF together on the mips32elr6 architecture. When I use qemu for remote debugging with pwntool's gdb.attach(), it runs target remote instead of gef-remote.
I did my research and found this was discussed in December of 2023 (https://github.com/Gallopsled/pwntools/issues/2264) where the consensus was made to have GEF fix it instead of pwntools. This created the https://github.com/hugsy/gef/pull/1020 pull request where a remote posthook was created that catches the target remote command and establishes basic functionality. However, it says in the description:
Note that this isn't a perfect solution since we do not have all the information needed for a proper instantiation of the GefRemoteSessionManager, but it seems to be a good workaround in order to make tools like pwntools work correctly with gef.
It "works" for me, but the main issue I have is that the registers don't propagate because the registers command fails.
I guess no one else has complained about this yet but I would love it if the registers could at least show up there. Other stuff (like vmmap) I don't know if that's possible to show up accurately just based on the data transferred by qemu with remote debugging, but my main request is that registers show up with target remote.
Implementation idea/suggestion
Ideally, pwntools would just bite the bullet and figure out how to do gef-remote, but since it was decided that GEF will deal with it, I'm asking here. I also am aware the documentation says
Note: If using GEF, gef-remote must be your way or debugging remote processes, never target remote. Maintainers will provide minimal support or help if you decide to use the traditional target remote command. For many reasons, you should not use target remote alone with GEF. It is still important to note that the default target remote command has been overwritten by a minimal copy gef-remote, in order to make most tools relying on this command work.
I'm not familiar enough with the GEF or pwntools codebases to know the best way to deal with this, but would it be possible to just add the registers command or functionality so they show up in this situation? My current workaround is to patch the pwntools source code to run gef-remote instead...
Existing alternatives?
No response
Additional information
No response
This seems very strange to me, I will look into it. Can you provide a complete reproduction case of what you're trying to test (command lines, binaries, scripts...)?
All the files you need should be located in here. Just unzip and run python3 solve.py inside of tmux. Let me know if you need anything else.
looks like it's not setting up gef-remote at all. It's trying to read local maps. Very strange that it actually has the arch set correctly, though.
looks like it's not setting up gef-remote at all. It's trying to read local maps. Very strange that it actually has the arch set correctly, though.
Yeah, pwntools runs target remote under the hood instead of gef-remote (see linked issues above). Arch is set in GEF from context.binary, and GDB would normally auto-detect the architecture, but pwntools sets it manually. I think pwntools pulls the arch from the binary passed in to the exe argument in gdb.attach(). Note that I manually set it to mips:isa32r6 in the gdbscript because pwntools doesn't support specific releases of MIPS32 (like r6 vs r1).
@Legoclones Hi, yes thanks to your repro, I've been able to reproduce the issue, but had little time to work on a proper solution.
The issue is actually known for us and long-standing: GEF relies on procfs for the dereferencing commands to work properly. When using target remote manually to a qemu emulated binary, gef fails to know the memory layout, and therefore fails. To prove it, if you manually create a mock memory layout then everything works as expected.
Note that this is very much a workaround, not an actual fix. Unfortunately, I haven't had the time lately to work seriously on this.
For tracking: the fix for this issue will be part of a bigger work, tracked in #1149