scwuaptx/pwngdb

gdb for pwn

Pwngdb

GDB for pwn.

Install

install

cd ~/
git clone https://github.com/scwuaptx/Pwngdb.git 
cp ~/Pwngdb/.gdbinit ~/

If you dont want to use gdb-peda , you can modify the gdbinit to remove it.

pwndbg

If you only want to install with pwndbg, see pwndbg/README.md

Heapinfo

If you want to use the feature of heapinfo and tracemalloc , you need to install libc debug file (libc6-dbg & libc6-dbg:i386 for debian package)

Features

• libc : Print the base address of libc
• ld : Print the base address of ld
• codebase : Print the base of code segment
• heap : Print the base of heap
• got : Print the Global Offset Table infomation
• dyn : Print the Dynamic section infomation
• findcall : Find some function call
• bcall : Set the breakpoint at some function call
• tls : Print the thread local storage address
• at : Attach by process name
• findsyscall : Find the syscall
• fmtarg : Calculate the index of format string
  • You need to stop on printf which has vulnerability.
• force : Calculate the nb in the house of force.
• heapinfo : Print some infomation of heap
  • heapinfo (Address of arena)
  • default is the arena of current thread
  • If tcache is enable, it would show infomation of tcache entry
• heapinfoall : Print some infomation of heap (all threads)
• arenainfo : Print some infomation of all arena
• chunkinfo: Print the infomation of chunk
  • chunkinfo (Address of victim)
• chunkptr : Print the infomation of chunk
  • chunkptr (Address of user ptr)
• mergeinfo : Print the infomation of merge
  • mergeinfo (Address of victim)
• printfastbin : Print some infomation of fastbin
• tracemalloc on : Trace the malloc and free and detect some error .
  • You need to run the process first than tracemalloc on, it will record all of the malloc and free.
  • You can set the DEBUG in pwngdb.py , than it will print all of the malloc and free infomation such as the screeshot.
• parseheap : Parse heap layout
• magic : Print useful variable and function in glibc
• fp : show FILE structure
  • fp (Address of FILE)
• fpchain: show linked list of FILE
• orange : Test house of orange condition in the _IO_flush_lockp
  • orange (Address of FILE)
  • glibc version <= 2.23

Screenshot

• Chunkinfo

• Mergeinfo

• Heapinfo

• Heapinfoall

• parseheap

• tracemalloc

• magic

pwngdb's Issues

[Bug] Weird behavior while detecting overlapped chunk

Hi, I found a bug in the function of detecting overlapped chunk
Here is my testing program (x86_64 ELF):

#include <stdio.h>
#include <string.h>
#include <math.h>
#include <stdlib.h>
#include <unistd.h>

int main(int argc, char *argv[])
{
    char *p = malloc(30);
    char *q = malloc(30);
    char *r = malloc(30);
    free(p);
    free(q);
    free(p);
    return 0;
}

And here's the gdb command:

b main  
r
tracemalloc on
c

The debugger run normally at the first run:

But then it got the wrong result with the second run:

I guess there exist some bug during the data re-initialization ?

glibc heap analyzing displays wrong indexes for largebins

Analyzing glibc2.24 malloc internals on a 64-bit machine, I'm using both parseheap & heapinfo functionalities.

