Endless Paradigm

Endless Paradigm > PSP Customization > PSP General Customization & Help > PSP Customisation Developments > [Random Info] (decrypted) RCO File Format
Full Version: [Random Info] (decrypted) RCO File Format
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2

ZiNgA BuRgA

19/02/2007, 10:42 PM
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

bstronga

13/03/2007, 06:12 AM
:suprised:
i always wondered how you and Z33 figure out the header information of a unknown format.

beaner2k6

13/03/2007, 09:11 AM
bstronga Wrote::suprised:
i always wondered how you and Z33 figure out the header information of a unknown format.

ZiNgA BuRgA

13/03/2007, 04:26 PM
Urgh, this guide is outdated...  I know most of the RCO now - well, at least every section - there's still a few numbers I'm not sure of.
I'll need to update this sometime.

bstronga Wrote::suprised:
i always wondered how you and Z33 figure out the header information of a unknown format.
Well, actually I started off with the images.  Then I searched for pointers to the images and then you'll eventually get a pattern.  Basically, you keep going and you'll find the rest :P

bstronga

14/03/2007, 01:24 AM
zomg
SpectroPlasm Wrote: [ -> ]um for RCOs you can't just decrypt them like you would with PRXs because between the two it's comparing an .EXE file with a .DLL file.  the RCO just holds the extra non code data (icon, sound,anims,etc...)

**Though some RCO will have executable code inside them just like DLLs it's not very easy to decrypt due to difference in code and encryption argos.  :)

executable code in a .rco ;o

ZiNgA BuRgA

14/03/2007, 02:45 AM
^^I'm partially doubting him actually.  I've seen the header of 3.10 RCOs (the first section isn't encrypted/compressed) - nothing has changed in terms of structure, and I know that RCOs only contain 6 parts of data:
  • Image resources (MIG/PNG)
  • Sound resources (VAG)
  • Object resources (OMG/GMO - eg waves)
  • Text Data (eg menu labels)
  • Page Data
  • Anim Data
There's also some labels and "native" data describing the above, as well as the table entries of course.

Also, he claims that some RCOs were Gzip compressed (he says that on the same page).  I sent him this PM:
zinga Wrote:Yeah, PMd you cause don't want to get too off-topic in that thread :P

SpectroPlasm Wrote: [ -> ]well if you want to know more the rco's contain both zlib compression and Gzip compression :) try deflating some with Gzip :p, by the way your RCOeditor is really good :) you should have 3.03 file support though because not all 3.03 files are encrypted
pm me sometime when you're free ;)
Hehe, thanks a lot for that info.
I had a look at some random ones (auth and system_plugin_fg.rco) but wasn't able to inflate using GZip (is it somewhat different to zlib's deflate?  cause I believe zlib includes gzip handling functions...  dunno though - I've never really delved into compression before).
All I've been able to discover (if you didn't know this already - lol, my n00b findings :P):

- the newer compression achieves a slightly better compression ratio than what zlib can achieve (on level 9) - for example, the triangle image in system_plugin_fg is 200 bytes, one in 2.50 is 227 bytes.  Recompressing it squishes it down to 223 bytes.  If gzip's deflate is different from zlib's, is it this much different?

- In system_plugin_fg.rco, for the circle and cross images, the first ~64 bytes are identical...  this isn't the behaviour of zlib's deflate.

- Signature for the images is 0xD905 (2 bytes), but it seems that the first four bytes are required - the rest can be blanked without the PSP crashing

- For the header sections, things seem to be broken into components, but the signature seems to vary, but there's some common ones


Anyways, ignoring all that junk, I don't have any idea on how to decompress the 3.xx RCOs...  I do remember at one point, jas0nuk claimed that it could possibly be the 2RLZ compression algorithm.

Thanks a lot for bringing this up :)  Would be great if this could be figured out! :D


He never replied...
Basically, I'm not certain he exactly knew that he was right...  I dunno though...

ZiNgA BuRgA

14/03/2007, 04:31 AM
Finally updated this guide a bit.  It's a LOT more accurate than the previous one :P
As you can see, there's only really a few unknown values now :yipi:

bstronga

17/03/2007, 12:39 PM
very nice! apart from the "Too lazy to write this section up now " parts ;p

anyway just played around a little with the topmenu_plugin.rco and actually noticed that this rco doesn't hold much information about the subicons... ?

ZiNgA BuRgA

17/03/2007, 03:49 PM
bstronga Wrote:anyway just played around a little with the topmenu_plugin.rco and actually noticed that this rco doesn't hold much information about the subicons... ?
Seems so...  Not absolutely sure, but does seem the case. Erk

bstronga

20/03/2007, 10:41 AM
i was messing around again.
wanted to know why certain icons corrupted when using tex_fcs/tex_sdw and eventually noticed that they start to corrupt from a certain point in the mig table. putting icons higher in the table will also move the corruption point higher, could this be a memory issue?
Pages: 1 2
Endless Paradigm > PSP Customization > PSP General Customization & Help > PSP Customisation Developments > [Random Info] (decrypted) RCO File Format
Reference URL's