Page 7 of 7 FirstFirst ... 567
Results 61 to 69 of 69



  1. #61
    Registered User bigblockchev's Avatar
    Join Date
    Aug 2007
    Posts
    36

    Wink Progress

    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 Attached Files

  2. #62
    Registered User xfcj's Avatar
    Join Date
    Apr 2005
    Posts
    4
    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.

  3. #63
    Banned User
    Join Date
    Jan 2008
    Posts
    27
    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....

  4. #64
    Registered User almar's Avatar
    Join Date
    Jul 2005
    Posts
    6
    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?

  5. #65
    Registered User bigblockchev's Avatar
    Join Date
    Aug 2007
    Posts
    36

    Post Research results...

    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.
    Code:
    ---
    *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

  6. #66
    Contributor Kantraz's Avatar
    Join Date
    Dec 2007
    Posts
    13
    Quote Originally Posted by SniprSnake View Post
    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

  7. #67
    Registered User xfcj's Avatar
    Join Date
    Apr 2005
    Posts
    4
    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 Attached Files

  8. #68
    Registered User bigblockchev's Avatar
    Join Date
    Aug 2007
    Posts
    36

    Lightbulb Progress

    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.
    Code:
    (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.
    Code:
    (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 Attached Files

  9. #69
    Registered User xfcj's Avatar
    Join Date
    Apr 2005
    Posts
    4
    @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 Attached Files

 


 
Page 7 of 7 FirstFirst ... 567

Tags for this Thread