We’re rewarding the question askers & reputations are being recalculated! Read more.
3 Added more info
source | link

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 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.

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?

    Tweeted twitter.com/StackReverseEng/status/1151507015652532225
2 Better formating
source | link

Forgive me if this happens to be something stupid that I'm overlooking. I'm completely self-taught in a lot of this stuff and I'm still learning.

So I'mI 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.

Forgive me if this happens to be something stupid that I'm overlooking. I'm completely self-taught in a lot of this stuff and I'm still learning.

So I'm 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.

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.

1
source | link

Any reason why Ghidra is screwing with this byte in this dissassembly?

Forgive me if this happens to be something stupid that I'm overlooking. I'm completely self-taught in a lot of this stuff and I'm still learning.

So I'm 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.