Difference between revisions of "CRI ROFS"

From Wiki - GameHacking.org
Jump to: navigation, search
(Links)
Line 7: Line 7:
 
== Random ==
 
== Random ==
  
Several official programs for handling CVM files are known to exist. Actual usage is not entirely known.
+
Several official programs for handling CVM files are known to exist. Usage is not known and guessed below.
  
 
     rofstoko.exe - ? Seemingly used to change existing data and perhaps conversion of some file types.
 
     rofstoko.exe - ? Seemingly used to change existing data and perhaps conversion of some file types.
 
     rofsedit.exe - ?
 
     rofsedit.exe - ?
 
     rofsgen.exe  - ?
 
     rofsgen.exe  - ?
     rofsbld.exe  - ?
+
     rofsbld.exe  - ? Most likely the program used to compile an ROFS structure from a list of files.
 
     rofsview.exe - ?
 
     rofsview.exe - ?
  
Line 39: Line 39:
  
 
=== Basic ===
 
=== Basic ===
 +
 +
As the format is built on top of the original Yellow Book standard, the file storage itself is well documented. Since both ISO and IEC are greedy bastards a relevant item to look up is ECMA-119. The ==Logical Block Size== is 2048 bytes.
  
 
At least two versions exist, perhaps not compatible with each other. One is '''''ROFSROFSBLD Ver.1.52 2003-06-09''''', another is '''''ROFSROFSBLD Ver.1.23 2001-10-17'''''.
 
At least two versions exist, perhaps not compatible with each other. One is '''''ROFSROFSBLD Ver.1.52 2003-06-09''''', another is '''''ROFSROFSBLD Ver.1.23 2001-10-17'''''.
  
