Endless Paradigm / PSP Customization / PSP General Customization & Help / PSP Customisation Developments / [Random Info] (decrypted) RCO File Format

Post Reply 
[Random Info] (decrypted) RCO File Format
Author Message
ZiNgA BuRgA
Smart Alternative

Posts: 17,022.2988
Threads: 1,174
Joined: 19th Jan 2007
Reputation: -1.71391
E-Pigs: 446.1274
Offline
Post: #1
[Random Info] (decrypted) RCO File Format
Note, I'm assuming you already have basic hex editing knowledge...

This is the file structure, as far as I know, of decrypted (FW2.60 and lower) RCOs.
Many thanks go to Z33 at MaxConsole for providing much information on this.  His thread can be found here.

NOTES:
  • I tend to refer to "encrypted" - RCOs aren't really encrypted, but just compressed in an unknown way.  I use this word for convenience purposes :P
  • Everything is aligned to a 4 byte boundary, so basically all values are DWords.  There are one or two which are just Words however.  Thus, padding is used to achieve this 4 byte boundary at times
  • Lengths don't include padding (obviously)
  • For text entries, they are always separated by at least one null character

Anyways, there's 3 basic sections of the RCO.

Contents

RCO Header
OffsetType/SizePurpose
0x00DWordRCO Signature, always is 0x46525000 (.PRF)
0x04DWordAppears to be a switch of some kind:
  • 0x70 or 0x71 means normal table section
  • 0x90 means a deflated table section
  • larger values indicate that it's "encrypted"
0x08DWordUnknown - always seems to be 0x00
0x0CDWordSeems to change when different compressed headers are used:
  • 0x00 = normal header
  • 0x10 = deflated header
  • 0x20 = "encrypted" header
For the following sections, 0xFFFFFF means the section doesn't exist
0x10DWordOffset of the "information"? table - always is 0xA4
0x14DWordUnknown.  Always seems to be 0xFFFFFF
0x18DWordOffset of the text table
0x1CDWordOffset of the sound (VAG) table
0x20DWordOffset of the model (OMG) table
0x24DWordOffset of the image (MIG) table
0x28DWordUnknown.  Always seems to be 0xFFFFFF
0x2CDWordUnknown.  Always seems to be 0xFFFFFF
0x30DWordOffset of the "page" table
0x34DWordOffset of the "anim" table
0x40DWordOffset of the label table
0x44DWordLength of the label table
0x48DWordOffset of the "native:/" table
0x4CDWordLength of the "native:/" table
0x50DWordOffset of the text pointer table.
0x54DWordLength of the text pointer table.
0x58DWordOffset of the image (MIG) pointer table.
0x5CDWordLength of the image (MIG) pointer table.
0x60DWordOffset of the model (OMG) pointer table.
0x64DWordLength of the model (OMG) pointer table.
0x68DWordOffset of the sound (VAG) pointer table.
0x6CDWordLength of the sound (VAG) pointer table.
0x70DWordOffset of the "page" pointer table.
0x74DWordLength of the "page" pointer table.
0x78DWordOffset of the "anim" pointer table.
0x7CDWordLength of the "anim" pointer table.
0x38DWord(note the offset) Offset and length to some text.  If this text doesn't exist, this value is the same as the value at 0x40, and length is 0x00.
0x80DWordOffset of the image (MIG) data section
0x84DWordLength of the image (MIG) data section
0x88DWordOffset of the sound (VAG) data section
0x8CDWordLength of the sound (VAG) data section
0x90DWordOffset of the model (OMG) data section
0x94DWordLength of the model (OMG) data section
0x98DWordEnd marker???  Always seems to be 0xFFFFFF
0x9CDWordEnd marker???  Always seems to be 0xFFFFFF
0xA0DWordEnd marker???  Always seems to be 0xFFFFFF


Table Section (begins at 0xA4)
If the table area is compressed (FW2.60), there are 3 DWords before the compressed data:
OffsetType/SizePurpose
0x00DWordPacked size of all the table sections
0x04DWordUnpacked size of all the table sections
0x08DWord"Something about the unpacked size of the next file after the packed header..." -Z33

