Since this project invokes gdb later, it's this project's job to decide when the wanted program state is achieved and then launches gdb for debugging. The current approach, counting heap operation numbers, is not a reliable way to determine program state because real-world programs may invoke different numbers of heap operations each time to reach a specific program state (for example, initialization code behaves differently each time).

I suggest supporting another interface that allows users to set a breakpoint at a specific address and using the times this breakpoint is invoked as an indicator whether the execution should be passed to gdb.

I was in bed thinking about these and decided to write them down

• make sure we're using size calculated from request2size to check ret vals. Update bst code to search for it -- nvm if we warn about this, we also have to track consolidation which is rly complicated. not worth it for now.
• notify user if malloc etc returns pointer inside glibc/elf. This prob means we pwned the chal -- done
• Add support for attach to pid -- done
• Make it so we can trace both parent and.child at once. Copy context just change pid lol. Oh also copy all the heap stuff ofc -- this is harder than it sounds. We need to fork() to be able to waitpid both pids

Hi.

Awesome project, really MUSTHAVE!

But I catch some troubles:

1. It doesn't compile because of undefined sigabbrev_np() Quick reading of man sigabbrev_np push me to change it to strsignal(), the binary compiled ok.

But it doesn't launch with any attrs throwing the message from header.

Checked on libc-2.31.so and libc-2.28.so. Same results.

I didn't find any information about minimal required libc version. Am I was looking bad?

Thanks.

Make a heaptrace program (not shared lib) with similar syntax to that of ltrace and add support for statically linked binaries.

• If the target binary is dynamically linked, use LD_PRELOAD=./heaptrace.so automatically as this is significantly more reliable/less hacky. Pass the argv before the target binary's name/args to HEAPTRACE_ARGS environ var.

