Debugger: Module Mapping Overwriting Previously Mapped Modules

[clearbluejar]

Describe the bug
When debugging a x64 Windows RPC server payload using dbgeng IN-VM and stepping into code that doesn't exist (not imported yet), the decompiler window goes blank and the only windows that are available are the dynamic and static listing (as expected). After importing and analyzing the missing binary (in this case rpcrt4.dll), and then mapping the binary from the import window (manually) the debugger once again behaves as expected and I can step through rpc and return to the original binary (in this case server.exe). When I return to the original binary the original module mapping has disappeared. I am forced to manually map the module again, then I lose the previous rpcrt4.dll mapping.

It seems that the module mapping:

1. isn't automatic (when it could be because I already imported and analyzed rpcrt4.dll). Is it supposed to be, or maybe this is a future feature request.
2. the manual mapping seems to overwrite previous module mappings, and forces me to manually remap a module each time I switch modules.

Initial module mapping:

When I map rpcrt4.dll I lose server.exe mapping.

When I then manually remap server.exe, I once again lose rpcrt4.dll mapping and the cycle repeats.

Could it be an issue with the reported size of the modules?

The reported size is too big, and the module is mapped over others?

To Reproduce
Steps to reproduce the behavior:

Expected behavior
I would expect not to have to re-map the modules each time in a cycle, or even that the module bot would auto map modules with matching names.

Screenshots
See Above

Environment (please complete the following information):

• OS: Windows 11
• Java Version: 17
• Ghidra Version: 10.4
• Ghidra Origin: official GitHub distro

Additional context
The modules being mapped and unmapped also affect the stack output. When rpcrt4.dll is mapped I can see the rpc calls are resolved, but not the original server function calls.

I would expect the output to mimic the interpreter:

[d-millar]

@clearbluejar Sounds like we are not handling the re-add correctly (obviously, I guess) - will put a ticket in.

[clearbluejar]

Does the module map normally auto-map a module if the module name exists in the current Ghidra project?

[d-millar]

Yes, if the program name in Ghidra matches the name in the module list produced by the OS. Needless to say, there are a multitude of reasons they might not match, e.g. executable renamed on disk, executable renamed on import, program renamed in Ghidra, etc.

[nsadeveloper789]

@clearbluejar I saw your blog post that led you to this bug: https://clearbluejar.github.io/posts/decompilation-debugging-pretending-all-binaries-come-with-source-code/ . Thanks for the thorough write-up! We haven't yet "ported" our tutorial to Windows, and it's also nice to see a tutorial for something more interesting than a minesweeper clone, so double thanks. I went ahead a put a ticket in for the module column in the stack table, too.

[clearbluejar]

put a ticket in for the module column in the stack table

Awesome!

Ghidra continues to impress me with its capability, improvement over time, and also your team's response to community input and feedback. Nothing but good things to say about the tool and your team.

a tutorial for something more interesting than a minesweeper clone

That tutorial and documentation for the minesweeper clone is excellent. It covered all of the primary features and helped me understand each of the components. It really helped me wrap my head around the idea the Ghidra is providing this static and dynamic view side by side. Again, kudos to the author(s).

[nsadeveloper789]

I can confirm that it's because the reported module size is too big. The TEB analyzer creates an artificial memory block, and the module mapper is mistaking it for an actual section. I'm not sure that's the only factor at play, but the following patch should fix it. There's a bigger issue I'm hoping to address, too, but in the short term, here's the patch:

diff --git a/Ghidra/Debug/Debugger/src/main/java/ghidra/app/plugin/core/debug/service/modules/DefaultModuleMapProposal.java b/Ghidra/Debug/Debugger/src/main/java/ghidra/app/plugin/core/debug/service/modules/DefaultModuleMapProposal.java
index 3a3465f593..c54769be2a 100644
--- a/Ghidra/Debug/Debugger/src/main/java/ghidra/app/plugin/core/debug/service/modules/DefaultModuleMapProposal.java
+++ b/Ghidra/Debug/Debugger/src/main/java/ghidra/app/plugin/core/debug/service/modules/DefaultModuleMapProposal.java
@@ -18,6 +18,7 @@ package ghidra.app.plugin.core.debug.service.modules;
 import java.util.*;
 
 import ghidra.app.services.DebuggerStaticMappingService;
+import ghidra.app.util.datatype.microsoft.ThreadEnvironmentBlock;
 import ghidra.debug.api.modules.ModuleMapProposal;
 import ghidra.debug.api.modules.ModuleMapProposal.ModuleMapEntry;
 import ghidra.program.model.address.*;
@@ -59,6 +60,9 @@ public class DefaultModuleMapProposal
                        if (block.isExternalBlock()) {
                                return false;
                        }
+                       if (ThreadEnvironmentBlock.BLOCK_NAME.equals(block.getName())) {
+                               return false;
+                       }
                        return true;
                }