For FW2.71+, the table seems to be packed in parts, rather than the whole table section packed together.


Now, back to the uncompressed header.
Each table entry seems to have a 40 byte header, followed by the entry data. (note, the "main entry" refers to the first one - which "contains" all the other entries)

Table entry headers
OffsetType/SizePurpose
0x00ByteID of the current entry???  The main entry, seems to have a value of 1.  Some subentries seem to use this as the "depth" of the current entry.
0x01ByteType of the entry.  Here's a few:
  • 0x01 = main entry
  • 0x03 = text
  • 0x04 = image (GIM or PNG)
  • 0x05 = model (GMO)
  • 0x06 = sound (VAG)
  • 0x08 = "page"
  • 0x09 = "anim"
The "anim" sections seem to have subentries with higher values
0x02WordUnknown - always seem to be 0x0000
0x04DWordOffset to the label (relative to the label table).  0xFFFFFFFF means the label doesn't exist for this entry
0x08DWordSize of entry header? (always 0x28)
0x0CDWordOffset of current entry to first entry (of same depth)?
0x10DWordNumber of subentries in this one
0x14DWordSize of the entry
0x18DWordOffset to the next entry?
0x1CDWordCurrent entry offset from the main table (which is always 0xA4)
0x20DWordUnknown - always seem to be 0x00000000
0x24DWordUnknown - always seem to be 0x00000000
For entry headers longer than this, the rest is unknown

Table entry data
This varies, depending on the type:
0x03 (text)
This starts off with 2 bytes, before the actual text indexes.
OffsetType/SizePurpose
0x00DWordLanguage ID:
  • 0x10000 = Japanese
  • 0x10001 = English
  • 0x10002 = French
  • 0x10003 = Spanish
  • 0x10004 = German
  • 0x10005 = Italian
  • 0x10006 = Netherlands
  • 0x10007 = Portugese
  • 0x10008 = Russian
  • 0x10009 = Korean
  • 0x1000A = Chinese (Traditional)
  • 0x1000B = Chinese (Simplified)
