PS2 ELF (R3000) should be parsed as 64v2 instead of 32 bit mips

[GovanifY]

Title of the issue says it all

We need an accurate auto detection of that as R3000 ELFs might actually be R5900 64bits ones

https://github.com/radare/radare2/issues/7611

[radare]

how?

any way to detect this?

On 30 May 2017, at 15:33, GovanifY notifications@github.com wrote:

Title of the issue says it all

We need an accurate auto detection of that as R3000 ELFs might actually be R5900 64bits ones

7611 https://github.com/radare/radare2/issues/7611

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/radare/radare2/issues/7636, or mute the thread https://github.com/notifications/unsubscribe-auth/AA3-lglSXa8bJ-e5xzfh92aTLnyrll3Wks5r_Bq9gaJpZM4NqTSx.

[GovanifY]

That's the golden question; Try to see if there are any invalid opcodes or just look for a header that looks like ps2 toolchains?(ie padduw NB: Create a capstone issue for paddu(w) )

There's not really any good solution for it as far as I'm aware so we'll have to find one that have the least drawbacks possible

[GovanifY]

Also as a matter of fact 64v2 seems to fail to find entry0 on those ELFs which is also worth noting as basic mips64 have no issue whatsoever with it(just the paddu(w)) issue

[GovanifY]

Another issue I've seen on 64v2: 0x1da5dc should be a "jr $t5" but is instead seen as a qword which should DEFINITELY not happen

Same ELF as the issue I referenced

[mrmacete]

Another issue I've seen on 64v2: 0x1da5dc should be a "jr $t5" but is instead seen as a qword

can't reproduce this:

$ r2  ~/Downloads/SLPM_666.75
[0x0010001c]> e asm.cpu=64v2
[0x0010001c]> s 0x1da5dc
[0x001da5dc]> pd 1
        ┌─< 0x001da5dc      0800a001       jr t5
[0x001da5dc]>

[GovanifY]

@mrmacete

govanify@ThinkPadW500 ~ $ r2 Documents/PROJECTS/PROGRAMMING/HACKING/GAMES/KINGDOM_HEARTS/KH2FM/SLPM_666.75 
Warning: Cannot initialize dynamic strings
 -- Execute commands on a temporary offset by appending '@ offset' to your command.
[0x0010001c]> e asm.cpu=64v2
[0x0010001c]> s 0x1da5dc
[0x001da5dc]> pd 1
        ,=< 0x001da5dc      0800a001       jr t5