Basically, when we use heapinfo we get "wrong" index number for largebins.
It will be easier to explain with an example.

 1 heap_k.c                                                                                                                       X 
 #include <stdio.h>
 #include <stdlib.h>
 #include <string.h>
 
 #define NSMALLBINS 64 // from glibc 2.24
 
 // actual calculation of NSMALLBINS 
 #define NUNSORTEDBINS 1 
 #define MIN_LARGE_SIZE (NSMALLBINS * 0x10)
 #define MIN_CHUNK_SIZE 0x20
 #define CHUNKS_SKIP ((MIN_CHUNK_SIZE / 0x10) - 1)
 #define OVER_HEAD 0x8
 #define REAL_NSAMLLBINS ((MIN_LARGE_SIZE - (NUNSORTEDBINS * 0x10)) / 0x10 - CHUNKS_SKIP) // 62
 
 
 void main(){
 
     setvbuf(stdin,NULL,_IONBF,0);  // no buffering
     setvbuf(stdout,NULL,_IONBF,0); // no buffering
     char* a00 = (char*) malloc(512);  // no coalescing 
     char* a01 = (char*) malloc(0xb0); // smallbin will be splitted for malloc(0x0) request
     char* a02 = (char*) malloc(512);  // no coalescing 
     char* a03 = (char*) malloc(REAL_NSAMLLBINS * 0x10 + CHUNKS_SKIP * 0x10 - OVER_HEAD); // biggest smallbin chunk possible
     char* a04 = (char*) malloc(512);  // no coalescing 
     char* a05 = (char*) malloc(REAL_NSAMLLBINS * 0x10 + CHUNKS_SKIP * 0x10 - OVER_HEAD + 1); // smallest largebin chunk possible
     char* a06 = (char*) malloc(512);  // no coalescing 
     char* a07 = (char*) malloc(9000); // random largebin chunk
     char* a08 = (char*) malloc(512);  // no coalescing 
 
     free(a01);
     free(a03);
     free(a05);
     free(a07);
 
     char* a09 = (char*) malloc(0x90); // a01 is spillted to size 0xb0-0x90 = 0x20 
     char* a10 = (char*) malloc(0x9001); // sort unorderedbin
 
 }
 ~     

What this example does is forcing a split of chunks so a chunk of size 0x20 (smallest) will be inserted to the 0x20 smallbin which is the first one. Then it allocates the biggest chunk that fits smallbin requirments 0x3f0 - 8 so it will be inserted to the 0x3f0 which is the last smallbin.
Afterwards it allocates the smallest chunk that fits largebin requirments 0x3f0 + 1 so it will be inserted to the first largebin.

The calculation problem, lets break into this program at the end of main.
gdb heap_h -x utils.sh

# utils.sh
...
define hip
parseheap
heapinfo
end
...

output

gdb-peda$ hip
addr                prev                size                 status              fd                bk                
0x555555756000      0x0                 0x210                Used                None              None
0x555555756210      0x0                 0xa0                 Used                None              None
0x5555557562b0      0x0                 0x20                 Freed     0x7ffff7dd3b68    0x7ffff7dd3b68
0x5555557562d0      0x20                0x210                Used                None              None
0x5555557564e0      0x0                 0x3f0                Freed     0x7ffff7dd3f38    0x7ffff7dd3f38
0x5555557568d0      0x3f0               0x210                Used                None              None
0x555555756ae0      0x0                 0x400                Freed     0x7ffff7dd3f48    0x7ffff7dd3f48
0x555555756ee0      0x400               0x210                Used                None              None
0x5555557570f0      0x0                 0x2330               Freed     0x7ffff7dd4208    0x7ffff7dd4208
0x555555759420      0x2330              0x210                Used                None              None
0x555555759630      0x0                 0x9010               Used                None              None
(0x20)     fastbin[0]: 0x0
(0x30)     fastbin[1]: 0x0
(0x40)     fastbin[2]: 0x0
(0x50)     fastbin[3]: 0x0
(0x60)     fastbin[4]: 0x0
(0x70)     fastbin[5]: 0x0
(0x80)     fastbin[6]: 0x0
                  top: 0x555555762640 (size : 0x149c0) 
       last_remainder: 0x5555557562b0 (size : 0x20) 
            unsortbin: 0x0
(0x3f0)  smallbin[61]: 0x5555557564e0
(0x020)  smallbin[ 0]: 0x5555557562b0
         largebin[64]: 0x555555756ae0 (size : 0x400)
         largebin[108]: 0x5555557570f0 (size : 0x2330)
gdb-peda$

heapinfo output shows us the "a05" is in the 64th largebin, it should be the 1st (0) in largebins.

Sidenote, both smallbins and largebins are part of a bigger array in "malloc_state" struct called "bins".
This array length is determined at compile time:

// glibc2.24
// https://github.com/bminor/glibc/blob/release/2.24/master/malloc/malloc.c
#define NBINS             128

