Reading unmapped memory is not a crime?

[shamefulCake1]

Sorry, this question is not really about Ghidra (or maybe it is), but about debugging aarch64.

I have the following code in my binary:

1. "Dynamic Listing":

      79b433bb80 41 00 40 fd     ldr        d1,[x2]

2. "Static Listing":

        00bacb80 41 00 40 fd     ldr        d1,[inwidth]

3. "Decompiler"

uVar62 = *puVar10;

4. The value in x2 is 78e6a39018

true | 340 | x2 | 78e6a39018 |   |   |  

When I am going to 0x78e6a39018 in "Dynamic", I am getting it all highlighted with red, and, seemingly, uninitialised/unmapped:

      78e6a39018 00              ??         00h

BUT

Stepping through this instruction works!
When I am stepping to the next instruction, I am not getting a crash, and the value in d1 is not 0, but 208020d020d020f.

What is going on? Is this a bug? If yes, then in what? In Ghidra? In lldb? In Android?
If this is not a bug, then what is it? A device-mapped address unavailable to a debugger? A shared memory piece unavailable to a debugger?

How do I debug such cases?

Sorry if this is not entirely Ghidra-related, but perhaps I am missing something completely obvious, but this really seems mysterious, and I hope that future Ghidra users stumbling upon this question might find it useful.

[d-millar]

Hmmm, am going to guess this is a bug, but not one I understand at the moment. Generally, "red" means it couldn't read the memory or didn't try because that memory didn't exist in any known region. Assuming "Force Full map" was on, the latter shouldn't be the case. Might be a caching or synchronization issue, but I would have thought it would have shown up greyed out versus red. I'll discuss this with @nsadeveloper789 - probably Tuesday (snow and what not here).

You probably have more context, but I wouldn't have guessed device-mapped memory and shared memory is typically readable for the debugger. If you read the same memory at the same point from lldb proper (no Ghidra), do you get valid bytes? If no, your theories are still in play. If yes, am going with a bug in our code.

[shamefulCake1]

Reading memory from the debugger prompt is not working as well. Admittedly, I did not connect a "bare" lldb, I just typed "memory read" into the debugger prompt in Ghidra.

[d-millar]

OK, well, that's evidence in favor of your other theories, but still a little unclear as to the base cause. The terminal in Ghidra is a pretty thin wrapper on the lldb repl. Am guessing a bare lldb experiment will yield the same results. And am guessing a command-line read of the memory after that instruction was executed would succeed, at least in the local case.

Lldb's behavior in the remote case is a little different than the local case, particularly with regard to caching, as I understand it. Presumably, stepping clears this cache, so, even if the initial read from ghidra/lldb causes the memory to be paged in, you may not see the memory marked as valid until the cache gets cleared and a new read is executed.

You can also try forcing a cache flush with process handle -s false -p true -n false or disabling caching from the start using settings set target.process.disable-memory-cache true.

[shamefulCake1]

And am guessing a command-line read of the memory after that instruction was executed would succeed, at least in the local case.

No, it doesn't. The memory is still "red".

If this is a "memory-mapped device", is there a way to "highlight" it somehow? Or is this too much out of scope for the Ghidra debugger (or for lldb)? I do suspect this is some kind of Android's "Binder IPC" interfering, but surely there should be a way to debug IPCs.

[shamefulCake1]

Stack overflow claims that it is not possible to read memory-mapped regions using ptrace. https://stackoverflow.com/a/672934/1405403

But perhaps there could be at least a way to highlight such regions with a different colour?

[d-millar]

Sorry, the question was not whether the command-line read would change the color, but whether it would return non-zero values.

I don't really have a clear sense of the root cause here yet, and without knowing that it would be hard to proceed.

We could certainly change the color of the Dynamic Listing if we had information indicating it was memory-mapped. My impression, however, that you have no memory map given you've forced full memory on. The regions view is empty,correct?

[shamefulCake1]

@d-millar so, I have done more reversing on my app, and it seems that this area is shared memory mapped by the Android "Binder IPC".

I wonder whether there is really no way to find out which memory areas are not "conventional memory", that is, for example, IPC-mapped regions, devices, similarly weird things.

[d-millar]

Interesting - Android definitely a target of interest for us, but one we have trouble doing regular development against.

I may have missed it, but does your Regions View have the "full map" on by default?

I will see if I can do some more research, but the basic issue is we can only process what lldb gives us. If we're erroring out in our code, there may be a workaround, but, if Android simply doesn't support SBMemoryRegion, a consistent solution won't be trivial.