PE code cave disassembly

Multiple ShadowHammer samples decrypt their shellcode via a function called from ___crtExitProcess(). The screenshot below is MD5 cdb0a09067877f30189811c7aea3f253.

SUB_0051b908 cannot be viewed because it lies within a 511-byte code cave within the .text section. Ghidra sets the .text section boundary based on the VirtualSize (0x0011A801) as shown in the screenshot below. The RawSize of the .text section is 0x0011AA00.

For reference, IDA Pro’s segmentation is shown below. It appears to treat everything up to the next section as part of the .text section and attempts to disassemble it.

Expanding the .text section in Ghidra’s memory map does not cause it to re-read the file’s bytes and undefined bytes are displayed. Outside of modifying the sample’s PE header, is there a way to force Ghidra to read and disassemble these bytes?

[ryanmkurtz]

We’ll have to discuss how to best handle this generically. I’ll leave this open as an enhancement request.

[0x6d696368]

So the extra bytes at the end of the section in the file are actually code and not just all zeros? Do you know if that’s common?

The extra bytes are code. It’s a small shellcode. It is basically the whole malicious part of the binary. I assume it was placed in that code cave with good reason. It’s a malware technique.

Not sure how common, because IDA automatically will include the code outside the .text section into the analysis. But if you are dealing with malware things like that are to be expected and a good tool should handle them.