The first bin is the unsortedbin, then (in this example) 62 smallbins and the rest should be largebins (63?)..

Example of calculating the last smallbin and first largebin address in malloc_state.
Check main_arena (malloc_state) struct

gdb-peda$ p main_arena
$1 = {
  mutex = 0x0, 
  flags = 0x1, 
  fastbinsY = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, 
  top = 0x555555762ad0, 
  last_remainder = 0x555555756740, 
  bins = {0x7ffff7dd3b58 <main_arena+88>, 0x7ffff7dd3b58 <main_arena+88>, 0x555555756740, 0x555555756740, 0x555555756000, 
...

calculate

gdb-peda$ set $unorderedbin=(long long int)(&main_arena.bins)
gdb-peda$ set $last_smallbin=(long long int)(&main_arena.bins) + 0x10 * 62
gdb-peda$ set $first_largebin=(long long int)(&main_arena.bins) + 0x10 * 63
gdb-peda$ x $unorderedbin
0x7ffff7dd3b68 <main_arena+104>:	0x00007ffff7dd3b58
gdb-peda$ x $last_smallbin
0x7ffff7dd3f48 <main_arena+1096>:	0x00005555557564e0
gdb-peda$ x $first_largebin
0x7ffff7dd3f58 <main_arena+1112>:	0x0000555555756ae0

SyntaxWarning: invalid escape sequence

/usr/share/pwngdb/pwngdb.py:406: SyntaxWarning: invalid escape sequence '\.'
  data = re.search(".*libc.*\.so",infomap)
/usr/share/pwngdb/pwngdb.py:416: SyntaxWarning: invalid escape sequence '\.'
  data = re.search(".*ld.*\.so",infomap)
/usr/share/pwngdb/pwngdb.py:426: SyntaxWarning: invalid escape sequence '\]'
  data = re.search(".*heap\]",infomap)
/usr/share/pwngdb/pwngdb.py:610: SyntaxWarning: invalid escape sequence '\%'
  print("The index of format argument : %d (\"\%%%d$p\")" % (idx,idx - 1))
/usr/share/pwngdb/pwngdb.py:614: SyntaxWarning: invalid escape sequence '\%'
  print("The index of format argument : %d (\"\%%%d$p\")" % (idx,idx - 1))
/usr/share/pwngdb/angelheap/angelheap.py:371: SyntaxWarning: invalid escape sequence '\.'
  data = re.search(".*libc-.*\.so",infomap)

Since Python3.12, a backslash-character pair that is not a valid escape sequence now generates a SyntaxWarning, instead of DeprecationWarning. It can be fixed by using raw strings.
e.g. data = re.search(r".*libc.*\.so",infomap)

i run heapinfo command but it not works

pwndbg> heapinfo
Undefined command: "heapinfo". Try "help".

無法在gdb中attach pid

不好意思，前幾天用了你的pwngdb之後發現無法在gdb裡面attach pid，pidof找到程式的pid後輸入指令at pid 之後顯示No such process...。目前僅能在terminal下sudo gdb -p pid，請問可有解決方式？謝謝

※我的peda是自己另外下載的，不知道有沒有關......
※剛剛沒顯示pid出來><

tls for i386 is not correct

Hi, Bruce here :)
Spot a weird implementation in your debugger
Please correct me if I have any misunderstanding !

Although there's been a lot less i386 binary in the CTF pwning challenge now
I think I'll still point out that the gettls function for the i386 binary isn't giving the correct address
In fact I'm quite surprise that you are using libc's base address - 0x300 as the tcbhead_t's base address , where did you get that information ? Can you provide the reference?

BTW , I've also implement getting the tls address in my own debugger, too (by modifying gdb-peda's source code), here the link ( at line 4494, function tls_i386)
According to this link, sysinfo will be stored as the 5th member of a tcbheader_t's structure, which is at tls base address + 0x10. So here's how I implement:

• Find the address of the __kernel_vsyscall ( = sysinfo ) by using info functions
• Find the address that stores the sysinfo
• The tls base address = address that stores the sysinfo - 0x10

Here's the difference between your gettls function and mine (test in Ubuntu Linux 14.04 32 bit):
yours:

