[PS3 Dev Request]: Have a PSP and familiar with .RCO files?

[bigblockchev]

I am learning the file format. I have seen evidence that these ps3 rco files are showing structure signs of older <2.60 rco files. I will focus on the uncompressed rco files now as I believe I can uncover most of the structure rather quickly.

Dug up this old tool and got results using dlna_plugin.rco from xfcj's modified rco's.

C:\Unixdos>rcotool -l test2.rco
*.rco detected... fw ver: 1.50-2.50

Labels for 16 languages

Graphicfiles: 2
tex_dlna (.png)
tex_dlna_shadow (.png)

Soundfiles: 0
Objectfiles: 0

Both RCOEdit and rcotool are showing promise. This result may also explain why Ressursiklunssi does try to process graphics even if this file is not compressed.

Attached Files

	rcotool.rar (31.6 KB, 11 views)
	texdlnaPngs.rar (3.0 KB, 12 views)

[xfcj]

After looking at the structure of the sound and image tables I realized that they're made up of headers for each image/audio file in the rco. Each file gets a header that is 0x3c bytes with the first two words needing to be flipped then the rest of the header is made up of dwords that need to be flipped.

Currently I've got something wrong with the data that says what format the images are in since they're not getting decompressed when extracted with RCOEdit.

[SniprSnake]

the only thing that caught my eye was when opening the dlna.plugin.rco with notepad u can read some text like

the internet connection is disabled. Go to[Settings]>[Network Settings] and enable internet connection. a connection to the network could not be established. Go to[Settings]>[Network Settings] and check your settings. There are too many Media servers. some media servers will not be displayed. no media servers were found. 1 media servers was found. a Ethernet cable is not connected. scanning... please wait.

but in many languages...

i think this RCO is for the media server options....

[almar]

Wow there seems to be big progress. But what i don't understand is that you are using these tools on the ps3 version, why not look at how they are made and change the tools instead of the files so that we can extract all the relevant data on the pc?

[bigblockchev]

The osk_plugin.rco posted here for analysis has hex 71000000 @ 0x04 similar to the fw2.50 structure. Technically this meant the file had a "normal" table section. (see below)

Before fw2.60 the rco file structure was not heavily compressed and many rco's were "normal".

Taking note of hex values 71 00 00 00, the newer compressed ps3 rco file friendim_plugin.rco has 00 00 01 07 or preferably 07 01 00 00 in the header. Looks like a split of 7 and 1 into a whole byte per value.

I wonder if this split shows a sign of how the file has changed over to the ps3. Maybe this is a "normal compressed" rco file. Would the ps3 start anything at a plain-text level anyway? Could the header be shifted
slightly, simply?

I am posting my organized research so far.

---
*decrypted fw2.50 rco file structure findings.

00505246 <-- Signature
71000000 <-- always the same in all RCOs...
00000000 <-- always the same in all RCOs...
00000000 <-- always the same in all RCOs...
A4000000 <-- always the same in all RCOs...
FFFFFFFF <-- always the same in all RCOs...
FFFFFFFF
DC020000 <-- offset of the sound table
7C020000 <-- offset of the animation table
CC000000 <-- offset of the image table
FFFFFFFF <-- offset of some other table?
FFFFFFFF <-- offset of some other table?
48030000 <-- offset of some other table?
64090000 <-- offset of some other table?
784C0000 <-- offset of some other table?
00000000 <-- offset of some other table?
784C0000 <-- Offset of the text table
48020000 <-- Length of the text table
C04E0000 <-- Offset of the "native:/" table
88010000 <-- Length of the "native:/" table
FFFFFFFF <-- Offset of an "unknown data" - FFFFFF = not present
00000000 <-- Length of the "unknown data"
BC4B0000 <-- Offset of an "unknown data 2"
1C000000 <-- Length of the "unknown data 2"
D84B0000 ...etc etc
08000000
E04B0000
08000000
E84B0000
44000000
2C4C0000
4C000000
48500000 <-- Offset of the image data
BC400000 <-- Length of the image data
04910000 <-- Offset of the sound data
20140300 <-- Length of the sound data
24A50300 <-- Offset of the animation data
B0440000 <-- Length of the animation data
FFFFFFFF <-- End marker?
FFFFFFFF <-- End marker?
FFFFFFFF <-- End marker?