[0x001da5dc]> aaaa
[Cannot find function 'entry0' at 0x0010001c entry0 (aa)
[x] Analyze all flags starting with sym. and entry0 (aa)
[ ] 
[aav: using from to 0x100000 0x381ef4
Using vmin 0x100000 and vmax 0x1f18098
aav: using from to 0x100000 0x381ef4
Using vmin 0x100000 and vmax 0x1f18098
[x] Analyze len bytes of instructions for references (aar)
[x] Analyze function calls (aac)
[x] Emulate code to find computed references (aae)
[x] Analyze consecutive function (aat)
[x] Type matching analysis for all functions (afta))unc.* functions (aan)
[x] Type matching analysis for all functions (afta)

NB: UI during analyzing is sometimes broken, shouldn't be hard to fix but forgot to create an issue for that long time ago

[0x001da5dc]> pd 1
            0x001da5dc      .dword 0x01a00008 ; sym.0x01a00008
[0x001da5dc]> 

r2 analysis doesn't seem to play well with this executable...

[GovanifY]

yet another issue, but with graphs this time:

[0x001da558]> VV @ fcn.001da558 (nodes 1 edges 0 zoom 100%) BB-NORM mouse:canvas-y movements-speed:5                                                    

                                                .------------------------------------------------------.
                                                | [0x1da558] ;[ga]                                     |
                                                | (fcn) fcn.001da558 4                                 |
                                                |   fcn.001da558 ();                                   |
                                                |    ; CALL XREF from 0x0016caf4 (fcn.0016cab8 + 60)   |
                                                |    ; CALL XREF from 0x0016cd94 (fcn.0016cd48 + 76)   |
                                                |    ; CALL XREF from 0x0016ca24 (fcn.0016c8f8 + 300)  |
                                                | addiu sp, sp, -0xc0                                  |
                                                `------------------------------------------------------'

[0x001da558]> pd 10
/ (fcn) fcn.001da558 4
|   fcn.001da558 ();
|              ; CALL XREF from 0x0016caf4 (fcn.0016cab8 + 60)
|              ; CALL XREF from 0x0016cd94 (fcn.0016cd48 + 76)
|              ; CALL XREF from 0x0016ca24 (fcn.0016c8f8 + 300)
\           0x001da558      40ffbd27       addiu sp, sp, -0xc0
            0x001da55c      7000b2ff       sd s2, 0x70(sp)
            0x001da560      8000b4ff       sd s4, 0x80(sp)
            0x001da564      9000b6ff       sd s6, 0x90(sp)
            0x001da568      .dword 0x0080902d ; sym.0x0080902d
            0x001da56c      9800b7ff       sd s7, 0x98(sp)
            0x001da570      2da00000       move s4, zero
            0x001da574      a000beff       sd fp, 0xa0(sp)
            0x001da578      .dword 0x00c0b02d ; sym.0x00c0b02d
            0x001da57c      6000b0ff       sd s0, 0x60(sp)
[0x001da558]> 

I don't even EDIT: Just to be sure to clearly explain: move aren't detected correctly, function is badly auto defined, jr is also badly analyzed Broken, broken everywhere!

[mrmacete]

yeah i guess many mips64 specific stuff is missing in anal

[mrmacete]

this: https://github.com/radare/radare2/pull/7643 fixes mips64 analysis, i.e. it passes the correct params to capstone.

the false positive .dword stuff is still produced by aaa (still to investigate the reason, may be related to other issues), but at least you can use aa and aac on 64v2.

[GovanifY]

Nice thanks, I will try to fix paddu(w) on capstone as soon as I can, although I'm mildly busy so I'm unsure if I'll post the issue/pull request today

[GovanifY]

https://github.com/aquynh/capstone/issues/940

Posted a minimal issue about padduw (we'll see about the rest later) I'll try to dive into capstone in the next days to know how to implement it

[GovanifY]

Looks like a big update is planned so I won't have to implement it in the end, great

[mrmacete]

now that "64v2" has gone, just set -b 64 or e asm.bits=64 for mips64

[radare]

Can we close this now?

[radare]

closing unless @GovanifY complains tired of waiting

[GovanifY]

Sorry, I wasn't near a computer yesterday.

As for it the issue is still there as PS2 ELFs are read using the wrong architecture type. I don't really know how to fix it in a non-hacky way but others disassemblers such as IDA and Binary Ninja(iirc, might be wrong on the latter) still read it correctly

Although IDA is of course not an example with exotic binaries we can't get that out and just dig this issue.

Or we could just say it's sony's fault for mislabelling ps2 ELFs too.

[Maijin]

Please provide such files here otherwise how can we test and fix that behavior?

[GovanifY]

Didn't I already provided files on this issue...? If I didn't it was on a different one.

Here's a PS2 binary SLPM_666.75.zip /!\ I am not sure of the integrity of this file, it might have been modded but the ELF file infos are the same in either way so this shouldn't cause troubles

[GovanifY]

reports as

bits     32
canary   false
class    ELF32
crypto   false
endian   little
havecode true
lang     c
linenum  false
lsyms    false
machine  MIPS R3000

Should be a MIPS R5900 ELF64

[radare]

What do binutils thinks about it?

On 10 Jul 2017, at 09:31, Maijin notifications@github.com wrote:

Reopened #7636.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub, or mute the thread.

[GovanifY]

➜  KH2FM readelf -a SLPM_666.75
ELF Header:
  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 
  Class:                             ELF32
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           MIPS R3000
  Version:                           0x1
  Entry point address:               0x10001c
  Start of program headers:          52 (bytes into file)
  Start of section headers:          2628364 (bytes into file)
  Flags:                             0x20920001, noreorder, unknown CPU, mips3
  Size of this header:               52 (bytes)
  Size of program headers:           32 (bytes)
  Number of program headers:         2
  Size of section headers:           40 (bytes)
  Number of section headers:         25
  Section header string table index: 24

[radare]

this elf header is an ELF32, the machine is R3000 which is 32bit, and the FLAGS specify it's mips3, which is 32bits too. so this elf header is clearly wrong. My guess is that ida and bn just assume mips64 by default, or they added an exception for those binaries, which is imho a crappy way to lie to users.

I have added a hacky assumption in the asm.bits identification for elf that will solve this issue, but thats obviously a lie because the header is wrong. This will be fine until someone else using a different mips machine complains..

[radare]

my assumption is because its a mips R3000 binary of type EXEC without interp and the mips3 bit set in the elf flags.