fix/remote-vmmap-updates

[robwaz]

Description

Adds objfile handlers to non gef-remote remote sessions. Handler re-syncs /proc/maps when new objects are loaded.

Currently, if a non-gef gdb remote session is started (such as via pwntools gdb.debug), the vmmap command does not refresh when new libraries are loaded including libc. This breaks vmmap and other gef functionality that relies upon the newly mapped memory.

• [x] My code follows the code style of this project.
• [x] My change includes a change to the documentation, if required.
• [x] If my change adds new code, adequate tests have been added.
• [x] I have read and agree to the CONTRIBUTING document.

[github-actions[bot]]

🤖 Coverage update for 8a7fabd3c8e43c76aff933448afed775b55a86a2 🟢

	Old	New
Commit	db5b7b8d1784610d4577cf4137e453e974541aac	8a7fabd3c8e43c76aff933448afed775b55a86a2
Score	71.7996%	71.7996% (0)

[hugsy]

Thanks for the PR, but there are several things to point out:

Adds objfile handlers to non gef-remote remote sessions.

For now there are a lot of info missing from not using gef-remote which gef requires. So we don't support that. A beginning of work to fix this gap has been introduced by PR #1020 . However, there are some caveats.

Currently, if a non-gef gdb remote session is started (such as via pwntools gdb.debug),

There was an issue with bad sync for the memory mapping, but I think this bug has been fixed by #1047 Have you tried on this branch ?

[robwaz]

Yes, the memory mapping behavior is fixed in #1047 via an alternative approach here where info proc mappings is used instead of a local copy of the data in /tmp which makes more sense in my use-case.

https://github.com/hugsy/gef/commit/f07035f6c3b3321596305c406211b0a9185be1c7#diff-938d7f70ced09ad19db4c7483448b0814adafb564d10c9a3c04ed5e8a6357123R10469

[Grazfather]

What do you mean by a non-gef gdb remote session?

[robwaz]

gdbserver is launched against a binary

hacker@practice~program-interaction~level6:~$ gdbserver localhost:1234 /bin/cat
Process /bin/cat created; pid = 1892
Listening on port 1234
Remote debugging from host 127.0.0.1, port 37272

gdb connects via target remote localhost:1234

Full example of behavior that motivated PR is shown in attached file.

gef.txt

[hugsy]

Yes, the memory mapping behavior is fixed in https://github.com/hugsy/gef/pull/1047

I suspected so, great to know you could confirm that fixes it. info proc mappings is the way to go IMO because it unifies everything.

@Grazfather #1047 is ready for merge, fixes this bug (and restores rr and coredump support) think you can review it?

[Grazfather]

gdbserver is launched against a binary

hacker@practice~program-interaction~level6:~$ gdbserver localhost:1234 /bin/cat
Process /bin/cat created; pid = 1892
Listening on port 1234
Remote debugging from host 127.0.0.1, port 37272

gdb connects via target remote localhost:1234

Full example of behavior that motivated PR is shown in attached file.

gef.txt

We warn against doing this and don't support it. Why don't you just use gef-remote?

[robwaz]

The true use-case is using the python library pwntools to launch a process and debug it in gdb.

Pwntools performs the steps as I have shown in the example to remote attach. While not expressly supported by GEF, this has worked with GEF for many years. I use GEF in an educational setting, and currently have several learners that observe older material or online examples where this behavior works as expected. It would be one thing if this outright errored, but displaying stale/incorrect information is the least-helpful action that could occur. Yes, I can ask learners to not perform this exact series of steps, but now I am actively working against a common approach found all over the internet. A small PR that restores this behavior seemed a preferable solution.

As mentioned above, it looks like this behavior will be changed when PR #1047 is merged in as that PR also changes the behavior of the vmmap command such that it will prioritize info proc mappings over a temp file that does not get updated.

[Grazfather]

OK but FYI you can set up a dot file that will get picked up for the debug functionality. I used to use it to auto-split a tmux pane and debug in the new pane. Even if the above PR fixes it, you might want to include this in your setup for your students so that you get more consistent behaviour.

[Grazfather]

PR has been merged. @robwaz can you please confirm that your flow works now?

[robwaz]

I checked behavior on a couple boxes. Behavior is still present on ubuntu 20.04 because the packaged gdb version is 9.2.

The following check skips using info proc mappings and stale data is shown. https://github.com/hugsy/gef/blob/0fca69886b67ec5d8ea694fd4096eb13bb96a325/gef.py#L10588

[Grazfather]

OK. Removed that here https://github.com/hugsy/gef/pull/1073

[robwaz]

The vmmap command updates in all my tests in #1073 . I'll consider the permissions a separate issue and this PR can be closed once #1073 is merged in.

I appreciate your help with this!

[hugsy]

So it seems solved, can we close this PR?

[robwaz]

@hugsy As I mentioned above, #1073 was intended to make this feature work specifically on: ubuntu 20.04, gdb version 9.2 which would encountered the above GDB_VERSION check resulting in the stale vmmap data being displayed.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. You can reopen it by adding a comment to this issue.

[stale[bot]]

This issue has been automatically closed because it has not had recent activity. If you are the owner of this issue, you can either re-open it and provide a more complete description; or create a new issue. Thank you for your contributions.