instead of printing Addr: ... for a heap chunk print Chunk: ... Alloc…

[dmur1]

https://discord.com/channels/843809097920413717/843809097920413720/1228655319102521385

[dmur1]

does anyone understand what's happening here? i really don't see how +16 is producing this value?

[dmur1]

i will defer to others as to whether a) this is a good idea b) its a good way to do it - i was just implemented the discussed change

[CptGibbon]

I get an uneasy feeling this will only work for 64 bit architecture because of that hardcoded +16

[disconnect3d]

I get an uneasy feeling this will only work for 64 bit architecture because of that hardcoded +16

+1. Also: don't we somehow support/know what's the metadata/allocated buffer offset within the heap functionality?

Can't we reuse it here?

[CptGibbon]

don't we somehow support/know what's the metadata/allocated buffer offset within the heap functionality?
Can't we reuse it here?

pwndbg doesn't support that right now, though it's on my todo list.
Believe it or not malloc_chunk structs don't have a user data member, it's found using GLIBC's chunk2mem macro.

[disconnect3d]

@CptGibbon What should we do here? Can we just merge it and fix it in the future if it ever breaks?

Shall we maybe do +2*ptrsize instead of +16?

[CptGibbon]

@CptGibbon What should we do here? Can we just merge it and fix it in the future if it ever breaks?

Shall we maybe do +2*ptrsize instead of +16?

Definitely use the pointer size math in place of a hardcoded number, I'm surprised that doesn't fail tests but I guess there aren't enough 32 bit malloc tests.

I don't understand the change from "address" to "chunk" or what "alloc" is supposed to mean but yeah it's probably harmless 🤷‍♂️

[disconnect3d]

I spoke with @dmur1 and let's just drop this for now. I don't think this feature is super needed, unless more people ask for that.