News: 11 March 2016 - Forum Rules
Current Moderators - DarkSol, KingMike, MathOnNapkins, Azkadellia, Danke

Author Topic: [psx] Einhander Virtual File System  (Read 3250 times)

Griever

  • Jr. Member
  • **
  • Posts: 52
    • View Profile
[psx] Einhander Virtual File System
« 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

  • Hero Member
  • *****
  • Posts: 2007
  • 時を越えよう、そして彼女の元に戻ろう
    • View Profile
    • Apple of Eden
Re: [psx] Einhander Virtual File System
« Reply #1 on: January 24, 2011, 01:44:17 pm »
Why don't you just use a debugger instead of randomly guessing?
I am the lord, you all know my name, now. I got it all: cash, money, and fame.

Griever

  • Jr. Member
  • **
  • Posts: 52
    • View Profile
Re: [psx] Einhander Virtual File System
« 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

  • Hero Member
  • *****
  • Posts: 2007
  • 時を越えよう、そして彼女の元に戻ろう
    • View Profile
    • Apple of Eden
Re: [psx] Einhander Virtual File System
« 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.
I am the lord, you all know my name, now. I got it all: cash, money, and fame.

Griever

  • Jr. Member
  • **
  • Posts: 52
    • View Profile
Re: [psx] Einhander Virtual File System
« 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: [Select]
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.