ghidra icon indicating copy to clipboard operation
ghidra copied to clipboard

Return values with custom stack storage not visible in calls in decompiler

Open ubuntor opened this issue 5 years ago • 6 comments
trafficstars

Describe the bug Calls to functions that store return values on the stack don't show return values in the decompiler.

To Reproduce

  1. Open test.o (in attachments)
  2. Set f2 to use custom storage with param storage Stack[0x4]:4 and Stack[0x8]:4, and return storage Stack[0xc]:4
  3. Observe the decompilation of f1.

Expected behavior The decompilation of f1 should assign the return value of f2(...) to uStack4.

Screenshots Custom storage for f2: issue_f2_storage Decompilation of f2 (this looks fine): issue_f2_decomp Decompilation of f1 (note that the return value of f2 is not shown): issue_f1_decomp

Attachments test.zip Contains test.o with source test.S.

Environment (please complete the following information):

  • OS: Arch
  • Java Version: 8.0 (1.8.0_251-b08)
  • Ghidra Version: 9.1.2 and 9.2 DEV (commit eaf6ab2)

Additional context I'm working with m68k mac syscalls (a-line instructions) that store return values on the stack like _GetResource (0xa9a0, stores return value at Stack[0x6]:4) and _Random (0xa861, stores return value at Stack[0x0]:2).

ubuntor avatar Jun 09 '20 05:06 ubuntor

@ubuntor Coincidentally, I'm also looking at m68k mac binaries. Could you share how you're currently modeling a-traps in Ghidra?

resistor avatar Jun 21 '20 07:06 resistor

@resistor I'm disassembling them as a custom pcodeop, then marking them up as syscalls (with name and calling convention) with a script. Incredibly messy, but gives decent results (aside from this issue).

Processor (put these in Ghidra/Processors/68000/data/languages/): https://github.com/ubuntor/m68k_mac_reversing_tools/tree/main/ghidra/processor Script: https://github.com/ubuntor/m68k_mac_reversing_tools/blob/main/ghidra/scripts/M68kMacSyscallScript.java Data file for script (put in Ghidra/Features/Base/data): https://github.com/ubuntor/m68k_mac_reversing_tools/blob/main/m68k_mac_syscalls

ubuntor avatar Jun 21 '20 09:06 ubuntor

This also occurs with Go binaries on x86_64 Linux.

Gaelan avatar Dec 01 '21 10:12 Gaelan

This also occurs when reversing Go binaries with Go 1.12 on macOS.

chenzhuoyu avatar Jun 22 '23 05:06 chenzhuoyu

@ryanmkurtz, I noticed this issue doesn't have any labels or assignees. Did this issue slip through the cracks?

chenzhuoyu avatar Jun 22 '23 05:06 chenzhuoyu

@chenzhuoyu Can you please provide a golang example where it's not working with the latest version of Ghidra?

ryanmkurtz avatar Jun 22 '23 18:06 ryanmkurtz

@ryanmkurtz

stackret.zip

Ghidra 10.3.1 installed via Homebrew Go 1.12.17 downloaded from https://go.dev/dl/go1.12.17.darwin-amd64.tar.gz

Repro steps:

  1. Import stackret.zip/stackret and analyze with default settings.

  2. Go to function main.main, there should be a call to runtime.newobject

  3. Change the signature for runtime.newobject to this:

image

  1. The decompiler does not recognize the return value of runtime.newobject, which should be assigned to local_10 in this case.

image

chenzhuoyu avatar Jun 27 '23 06:06 chenzhuoyu

Thanks, i've passed this along to @dev747368 who is our Go expert.

ryanmkurtz avatar Jun 27 '23 11:06 ryanmkurtz

e9b5be17c13f19d1005bbea52e36252cd504fb63 should address the issue with results on the stack.

dev747368 avatar Jul 11 '23 19:07 dev747368