Threaded Mode | Linear Mode

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
Table section
Data area

RCO Header

Offset	Type/Size	Purpose
0x00	DWord	RCO Signature, always is 0x46525000 (.PRF)
0x04	DWord	Appears 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"
0x08	DWord	Unknown - always seems to be 0x00
0x0C	DWord	Seems 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
0x10	DWord	Offset of the "information"? table - always is 0xA4
0x14	DWord	Unknown. Always seems to be 0xFFFFFF
0x18	DWord	Offset of the text table
0x1C	DWord	Offset of the sound (VAG) table
0x20	DWord	Offset of the model (OMG) table
0x24	DWord	Offset of the image (MIG) table
0x28	DWord	Unknown. Always seems to be 0xFFFFFF
0x2C	DWord	Unknown. Always seems to be 0xFFFFFF
0x30	DWord	Offset of the "page" table
0x34	DWord	Offset of the "anim" table

0x40	DWord	Offset of the label table
0x44	DWord	Length of the label table
0x48	DWord	Offset of the "native:/" table
0x4C	DWord	Length of the "native:/" table
0x50	DWord	Offset of the text pointer table.
0x54	DWord	Length of the text pointer table.
0x58	DWord	Offset of the image (MIG) pointer table.
0x5C	DWord	Length of the image (MIG) pointer table.
0x60	DWord	Offset of the model (OMG) pointer table.
0x64	DWord	Length of the model (OMG) pointer table.
0x68	DWord	Offset of the sound (VAG) pointer table.
0x6C	DWord	Length of the sound (VAG) pointer table.
0x70	DWord	Offset of the "page" pointer table.
0x74	DWord	Length of the "page" pointer table.
0x78	DWord	Offset of the "anim" pointer table.
0x7C	DWord	Length of the "anim" pointer table.

0x38	DWord	(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.
0x80	DWord	Offset of the image (MIG) data section
0x84	DWord	Length of the image (MIG) data section
0x88	DWord	Offset of the sound (VAG) data section
0x8C	DWord	Length of the sound (VAG) data section
0x90	DWord	Offset of the model (OMG) data section
0x94	DWord	Length of the model (OMG) data section
0x98	DWord	End marker??? Always seems to be 0xFFFFFF
0x9C	DWord	End marker??? Always seems to be 0xFFFFFF
0xA0	DWord	End 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:

Offset	Type/Size	Purpose
0x00	DWord	Packed size of all the table sections
0x04	DWord	Unpacked size of all the table sections
0x08	DWord	"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

Offset	Type/Size	Purpose
0x00	Byte	ID 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.
0x01	Byte	Type 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
0x02	Word	Unknown - always seem to be 0x0000
0x04	DWord	Offset to the label (relative to the label table). 0xFFFFFFFF means the label doesn't exist for this entry
0x08	DWord	Size of entry header? (always 0x28)
0x0C	DWord	Offset of current entry to first entry (of same depth)?
0x10	DWord	Number of subentries in this one
0x14	DWord	Size of the entry
0x18	DWord	Offset to the next entry?
0x1C	DWord	Current entry offset from the main table (which is always 0xA4)
0x20	DWord	Unknown - always seem to be 0x00000000
0x24	DWord	Unknown - 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)

0x04 (image)

0x05 (object)

0x06 (sound)

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
1	Position X
2	Position Y
3	Object Scale
4	Colour Channel (Red)
5	Colour Channel (Green)
6	Colour Channel (Blue)
7	Colour Channel (Alpha)
8	Dimension - Width
9	Dimension - Height
10	Unknown
11	Stretch X
12	Stretch Y
13	Element 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:

Type	Pointer
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)

Type	Data
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)

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

(13/03/2007 10:23 AM)dasme 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

(14/03/2007 01:00 PM)michaelp 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?

Threaded Mode \| Linear Mode [Random Info] (decrypted) RCO File Format
Author	Message