+  RHDN Forum Archive
|-+  Romhacking
| |-+  ROM Hacking Discussion
| | |-+  [psx] Einhander Virtual File System
Pages: [1]
Author Topic: [psx] Einhander Virtual File System  (Read 1 times)
Griever
Guest
« on: January 24, 2011, 12:18:30 pm »

Good day, everyone!
I can't figure out Einhander's virtual file system. The game has one BININDEX.BIN and a few BINPACK0.BIN, BINPACK1.BIN, BINPACK2.BIN etc. BINPACKs have raw data in them and sector aligned.
Sure it looks like BININDEX is a header file with offsets of end files in it, but here, what I've learned:
1) BININDEX is sector aligned and has a few sections inside itself. There are no filenames in it - guess it's ok for some PSX games
2) Offset 0x2C in BININDEX is an end_file offset in sectors from the beginning of BINPACK0.BIN (offset is equal to 0x01BF). 0x2C is loaded from executable itself and there are no continuum data in the neighbourhood in sys.exe
3) I've corrupted data 0-0x20 in BININDEX and it didn't affect the game, also they are not readed. So all these meaning bytes are actually not used!
My guess is that this game does not have any VFS: just a file BININDEX with offsets, which are placed in random pattern and they are loaded in each time by appropriate code.
Can it be right, or I'd mistaken somewhere?
Gemini
Guest
« Reply #1 on: January 24, 2011, 01:44:17 pm »

Why don't you just use a debugger instead of randomly guessing?
Griever
Guest
« Reply #2 on: January 24, 2011, 03:00:45 pm »

And that's excacly what I was doing from the very beginning. Actually FLIRT signatures helped me a lot to get where I am now and that's the problem:
Almost no bytes are actually read from binindex (no breakpoints halted), except 0x2C - there are no overall processing function for processing binindex it is randomly accessed. I'm just confused, cause such file system structure has no sense - just obfuscation purposes maybe. Or maybe I was too blind to see what's really going on in the code.
Gemini
Guest
« Reply #3 on: January 24, 2011, 05:58:55 pm »

You should check for instances of the CdControlX functions (CdControl, CdControlB, CdControlF) with parameter 1 (a0) set to CdSetloc (=2). Those are used to set disk seek, ergo it's where you should start looking for your virtual file system.
Griever
Guest
« Reply #4 on: January 25, 2011, 01:01:10 pm »

Nah, what should I see? I know how and where to binindex and binpack0 are loaded. Just RAM addresses now:
Code:
sll     $v0, $v1, 1
addu    $v0, $v1
sll     $v0, 2
subu    $v0, $v1
sll     $v0, 2
lui     $1, 0x8005
addu    $1, $v0
lwl     $v1, 0x6F3B($1)
lui     $1, 0x8005
addu    $1, $v0
lwr     $v1, 0x6F38($1)
nop
swl     $v1, 0x40+var_2D($sp)
swr     $v1, 0x40+var_30($sp)
jal     CdPosToInt
move    $a0, $s1
lw      $v1, unk_80062AF4
nop
lhu     $a0, 0x12($v1)   # load 0b from .exe
lhu     $a1, 0x10($v1)   # load 00 from .exe
                         
sll     $a0, 2           # get 2c - offset in the binindex.bin
sll     $v1, $a1, 2     
addu    $v1, $a1
sll     $v1, 6
addu    $a0, $v1
lui     $1, 0x8006
addu    $1, $a0          # Add offset in binindex
lhu     $v1, 0x5080($1)  # The beginning of BinIndex in RAM
                         # load a word at 2C in binindex
                         # thats a sector offset (0x01BF)
move    $a1, $s1
addu    $s0, $v0, $v1    # V0 - is a sector offset of binpack0.bin at CD
                         # add offset from the beginning of binpack0
                         # and get absolute position
jal     CdIntToPos
move    $a0, $s0

The only problem here is that code itself has a bunch of commands like:

Which randomly access binindex.bin.
Still guess I'm right - there is no system in this infernal game.
Pages: [1]  


Powered by SMF 1.1.4 | SMF © 2006-2007, Simple Machines LLC