Editing Talk:XMB Layouts
Jump to navigation
Jump to search
The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then publish the changes below to finish undoing the edit.
| Latest revision | Your text | ||
| Line 23: | Line 23: | ||
The way how works the XMB layout references inside rco files has been documented before, but the way how works inside the sprx files has been just an unproven theory since many time ago. This experiment is a sample of how it works, it throws an small ray of light at how the sprx files applyes "patches" over the [[RCOXML Objects]]<br> | The way how works the XMB layout references inside rco files has been documented before, but the way how works inside the sprx files has been just an unproven theory since many time ago. This experiment is a sample of how it works, it throws an small ray of light at how the sprx files applyes "patches" over the [[RCOXML Objects]]<br> | ||
The theory behind this experiment is based on the hipotesys that in between 4.88 and 4.99 there was maaaaany sprx files where the only thing that was updated in them is just a couple of bytes "here and there" that are the references to a line number of the XMB layout files, and the hipotesys that there are many times where the rco is storing the values inside the XMB layouts consecutivelly (so it could happen that the rco and the sprx could store all his values consecutivelly). So for this experiment it was needed to find a guinea pig where both, the sprx and the rco was updated in 4.89, also his function should be something trivial just to be sure sony was not trying to update anything important, and the last consideration was to find the files with the smallest size posible just to simplify the research with hexeditors/IDA... and the winner | The theory behind this experiment is based on the hipotesys that in between 4.88 and 4.99 there was maaaaany sprx files where the only thing that was updated in them is just a couple of bytes "here and there" that are the references to a line number of the XMB layout files, and the hipotesys that there are many times where the rco is storing the values inside the XMB layouts consecutivelly (so it could happen that the rco and the sprx could store all his values consecutivelly). So for this experiment it was needed to find a guinea pig where both, the sprx and the rco was updated in 4.89, also his function should be something trivial just to be sure sony was not trying to update anything important, and the last consideration was to find the files with the smallest size posible just to simplify the research with hexeditors/IDA... and the winner combo is... eula_hcopy_plugin.sprx (27 KB) / eula_hcopy_plugin.rco (60 KB) | ||
The samples below are stripped versions from the main XML file generated by rcomage, where has been left only: the [[RCOXML Objects|RCOXML Object name]] (e.g: <IList>), the unique name (e.g: list_eula_start), and the attribute that difers in between 4.88 and 4.89 (the "overrides", responsibles of loading a value from a line of the XMB layout .txt files) | The samples below are stripped versions from the main XML file generated by rcomage, where has been left only: the [[RCOXML Objects|RCOXML Object name]] (e.g: <IList>), the unique name (e.g: list_eula_start), and the attribute that difers in between 4.88 and 4.89 (the "overrides", responsibles of loading a value from a line of the XMB layout .txt files) | ||
XMB layout references in eula_hcopy_plugin.sprx 4.88 | XMB layout references in eula_hcopy_plugin.sprx 4.88 | ||
| Line 147: | Line 143: | ||
</syntaxhighlight>}} | </syntaxhighlight>}} | ||
In total there are 11 attributes updated in between 4.88 and 4.89 in eula_hcopy_plugin.rco but some of them contains the same hex value (for optimization purposes, are references to the same line in the XMB layout files) | |||
If we count only the unique values (to get an idea at how much lines this rco is using from the XMB layout files) we have a total of 6 references to the XMB layouts | |||
The references to the XMB layouts in the xml file generated by rcomage are in little endian, to convert them to "human readable" needs to be splitted in 2 chunks of 2 bytes each, first chunk is the "grid" and second chunk is the "factor". In this sample it can be seen how all the references to the "grid" was increased in +7 units<br> | |||
In firmware 4.89 this rco is storing 4 values consecutivelly at lines 3399, 3400, 3401, 3402. And additionally is storing another 2 values at lines 4351 and 4353 (not consecutivelly, there is a gap in between them used by something else) | |||
---- | |||
When comparing the (decrypted) 4.88 and 4.89 versions of eula_hcopy_plugin.sprx there are only 2 bytes that differs (that belongs to 2 values of 2 bytes length each) | |||
In the "human readable" conversion for rco values im adding a +1 because in code the first line of a .txt file is line 0, but in a text editor the first line is 1... so im guessing is also neeed to do this +1 addition in the values from the sprx<br> | |||
The 2 bytes updated in this sprx for 4.89 are the references to the XMB layouts, and both are a references to the same line number of the XMB layouts, so this sprx only stores a single value in the XMB layouts (located 3 lines before the values stored by the associated rco)<br> | |||
From this behaviour in the order of how the values are stored in the XMB layouts we can deduce that "the sprx stores first" (and the slave rco stores last) but maybe this is just a coincidence and not an strict rule | |||