search

NationalSecurityAgency / ghidra

Ghidra is a software reverse engineering (SRE) framework
https://www.nsa.gov/ghidra
Apache License 2.0
52.24k stars 5.92k forks source link

Is pacal calling convention supported? #496

Open rkfg opened 5 years ago

rkfg commented 5 years ago

This is related to #485. The Win16 API function calls should use __pascal calling convention for the argument order to be right (left to right). I didn't find anything useful in the code regarding this issue. Is it possible to define a new convention with arguments being pushed left to right? Maybe there's a parameter for a cspec definition that reverses the argument order? So far I couldn't find an easy way to do that.

WasserEsser commented 5 years ago

Rightclick -> Edit Function Signature allows you to customize the calling conventions. You can specify where parameters go, including the stack. This can be done left to right and right to left, just set the correct stack locations.

Image

rkfg commented 5 years ago

Yeah, I know about this but it's not very convenient. I'd prefer the order to be automatic if possible.

GregoryMorse commented 5 years ago

This is a flaw in the Java frontend only, not the back end as pointed out. The decompiler just expects the stack locations to be correct. pascal is stdcall with a reverse order. It should be added but also the library definitions need to have knowledge about it for it to be practically useful.

Arcnor commented 5 years ago

I've tried adding it to Ghidra/Processors/x86/data/languages/x86-16.cspec by copying stdcall and making it have the arguments in reverse, but I don't see a way to specify what the stack order should be.

  <prototype name="__stdcall16far" extrapop="unknown" stackshift="4">
    <input>
      <pentry minsize="1" maxsize="500" align="2">
        <addr offset="4" space="stack"/>
      </pentry>
    </input>
...

@GregoryMorse you say the backend doesn't have a flaw for this to work, do you know if there is a way of changing that XML to make it work?

GregoryMorse commented 5 years ago

The backend does not really care much about the order. Its only a display issue. So the XML would be identical for stdcall. Underneath the hood the stack offsets are fixed and merely needs to be displayed backwards. The decompiler does not need to know about it whatsoever. So exactly how to fix this is less clear - some extra metadata like displayorder="ltr/rtl" could be added again only for the frontend to display it differently. But perhaps extra metadata in files generally intended only for sleigh/decompiler which will not be used by them is best integrated elsewhere.

beholdnec commented 4 years ago

The backend does not really care much about the order. Its only a display issue. So the XML would be identical for stdcall. Underneath the hood the stack offsets are fixed and merely needs to be displayed backwards.

This is not true in the case of varargs. Functions such as KERNEL:_wsprintf cannot be displayed correctly under this scheme.

Wall-AF commented 2 years ago

This is still outstanding and shouldn't be closed.

Arcnor commented 2 years ago

So I'm hitting this issue again today. Is there anything on latest Ghidra that can help to make this work? I.e. is the backend now capable of dealing with this and it's just a matter of changing the XML to add the right calling convention?