``visualize-libc-heap-chunks`` command seems to fail because of a mistype on a GlibcChunk class member

[0xShad3]

─────────────────────────────────────────────────────────────────────────────────────────────── source:malloc_playground.c+10 ────
      5  {
      6
      7
      8         char *p = malloc(0x800);
      9         int *d = p;
          // p=0x00007ffffffedf20  →  [...]  →  0x0000000000000000
 →   10         free(p);
     11         printf("%p\n",d);
     12  }
───────────────────────────────────────────────────────────────────────────────────────────────────────────────────── threads ────
[#0] Id 1, Name: "malloc", stopped 0x80011b2 in main (), reason: SINGLE STEP
─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── trace ────
[#0] 0x80011b2 → main(argc=0x1, argv=0x7ffffffee028)
──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
gef➤  visualize-libc-heap-chunks
[!] Command 'visualize-libc-heap-chunks' failed to execute properly, reason: 'GlibcChunk' object has no attribute 'base_address'

It seems that it fails since the GlibcChunk class seems to have changed since this plugin was written.

By changing some of the `visualize_heap.py lines just to test if there's a misconfig on my end it seems to work (partially at least...)

115         colors = [ "cyan", "red", "yellow", "blue", "green" ]
116         cur = GlibcChunk(base, from_base=True)
117         gef_print("{}".format(cur.__dict__))
118         idx = 0
119
120         known_ranges = collect_known_ranges()
121         known_values = collect_known_values()
122
123         while True:
124             base = cur.chunk_base_address

gef➤  visualize-libc-heap-chunks
gef➤  visualize-libc-heap-chunks
{'ptrsize': 8, 'chunk_base_address': 134238208, 'address': 134238224, 'size_addr': 134238216, 'prev_size_addr': 134238208}
0x0000000008005000    0x0000000000000000    ........    Chunk[0]
0x0000000008005008    0x0000000000000291    ........    656|PREV_INUSE
0x0000000008005010    0x0000000000000000    ........
        ↓
      [...]
        ↓
0x0000000008005288    0x0000000000000000    ........
[!] Command 'visualize-libc-heap-chunks' failed to execute properly, reason: 'GlibcChunk' object has no attribute 'data_address'

[0xShad3]

I can go through the code fixing this type of version mismatches , similar issues etc and submit a PR if that's indeed a valid issue and I haven't done anything insanely stupid.

[hugsy]

You need to use the version of gef from the dev branch.

[jrozner]

Switching over to the dev branch it looks like it's still broken but for a different reason. get_main_arena seems to have been removed in 11a68a2f1264608e343e3a95a7a9d34a081d682c and replaced with get_glibc_arena. I tried simply swapping out the function name but that doesn't seem to be compatible. When I try to execute I'm getting

[!] Command 'visualize-libc-heap-chunks' failed to execute properly, reason: Cannot access memory at address 0x56277cea2ff0

[hugsy]

Using dev I could repro it was not working properly due to a recent code change in gef.

[hugsy]

Should be fixed by 041fc86 , feel free to check and close if is.

Make sure you use gef from dev

[jrozner]

It doesn't seem to be fixed

[!] Command 'visualize-libc-heap-chunks' failed to execute properly, reason: Cannot access memory at address 0x55b18db0dff0
gef➤  vmmap
[ Legend:  Code | Heap | Stack ]
Start              End                Offset             Perm Path
0x000055b18cf75000 0x000055b18cf76000 0x0000000000000000 r-- /home/jrozner/tsgctf2021/pwn/cheap/cheap
0x000055b18cf76000 0x000055b18cf77000 0x0000000000001000 r-x /home/jrozner/tsgctf2021/pwn/cheap/cheap
0x000055b18cf77000 0x000055b18cf78000 0x0000000000002000 r-- /home/jrozner/tsgctf2021/pwn/cheap/cheap
0x000055b18cf78000 0x000055b18cf79000 0x0000000000002000 r-- /home/jrozner/tsgctf2021/pwn/cheap/cheap
0x000055b18cf79000 0x000055b18cf7a000 0x0000000000003000 rw- /home/jrozner/tsgctf2021/pwn/cheap/cheap
0x000055b18db0e000 0x000055b18db2f000 0x0000000000000000 rw- [heap]
0x00007fdbcf9fe000 0x00007fdbcfa23000 0x0000000000000000 r-- /usr/lib/x86_64-linux-gnu/libc-2.31.so
0x00007fdbcfa23000 0x00007fdbcfb9b000 0x0000000000025000 r-x /usr/lib/x86_64-linux-gnu/libc-2.31.so
0x00007fdbcfb9b000 0x00007fdbcfbe5000 0x000000000019d000 r-- /usr/lib/x86_64-linux-gnu/libc-2.31.so
0x00007fdbcfbe5000 0x00007fdbcfbe6000 0x00000000001e7000 --- /usr/lib/x86_64-linux-gnu/libc-2.31.so
0x00007fdbcfbe6000 0x00007fdbcfbe9000 0x00000000001e7000 r-- /usr/lib/x86_64-linux-gnu/libc-2.31.so
0x00007fdbcfbe9000 0x00007fdbcfbec000 0x00000000001ea000 rw- /usr/lib/x86_64-linux-gnu/libc-2.31.so
0x00007fdbcfbec000 0x00007fdbcfbf2000 0x0000000000000000 rw-
0x00007fdbcfbfc000 0x00007fdbcfbfd000 0x0000000000000000 r-- /usr/lib/x86_64-linux-gnu/ld-2.31.so
0x00007fdbcfbfd000 0x00007fdbcfc20000 0x0000000000001000 r-x /usr/lib/x86_64-linux-gnu/ld-2.31.so
0x00007fdbcfc20000 0x00007fdbcfc28000 0x0000000000024000 r-- /usr/lib/x86_64-linux-gnu/ld-2.31.so
0x00007fdbcfc29000 0x00007fdbcfc2a000 0x000000000002c000 r-- /usr/lib/x86_64-linux-gnu/ld-2.31.so
0x00007fdbcfc2a000 0x00007fdbcfc2b000 0x000000000002d000 rw- /usr/lib/x86_64-linux-gnu/ld-2.31.so
0x00007fdbcfc2b000 0x00007fdbcfc2c000 0x0000000000000000 rw-
0x00007ffe02324000 0x00007ffe02345000 0x0000000000000000 rw- [stack]
0x00007ffe02387000 0x00007ffe0238b000 0x0000000000000000 r-- [vvar]
0x00007ffe0238b000 0x00007ffe0238c000 0x0000000000000000 r-x [vdso]

[hugsy]

Re-tested and it works as expected. If it fails provide a complete description so we can try reproduce.

Note it should go without saying that if the heap is corrupted (in the case of a heap corruption exploit dev for instance), there is no way for this command to work.