• Otherwise, print an "unstable" warning. Then, resolve malloc/free/realloc symbols (require user to specify addresses if any syms aren't defined), use ptrace to set an int3 breakpoint at those functions, and, when breakpoints get hit, call the malloc/free/realloc tracing functions.

  The orig_malloc/orig_free/orig_realloc functions in the static version of heaptrace should just resume execution until a ret, at which point it should get its return value (if relevant) and continue executing the tracing function. Once the tracing function is done, it should remove the relevant ret breakpoint and continue execution as if nothing ever happened.

       However,  unlike  that  realloc()  call, reallocarray() fails safely in the case where the multiplication
       would overflow.  If such an overflow occurs, reallocarray() returns  NULL,  sets  errno  to  ENOMEM,  and
       leaves the original block of memory unchanged.

I think it's prob because it exec()s

... #2843: malloc(0x20)		=  0x555555681e70
... #2844: malloc(0x03)		=  0x555555681ea0
... #2845: malloc(0x30)		=  0x555555681ec0
... #2846: malloc(0x08)		=  0x555555681f00
... #2847: malloc(0x08)		=  0x555555681f20
... #2848: malloc(0x20)		=  0x555555681f40
... #2849: malloc(0x04)		=  0x555555681f70
... #2850: malloc(0x7f0)		=  0x555555681f90
... #2851: malloc(0xff0)		=  0x555555682790
... #2852: malloc(0x06)		=  0x555555683790
... #2853: malloc(0x18)		=  0x5555556838d0
... #2854: malloc(0x18)		=  0x5555556838f0
... #2855: malloc(0x0c)		=  0x555555683910
... #2856: free(0x0)
... #2857: malloc(0x5e)		=  0x5555556705c0
... #2858: free(0x555555683960)
    |-- warning: freeing a pointer to unknown chunk
... #2859: malloc(0x1d8)		=  0x55555564d4d0
... #2860: malloc(0x1000)		=  0x555555683c40
... #2861: malloc(0x617)		=  0x555555684c50
... #2862: reallocarray(0x555555685270, 0x2e, 0x1e8)	
    |-- warning: attempting to reallocarray a chunk that was never allocated
=  0x555555685270

heaptrace error: heaptrace segfaulted. Please re-run with --debug and report this.

heaptrace [ptrace] % ./heaptrace this-does-not-exist
================================ BEGIN HEAPTRACE ===============================

[1]    738632 segmentation fault (core dumped)  ./heaptrace this-does-not-exist

Right now I have absolute trash of a hack code @ https://github.com/Arinerron/heaptrace/blob/main/src/debugger.c#L177 and https://github.com/Arinerron/heaptrace/blob/main/src/debugger.c#L109 to parse /proc/pid/maps. I need to find a better way to get the information (file path, address start, address end).

I'd appreciate any tips if anyone knows of a way to get that information other than /proc/pid/maps

some programs fork() and execute another binary, so we get two+ BEGIN HEAPTRACE messages. It's not clear which is which. There's not really an easy solution to this, but it'd be helpful if it at least specified which program is which so it's easy to tell what's going on

Statistics:
... mallocs count: 7
... callocs count: 1
... frees count: 3
... reallocs count: 0
... reallocarrays count: 0

| | V

Statistics:
... mallocs count: 7
... callocs count: 1
... frees count: 3

Just check if the return addr is in range of the ELF's start-end. If so, it's from binary. If not, it's from the ELF.

Not sure how to best visualize this info yet. Maybe bold for ELF and not bold for libraries? Not very intuitive...

Hello,

my program takes input via a pipe, for example:

cat input | heaptrace ./program

This works without --break. When i try to --break, gdb instantly takes the input as commands (probably the remaining of input), and does quit out from the debugger. Is there a way to keep the debugger alive, or to not parse the piped input as gdb commands? Normaly there would be the run < input command in gdb, but this is not realy the value which would be provided by heaptrace breakpoints.

Thanks for your help

This PR patches the Makefile such that toolchain environment variables (CC, CFLAGS, ...) take precedence over the default values in the Makefile. This makes the work of distribution packagers more easy as the values don't have to be explicitly specified in the call of make.

Put a quick description of what happens here. What do you expect to happen? What happens instead?

• Full output when run with --debug:

(link to pastebin if it's long, please)
Repository      : AUR
Name            : heaptrace
Version         : 2.2.8-1
Maintainer      : arinerron
URL             : https://github.com/Arinerron/heaptrace
AUR URL         : https://aur.archlinux.org/packages/heaptrace
License         : BSD
Votes           : 0
Popularity      : 0%
Installed       : No
Out Of Date     : No
Depends On      : None
Make Deps       : None
Check Deps      : None
Optional Deps   : None
Provides        : None
Conflicts With  : None
Replaces        : None
Package Base    : heaptrace
Last Update     : Tue Dec  7 21:48:18 2021
Description     : helps visualize heap operations for pwn and debugging

==> Making package: heaptrace 2.2.8-1 (Thu 12 May 2022 10:22:42 PM EDT)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving sources...
  -> Downloading heaptrace-heaptrace...
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
100 1051k  100 1051k    0     0  2066k      0 --:--:-- --:--:-- --:--:-- 3360k
  -> Downloading heaptrace-heaptrace.1...
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  2905  100  2905    0     0  15083      0 --:--:-- --:--:-- --:--:-- 15130
==> Validating source_x86_64 files with sha256sums...
    heaptrace-heaptrace ... Passed
    heaptrace-heaptrace.1 ... FAILED
==> ERROR: One or more files did not pass the validity check!
:: Unable to build heaptrace - makepkg exited with code: 1

Expected behavior: Package passes checksum Current behavior: Fails checksum

Tried: Downloading it.

... #471: malloc(0x18)                                                                              = 0x7ffff792da40 
... #472: malloc(0x18) 
    |-- warning: return value is not a heap pointer
    |   * this indicates some form of heap corruption
    |   * pointer is inside of section "<malware>" (0x555555554000-0x5555555f8000)                                           

when I run it on the malware it:

• doesn't bold the "warning" heading
• returns a chunk inside of the elf?? todo investigate