From: [http://forum.xentax.com/viewtopic.php?p=22826#p22826 XeNTaX - ROFS Compression\?Encryption? Method]
+
From: [http://forum.xentax.com/viewtopic.php?p=22826#p22826 XeNTaX - ROFS Compression?Encryption? Method]
  
 
     ROFS , By turning off the 0x1800 byte from the forefront of the file (header), and change the extension to .iso, Daemon tools can mount it.
 
     ROFS , By turning off the 0x1800 byte from the forefront of the file (header), and change the extension to .iso, Daemon tools can mount it.
Line 74: Line 76:
 
     1W: next data length = B
 
     1W: next data length = B
 
      
 
      
     here byte become A. Reading B Byte next, it processes.  
+
     here byte become A. Reading B Byte next, it processes.
 
      
 
      
 
     However, because completely it has become the same contents as A in regard to data which is read next,  
 
     However, because completely it has become the same contents as A in regard to data which is read next,  
Line 103: Line 105:
 
     last 1W: In case of data length of following data D
 
     last 1W: In case of data length of following data D
 
     0x0000, it adjusts the length of the following data and is packed (?)There is a place where it is done. The data other than
 
     0x0000, it adjusts the length of the following data and is packed (?)There is a place where it is done. The data other than
     0x00 appears to has the necessity to search.  
+
     0x00 appears to has the necessity to search.
 
      
 
      
 
     The quantities of all to here byte become C. Reading D Byte next, it processes.  
 
     The quantities of all to here byte become C. Reading D Byte next, it processes.  
     However, it adjusts and is packed (?)When it was done, data length stops being agreeable.  
+
     However, it adjusts and is packed (?)When it was done, data length stops being agreeable.
 
      
 
      
 
     After returning to DATA FIRST, to FAT SIZE + 0x1800 it repeats processing.
 
     After returning to DATA FIRST, to FAT SIZE + 0x1800 it repeats processing.
  
  
From: [http://forum.xentax.com/viewtopic.php?p=24509#p24509 XeNTaX -  - ROFS Compression\?Encryption? Method]
+
From: [http://forum.xentax.com/viewtopic.php?p=24509#p24509 XeNTaX -  - ROFS Compression?Encryption? Method]
  
 
  struct ROFSRootEntry
 
  struct ROFSRootEntry
Line 138: Line 140:
 
  First read the root entries at offset ??? load them into memory and use that to get the entire  
 
  First read the root entries at offset ??? load them into memory and use that to get the entire  
 
  file list(with rofsentry structure) it is just a bunch of interconnecting nodes.
 
  file list(with rofsentry structure) it is just a bunch of interconnecting nodes.
 +
 +
== Partial List of Games ==
 +
 +
=== Playstation 2 ===
 +
 +
Arcana Heart
 +
 +
Namcollection
 +
 +
Odin Sphere
 +
 +
Persona 3
 +
 +
Persona 3 FES
 +
 +
Persona 4
 +
 +
Sakura Taisen V
 +
 +
Sonic Gems Collection
 +
 +
Sonic Heroes
 +
 +
Tales of Symphonia
 +
 +
Tales of the Abyss
 +
 +
Virtua Fighter 4
 +
 +
Virtua Fighter 4 Evolution
  
  
 
== Links ==
 
== Links ==
*[http://www.cri-mw.co.jp/insidemw/rofs1/index_j.htm CRI・ミドルウェア : インサイドミドルウェア : 第2話 インサイドROFS 「ROFSTOKO.EXE」:] - Japanese page roughly describing ROFS.
+
*[http://www.cri-mw.co.jp/insidemw/rofs1/index_j.htm CRI·?????? : ??????????? : ?2? ?????ROFS ?ROFSTOKO.EXE?:] - Japanese page roughly describing ROFS.
*[http://homepage1.nifty.com/~hin/rofs.html ROFS について] - Another page in Japanese, with actual information about the file structure.
+
*[http://homepage1.nifty.com/~hin/rofs.html ROFS ????] - Another page in Japanese, with actual information about the file structure.
 
*[http://apache3.net/ Apache3] - Site for Apache3, Munge Explorer, and several other programs.
 
*[http://apache3.net/ Apache3] - Site for Apache3, Munge Explorer, and several other programs.
 
*[http://www.mactech.com/articles/develop/issue_03/high_sierra.html The Ins And Outs Of ISO 9660 And High Sierra] - A rather detailed explanation of an ISO-9660 filesystem.
 
*[http://www.mactech.com/articles/develop/issue_03/high_sierra.html The Ins And Outs Of ISO 9660 And High Sierra] - A rather detailed explanation of an ISO-9660 filesystem.
 +
*[http://www.ecma-international.org/publications/standards/Ecma-119.htm ECMA-119 - Volume and File Structure of CDROM for Information Interchange 2nd edition (December 1987)]
  
 
[[Category:File Systems]]
 
[[Category:File Systems]]

Revision as of 09:27, 25 May 2009

ROFS is a bulk data file structure developed by CRI Middleware Co., Ltd. It is greatly built off of the ISO-9660 standard. These are easily identified as having the file name extension of CVM.



Random

Several official programs for handling CVM files are known to exist. Usage is not known and guessed below.

    rofstoko.exe - ? Seemingly used to change existing data and perhaps conversion of some file types.
    rofsedit.exe - ?
    rofsgen.exe  - ?
    rofsbld.exe  - ? Most likely the program used to compile an ROFS structure from a list of files.
    rofsview.exe - ?

There are a few homemade programs created for interacting with CVM filesystems with various limited functionality.

Apache3 - Badly named but effective for extracting the contents of a CVM (and several other disc image types such as GCM). It can also replace files inside the image. Has entirely no capacity to create new files from scratch.

apache3_setup.exe v3.10.6 beta

Daemon Tools (and some other disc mounting software) - If a 0x1800 block is removed from the start of the file, it can be mounted as a disc image. Other mounting utilities may not cooperate.

Abyss - A tiny custom tool made by darthi8nt for beating up the TO7BTL.cvm file from Tales Of The Abyss. It looks to be only for that specific file and no others.

abyss.zip

abyss_update.zip

VF4EXt_n_reb - Another tool from darthi8nt. Same deal as with Abyss, but for VF4STRMS.cvm on Virtua Fighter 4.

VF4EXt_n_reb.rar


Structure

This information is incomplete and may by itself not be of much help. Note also that it may not apply to all containers of this format being that there are known to be incompatible revisions.

Basic

As the format is built on top of the original Yellow Book standard, the file storage itself is well documented. Since both ISO and IEC are greedy bastards a relevant item to look up is ECMA-119. The ==Logical Block Size== is 2048 bytes.

At least two versions exist, perhaps not compatible with each other. One is ROFSROFSBLD Ver.1.52 2003-06-09, another is ROFSROFSBLD Ver.1.23 2001-10-17.

From: XeNTaX - ROFS Compression?Encryption? Method

    ROFS , By turning off the 0x1800 byte from the forefront of the file (header), and change the extension to .iso, Daemon tools can mount it.
    
    With the header where 0x1800 is gone, then it seems that its retained with the file system ( ISO9660 )
    
    ROFS (CVM) file format memo
    
    B = byte (8bit)
    W = word (16bit)
    L = long word (32bit)
    
    -- 
    0x0000-0xb7ff
    - ROFS version
    - GAME TITLE and PUBLISHER_NAME etc.
    
    offset 0xb800
    1W: first data length = A
    1L: START address START (little endian)
    1L: START address START (big endian)
    1L: FAT SIZE (little endian)
    1L: FAT SIZE (big endian)
    1B: 0x68??
    1B: data length X
    XB: ?? (date?)
    4B: 01 00 00 01 ??
    2B: 01 00 or 01 01
    01 01 as for the FAT SIZE-related data end?
    
    1W: next data length = B
    
    here byte become A. Reading B Byte next, it processes.  
    
    However, because completely it has become the same contents as A in regard to data which is read next, 
    as for meaning in regard to data of B you do          not understand well. For verification?
    
    -- 
    offset 0xb800 + A + B
    1W: data length C
    
    :DATA FIRST
    
    1L: START address START (little endian)
    1L: START address START (big endian)
    FILE START address = 0x800*START + 0x1800
    1L: file size (little endian)
    1L: file size (big endian)
    
    1B: 0x68 ??
    1B: data length Y
    YB: ?? (date?)
    4B: 01 00 00 01 ??
    1B: file name length Z
    ZB: file name
    2B: 3B 31 (flag?)
    
    0 fill are done
    
    last 1W: In case of data length of following data D
    0x0000, it adjusts the length of the following data and is packed (?)There is a place where it is done. The data other than
    0x00 appears to has the necessity to search.  
    
    The quantities of all to here byte become C. Reading D Byte next, it processes. 
    However, it adjusts and is packed (?)When it was done, data length stops being agreeable.  
    
    After returning to DATA FIRST, to FAT SIZE + 0x1800 it repeats processing.


From: XeNTaX - - ROFS Compression?Encryption? Method

struct ROFSRootEntry
{
int Offset;
short Unknown;
std::string Name;
};

struct ROFSEntry
{
unsigned short EntrySize; // Entry Header Size
unsigned int Address; // File start offset
unsigned int Size; // File Size
unsigned char Unk0[10];
unsigned short Unk;
std::string Name;
};

if I remember correctly the root entries are a listing of all directories in the file. 
from there the rofsentry structure is used to navigate the actual directory and file structure. 
a flag in the rofsentry structure tells if the entry is a directory(0x02) or a file(0x01) but I don't know 
where that was ^_^; when the entry is a directory the offset leads to another listing of directories 
or files. the file is padded to 4096 or 2048 I don't remember. (directories always have "." and ".." entries)

First read the root entries at offset ??? load them into memory and use that to get the entire 
file list(with rofsentry structure) it is just a bunch of interconnecting nodes.

Partial List of Games

Playstation 2

Arcana Heart

Namcollection

Odin Sphere

Persona 3

Persona 3 FES

Persona 4

Sakura Taisen V

Sonic Gems Collection

Sonic Heroes

Tales of Symphonia

Tales of the Abyss

Virtua Fighter 4

Virtua Fighter 4 Evolution


Links