Memory telescoping enhancement

[merrychap]

Is your feature request related to a problem? Please describe. When using pxr command for showing hexword references I'm always confused by the output. There is not enough information about values that are located inside of the memory. pxr shows only the value, it's str representation, and the location of this value (is it stack / ld / something else). When analyzing a binary with some complex logic and structures it's not enough to see only the value in the memory (and str representation is useless). For example, it could be a stack reference to heap-allocated chunk which holds a reference to another heap chunk in its first qword:

         for example linked list of chunks in the first qword
                            |
[stack ptr] -> [heap chunk] -> [another heap chunk]

In my opinion, it would be better to show the whole memory chains in a way it's done in gef. This issue applies not only to pxr command but to any "telescoping" command like drr.

Also, gef marks each address with the corresponding color which is also nice - it helps to understand it's either r-x section or rw- or stack or heap etc

Describe the solution you'd like

Show the whole memory chain dereferences when using telescoping commands in a way it's done in gef and also marks each address with the corresponding color (r-x / rw- / rwx / heap / stack / etc). rizin also outputs which instruction address is pointing to, but it's done in a non-human readable format, please consider gef-like output format

Describe alternatives you've considered As I already said above, it would be nice to use the same approach as is used in gef.

Additional context Compare these two stack dumps and see the big difference in the provided information by each tool:

gef:

gef➤  telescope $rsp 20
0x00007fffffffdf10│+0x0000: 0x00007fffffffe058  →  0x00007fffffffe3aa  →  "/tmp/test/test"   ← $rsp
0x00007fffffffdf18│+0x0008: 0x00000001f7e6defc
0x00007fffffffdf20│+0x0010: 0x00007ffff7fd34a0  →  <dl_main+0> endbr64 
0x00007fffffffdf28│+0x0018: 0x000055555555529d  →  <__libc_csu_init+77> add rbx, 0x1
0x00007fffffffdf30│+0x0020: 0x0000000000000000
0x00007fffffffdf38│+0x0028: 0x0000000000000000
0x00007fffffffdf40│+0x0030: 0x0000555555555250  →  <__libc_csu_init+0> endbr64 
0x00007fffffffdf48│+0x0038: 0x0000555555555060  →  <_start+0> endbr64 
0x00007fffffffdf50│+0x0040: 0x00007fffffffe050  →  0x0000000000000001
0x00007fffffffdf58│+0x0048: 0x0000000000000000
0x00007fffffffdf60│+0x0050: 0x0000555555555250  →  <__libc_csu_init+0> endbr64   ← $rbp
0x00007fffffffdf68│+0x0058: 0x00007ffff7dec152  →  <__libc_start_main+242> mov edi, eax
0x00007fffffffdf70│+0x0060: 0x00007fffffffe058  →  0x00007fffffffe3aa  →  "/tmp/test/test"
0x00007fffffffdf78│+0x0068: 0x00000001f7debf73
0x00007fffffffdf80│+0x0070: 0x0000555555555176  →  <main+0> push rbp
0x00007fffffffdf88│+0x0078: 0x0000000800000000
0x00007fffffffdf90│+0x0080: 0x0000000000000000
0x00007fffffffdf98│+0x0088: 0xf7fa323f9ee8d6ca
0x00007fffffffdfa0│+0x0090: 0x0000555555555060  →  <_start+0> endbr64 
0x00007fffffffdfa8│+0x0098: 0x0000000000000000

rizin:

0x7ffe14b34e40 0x00007ffe14b34f88   .O...... @ rsp [stack] stack R W 0x7ffe14b363a9
0x7ffe14b34e48 0x00000001d3e63efc   .>...... 7850049276
0x7ffe14b34e50 0x00007f7fd3fc54a0   .T...... /usr/lib/ld-2.32.so library R X 'endbr64' 'ld-2.32.so'
0x7ffe14b34e58 0x000055c7b6db329d   .2...U.. /tmp/test/test .text program R X 'add rbx, 1' 'test'
0x7ffe14b34e60 ..[ null bytes ]..   00000000 
0x7ffe14b34e70 0x000055c7b6db3250   P2...U.. /tmp/test/test .text __libc_csu_init program R X 'endbr64' 'test'
0x7ffe14b34e78 0x000055c7b6db3060   `0...U.. /tmp/test/test .text entry0,section..text,.text,_start,r12 program R X 'endbr64' 'test'
0x7ffe14b34e80 0x00007ffe14b34f80   .O...... [stack] stack R W 0x1
0x7ffe14b34e88 ..[ null bytes ]..   00000000 
0x7ffe14b34e90 0x000055c7b6db3250   P2...U.. @ rbp /tmp/test/test .text __libc_csu_init program R X 'endbr64' 'test'
0x7ffe14b34e98 0x00007f7fd3de2152   R!...... /usr/lib/libc-2.32.so library R X 'mov edi, eax' 'libc-2.32.so'
0x7ffe14b34ea0 0x00007ffe14b34f88   .O...... [stack] stack R W 0x7ffe14b363a9
0x7ffe14b34ea8 0x00000001d3de1f73   s....... 7849516915
0x7ffe14b34eb0 0x000055c7b6db3176   v1...U.. /tmp/test/test .text main,main program R X 'push rbp' 'test'
0x7ffe14b34eb8 0x0000000800000000   ........ 34359738368
0x7ffe14b34ec0 ..[ null bytes ]..   00000000 
0x7ffe14b34ec8 0x0c605d81a556d17b   {.V..]`.
0x7ffe14b34ed0 0x000055c7b6db3060   `0...U.. /tmp/test/test .text entry0,section..text,.text,_start,r12 program R X 'endbr64' 'test'
0x7ffe14b34ed8 ..[ null bytes ]..   00000000 
0x7ffe14b34ef0 0x581319515cb6d17b   {..\Q..X
0x7ffe14b34ef8 0x5910978b83f8d17b   {......Y
0x7ffe14b34f00 ..[ null bytes ]..   00000000 
0x7ffe14b34f18 0x0000000000000001   ........ 1
0x7ffe14b34f20 0x00007ffe14b34f88   .O...... [stack] stack R W 0x7ffe14b363a9
0x7ffe14b34f28 0x00007ffe14b34f98   .O...... [stack] stack R W 0x7ffe14b363b8
0x7ffe14b34f30 0x00007f7fd3ff01a0   ........ /usr/lib/ld-2.32.so library R W 0x55c7b6db2000

[merrychap]

Any plans on this feature?

[ret2libc]

Any plans on this feature?

Not right now, unless someone wants to pick it up (maybe @PulakIIIT or @yossizap ? But I can't speak for them, ofc :). We are already moving forward with various quite big refactoring involving RzBin, types, shell, hash... So I think we have our hands quite full at the moment.

[merrychap]

Okay, got it. Thanks for the answer :+1:

[ret2libc]

I'm reviewing the issues and this indeed seems a very big win for the users. Honestly, the rizin output is really bad compared to gef. I can't understand what's in that memory, no idea at all. It shouldn't be too hard to improve the situation here. I'm going to place this for 0.4.0 so we don't forget.

[ret2libc]

I didn't see any work on this during this time, so I doubt it will be done for 0.4.0. I'm removing the milestone for now until someone starts to actively looking at this.

cc @XVilka