The "unknown data" always seems to appear before the 
"text table".

The image/sound/animation data always seems to 
straight after the "native:/" table.
Also, later on, the offsets in the subsequent tables are 
relative to the offsets mentioned above, for example:
20140300 snd_opening size
00000000 snd_opening start offset minus ?
108A0100 snd_opening single channel size

The offset of the sound data is 0x9104, so the offset of 
snd_opening is 0x9104+0x0000 = 0x9104

---
*decrypted fw2.60 rco file structure findings.

- all values are DWords and are aligned to a 4 byte 
boundary. Padding is used for the few Words involved.

- text entries are always seperated by at least one null 
character.

- there are 3 sections in an RCO file:
1. rco header
2. table section
3. data area

HEADER:
- signature 0x00=46525000 (reversed?, like ps3)
0x04=70 or 71, "normal" table
      =90, deflated table
      =91+, very compressed
0x0C=00, normal header
      =10, deflated header
      =20, very compressed header
0x10=table offset, always A4
0x18=text table offset
0x1C=sound (VAG) table offset
0x20=model (OMG) table offset
0x24=image (MIG) table offset
0x28=FFFFFFFF
0x2C=FFFFFFFF
0x30=page table offset
0x34=anim table offset
*0x38=offset and length to text, if no text found then
*0x38=same as 0x40, length 0x00
0x40=label table offset
0x44=label table length
0x48=native:/ table offset
0x4C=native:/ table length
0x50=text pointer table
0x54=text pointer table length
0x58=image (MIG) pointer table offset
0x5C=image (MIG) pointer table length
0x60=model (OMG) pointer table offset
0x64=model (OMG) pointer table length
0x68=sound (VAG) pointer table offset
0x6C=sound (VAG) pointer table length
0x70=page pointer table offset
0x74=page pointer table length
0x78=anim pointer table offset
0x7C=anim pointer table length
0x80=image (MIG) data section offset
0x84=image (MIG) data section length
0x88=sound (VAG) data section offset
0x8C=sound (VAG) data section length
0x90=model (OMG) data section offset
0x94=model (OMG) data section length
0x98=FFFFFFFF
0x9C=FFFFFFFF
0xA0=FFFFFFFF

TABLE:

fw2.60
compression can be identified by 3 DWords before the 
compressed data:
0x00=packed size of all table sections
0x04=unpacked size of all the table sections
0x08=unpacked size of next file after packed header

fw2.70
Rather than the whole table section being packed 
together the table has been packed into parts.

GRAPHICS (data):

Quote: (Z33) 
"All the graphical elements inside the rco's have alpha 
channel in them. That's why they can be extracted. But 
building your own icons with proper alpha channels is a 
bit of a task to do as some elements use the alpha 
channel to set the visibility, others use it for transparent, 
and then there are graphics which are kinda drawn into 
the alpha channel.

Anywho, the palette data in the gim/mig files is arranged 
as: BBGGRRAABBGGRRAABBGGRRAABBGGRRAA...

The imagedata itself is in 4 different formats. Most of the 
data is arranged into blocks of 16x8 pixels, and few of the 
elements are in a linear format, pixel after pixel, line after 
line. And both of those formats can be found mostly in 
8bit color format, few in 4bit colors. Rcotool currently 
extracts all of these images.

And then there's kd/resource/impose.rsc which holds 
those images seen when you press HOME during a 
game."

---

Above information gleaned from various sources. Thanks to all sources respectfully listed here:
-endlessparadigm.com

[Kantraz]

Originally Posted by SniprSnake the only thing that caught my eye was when opening the dlna.plugin.rco with notepad u can read some text like but in many languages... i think this RCO is for the media server options....

I think, that could be usefull to hack.. Then you could stream homebrew over a media server :P

[xfcj]

After looking at the files some more I realized there are more headers in the tables that I was missing. I fixed up the image and sound tables but still slightly confused with the text and page tables. I'll look into these more tomorrow.

Attached is a new version of osk_plugin.rco that you can extract the images and sound out of with RCOEdit.

Attached Files

modified_osk_plugin.zip (12.8 KB, 17 views)

[bigblockchev]

xfcj,

Great work.

I've been playing around with your modified osk_plugin.rco (ps3). I took the original osk_plugin.rco (ps3) and reversed the entire file and dropped your header on it.

