Heap analysis tooling for ptmalloc
License: MIT License
libptmalloc is a python library to examine ptmalloc (the glibc userland heap implementation). It is currently designed for use with GDB but could easily be adapted to work with other debuggers.
Please refer to the Install Guide.
Please refer to the User Guide.
Please refer to the Supported Versions.
Please refer to the Development Guide.
Fix ptchunk output for small chunks as they are shown as fastbins even though they are allocated.
pwndbg> ptchunk 0x8913308 -c 5
0x8913308 f sz:0x000a8 fl:--P
0x89133b0 f sz:0x000a8 fl:--P
0x8913458 f sz:0x00068 fl:--P
0x89134c0 f sz:0x00068 fl:--P
0x8913528 f sz:0x00068 fl:--P
pwndbg> ptchunk 0x8913308 -c 2 -x
0x8913308 f sz:0x000a8 fl:--P
0x9c bytes of chunk data:
0x8913310: 0x00000000 0x00000000 0x00000000 0x08913310
0x8913320: 0x00000000 0x00000000 0x00000000 0x00000000
0x8913330: 0x00000000 0x00000000 0x00000000 0x00000000
0x8913340: 0x00000000 0x00000000 0x00000000 0x00000000
0x8913350: 0x00000000 0x00000000 0x00000000 0x00000000
0x8913360: 0x00000000 0x00000000 0x00000000 0x00000000
0x8913370: 0x00000000 0x00000000 0x00000000 0x00000000
0x8913380: 0x00000000 0x00000000 0x00000000 0x00000000
0x8913390: 0x00000000 0x00000000 0x00000000 0x00000000
0x89133a0: 0x00000000 0x00000000 0x00000000
--
0x89133b0 f sz:0x000a8 fl:--P
0x9c bytes of chunk data:
0x89133b8: 0x00000000 0x089133b8 0x00000000 0x00000000
0x89133c8: 0x00000000 0x00000000 0x00000000 0x00000000
0x89133d8: 0x00000000 0x00000000 0x00000000 0x00000000
0x89133e8: 0x00000000 0x00000000 0x00000000 0x00000000
0x89133f8: 0x00000000 0x00000000 0x00000000 0x00000000
0x8913408: 0x00000000 0x00000000 0x00000000 0x00000000
0x8913418: 0x00000000 0x00000000 0x00000000 0x00000000
0x8913428: 0x00000000 0x00000000 0x00000000 0x00000000
0x8913438: 0x00000000 0x00000000 0x00000000 0x00000000
0x8913448: 0x00000000 0x00000000 0x00000000
It is probably due to the fact that most of our tests were with libmempool and we were able to guess if a small chunk was free or not (i.e. a part of the fast bins or not - noted "f" as above) based on the mempool header values. But here we don't have that.
So a fix is to mark it as M instead of f and have a warning indicating it could be part of a fastbins due to the size. Then the only way to remove the warning would be to search the arena fastbins bins and check if the chunk is part of the fastbins so we could mark it "f".
the help needs to be updated to accurately say what the command does
at the moment the ptarena -l command doesn't actually which arenea is the main arena itself, which is a little bit confusing.
(remote-gdb) p &main_arena
$7 = (struct malloc_state *) 0x7ffff7852b80 <main_arena>
(remote-gdb) ptarena
Retrieving arena again
struct malloc_state @ 0x7ffff7852b80 {
mutex = 0x0
flags = 0x0
have_fastchunks = 0x0
fastbinsY = {...}
top = 0x5555556b5310
last_remainder = 0x555555604920
bins = {...}
binmap = {...}
next = 0x7fffec000020
next_free = 0x0
attached_threads = 0x1
system_mem = 0x102000
max_system_mem = 0x102000
(remote-gdb) ptarena -l
Retrieving arena again
Arena(s) found:
arena @ 0x7ffff7852b80
arena @ 0x7fffec000020
we should update this so that fthe main arena is listed and indicated in the list of arenas found, possibly just like: main_arena @
this can be done by introducing a new ptversion command it lets you specify a supported version, and we can also add support for a heuristic that tries to guess the version. we can walk the bins for a guessed layout, and test pointers that don't point back to the main arena to see if this size actually correlates to the guessed index, in if not we can adjust the off said for that bin so that at lines up correctly and do further sanity tests
when calling pthelp we don't currently list the ptbin command
right now when you're looking at the next point it's confusing if there is actually another arena or not
right now dumping the entire arena every time is annoying
at the moment you need debug symbols from the target libc in order to use the tool, but we should add support for trying to find it on the fly, for both convenience and first situations where we just can't get the dug symbols.
I get the following error when I am trying to install it:
`
ubuntu@ubuntu:~/heap$ sudo pip3 install ./libptmalloc/
Processing ./libptmalloc
Preparing metadata (setup.py) ... error
error: subprocess-exited-with-error
× python setup.py egg_info did not run successfully.
│ exit code: 1
╰─> [17 lines of output]
Traceback (most recent call last):
File "/usr/lib/python3.10/tokenize.py", line 344, in find_cookie
codec = lookup(encoding)
LookupError: unknown encoding: future_fstrings
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "<string>", line 2, in <module>
File "<pip-setuptools-caller>", line 28, in <module>
File "/usr/lib/python3.10/tokenize.py", line 396, in open
encoding, lines = detect_encoding(buffer.readline)
File "/usr/lib/python3.10/tokenize.py", line 373, in detect_encoding
encoding = find_cookie(first)
File "/usr/lib/python3.10/tokenize.py", line 352, in find_cookie
raise SyntaxError(msg)
SyntaxError: unknown encoding for '/home/ubuntu/heap/libptmalloc/setup.py': future_fstrings
[end of output]
note: This error originates from a subprocess, and is likely not a problem with pip.
error: metadata-generation-failed
× Encountered error while generating package metadata.
╰─> See above for output.
note: This is an issue with the package mentioned above, not pip.
hint: See above for details.
ubuntu@ubuntu:~/heap$ python3 --version
Python 3.10.6
`
Installing or uninstalling future_fstrings package does not seem like affecting the outcome.
(gdb) ptchunk 0x5625e5094920-0x10
self.address: 0x5625e5094940
[!] Could not read nextchunk (@0x5625e50b5000) size. Invalid chunk address?
in this case it's actually ok:
(gdb) heapls
ADDR SIZE STATUS
sbrk_base 0x5625e5094000
chunk 0x5625e5094000 0x250 (inuse)
chunk 0x5625e5094250 0x230 (inuse)
chunk 0x5625e5094480 0x80 (inuse)
chunk 0x5625e5094500 0x410 (inuse)
chunk 0x5625e5094910 0x30 (inuse)
chunk 0x5625e5094940 0x206c0 (top)
sbrk_end 0x5625e50b5000
so we should gracefully handle that
This is the error if you try to source it before the program is actually running under gdb:
[!] GDB is not running.
Read glibc configuration from config file
[!] GDB is not running.
[!] error fetching size
Traceback (most recent call last):
File "../../tools/heap/libptmalloc/pyptmalloc-dev.py", line 13, in <module>
from libptmalloc import *
File "/source/tools/heap/libptmalloc/libptmalloc/__init__.py", line 34, in <module>
pyp.pyptmalloc()
File "/source/tools/heap/libptmalloc/libptmalloc/pyptmalloc.py", line 69, in __init__
self.ptm = pt.ptmalloc(debugger=self.dbg, version=glibc_version, tcache_enabled=tcache_enabled)
File "/source/tools/heap/libptmalloc/libptmalloc/ptmalloc/ptmalloc.py", line 63, in __init__
self.set_globals(SIZE_SZ=self.SIZE_SZ)
File "/source/tools/heap/libptmalloc/libptmalloc/ptmalloc/ptmalloc.py", line 74, in set_globals
raise Exception("sys.exit()")
This output could be improved to be more clear about what needs to be done, also just exit earlier as soon as it knows it's not running.
One feature of libptmalloc is to print info for a chunk in a one-line showing the chunk address (using the "ptchunk" command), if it is freed or allocated, some flags. One cool feature to have would be to also print the function that allocated that chunk. In general we can't do that as no metadata is stored for that. However if we use the "ptchunk" command just after an allocation or before a free (i.e by setting a bp on malloc or free), we could get that information from gdb and show it in the same one-line. This would allow showing beautiful feng shui with just "ptchunk" commands.
We could even improve it by ignoring some functions and go deeper in the backtrace if we know some functions are not relevant for us, so we get a better output.
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.