06-04-2014, 11:45 PM
Did you check the log or only the console?
Is it possible to Decipher file structure from mips?
|
06-04-2014, 11:45 PM
Did you check the log or only the console?
06-05-2014, 12:42 AM
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
06-06-2014, 10:10 AM
I dont think i know how to use this debbuger.
Under R3000 there is some mips code, who owns it?
06-06-2014, 08:44 PM
PCSX2 debugger is ee only.
Quote:who owns it?What do you mean? (06-06-2014, 08:44 PM)gregory Wrote: PCSX2 debugger is ee only. 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: # $fea0, $0060, $3f30 I thought this was immediate mode where do these registers come from? Stack addresses? Code: FNC_00193b70: # 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
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... 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.
06-07-2014, 07:42 AM
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: # 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.
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.
06-07-2014, 09:55 AM
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
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. |
« Next Oldest | Next Newest »
|