0x04DWordNumber of text indexes in current entry
After this, is the actual text indexes (each is 12 bytes long):
OffsetType/SizePurpose
0x00DWordOffset to label, relative of the label table
0x04DWordLength of the text
0x08DWordOffset of the text, relative to the text data start address
0x04 (image)
OffsetType/SizePurpose
0x00WordFile type ID (0x05 = MIG)
0x02WordCompression flag?  0x00 = uncompressed, 0x01 = zlib deflated
0x04DWordPacked size of data without padding
0x08DWordOffset of data relative to the beginning of the image data section
0x0CDWordSize of unpacked data
0x05 (object)
OffsetType/SizePurpose
0x00WordFile type ID? (0x00 = OMG)
0x02WordCompression flag?  0x00 = uncompressed, 0x01 = zlib deflated
0x04DWordPacked size of data without padding
0x08DWordOffset of data relative to the beginning of the image data section
0x0CDWordSize of unpacked data
0x06 (sound)
OffsetType/SizePurpose
0x00WordFile type ID? (0x01 = VAG)
0x02WordNumber of channels, either 0x01 or 0x02
0x04DWordSize of data (if there's two channels, then this is the size of both)
0x08DWordOffset of the sound data to the beginning of the sound data section
0x0CDWordSize of left channel VAG
0x10DWordOffset of left channel VAG to the beginning of the sound data section
Note, the following values don't exist for single channel VAGs
0x14DWordSize of right channel VAG
0x18DWordOffset of right channel VAG to the beginning of the sound data section
0x08 (page)
In this section, the entry ID (from the table entry header described above) is rather important in determining what the page entry does, and the type of values under it.

A few common common characteristics first though:
Many entries have a "position description" at the beginning.  This consists of 13 consecutive float values:
#Purpose
1Position X
2Position Y
3Object Scale
4Colour Channel (Red)
5Colour Channel (Green)
6Colour Channel (Blue)
7Colour Channel (Alpha)
8Dimension - Width
9Dimension - Height
10Unknown
11Stretch X
12Stretch Y
13Element Scale
For the position values, 0 = centre of screen.  For the colour channels, 0 = no colour, 1 = full colour (for example, the colour red (FF0000FF in hex colour code) would be R:1, G:0, B:0, A:1)

Another common thing are "objects".  These consist of two DWords, the first is a type descriptor, the second refers points to the object.  Below is a list of the types of objects known:
TypePointer
0x400 (event)Points to a native:/ entry relative to the "native" table.
0x401 (text)The text entry #.  For example, 0 = the first text entry.
0x402 (image)Absolute pointer to the image table entry.
0x403 (model)Absolute pointer to model table entry.
0x407 (page?)Same as 0x409???
0x408 (anim)Absolute pointer to anim table entry.
0x409 (page)Absolute pointer to page table entry.
0xFFFF (blank)This value should always be 0xFFFFFFFF

Now onto each type of entry.  The following table shows the types of values (in order) under each particular type of page entry. (note, RCO Editor will stick a "8" at the front, thus 0x802 instead of 0x02)
TypeData
0x01 (page)* note that this is always a top level page entry
0x111 (dunno what this does)
<object (event)>
<object (event)>
<object (event)>
<object (event)>
0x02 (plane)* this entry seems to describe an image
<position description>
<DWord>
<object (event)>
<object (image)>
<DWord>
0x03 (button)* this entry seems to be used for "buttons" or small images
<position description>
<DWord>
<object (event)>
<object (image)>
<object (image)>
<object (image)>
<object>
<object (event)>
<object (event)>
<object (event)>
<object (event)>
<object (event)>
<object (event)>
<object (event)>
<object (event)>
<DWord>
0x04 (xmenu? [XmbMenu?])<position description>
<?>
<object (event)>
<DWord> * number of sub menus?
<object (event)>
<object (event)>
<object (event)>
<object (event)>
<object>
0x05 (list [XmbMainList?])* this entry seems to only appear for XMB main menu icons
<?>
<object (image)>
<object>
0x06 (xlist [XmbList])<position description>
<DWord>
<object (event)>
<DWord> * seems to be number of items under this xlist
<object (event)>
<object (event)>
<object (event)>
<object (event)>
<object (event)>
<object (event)>
<object (event)>
0x07<position description>
<DWord>
<object (event)>
<Float>
<?>
<object>
<object>
<object>
0x08 (scroll?)* A scrollbar???  Only seems to appear under lists
<position description>
<DWord>
<object>
<Float>
<Float>
<?>
<object>
<object>
<object>
<object>
<object>
0x09 (mlist [MenuList])* seems to describe those context menus, for example, selecting a language in the System Settings
<position description>
<DWord>
<object (event)>
<DWord>
<?>
<DWord>
<Float>
<Float>
<object>
<object (event)>
<object>
<object>
<object>
<object (event)>
<object>
<object>
<object>
<object (event)>
<object>
0x0A (item [MenuItem])* Item under MenuList
<object (text)>
<object (text)>
<object>
0x0B* This type doesn't seem to exist :P
0x0C (item_xlist [XmbListItem])<object (image)>
<object (text)>
<object>
0x0D (text)<position description>
<DWord>
<object>
<object (text)>
<object>
<DWord>
<DWord>
<Float>
<Float>
<Float>
<Float>
<Float>
<Float>
<Float>
<?>
<?>
<?>
<?>
<Float>
<Float>
<Float>
<?>
<Float>
<Float>
<Float>
<Float>
<?>
<?>
<?>
<Float>
<Float>
<Float>
<Float>
<DWord>
0x0E (model)<position description>
<?>
<object (event)>
<object (model)>
0x0F<position description>
<DWord>
<object (event)>
<?>
<DWord>
<object>
<object>
<object (event)>
<object (event)>
<object (event)>
<object>
<object>
<object>
<object>
<object>
0x10<object>
0x11 (item_spin)* seems to be some item which often changes - eg the seconds counter when listening to music
<position description>
<DWord>
<object (event)>
<DWord>
<DWord>
<DWord>
<DWord>
<DWord>
<Float>
<object>
<object>
<object (event)>
<object (event)>
<object>
<object>
<object>
<object>
<object (page)>
<object (page)>
0x12 (group)* used to group page resources together?
<position description>
<DWord>
<object>
0x13 (list?)<position description>
<DWord>
<object>
<DWord>
<?>
<Float>
<object>
<object>
<object>
<object>
<object>
<object>
<object (event)>
<object>
0x14 (litem?)<object (text)>
<object>
<object>
0x15 (edit?)* An edit field?
<position description>
<DWord>
<object (event)>
<?>
<?>
<?>
<?>
<object>
<object>
<object (event)>
<object>
<object>
<object>
<object (event)>
<object (event)>
<object (page)>
<object (page)>
<object>
0x16 (clock)* O_o, a clock :P
<position description>
<DWord>
<object (event)>
<DWord>
<Float>
<object (text)>
<object (text)>
<object>
<object>
<object (event)>
<object (event)>
<object>
<object>
<object (event)>
<object (event)>
<object>
<object>
<object (event)>
0x17 (ilist [InfoList])<position description>
<DWord>
<object (event)>
<Float>
<object>
<object>
<object (event)>
<object>
0x18 (item [InfoItem])* A piece of "information"
<object (text)> * Default text to display
<object (text)> * Error/alternative text to display
0x19 (icon?)<position description>
<?>
<object (event)>
<object (image)>
<object (image)>
<object>
0x09 (anim)
Note that the following information has not been tested yet - it's actually just my idea on how it works :P
The structure of anim resources are similar to that of page resources.  There's no multiple-depth subentries, and subentries don't have a label.
It seems that each subentry describes a "command".  The PSP, when the animation sequence is fired, will start executing each command in order in parallel, until a DELAY (0x07) command is reached.
Most of these commands involve modifying some attribute of a page resource - for these, the first bit of data is the <object (page)> to modify, then the next item would be the time (in ms) it takes to perform the animation (for example, if a set position command is given, with time=100, then the PSP will take 0.1 seconds to animate the page moving to the specified position).  Times are floats (so decimals accepted).
Note that anim resources will borrow the <object> concept from page resources.

Here's the list of IDs: (note, RCO Editor will stick a "9" at the front, thus 0x902 instead of 0x02)
IDDescriptionData
0x01Parent* No data
0x02Set pos.<object (page)>
Time
<?>
Target X
Target Y
<?>
0x03Set colour<object (page)>
Time
<?>
New Red value
New Green value
New Blue value
New Alpha value
0x05Set scale?<object (page)>
Time
<?>
New Object Scale?
New X Scale?
New Y Scale?
0x06Set alpha<object (page)>
Time
<?>
New Alpha value
0x07DelayTime
0x08Fire event<object (event)>
0x09Some switch???0xFFFFFFFF
0x0B???<object (page)>
<?>
<?>
<Float>
<?>
<?>
<Float>

Entry Pointer sections
These immediately follow the above tables.  They just contain absolute offsets to the various subentries above.  These sections are described by the values from 0x50 to 0x80, and follow the same order.
However, these seem to be out of order, and have "null" entries.  Don't understand why, lol Erk


Text/"native:/" Tables
The "text tables" (offset is given at 0x40 and 0x48) are just ASCII text separated by null characters.  Each string is aligned to a 4 byte boundary (thus extra padding may be used).


Data Area
Basically, where all the data is stored...
Resources are aligned to 4 byte boundaries (thus padding may be used to achieve this).
Deflated resources have the 2 byte signature, 0xDA78.  "Encrypted" resources have the 2 byte signature, 0xD905.



Alright, that's all I really know about the RCO format - Z33 has some more info in his documentation (can be found here).

Hope this guide helped someone Erk
(This post was last modified: 08/08/2007 04:40 PM by ZiNgA BuRgA.)
19/02/2007 10:42 PM
Visit this user's website Find all posts by this user Quote this message in a reply
Post Reply 


Messages In This Thread
[Random Info] (decrypted) RCO File Format - ZiNgA BuRgA - 19/02/2007 10:42 PM

Forum Jump:


User(s) browsing this thread: 1 Guest(s)

 Quick Theme:


Privacy Policy | Endless Paradigm | Return to Top | Return to Content | Lite (Archive) Mode | RSS Syndication