RISC-V: Cannot invoke Varnode.getAddress because the return value of VariableStorage.getFirstVarnode is null

[gamelaster]

Describe the bug I'm reverse engineering rv32imafc binary, and for some functions, decompiler shows this error:

  Cannot invoke "ghidra.program.model.pcode.Varnode.getAddress()" because the return value of
       "ghidra.program.model.listing.VariableStorage.getFirstVarnode()" is null

To Reproduce Steps to reproduce the behavior:

1. Open firmware.bin attached, select RV32IMC language, and set base address to 0x23000000
2. Go to 0x23000dae and check decompile panel
3. (Optional) Go to similar function (but smaller) at 0x23000d68, this decompiles nicely.

Expected behavior Decompiler should be able to decompile the function.

Screenshots Stacktrace:

Attachments firmware.bin.zip

(In show log, there wasn't anything useful)

Environment

• OS: Linux 6.0.8
• Java Version: 19.0.1
• Ghidra Version: 10.2.2 DEV 2022-Nov-15 2224 CET
• Ghidra Origin: ArchLinux Packages

Additional context Let me know if any other information will be needed. Thanks

[mumbel]

First, IMAFC would be better to use RV32GC instead of IMC (G is shorthand for IMAFD). If you do actually have any A or F instructions, it would/should fail to disassemble.

The issue here is It looks like its failing to pick up the gp register.

        23000000 97 61 01 1f     auipc      gp,0x1f016
        23000004 93 81 01 4f     addi       gp,gp,0x4f0

select all (ctrl+a) in the disassembly window right click in the selected disassembly choose Set Register Values choose the gp register enter 0x1f0164f0 for the value

[gamelaster]

@mumbel That worked out perfectly, thanks! Two questions: 1) Is it possible to change language to RV32GC? I couldn't find this anywhere. Or I need to import the firmware again? 2) Should I keep this issue opened, or close it after verifying that all functions decompile just fine?

Thanks.

[mumbel]

You might be able to close the code browser and right click firmware.bin in the frontend window and "choose language" (I think, AFK now) and see if it lets yous choose a new language.

Id leave open for now just track if there's something that could be fixed for gp detection

[gamelaster]

Hi @mumbel , thanks for all the help. (For anyone struggling with this) Since I applied mumbel's recommendation, I got memory reads on memory areas, which didn't gave any sense, generally having GP at 0x1F0164F0 didn't gave any sense in context of real MCU memory map. After a bit thinking, I find out, this GP is wrong.

The first instruction is AUIPC, which add upper immediate to PC. This instruction adds a 20-bit immediate value to the upper 20 bits of the program counter and set it to register. This means for:

• 23000000 97 61 01 1f auipc gp,0x1f016: 0x23000000 + (0x1F016 << 12) = 0x42016000
• 23000004 93 81 01 4f addi gp,gp,0x4f0: 0x42016000 + 0x4F0 = 0x420164F0

So correct GP is 0x420164F0.

[emteere]

Not having the GP set appears to be an issue introduced in 10.2.x, making not having the GP worse, which is causing the above exception. There are some pattern issues as well as instruction flow issues that should make it in soon.

Will also take a look at the GP tracking. As long as the program is using 1 value it should be an easy add.