Open hyjun0407 opened 8 months ago
Hi @hyjun0407
Try using the latest version of GEF from main
and use the correct syntax from the docs.
Hi guys, I'm facing this same problem on ubuntu, and I don't understand why. I used kali linux and it was possible to see the stack view, but for some reason in ubuntu it is not possible to do this.
Marked as stale as this needs more info. I cannot reproduce, if anyone can, update this issue with a full step by step.
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.
The same happens for me when I debug a local coredump.
gef➤ dereference $rsp
[!] Unmapped address: '$rsp'
gef➤ x/20g $rsp
0x7fff2d2fbc50: 0x0000003000000028 0x00007fff2d2fbd30
0x7fff2d2fbc60: 0x00007fff2d2fbc70 0x61f9ae278780fd00
0x7fff2d2fbc70: 0x0000000000000000 0x000057c7cce0f3a1
0x7fff2d2fbc80: 0x000057c7cce13220 0x000000000000004c
0x7fff2d2fbc90: 0x00007fff2d2fbee4 0x00000000fffffffd
0x7fff2d2fbca0: 0x0000000000000000 0x000057c7dcba01e0
0x7fff2d2fbcb0: 0x0000000000000016 0x000057c7dcba01e0
0x7fff2d2fbcc0: 0x000000002d2fbd00 0x0000000000000000
0x7fff2d2fbcd0: 0x000057c7dcba0bf1 0x0f00000000000001
0x7fff2d2fbce0: 0x00007fff2d2fbd20 0x00007fff2d2fc080
Maybe the issue happens when the program is not currently running locally? I can provide you with the coredump if needed.
I'd guess it's caused by #1046.
(In support of this, the bug appears with version 2024.06 but not in 2024.01.)
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.
.
@heinrich5991 can you try reverting that one PR to confirm if it's that issue?
If it's not the gef.memory.maps
then we will indeed spit that out. I don't know why info proc mappings
would not include the range that includes the stack.
I bisected the issue between 2024.01 and 2024.06 to find that c9a8b18808f06bb2e8c7fdb6de5a3dafcbfa7c56 is indeed the first commit with this bug.
c9a8b18808f06bb2e8c7fdb6de5a3dafcbfa7c56 is the first bad commit
commit c9a8b18808f06bb2e8c7fdb6de5a3dafcbfa7c56 (HEAD)
Author: crazy hugsy <hugsy@users.noreply.github.com>
Date: Sat Jan 20 10:37:32 2024 -0800
Use `info proc mapping` (#1046)
## Description
Use `info proc mapping` as a first memory layout enumeration technique.
Removed `maintenance info sections` which is not about memory layout
Restore CI coverage (#1050)
.github/workflows/coverage.yml | 74 +++++++-----------------------
.github/workflows/validate.yml | 8 ++--
gef.py | 109 +++++++++++++++++++++++++-------------------
tests/api/gef_memory.py | 147 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
tests/api/misc.py | 77 +------------------------------
tests/base.py | 9 +++-
tests/utils.py | 27 ++++++++---
7 files changed, 259 insertions(+), 192 deletions(-)
create mode 100644 tests/api/gef_memory.py
Easily reverting that commit wasn't possible on master:
$ git revert c9a8b18
Auto-merging .github/workflows/validate.yml
CONFLICT (content): Merge conflict in .github/workflows/validate.yml
Auto-merging gef.py
CONFLICT (content): Merge conflict in gef.py
CONFLICT (modify/delete): tests/api/gef_memory.py deleted in parent of c9a8b18 (Use `info proc mapping` (#1046)) and modified in HEAD. Version HEAD of tests/api/gef_memory.py left in tree.
Auto-merging tests/api/misc.py
Auto-merging tests/utils.py
error: could not revert c9a8b18... Use `info proc mapping` (#1046)
Reproduction:
#include <stdlib.h>
int main() {
abort();
}
$ gcc a.c
$ ./a.out
$ gdb a.out core.*
gef➤ dereference $rsp
[!] Unmapped address: '$rsp'
gef➤ x/20gx $rsp
0x7fff55ef4d10: 0x0100000000000008 0x69b6c0d46a2eeb00
0x7fff55ef4d20: 0x0000000000800000 0x0000000000000006
0x7fff55ef4d30: 0x0000702e1d092740 0x0000000000000000
0x7fff55ef4d40: 0x0000702e1d30b000 0x00005836e3598dd8
0x7fff55ef4d50: 0x00007fff55ef4d70 0x0000702e1d0d2120
0x7fff55ef4d60: 0x0000000000000040 0x0000702e1d27db50
0x7fff55ef4d70: 0x00007fff55ef4e30 0x0000702e1d0b94c3
0x7fff55ef4d80: 0x0000000000000020 0x0000000000000004
0x7fff55ef4d90: 0x0000000000000040 0x0000000000000800
0x7fff55ef4da0: 0x0000000000400000 0x0000000000000800
@Grazfather Could the https://github.com/hugsy/gef/labels/need-more-info label be removed if that's the one triggering the stale bot?
OK yeah I can reproduce.
That is annoying. Why would info proc mapping
not show the stack when debugging a core file?
I had time to root cause this. AFAICT the issues reported by @heinrich5991 and @hyjun0407 are different.
What @hyjun0407 reported is now being fixed in #1151 (not merged yet). It was coming from a bad support of qemu-user. This PR improves it and offers the possibility to use a mock layout if none was reported by qemu (for old versions). So this issue is now on the process of being fixed.
@heinrich5991 issue is specific to coredumps, which do not store stack layout in info proc maps
but in maintenance info sections
as @heinrich5991 rightfully pointed out. FWIW this could be worked around trivially by adding a stack Section
to GEF for instance as such:
gef➤ pi p=gef.arch.sp & ~0xfff
gef➤ pi gef.memory.maps.append( Section(page_start=p, page_end=p+0x1000, permission=Permission.ALL, path="[stack]") )
This is not a perfect solution but it's worth commenting, because those 2 issues are different despite seemingly similar.
Update: As #1151 is on its way to be merged and fix the initial issue reported by @hyjun0407 I have created another issue for the one reported by @heinrich5991 under https://github.com/hugsy/gef/issues/1154
GEF+GDB version
Operating System
WSL No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 22.04.4 LTS Release: 22.04 Codename: jammy
Describe the issue you encountered
qemu-aarch64-static -g 1234 ./prob When I run the command with and proceed to gef-remote localhost 1234 with gdb-multiarch, Stack View is not available as above. when i enter 'tele', it said [!] Unmapped address: '$sp' .
Do you read the docs and look at previously closed issues/PRs for similar cases?
No
Architecture impacted
Describe your issue. Without a proper reproduction step-by-step, your issue will be ignored.
qemu-aarch64-static -g 1234 ./prob When I run the command with and proceed to gef-remote localhost 1234 with gdb-multiarch, Stack View is not available as above. when i enter 'tele', it said [!] Unmapped address: '$sp' .
Minimalist test case
Use this field for a minimal code to compile and spot the issue:
You can also provide a Dockerfile if you prefer
Additional context?