gdb-peda$ info proc
process 3844
cmdline = './Desktop/starbound_patch'
cwd = '/home/bruce30262'
exe = '/home/bruce30262/Desktop/starbound_patch'
gdb-peda$ tls
tls : 0xb743a700
gdb-peda$ canary
canary : 0x9691973  <-- no null byte
gdb-peda$ 

mine:

gdb-peda$ info proc
process 3844
cmdline = './Desktop/starbound_patch'
cwd = '/home/bruce30262'
exe = '/home/bruce30262/Desktop/starbound_patch'
gdb-peda$ tls
setting $tls = 0xb7434700
setting $canary = 0x87354b00
0xb7434680: 0x00000000  0x00000000  0x00000000  0x00000000
0xb7434690: 0x00000000  0x00000000  0x00000000  0x00000000
0xb74346a0: 0x00000000  0x00000000  0x00000000  0x00000000
0xb74346b0: 0x00000000  0xb75e68a0  0xb75e8fc0  0x00000000
0xb74346c0: 0xb75871a0  0xb7586ba0  0xb7587aa0  0x00000000
0xb74346d0: 0x00000000  0x00000000  0xb75e6420  0x00000000
0xb74346e0: 0x00000000  0x00000000  0x00000000  0x00000000
0xb74346f0: 0x00000000  0x00000000  0x00000000  0x00000000
0xb7434700: 0xb7434700  0xb7434bc8  0xb7434700  0x00000000
0xb7434710: 0xb77b3414  0x87354b00  0x18ff5a26  0x00000000
0xb7434720: 0x00000000  0x00000000  0x00000000  0x00000000
0xb7434730: 0x00000000  0x00000000  0x00000000  0x00000000
0xb7434740: 0x00000000  0x00000000  0x00000000  0x00000000
0xb7434750: 0x00000000  0x00000000  0x00000000  0x00000000
0xb7434760: 0x00000000  0x00000000  0x00000000  0x00000000
0xb7434770: 0x00000000  0x00000000  0x00000000  0x00000000
0xb7434780: 0xbfd9f344  0x00000000  0x00000000  0x00000000
0xb7434790: 0x00000000  0x00000000  0x00000000  0x00000000
0xb74347a0: 0x00000000  0x00000000  0x00000000  0x00000000
0xb74347b0: 0x00000000  0x00000000  0x00000000  0x00000000
tls address: 0xb7434700
stack canary: 0x87354b00
Found a stack address 0xbfd9f344 at 0xb7434780

BTW this is such an OP debugger man, especially the heap info part, will it have a chance for you to modulize the heap info part so everyone can import the module to their own debugger?
Thanks !

[Bug] Wrong detecting result for x86 binary

I also found some bug while testing the heap feature with the x86 binary (32bit)
The testing program is the same as #4
The tracemalloc isn't giving the right result:

The inuse and heapinfo also seems to have some problem:

Would you please fix the problem ? Thanks

api "heap" is conflict with gef's heap

I'm big fan of Pwngdb, at the same time I use gef, but Pwngdb's api 'heap' is conflict with gef's heap, every time I test my docker I need to change Pwngdb's 'heap' to 'heapbase'.
In my opinion, use 'heapbase', 'libcbase' may be better.....

Upstream functionality to pwndbg

Hi,

It seems like this project is already making heavy use of the pwndbg API. Do you have any thoughts on upstreaming some of these features to the main pwndbg repo? If you want to discuss this more, feel free to join our discord here, if you're not already on there.

pwndbg installation failed

for now,there is no "pwndbg.commands.xor" in $pwndbg/pwndbg/init.py, which resulting in failed installation
can you modify the pwndbg installation README agian

Error

----------error info------------------------------
gdb-peda$ chunkinfo
Can't access memory
gdb-peda$ chunkptr
Python Exception <class 'TypeError'> unsupported operand type(s) for -: 'NoneType' and 'int':
Python Exception <class 'gdb.error'> Error occurred in Python command: unsupported operand type(s) for -: 'NoneType' and 'int':
Error occurred in Python command: Error occurred in Python command: unsupported operand type(s) for -: 'NoneType' and 'int'

