5

I am poking around some PS2 ELFs and I found this weird issue where Ghidra seems to be doubling the value of this byte for some reason.

Here's what Ghidra shows:

                             undefined Money_get()
             undefined         v0_lo:1        <RETURN>
                             Money_get                    XREF[1]:   Entry Point(*)
001bcb90 ec 00 01 3c     lui        at,0xec
001bcb94 98 00 03 3c     lui        v1,0x98
001bcb98 e8 aa 25 8c     lw         a1,-0x5518(at)=>DAT_00ebaae8

And what IDA shows:

main:001BCB90 Money_get:                          # CODE XREF: plmove_find_02+178↑p
main:001BCB90                                     # Item_get+70↑p
main:001BCB90                 lui     $at, 0x76
main:001BCB94                 lui     $v1, 0x98
main:001BCB98                 lw      $a1, 0x7657A8

What IDA shows is the correct disassembly. The first line is supposed to be

lui $at, 0x76  

But for some reason Ghidra has doubled the 0x76 to 0xEC. And because of that the address loaded in the 3rd line is incorrect. I've double checked that the input files are identical and I know IDA is the correct one because the gameshark code for this particular game modifies that address.

I even confirmed in a hex editor that the byte should be 0x76 but in Ghidra's own hex output it shows it as 0xEC. So during input it's doubling it for some reason.

So any reason why Ghidra is doing this? I tried reloading the file and analyzing as a generic MIPS (thinking it was the PS2 ELF loader I used) and it did the same thing.

So I did some more testing and when I strip off the ELF header and load the file as a raw binary then Ghidra loads it correctly. So I wonder what in the ELF header would cause Ghidra to modify that byte?

  • I am not totally familiar with the mips format, but have you checked the stack size? is it more that expected? – R4444 Jul 18 at 19:06
  • Can you share the file? – 0xec Jul 19 at 5:34
  • Don't think I can upload it since it's copyrighted. But it's the main executable for Breath of Fire Dragon Quarter for the PS2. File name is SLUS_204.99 on the root of the game disc. PS2 games are standard ELFs on the disc but I'm using this one in particular because they left the debug symbols in the executable for some reason. – AlphaXeno1 Jul 19 at 14:36
3

This has something to do with the way Ghidra handles relocations. Loading the SLUS_204.99 binary with the following processor options and relocations disabled.

Processor: MIPS
Variant: 64-32addr
Size: 32
Endian: little
Compiler: default

enter image description here

The disassembly is the same as that of IDA.

enter image description here


Using readelf shows that there are relocations of type R_MIPS_26 at the said address.

$  mipsel-linux-gnu-readelf --relocs SLUS_204.99 | grep "Money_get"

 Offset     Info    Type            Sym.Value  Sym. Name

...

0014b3b8  004add04 R_MIPS_26         001bcb90   Money_get
001bc290  004add04 R_MIPS_26         001bcb90   Money_get
011432c8  004add04 R_MIPS_26         001bcb90   Money_get
01144af0  004add04 R_MIPS_26         001bcb90   Money_get
01144b0c  004add04 R_MIPS_26         001bcb90   Money_get
01145090  004add04 R_MIPS_26         001bcb90   Money_get
01145204  004add04 R_MIPS_26         001bcb90   Money_get
0114527c  004add04 R_MIPS_26         001bcb90   Money_get
01145ae8  004add04 R_MIPS_26         001bcb90   Money_get
01145b24  004add04 R_MIPS_26         001bcb90   Money_get
01145b68  004add04 R_MIPS_26         001bcb90   Money_get
01145b9c  004add04 R_MIPS_26         001bcb90   Money_get
01140e3c  004add04 R_MIPS_26         001bcb90   Money_get
01140e5c  004add04 R_MIPS_26         001bcb90   Money_get
010063d4  004add04 R_MIPS_26         001bcb90   Money_get
01006bfc  004add04 R_MIPS_26         001bcb90   Money_get
010081e4  004add04 R_MIPS_26         001bcb90   Money_get
0102b93c  004add04 R_MIPS_26         001bcb90   Money_get
0102c454  004add04 R_MIPS_26         001bcb90   Money_get
0102d3e8  004add04 R_MIPS_26         001bcb90   Money_get
0102dc90  004add04 R_MIPS_26         001bcb90   Money_get
...

So the error is likely in the code that handles relocation of type R_MIPS_26.

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.