MIPS32 function resolution (loc._gp)

[drzraf]

Description

There is a limitation from ghidra regarding function name resolution.

pdg

(loc._gp + -0x7f5c) isn't resolved

But resolution is done in radare2:

pd

and can be done manually:

e anal.gp=loc._gp
pd 1 @(loc._gp + -0x7f5c)

==> sym.imp.fopen

Same code, other example, with iStack_35c = (**(pcStack_370 + -0x7f60))(0);

pdg

Knowing that

pd 1 @(loc._gp + -0x7f60)

==> sym.imp.time

Could this be somehow improved/automated by r2ghidra?

[trufae]

r2ghidra is using a 2 year old c++ code from ghidra. i tried to update it several times but things break and the build gets even more complex to handle. the code is full of bugs, and thats why i have to maintain a fork to workaround all their null derefs, use after free and overflows here and there. the current code is "safe" but a little far from realtime.

I'm saying this because ideally i would like to update the backend before applying any improvement or fix on top to not have to rework stuff twice.

as for workaround, i think that you can probably use a script that sets a flag on each dword that points to a flag. and i though there was a command for that in r2 but i was wrong. so i'll do that in master later today. but still r2ghidra wont probably be able to resolve recursive references pointed from a global register with a delta. and probably the only way to reflect that in r2ghidra would be to make that script find the esil references and set a comment on each line.

As an alternative you can use decai, the llm based decompiler that should work flawlessly and give you a better output. if you wanna try that i recommend you to use qwen2.5 with ollama in local or claude/openai in remote.

r2pm -ci decai
ollama run qwen2.5-coder:14b

and then in r2:

decai -e api=ollama
decai -e model=qwen2.5-coder:14b
decai -d