some enviroment
python version 2.7.6
gdb version 7.7
os ubuntu 14.04

Error in Free_Bp_handler when getting argument

Pwngdb/angelheap/angelheap.py

Lines 165 to 169 in cd736c1

	getarch()
	if arch == "x86-64":
	reg = "$rsi"
	result = int(gdb.execute("info register " + reg,to_string=True).split()[1].strip(),16) + 0x10
	else :

According to x86-64 function calling convention, The first six integer or pointer arguments are passed in registers RDI, RSI, RDX, RCX, R8, R9. so RDI stores the first argument of the free function. which denotes the pointer to free. Using RSI would get the wrong value.
Same for Malloc_Bp_handler function, but I found $RDI = $RSI in malloc when debugging. So malloc trace seems normal. But Free_Bp_handler failed to get the value of the pointer to be freed.

do the the command "free" have bug?

I have fastbin chunk: 0x14fb020, setting its fd and bk truely, and fake small chunk: 0x14fb040,
but not set its element prevsize, so when I free the small chunk, it can not pass the unlink check p->size=next-> prevsize. but use the command " free", it return "True".

angelheap failed to trace free() while using tracemalloc

Environment

• Ubuntu Linux 18.04.1 64 bit
• glibc version : Ubuntu GLIBC 2.27-3ubuntu1

Detail

testing program:

/* gcc -o test test.c*/

#include <stdio.h>
#include <string.h>
#include <math.h>
#include <stdlib.h>
#include <unistd.h>

int main(int argc, char *argv[])
{
    char *p1 = malloc(20);
    char *p2 = malloc(30);
    char *p3 = malloc(40);
    char *p4 = malloc(50);
    char *p5 = malloc(60);
    char *p6 = malloc(3000);

    free(p1);
    free(p2);
    free(p3);
    free(p5);
    free(p4);
    free(p6);
    return 0;
}

While using tracemalloc on/off, angelheap successfully trace the malloc() function call, but not the free() call. This cause some error in parseheap and overlapped chunk detecting.

For some unknown reason, glibc did not run into _int_free() in glibc 2.27.
Any idea how to fix it ?

Error when using Pwngdb in ubuntu 19.04 with libc 2.29

Ctrl + C cannot stop the gdb.
Using ubuntu:19.04 Docker with pwntools and tmux.

Basic Output Logging

is there an easy way to make output logging show only the output of results of commands?
I would rather not have to sift through all the context info after running a gdb script file to view some very specific info.

[Bug] heapbase variable is referenced before assignment.

I found a python exception when I tried the parseheap.
The error messages are as follows.

gdb-peda$ parseheap 
Can't find heap
Python Exception <class 'UnboundLocalError'> local variable 'heapbase' referenced before assignment: 
Python Exception <class 'gdb.error'> Error occurred in Python command: local variable 'heapbase' referenced before assignment: 
Error occurred in Python command: Error occurred in Python command: local variable 'heapbase' referenced before assignment

I found the cause of the exception at parse_heap() in angelheap.py.
When using only main_arena, main_arena variable will be correct address in libc and thread_arena will be NULL(0).
Therefore no conditional branch is satisfied, the value of heapbase is not assignment.

    # if thread_arena == main_arena :
    if main_arena :
        heapbase = int(gdb.execute("x/" + word + " &mp_.sbrk_base",to_string=True).split(":")[1].strip(),16)
    elif thread_arena :
        arena_size = int(gdb.execute("p sizeof(main_arena)",to_string=True).split("=")[1].strip(),16)
        heapbase = thread_arena + arena_size
    else :
        print("Can't find heap")

I hope this bug will be fix, thanks.

[Bug] Incorrect chunk address while showing tcache_entry

Environment:

• Ubuntu Linux 17.10 64 bit
• Ubuntu GLIBC 2.26-0ubuntu2.1

---

source code for testing:

char *p = malloc(16);                                                                                                                                                          
char *p1 = malloc(22);
free(p);
free(p1);

After freeing the memory, chunk in the tcache entry:

However angelheap shows the incorrect chunk address:

