Add mmap command that executes the mmap syscall in the inferior #1952
Conversation
- Additionally, moves syscall execution and general inferior-scoped code execution facilities into a single, new file, in 'pwndbg/gdblib/shellcode.py'
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## dev #1952 +/- ##
==========================================
+ Coverage 60.64% 60.67% +0.03%
==========================================
Files 181 183 +2
Lines 22315 22420 +105
Branches 2094 2113 +19
==========================================
+ Hits 13532 13603 +71
- Misses 8072 8093 +21
- Partials 711 724 +13 ☔ View full report in Codecov by Sentry. |
disconnect3d
changed the title
mmap command
| "PROT_READ": 0x1, | ||
| "PROT_WRITE": 0x2, | ||
| "PROT_EXEC": 0x4, | ||
| } |
There was a problem hiding this comment.
Should we maybe also support RWX or rwx?
| """Heuristic to convert PROT_EXEC|PROT_WRITE to integer value.""" | ||
| prot_int = 0 | ||
| for k, v in prot_dict.items(): | ||
| if k in protstr: |
There was a problem hiding this comment.
Fwiw PROT_EXECasdf will also work
There was a problem hiding this comment.
Yes, which isn't optimal, but I figured that if it's good enough for mprotect, it's probably good enough here too. But I could make it stricter.
pwndbg/commands/mmap.py
Outdated
| ) | ||
|
|
||
| page = pwndbg.lib.memory.Page(addr, int(length), 0, 0) | ||
| collisions = [] |
There was a problem hiding this comment.
In theory, there should never be more than a single collision (in practice if we have broken vmmap info there will be). We can safely assume a single collision here. Its fine if we print a single one if there are more
There was a problem hiding this comment.
I don't think I follow. If any range is permissible for our mmap, it could, in the worst case, technically collide with all of the mappings, no? Nothing's really stopping you from trying to call this with MAP_FIXED for [0, 0xffffffffffffffff[ (I know in practice there are limitations on covering the whole range, but this same logic applies for smaller ranges too).
There was a problem hiding this comment.
Oh... you are right. For some reason I was thinking that we map a single address instead of a range. Forgive my stupidness :)
We can be more lax tbh, such commands will always be "best effort" and are there just as a utility to support "interesting use cases" :D
Generally yes. This can be done in separate PR too |
Sure, I just feel that the testing I'm doing might be excessive. I'm thinking of disabling the more expensive range collision checks when run with
Shouldn't be too much trouble adding it now |
|
I've added some tests, but it's still missing a test for file based mappings. Should add them later today. |
This PR adds a
mmapcommand that calls themmapsystem call in the context of the inferior from inside pwndbg, allowing users to dynamically change the virtual memory layout of the program being analyzed.Example usage:
It achieves this in a manner similar to how the
mprotectcommand is currently implemented, with a few extra safeguards. Additionally, it moves that functionality into a new module located atpwndbg/gdblib/shellcode.py, and splits it into a function that allows for execution of arbitrary blobs of machine code in the context of the inferior (exec_shellcode), and, based on it, a function that allows for convenient invocation of system calls (exec_syscall).The
mmapcommand also notifies users of unaligned addresses (though it does not change those addresses on their behalf), and that checks for possibly overwritten mappings whenMAP_FIXEDis used and warns users of them.Finally, it also makes it so that
mprotectuses theexec_syscallfunction, rather than have its own separate implementation.A few questions that I feel need to be addressed:
mmapbe added?