Coredumps do not have stack exposed to GEF

[hugsy]

Initial report by @heinrich5991 : #1080 (comment)

Coredumps do not show an stack section via info proc section which GEF uses to populate its own memory view. As a result, any pointer to the stack pages will fail to be read/dereferenced.

Reproduction:

$ cat repro.c
#include <stdlib.h>
int main() {
        abort();
}
$ make repro
$ ./repro
...
[1]    215547 IOT instruction (core dumped)  ./repro
$ gef -ex "vmmap -n '[stack]'" -ex 'xinfo $rsp' ./repro /var/lib/apport/coredump/core._repro.1000.31303c93-a1c7-41bb-8914-f6df24e2bed4.215547.115027334
[...]
[ Legend:  Code | Stack | Heap ]
Start              End                Offset             Perm Path
──────────────────────────────────────────────── xinfo: 0x7fff2408a610 ────────────────────────────────────────────────
[*] Cannot reach 0x7fff2408a610 in memory space

However maintenance info sections does

gef➤  registers $rsp
$rsp   : 0x7fff2408a610
gef➤  maintenance info sections
[...]
[31]     0x7fff2406b000->0x7fff2408c000 at 0x00023000: load19 ALLOC LOAD HAS_CONTENTS

Hackish workaround:

gef➤  pi p=gef.arch.sp & ~0xfff
gef➤  pi gef.memory.maps.append( Section(page_start=p, page_end=p+0x1000, permission=Permission.ALL, path="[stack]") )

Better solution:
For coredumps only, extend sections collected by info proc sections with maintenance info sections

[heinrich5991]

Thanks for opening another issue, sorry that I've failed to notice it's a different one.

[hugsy]

Thanks for opening another issue, sorry that I've failed to notice it's a different one.

No worries, it was tricky to spot. Anyway the fix is underway 😉