---

Another source code for testing:

char *p = malloc(16);                                                                                                                                                          
char *p1 = malloc(22);
char *p2 = malloc(22);
free(p);
free(p1);
free(p2);

After freeing the memory, tcache_entry[0] should be:

But angelheap shows the following instead:

some command(such as bcall) could not find symbol

in the latest commit, some function such as "bcall" could not find symbol, the type of symbol is false when searching symbol using objdump; it should be "str", not "gdb value".

Libc symbols not found

When i patch an elf with a different libc-*.so and gdb it i keep get:
Can not get libc version
Cannot get main_arena's symbol address. Make sure you install libc debug file (libc6-dbg & libc6-dbg:i386 for debian package).
can't find heap info
Already installed libc6-dbg and libc6-dbg:i386
What should i do?

a bug of parse_heap

Problem

This bug is due to a strange alignment strategy in newer version of 32 bit glibc.

In a nutshell, the first 16 bytes of heap is 0 in glibc-2.26 (32bit), glibc-2.27 (32bit).

As a result, while parsing heap, the first chunk has size 0 and trigger stop.

Fix

Fix is really easy, just ignore the first chunk if size is 0.

More

This problem was initially found when I was finishing my project HeapInspect.

Then I find that pwndbg has this problem. So does your amazing angelheap.

tcache size error in i386

The size list of tcache seems architecture-independent, whitch means the size list is still [0x10, 0x20, 0x30,...] in i386 instead of [0x10, 0x18, 0x20,...].
look at this:

glibc heap analyzing uses a fixed number of fastbins

Analyzing glibc2.24 malloc internals on a 64-bit machine, I'm using both parseheap & heapinfo functionalities.
Basically, heapinfo shows info of 7 fastbins although 10 exist (actually max of actual use is 9?).

gdb-peda$ heapinfo
(0x20)     fastbin[0]: 0x555555756060 --> 0x555555756020 --> 0x0
(0x30)     fastbin[1]: 0x0
(0x40)     fastbin[2]: 0x0
(0x50)     fastbin[3]: 0x0
(0x60)     fastbin[4]: 0x0
(0x70)     fastbin[5]: 0x0
(0x80)     fastbin[6]: 0x5555557560a0 --> 0x0
                  top: 0x5555557562e0 (size : 0x20d20) 
       last_remainder: 0x0 (size : 0x0) 
            unsortbin: 0x0
gdb-peda$ p main_arena
$1 = {
  mutex = 0x0, 
  flags = 0x0, 
  fastbinsY = {0x555555756060, 0x0, 0x0, 0x0, 0x0, 0x0, 0x5555557560a0, 0x0, 0x5555557561a0, 0x0}, 
  top = 0x5555557562e0, 

I found in "mallopt" man page the param M_MXFAST you send to it to change what they describe as

http://man7.org/linux/man-pages/man3/mallopt.3.html
upper limit for memory allocation requests that are using "fastbins"
The default value is
64*sizeof(size_t)/4
The maximum value is
80*sizeof(size_t)/4

Also in the source code, the size of fastbinsY is determined at compile time, by NFASTBINS.

//glibc2.24 malloc.c
//https://github.com/bminor/glibc/blob/release/2.24/master/malloc/malloc.c

struct malloc_state
{
  /* Serialize access.  */
  mutex_t mutex;

  /* Flags (formerly in max_fast).  */
  int flags;

  /* Fastbins */
  mfastbinptr fastbinsY[NFASTBINS];

  /* Base of the topmost chunk -- not otherwise kept in a bin */
  mchunkptr top;

After a brief check, I saw that in my case NFASTBINS is 10.

Here is the part of the program that modified the max size of chunks in the fastbins (param M_MXFAST).

mallopt(M_MXFAST, 0xa0);
void* test = malloc(0x90);
free(test);

Can not Backtrack to prev state

Sorry for Disturbing.
I have a little problem，and i don't know it‘s a bug or not.
My env is Ubuntu 16.04.
I can't come back to prev state We i press "n" for continue,Sometimes I want to view some Information first few steps，But i notice i can't，It looks like: