Is it possible to Decipher file structure from mips?

[gregory]

Did you check the log or only the console?

[avok23]

I checked the log. IT was MASSIVE.

But it seems to have all that i need. The bad news is that the strings are not always spaced out

[avok23]

I dont think i know how to use this debbuger.
Under R3000 there is some mips code, who owns it?

[gregory]

PCSX2 debugger is ee only.

who owns it?

What do you mean?

[avok23]

PCSX2 debugger is ee only.
What do you mean?

I think i was sleepy when i wrote that. I probably meant where does it come from?
Is it one of the irx file? the iopxxxx.img or is it a continuously updated stream of instructions?


I don't really have a strategy at this point and that's what bothers me. I was hoping to find a label in IOMAN or in the slus and break point its address in pcsx2 allowing me to follow its instruction set but IOMAN seems like a game agnostic library and the addresses in the slus dont seem to match those of the debugger.

I'll reiterate i am a noob with only basic mips knowledge but..
How can you have a "string" as a label?

Code:

__002b3f28:                    #
    dsra        a2, zero, 4        # 002b3f28:0000313b    
    nop                    # 002b3f2c:00000000    
"DATA/FID.BIN":                    #
    .byte        $44            # 002b3f30    68  'D'
    .byte        $41            # 002b3f31    65  'A'
    .byte        $54            # 002b3f32    84  'T'
    .byte        $41            # 002b3f33    65  'A'
    .byte        $2f            # 002b3f34    47  '/'
    .byte        $46            # 002b3f35    70  'F'
    .byte        $49            # 002b3f36    73  'I'
    .byte        $44            # 002b3f37    68  'D'
    .byte        $2e            # 002b3f38    46  '.'
    .byte        $42            # 002b3f39    66  'B'
    .byte        $49            # 002b3f3a    73  'I'
    .byte        $4e            # 002b3f3b    78  'N'
    nop                    # 002b3f3c:00000000

$fea0, $0060, $3f30 I thought this was immediate mode
where do these registers come from? Stack addresses?

Code:

FNC_00193b70:                    #
    addiu        sp, sp, $fea0        # 00193b70:27bdfea0    
    lui        a1, $002b        # 00193b74:3c05002b    a1=$002b0000
    sd        ra, $0020(sp)        # 00193b78:ffbf0020    
    addiu        a0, sp, $0060        # 00193b7c:27a40060    
    sq        s1, $0010(sp)        # 00193b80:7fb10010    
    addiu        a1, a1, $3f20        # 00193b84:24a53f20    a1=$002b3f20
    jal        FNC_0012b2d0        # 00193b88:0c04acb4    ^ $0012b2d0
    sq        s0, $0000(sp)        # 00193b8c:7fb00000    
    lui        a1, $002b        # 00193b90:3c05002b    a1=$002b0000
    addiu        a0, sp, $0060        # 00193b94:27a40060    
    jal        FNC_0012b058        # 00193b98:0c04ac16    ^ $0012b058
    addiu        a1, a1, $3f30        # 00193b9c:24a53f30    a1="DATA/FID.BIN"
    lui        a1, $002b        # 00193ba0:3c05002b    a1=$002b0000
    addiu        a0, sp, $0060        # 00193ba4:27a40060    
    jal        FNC_0012b058        # 00193ba8:0c04ac16    ^ $0012b058
    addiu        a1, a1, $3f28        # 00193bac:24a53f28    a1=$002b3f28
    addiu        a0, sp, $0060        # 00193bb0:27a40060    
    jal        FNC_0012b468        # 00193bb4:0c04ad1a    ^ $0012b468
    daddu        s1, zero, zero        # 00193bb8:0000882d    
    sltu        at, zero, v0        # 00193bbc:0002082b    
    beq        at, zero, __00193c00    # 00193bc0:1020000f    v $00193c00
    addiu        s0, sp, $0060        # 00193bc4:27b00060

What i did was set a breakpoint at "00193b70" (FNC_00193b70) before launching the game. The game does indeed break but at a very different position

[dabore]

the string is not the label it's just ps2disasm collecting it for you. it's a plain data entry.

now that code looks funny. like... $fea0 is added to the stackpointer means it's allocating a space for standard procedure and local variables for the function. dunno if the stackframe runs forward or backwards. ra is the return address out of that function "pushed" on stack. s0 and s1 are "pushed" on the stack to save them from modifcation. the rest is basic functions call setup. a0 and a1 are arguments. a0 is probably variable that was passed to that fnc_00193b70 on the stack or is a result pointer. i'm not sure - stack confusion. a1 is fixed memory location 0x002b3f20. i can't see. call fnc_0012b2do. next. a0 same variable on stack. a1 is your "DATA/FID.BIN" data memory location. call fnc_0012b058. next. a0 same variable stack. a1 memory location 0x002b3f28 whiches data value is 0x0000313b. call fnc_0012b468. s1, zero, zero is a perhaps dummy instruction due to OOO instructions or optimized by the compiler to be zero in the function called. next. "sltu at" compares the result of the last function in v0 with 0 and branches to memory 00193c00. it's just a lil confusing. the calls with the out of order intructions. but... nice asm.

_____________________

i had a look at the kengo 2. the fid.bin had somewhat 900+ file indices. the elf opened in disasm had most of the mdl and sound filenames with pathes ~780 as strings embedded in a string table. sure lacking some order. also found a buffer location called fid_table. it could be some index into the stringtables but it's gotta be build. it was .bss section memory and it was not the full thing. you could try to find something similar in the 3 and puzzle the fid_tbl with cheat engine. there were also a bunch of load_xyz_tbl.

hope that helps.

[avok23]

Wow thanks a lot.
Some times i wonder, you find a label and all it does is one thing or the majority of of things it does is pushing variables to the stack. MIPS makes my eyes dizzy.

I spent time with all 4 versions and have found a way to identify some of the files. I wonder if it is due to folder structure but they seem to have files in files in files and they are not even compressed. All that unnecessary jumping around.

But now that you mention it i have noticed a lot more labels with fid in them.

Gregory said file reading is done in IOP

i found this in (kengo 1) in regular EE. Break points worked. wow

Code:

motion_Open:                    #
    jal        $0010e660        # 00115278:0c043998    ^ FNC_0010e660
    lw        a0, $c268(s0)        # 0011527c:8e04c268    a0=$0026c268
    sw        zero, $0004(s2)        # 00115280:ae400004    
    beq        zero, zero, $001152ac    # 00115284:10000009    v __001152ac
    lw        a0, $c268(s0)        # 00115288:8e04c268    a0=$0026c268

i dont know how bing that file was but it got real boring stepping thru that code after 10 minutes. I was hoping the debugger would suddenly switch to R3000/IOP at some stage but no luck. I am guessing the debugger just doesnt show us how both processors communicate.

[dabore]

you got files in files in files? that can be tricky. i know that... extracting ghost in the shell. it's like a tree structure. image.bin contains 20_0200_kusanagi.bin that contains tex0.bin that contains unnamed zim files. but they come out clean af. everything visible in raw. and pretty easy to just add the pointers and extract too. sure... atleast that game's format got filenames embedded in the packs. too bad kengo doesn't really. but...

did you have any luck with file string tables in the elf? i doubt it's really all strict "single shot" binary archived and compiled. but it's possible. the file traversal structure gotta be somewhere. also if you got files in files you could perhaps check if the fid.bin indices show signs of a tree in pointer offsets or length. just to get some sorting/"bucketing". or perhaps there are numberal "offset" tables in the elf with for example - per character or model data "collections". if you good with hexeditors you maybe can see patterns while scrolling. i do that fast. also if the code loads labeled offsets with data you can take that data as pointer or reference and go there or do other pointer math. you gotta traverse ever f*cking pointer route. to get a glimpse of what belongs where. i can think of tons of combinations how this is table structured. music, sound, mdl, character with texture buckets. it's virtually a "filesystem". but that "directories" gotta be somewhere. you gotta search.

also the initial "what file to open" operation is triggered by the EE. sure the iop executes, but...

and most of all you won't get the debugger to switch to iop. you miss the concept of that 2 processors. they have that gateway... SIF with dma. it's two sided. the processors running independant and catch that sif signals like interruptions. you'll only see EE/R5900 code in the debugger and it'll write to the sif or trigger a sif dma - no direct switch ot iop. and the R3000 is just not necessarily in need to debug. maybe that's why it's not inclu. would look funny tho to step cycle two different processors in different speeds.

that's about it what i can think of to offer to help. i hope your eyes don't bleed. i hate textwalls, but i put some lines in.

[avok23]

I managed to find some files in files that actually had name i then used the structure of the 360 game to figure out the rest at least for kengo 3. but i simply cannot find the text files. Pretty annoying.

From what i can see they changed file formats from 2 to 3. I think i am just gonna write a brute force parser that reads all the files and finds characters in Japanese character set range.

Just to clarify 1 more thing.
addiu sp, sp, $fea0

is $fea0 = fea0 or something else?


Were you able to get model and animation files from Ghost in the Shell? I really like how Motoko moves in that game

[dabore]

yeah japanese text files are probably unicode. 16 bit code. you can spot the bit patterns. they have that FFXX format or something. in raw ascii with wrong code table you can spot the box patterns. kinda easy. but i'd not trace a whole archive like that.

§feao is just a value that is added to the stack pointer.

and yeah. i didn't yet but i could extract everything. it's just how to interpret them. and everything except the maps. they are pretty beast packed. i'd have to crack the loading code first.