In the Ghidra decompiler, after applying a type to a function parameter, the compiler uses that type information to provide better decompilation within the function. When that parameter is used in a function call though, the type information does not propagate. I have to manually change the function signature for the type information to carry forward.

Is there any way to get Ghidra to automatically propagate the type information? I thought Commit Params/Return P or Commit Local Names would do it, but no luck. Finding it time-consuming to have to re-type a known entity in every function call it's used.


Looking at a Windows Kernel Driver, following the analysis steps here

Changed the type of param_2 from longlong to PIRP and renamed it pIRP. Then selected Analysis -> Auto-Analyze file.sys and only selected Decompiler Parameter ID.

After running the analysis, I'm left with this :

int FUN_140001a20(longlong test,PIRP pIRP)
    ... TRIMMED...

        if (uVar2 == 0xc3500e68) {
          uVar7 = FUN_140002a14(test,(longlong)pIRP,(longlong)pbVar3);

And double-clicking FUN_140002a14:

void FUN_140002a14(longlong param_1,longlong param_2,longlong param_3)

For whatever reason, pIRP's type is getting cast, and the signature for the called function doesn't change. I'd have expected the longlong to become PIRP.


Still working this. Since the types/names don't propagate, working a script to do it for me for a given function. Right now I'm grabbing all functions called by a given function and trying to change a known parameter's name/type.

What I'm most confused about is in the Decompiler window, when I rename/retype a variable, it propagates through the rest of that function. But when I query the parameters for those functions, the variables are unchanged. For example, in the decompiler window, pIRP is propagated to all functions where it's used, but when I get the function signatures in the script, it still has the name as param_2.

Decompiler Window:

uVar5 = FUN_140002a14(param_1,(longlong)pIRP,(longlong)CurrentStackLocation)

Script Output:

helloGhidra.java> FUN_140002a14[[longlong param_1@RCX:8], [longlong param_2@RDX:8], [longlong param_3@R8:8]]

This occurs even if I try Commit Params/Return P and Commit Local Names for the parameter.


I think the Decompiler Parameter ID analysis, should solve this, at least it is supposed to propagate type information across function boundaries.

  • Didn't quite work. Added to the question to show what happened
    – gr0k
    Nov 3 '21 at 1:41
  • The type seems correctly propagated. The Decompiler Parameter ID is not supposed to propagate the name of a variable, and I am not sure why you would expect an analysis to do that in the general case Nov 3 '21 at 17:17
  • I didn't change the type, just the name. But the same problem occurs with the type. Why should I have to change the variable name more than once? If I give a variable a meaningful name in function A, when said variable is passed to function B, when I look at function B, why does param_1 not keep the variable name I assigned in the calling function?
    – gr0k
    Nov 3 '21 at 21:28
  • Assume you have a function that you reverse engineered and named char* read_file(char *path) and this is called in a function where you named the variable secret_file. If Decompiler Parameter ID would propagate the name it would change path to secret_file Nov 3 '21 at 22:09
  • That the type didn't propagate is weirder, can check the actual code of Decompiler Parameter ID tomorrow to see what is going on there. If you really want to propagate the variable names to function param names you can write a script for it. Any questions coming up while writing that script are probably worth another dedicated StackExchange question Nov 3 '21 at 22:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.