RCOEdit identified the "French" language in the drop down list where no languages were listed before.

So that got me thinking and I reversed the entire original osk_plugin.rco (ps3) file and ran it through rcotool.

(original-reversed)
C:\Unixdos>rcotool -l test.rco
*.rco detected... fw ver: debug/1.00

Labels for 10 languages

Graphicfiles: 21
sabt0x0e  (.png)
sabt1x0e  (.png)
sabt2x0e  (.png)
sabt0x1e  (.png)
sabt1x1e  (.png)
sabt2x1e  (.png)
sabt0x2e  (.png)
sabt1x2e  (.png)
sabt2x2e  (.png)
sabt3x2e  (.png)
sabt0x3e  (.png)
sabt1x3e  (.png)
sabt2x3e  (.png)
sabt0x4e  (.png)
sabt1x4e  (.png)
sabt2x4e  (.png)
sabt0x1e  (.png)
sabt1x1e  (.png)
sabt2x1e  (.png)
_ksonoci  (.png)
apesetarpni_w_tuodniab_w  (.png)

Soundfiles: 2
_dnseksoretn  (.vag)
_dnscksoecna  (.vag)

Objectfiles: 0

What do we see?

Well straight away an identification to debug/1.0 firmware and 10 language labels found. Previously we found 16 language labels in xfcj's modified dlna_plugin.rco (ps3). We also have PNG graphics files Of course all the text is strange.

Then I ran your modified osk_plugin.rco (ps3) through rcotool.

(newfile)
C:\Unixdos>rcotool -l test.rco
*.rco detected... fw ver: 1.50-2.50

Labels for 10 languages

Graphicfiles: 21
tbase0x0  (.gim)
tbase0x1  (.gim)
tbase0x2  (.gim)
tbase1x0  (.gim)
tbase1x1  (.gim)
tbase1x2  (.gim)
tbase2x0  (.gim)
tbase2x1  (.gim)
tbase2x2  (.gim)
tbase2x3  (.gim)
tbase3x0  (.gim)
tbase3x1  (.gim)
tbase3x2  (.gim)
tbase4x0  (.gim)
tbase4x1  (.gim)
tbase4x2  (.gim)
tbase1x0_3L  (.gim)
tbase1x1_3L  (.gim)
tbase1x2_3L  (.gim)
osk_icon  (.gim)
separate_input_window_base  (.gim)

Soundfiles: 2
snd_oskenter  (.vag)
snd_oskcancel  (.vag)

Objectfiles: 0

What do we see?

What we expected. Normal fw detection, same languages but most importantly GIM graphics files.

I think this goes a long way to letting us assume we probably only have 2 img filetypes in this RCO to choose from.
---

Remember, there is no evidence that the RCO file format has changed too drastically. I have also learned that *some* previous RCO files were decompressable with different versions of gzip. The other compressor used was zlib. Can someone try extracting these 2 new files with different versions of gzip and zlib. I will attach both new files to this message for convenient and speedy testing.

xfcj:

Reversing this section of code changes GIM to PNG. Must be this section that is actual graphics files data.

0x4DE0 - 0x6B20

Attached Files

	osk_plugin-ps3-reversed.rar (13.9 KB, 4 views)
	osk_plugin-firstps3Editable.rar (13.8 KB, 5 views)

[xfcj]

@bigblockchev: In osk_plugin.rco 0x4DE0-0x66E8 is the image data and 0x66E8-0x78E8 is the sound data.

osk_plugin.rco has changed some things with the text section. All the psp RCOs used 2 bytes per character, but the PS3 osk_plugin uses 4 bytes per character. Also, the values of 0x10000-0x1000B are used to identify the language of the text in the psp RCOs, but the PS3 osk_plugin seems to use 0x20000-0x20009 posibly to signify that the text is encoded in 4 bytes instead of 2. dnla_plugin.rco has 0x10000-0x1000F for the languages, which means that Sony has added at least 4 more languages to the ps3.

I've also looked further into the page tables and fixed them up mostly. There's still some data that I don't know what it does, but it is somewhat sequential between the pages.

Attached is the fixed up dlna_plugin and osk_plugin.

Attached Files

Fixed_PS3_RCOs.zip (20.5 KB, 6 views)