Miniguide on Virtual File Systems

@DrWatson

Published in 

Hacking Tutorials

 · 21 Jun 2019

 

 /============================================================\ 
|Miniguide on Virtual Filesystems                             | 
|By Klarth                                                    | 
|From a post on RHDN's forums                                 | 
|December 12, 2006                                            | 
| http://www.romhacking.net/forum/index.php/topic,2494.0.html | 
\=============================================================/ 

Before going onto the explanation of it, any data hacker can 
identify the data and pointers associated with a VFS.  But to 
dump and rebuild it, you -WILL- need a beginner's knowledge of 
programming to make custom utilities.  If you know to do file 
i/o with binary files, then that alone is enough to write a VFS 
extractor/rebuilder in most cases. 

Here is some general information on the Virtual Filesystem and 
why it is so important to extract and rebuild it as one of the 
-VERY FIRST STEPS- in the project. 

A Virtual Filesystem is basically a lot of data files in one 
file on a CD/DVD that contains all of the data that you want to 
hack.  They can be as small as ~50MB up to ToD2's 1.41GB and 
even larger. When extracted, you can have hundreds to thousands 
of subfiles (or worse, archives with subfiles) to work with. 
This is key in keeping hacked files organized, teamwork running 
smoothly, and the subfiles are much more manageable in size. 
Furthermore, it's absolutely necessary to dissect for projects 
with compression, encryption, or where you just need to expand 
one file that last elusive byte. 

So now you know what it is, how can you identify, crack this 
thing, ooze its goodies out, and then rebuild it? 

- Identifying the VFS - 
   This is the easy part.  Just search the game disk for a 
   large file.  The filename is usually suggestive of whether 
   it's the main game data VFS or (another possibility) a game 
   movie VFS.  If there are more than two VFS's in a game, then 
   usually they can be cracked by the same method if you can 
   finish the next, more difficult step. 

- Finding the VFS Pointers - 
   Just as a dialogue string has its pointer for the game to 
   locate it, a VFS file has its pointer. 

      Prime Locations: 
       - In a separate file of pointers on the CD, usually in 
         the same directory as the VFS file is in.  It should 
         be a small file (< 100kb even for a massive file 
         count) and usually have no other data with it. 
       - In the VFS file itself.  Usually at the top. 
       - In the EXE file.  These ones stump me more often than 
         not. Maybe a good debugger would have prevented it or 
         a pointer table finder.  They're either in a 
         structured table or the compiler oddly put them into 
         hardcoded ASM pointers. 

- VFS Pointer Data Structure - 
   There are the primary things you'll be looking for when you 
   do notice a VFS pointer table. 
    
     - File start pointer: This is usually a linear pointer 
       from the start of the VFS.  I've always seen them as 
       being 4 bytes.  May be different on PS2 because the 
       processor is 64bit. 
     - File size: This doesn't always appear, but it makes your 
       work easier.  This usually gives the exact filesize, 
       rather than the filesize after it's padded to fill the 
       last sector.  (More info below in VFS Pointer Types) 
     - File name: This is a godsend if the game actually has 
       these.  But unfortunately, a lot don't. 
     - There may be more fields, but the above are the most 
       common by far. 

- VFS Pointer Types - 

  - Byte positioned - 
     This type is easy.  It directly points to the offset where 
     the file starts at.  It will be a multiple of 2048 bytes. 
  - Sector positioned - 
     Still easy.  Each CD data sector is 2048 (0x800) bytes and 
     the files are padded to that length for more efficient 
     reading.  So you multiply the sector position by 2048 to 
     get the file position.  These are usually 4 or 2 bytes 
     each. 
  - Byte positioned with file size data - 
     This type is a tricky find.  Some VFS Pointer Structures 
     will put the size value (either how many bytes into the 
     last sector the data is, or how many padding bytes are) 
     into the byte positioned pointer itself, the last 11 bits 
     that are usually 0's to sector-align the file.  It will 
     read the pointer, use & 0xFFFFF800 to chop the bottom bits 
     off, then use & 0x7FF to get the size of the last sector 
     the file takes up.  This type effectively saves almost 
     half the size (just one entry less than half in ToP PSX) 
     than a structure with a 32 bit pointer and a 32 bit size. 

I hope this answers a lot of questions about the VFS's in general.