Mark bytes as data and show as such in disassembly if referenced as DATA

[XVilka]

It's common on some architectures, e.g. ARM, especially in firmware, to store data between functions. Often that data is referenced as such from some of the functions. This should be marked as data if these two conditions are met:

• It's not a part of any function
• It's not referenced as CODE, only as DATA

Could be done as part of aaa

For example, see test/bins/elf/libarm64.so:

[0x0000e068]> pd 30
        ╎   ; CALL XREF from fcn.00005c8c @ 0x5cb4
        ╎   ; CALL XREF from fcn.0000aab4 @ +0xc0
╭ fcn.0000e068(uint64_t arg1);
│       ╎   ; arg uint64_t arg1 @ x0
│       ╎   0x0000e068      280e80d2       mov   x8, 0x71              ; 'q'
│       ╎   ;-- syscall.113:
│       ╎   0x0000e06c      010000d4       svc   0
│       ╎   0x0000e070      1f0440b1       cmn   x0, 1, lsl 12         ; arg1
│       ╎   0x0000e074      009480da       cneg  x0, x0, hi
│       ╰─< 0x0000e078      68faff54       b.hi  0xdfc4                ; fcn.0000e038-0x74
╰           0x0000e07c      c0035fd6       ret
            ; DATA XREFS from fcn.00005b80 @ 0x5bb0, 0x5bec
            0x0000e080      787bffff       invalid
            0x0000e084      587bffff       invalid
            0x0000e088      887bffff       invalid
            0x0000e08c      4c7bffff       invalid
            0x0000e090      a47bffff       invalid
            0x0000e094      c87bffff       invalid
            0x0000e098      ec7bffff       invalid
            ; DATA XREFS from sym.Java_o__003dc_e @ 0xaa64, 0xaaa8
            0x0000e09c      18caffff       invalid
            0x0000e0a0      f8c9ffff       invalid
            0x0000e0a4      48caffff       invalid
            0x0000e0a8      ecc9ffff       invalid
            0x0000e0ac      64caffff       invalid
            0x0000e0b0      28caffff       invalid
            0x0000e0b4      c8caffff       invalid
            0x0000e0b8      00000000       udf   0
            0x0000e0bc      00000000       udf   0
            ; DATA XREF from fcn.0000b564 @ 0xb594
            0x0000e0c0      0c000000       udf   0xc
            0x0000e0c4      0d000000       udf   0xd
            0x0000e0c8      0e000000       udf   0xe
            0x0000e0cc      0f000000       udf   0xf
            ; DATA XREF from fcn.0000b564 @ 0xb598
            0x0000e0d0      08000000       udf   8
            0x0000e0d4      09000000       udf   9
            0x0000e0d8      0a000000       udf   0xa
            0x0000e0dc      0b000000       udf   0xb
[0x0000e068]> px 40 @ 0xe080
- offset -   0 1  2 3  4 5  6 7  8 9  A B  C D  E F  0123456789ABCDEF
0x0000e080  787b ffff 587b ffff 887b ffff 4c7b ffff  x{..X{...{..L{..
0x0000e090  a47b ffff c87b ffff ec7b ffff 18ca ffff  .{...{...{......
0x0000e0a0  f8c9 ffff 48ca ffff                      ....H...
[0x0000e068]>

Note, also it didn't detect this as a jump table.
Compare with what Binary Ninja shows:

[ret2libc]

Yes this is something I'd love to have. I think marking those chunks as data would also improve the visualization of the address space, as it would be clearer when things are data vs code.