Talk:Resource Container (RCO): Difference between revisions
m (→Examples) |
|||
| Line 370: | Line 370: | ||
<div style="height:500px; overflow:auto"> | <div style="height:500px; overflow:auto"> | ||
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F | Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F | ||
00000000 <span style="background:#666666;">46 52 50 00</span> <span style="background:#666666;">00 00 01 30</span> <span style="background:#666666;">00 00 00 00</span> <span style="background:#666666;">00 00 00 00</span> FRP....0........ | |||
00000000 46 52 50 00 00 00 01 30 00 00 00 00 00 00 00 00 FRP....0........ | |||
00000010 00 00 00 A4 FF FF FF FF FF FF FF FF FF FF FF FF ...¤ÿÿÿÿÿÿÿÿÿÿÿÿ | 00000010 00 00 00 A4 FF FF FF FF FF FF FF FF FF FF FF FF ...¤ÿÿÿÿÿÿÿÿÿÿÿÿ | ||
00000020 FF FF FF FF 00 00 00 CC FF FF FF FF FF FF FF FF ÿÿÿÿ...Ìÿÿÿÿÿÿÿÿ | 00000020 FF FF FF FF 00 00 00 CC FF FF FF FF FF FF FF FF ÿÿÿÿ...Ìÿÿÿÿÿÿÿÿ | ||
Revision as of 20:14, 10 September 2016
RCO versions
All RCO files contains a version number, the version increases with bigger firmwares but not for every firmware and is not directly associated with it. The same versioning method is used in PSP and PS3 RCO's
It seems all the RCO's of a specific firmware shares the same version (verifyed for firmware 4.76) and seems to be the version of the "rco set", or the version of the "rco tool" used to compile the whole "rco set". RCOmage v1.1.1 (latest stable) identifyes the version with a list of hardcoded values
Code Sample
After extracting the contents of the RCO with RCOmage, the version is stored for rebuilding purposes in the RCOXML descriptor file as an attribute with the name minFirmwareVer
If the version is unknown is stored as unknownId0x%x using unknownId to specify the fact that is unknown + the real hex value 0x%x
Example... sysconf_plugin.rco from PS3 firmware 2.00 with version 0x106
Code Sample
Hashreports
PS3 all versions
all OFW 1.00-4.75 hashes: https://www.mirrorcreator.com/files/7KCMQKWQ/RCO-hashreport.7z_links <--- please someone convert this in a "human readable wiki table"
PSP 6.61
- PSP 6.60 and 6.61 firmware contains 63 .rco files (same files for both firmwares). Two of them are specific for PSPgo model (bluetooth_plugin.rco, slide_plugin.rco)
- Only 10 of them are compresed with ZLIB (dd_helper.rco, dnas_plugin.rco, htmlviewer_plugin.rco, lftv_rmc_univer3in1.rco, lftv_rmc_univer3in1_jp.rco, lftv_rmc_univertuner.rco, lftv_rmc_univertuner_jp.rco, lftv_tuner_jp_jp.rco, lftv_tuner_us_en.rco, oneseg_plugin.rco). All the others are compressed with RLZ (and RLZ decompression is not supported by rcomage, is needed to use Resurssiklunssi v0.3 to rebuild them)
- Resurssiklunssi rebuilds the .rco files and allows for two rebuild modes:
- TRIANGLE or CROSS - only rebuilds
- The converted files will have minFirmwareVer="1.5" (the original value is lost in the conversion)
- SQUARE or CIRCLE - rebuilds and recompress in ZLIB
- The converted files will have minFirmwareVer="2.6" (the original value is lost in the conversion)
- TRIANGLE or CROSS - only rebuilds
Code Sample
- PSP 6.60 and 6.61 firmware. RCO hashes after resurssiklunssi rebuild (cross option)
Code Sample
- PSP firmware 1.00 contains only 21 .rco files (all them uses ZLIB, none of them uses RLZ)
Code Sample
Examples
This is a temporal section for tests using rcomage to create frankensteins .rco files smallest as posible that could serve as an explain of his structure. Will contain the source xml file used to create the rco, a big table with ALL the values of the structure, and a sample in hexview of the created rco. Eventually one (or a couple) of this tables will be moved to front page but by now this is a shared notepad and experimentation to see how to make that tables intuitive, pretty, and smallest posible, feel free to add other examples
Also, i think rcomage has several problems (no offense intended is a great tool everybody loves) in how the areas of the structure are divided, some names that can be improved, some definition of lengths of partially known or unknown values, etc... the examples are going to look pretty similar to the examples i wrote at the bottom of CXML Containers page (the concept of how it works is the same)--Sandungas (talk) 18:48, 10 September 2016 (UTC)
ImageTree with 1 image
The .xml below is the RCOXML source file used to create the .rco. The file image_test.gim is a dummy of 16 bytes filed with 88888888888888888888888888888888
Code Sample
When compiled
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 00000000 46 52 50 00 00 00 01 30 00 00 00 00 00 00 00 00 FRP....0........ 00000010 00 00 00 A4 FF FF FF FF FF FF FF FF FF FF FF FF ...¤ÿÿÿÿÿÿÿÿÿÿÿÿ 00000020 FF FF FF FF 00 00 00 CC FF FF FF FF FF FF FF FF ÿÿÿÿ...Ìÿÿÿÿÿÿÿÿ 00000030 FF FF FF FF FF FF FF FF 00 00 01 34 00 00 00 00 ÿÿÿÿÿÿÿÿ...4.... 00000040 00 00 01 34 00 00 00 14 00 00 01 48 00 00 00 00 ...4.......H.... 00000050 FF FF FF FF 00 00 00 00 00 00 01 2C 00 00 00 08 ÿÿÿÿ.......,.... 00000060 FF FF FF FF 00 00 00 00 FF FF FF FF 00 00 00 00 ÿÿÿÿ....ÿÿÿÿ.... 00000070 FF FF FF FF 00 00 00 00 FF FF FF FF 00 00 00 00 ÿÿÿÿ....ÿÿÿÿ.... 00000080 00 00 01 48 00 00 00 10 FF FF FF FF 00 00 00 00 ...H....ÿÿÿÿ.... 00000090 FF FF FF FF 00 00 00 00 FF FF FF FF FF FF FF FF ÿÿÿÿ....ÿÿÿÿÿÿÿÿ 000000A0 FF FF FF FF 01 01 00 00 00 00 00 00 00 00 00 00 ÿÿÿÿ............ 000000B0 00 00 00 28 00 00 00 01 00 00 00 00 00 00 00 00 ...(............ 000000C0 00 00 00 00 00 00 00 00 00 00 00 00 04 00 00 00 ................ 000000D0 FF FF FF FF 00 00 00 00 00 00 00 28 00 00 00 01 ÿÿÿÿ.......(.... 000000E0 00 00 00 00 00 00 00 00 00 00 00 28 00 00 00 00 ...........(.... 000000F0 00 00 00 00 04 01 00 00 00 00 00 08 00 00 00 28 ...............( 00000100 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000110 00 00 00 28 00 00 00 00 00 00 00 00 00 05 01 00 ...(............ 00000120 00 00 00 10 00 00 00 00 00 00 00 01 00 00 00 F4 ...............ô 00000130 00 00 00 00 74 65 73 74 00 00 00 00 69 6D 61 67 ....test....imag 00000140 65 5F 74 65 73 74 00 00 88 88 88 88 88 88 88 88 e_test..ˆˆˆˆˆˆˆˆ 00000150 88 88 88 88 88 88 88 88 ˆˆˆˆˆˆˆˆ
| Offset | Length | Example | Name | Notes | |
|---|---|---|---|---|---|
| 0x00 | 0x04 | FRP | magic | FRP in big endian | |
| 0x04 | 0x04 | 00 00 01 30 | version | 0x130 = one of the firmwares for PS3 | |
| 0x08 | 0x04 | 00 00 00 00 | unknown | ||
| 0x0C | 0x04 | 00 00 00 00 | compress_header | 0x00 = uncompressed | |
| 0x10 | 0x04 | 00 00 00 A4 | info_table_offset | ||
| 0x14 | 0x04 | vsmx_table_offset | |||
| 0x18 | 0x04 | text_table_offset | |||
| 0x1C | 0x04 | sound_table_offset | |||
| 0x20 | 0x04 | model_table_offset | |||
| 0x24 | 0x04 | image_table_offset | |||
| 0x28 | 0x04 | unknown | FF FF FF FF | Always seems to be 0xFFFFFFFF | unknown_table_offset ? |
| 0x2C | 0x04 | font_table_offset | |||
| 0x30 | 0x04 | object_table_offset | |||
| 0x34 | 0x04 | anim_table_offset | |||
| 0x38 | 0x04 | text_table_offset | |||
| 0x3C | 0x04 | text_table_length | |||
| 0x40 | 0x04 | label_table_offset | |||
| 0x44 | 0x04 | label_table_length | |||
| 0x48 | 0x04 | native_table_offset | |||
| 0x4C | 0x04 | native_table_length | |||
| 0x50 | 0x04 | text_pointer_table_offset | |||
| 0x54 | 0x04 | text_pointer_table_length | |||
| 0x58 | 0x04 | image_pointer_table_offset | |||
| 0x5C | 0x04 | image_pointer_table_length | |||
| 0x60 | 0x04 | model_pointer_table_offset | |||
| 0x64 | 0x04 | model_pointer_table_length | |||
| 0x68 | 0x04 | sound_pointer_table_offset | |||
| 0x6C | 0x04 | sound_pointer_table_length | |||
| 0x70 | 0x04 | object_pointer_table_offset | |||
| 0x74 | 0x04 | object_pointer_table_length | |||
| 0x78 | 0x04 | anim_pointer_table_offset | |||
| 0x7C | 0x04 | anim_pointer_table_length | |||
| 0x80 | 0x04 | image_data_section_offset | |||
| 0x84 | 0x04 | image_data_section_length | |||
| 0x88 | 0x04 | sound_data_section_offset | |||
| 0x8C | 0x04 | sound_data_section_length | |||
| 0x90 | 0x04 | model_data_section_offset | |||
| 0x94 | 0x04 | model_data_section_length | |||
| 0x98 | 0x04 | unknown | Always seems to be 0xFFFFFFFF | unknown_data_section_offset ? | |
| 0x9C | 0x04 | unknown | Always seems to be 0xFFFFFFFF | unknown_data_section_length ? | |
| 0xA0 | 0x04 | unknown | Always seems to be 0xFFFFFFFF | ||
| 0x00 | 0x01 | hierarchy_depth | main table uses 0x01, may be used as a current entry depth value | ||
| 0x01 | 0x01 | entry_type | 0x1=MainTree 0x2=ScriptTree 0x3=TextTree 0x4=ImageTree 0x5=ModelTree 0x6=SoundTree 0x7=FontTree 0x8=ObjectTree 0x9=AnimTree |
||
| 0x02 | 0x02 | unknown | Always seems to be 0x0000 | ||
| 0x04 | 0x04 | entry_label_offset | Offset to the label (relative to the label table). 0xFFFFFFFF means the label doesn't exist for this entry | ||
| 0x08 | 0x04 | entry_header_size | sizeof(RCOEntry) = 0x28 [ only used for entries with extra info (ie not "main" entries) ] | ||
| 0x0C | 0x04 | entry_size | main tables (main/img etc) uses 0x28 here, or is this the length of current entry (not including subentries)? | ||
| 0x10 | 0x04 | children_number | |||
| 0x14 | 0x04 | next_entry_offset | next_brother_offset ? | ||
| 0x18 | 0x04 | previous_entry_offset | this is usually 0x0 however (does make writing RCOs easier though :P I guess Sony's tools do something similar...) | previous_brother_offset ? | |
| 0x1C | 0x04 | parent_offset | offset of this entry from parent table 0x20 | ||
| 0x20 | 0x04 | unknown | Always seems to be 0x00000000 | ||
| 0x24 | 0x04 | unknown | Always seems to be 0x00000000 | ||