A brainstorming i just had... im going to write the deductive process that took me to this idea because otherway, if i only write a single line with the theory you are going to be a bit like "wtf, you build that theory from smoke" (and you would be correct), but i want to explain it a bit
Your brainstorming is like a real storm lol
I was thinking in the pages in wiki if creating one with the name "silk container", and the name SILKPADD
One thing im sure you agreee with me is the name SILKPADD is composed by 2 parts, we know "silk" is a codename, and the "magic" names are usually 4 bytes too... so ok, lets remove the SILK and think about what means PADD
While thinking if the new wiki page could be grouped with other "containers" formats it came an question to mind
Most of the time, it's bytes and in readable ASCII, however they are plenty of expections. I would prefer for it to be 8 bytes, SILKPADD, with the PADD added because SILK only could have been mixed with another file. Or maybe they just want to shift everything by 4 bytes (yeah, I know crazy idea, ignore me)
Why there is not a "C" in the "PADD" ?
Why should there be a "C" in PADD?
Most containers have one, i know this is not a golden rule, but then the next idea came to mind... what if SILKPADD is not a container ?
What should containers have one? And SILKPADD is without doubt a simple container.
The SILKPADD fileformat is simple, doesnt even allows for any type of compression like most other containers
Perhaps there was no need for compression, and it's not that simple, it is obviously tweaked a bit. And we still do not fully know some details, especially in the header.
And then... i had a transcendental experience where mr. sony told me the truth
But... why didn't you ask him about the latest private keys?!
PADD is composed by 2 words, there are 3 ways to dedicate characters for 2 words:
-PAD D
-PA DD
-P ADD !!! Is typical in composed codenames to use only the first character of the first word, and severals characters of the second (as example, for "sandungas brainstormings" in 4 characters SBRA)
I get your point but but it could still be that each letters represents something.
P would be interesting. Packed?
D - Data?
P = program
ADD = address
Possible but not probable. ADD seems good but P for program does not really convince me to be honest. I see no program inside this container.
So... SILKPADD is the Program ADDress of SILK (the web browser)
So... the IDs associated with the entries in the index of the SILKPADD fileformat are the addressess ?
Addresses of the program memory ?
That sounds good but again, highly unlikely. Doubt them to be memoery address. They are certainly ID for getting the proper entries. The corresponding string for that ID can be found inside silk***,sprx files.
But the way i see at it now is better defined as a "memory map", not an exact 1:1 copy of memory, but a list that indicates where the datas are going to be "copypasted" to memory
This is why some of the datas (CEMenu, CEdialog) are very complex
Imo, it is simplier than that. It just takes the proper entry and parses it. CEMenu and CEDialog are a bit complex but overall simple. They just keep the needed info about a dialog.
Edit2:
Hmmm, as i mentioned in other post before (but i was not explicit enought, sorry) every "children" of the CEDialog have an unique ID
This is an additional ID (not located in the index like the others shown in the "silkpadd editor" made by NewFile)
Each children has a unique children and this children is linked to the main object. But the editor has nothing ot do with this since it solely edits the container and not further parses stuff(although we do it)
Lets say... we have a CEDialog, with an ID in the index (lets call this one the "main ID")
And CEDialog have 2 childrens named CEButton
What i was trying to explain is this CEButton has his own unique ID
Incase it had more childrens, all them would have unique IDs, without exception. It can be said that everything under the CEDialog hierarchy seems to be accuratelly mapped using unique IDs
I have done some reversing to this and CEDialog and CEMenu as quite similiar. Hovever, it is certainly needed to actually display a Dialog and Menu and tweaked some values to confirm what they are. Right now, it has type of entry, width, size, component type, hotkey string and probably more.
Maybe this IDs are used also as "memory address positions" where every one of them needs to be copypasted
As far i remember for the few time i was looking at this... all this IDs are consecutive, and increases in a amount of 1 each
As example... 234, 235, 236, and so on
The id can in fact even be the height, or position. These items are linked in a strange way together. But we need to actually show a Menu or dialog to see what happens.
Eitherway, I have my own theory of all this. Our first problem, is the webrowser itself. In regards to say, I am going to say:
The PS3 has no web browser.
Before you crucify me(dude what the hell, we can surf the net with it) you should read till the end.
The PS3 has only a browser engine, a browser object, control. This object seems to be used by games and the system itself for different purposes.
It contains two versions: Silk and WebKit.
Silk is a rather "limited" version but more powerful as it allows more controller by the programmer. Silk does have Javascript enabled.
Webkit is more advanced and with more options.
When we open the web browser in the PS3 we are not launching an app by no means. We are doing the same thing that developers do when they launch the browser ingame.
We are launching a web engine in a "box" with parametrs taken form xRegistry.sys and other places. We later control that "box" by sending commands to it, again, just like the developers do it.
PADD mostly stand form the PAD, the screen, the view, the real box when the page is displayed when surfing the net. The extra D could had been added to fill the 4 bytes. Or if you follow google:
http://memory-alpha.wikia.com/wiki/PADD (ignore the random site, it gave a good idea)
Personal Access Display Device , hence the "box"
What proof do I have for this:
Well for a start none of the user options(addres bar, Menu settings) is inside it, but they are added in top or to left of it.
SILKPADD contains only strings and resources which display only inside ths box. Boomarks, Size, File, Save As, etc,... such string we never find in any of the SILKPADD files.
This means that SILKPADD is indeed a container for the engine itself!
The pseudo browser wokrs by launching this "box" just like in a game and communicating with it, again just like game developers. The Menu: Vien, Size, etc.. is in fact found in webrowser.rco and webbrowser.rco. Anything you see outside the box, icons of browser setting, the SSL icon, the trendmicro icon is in fact located in these rco files and not in SILKPADD files.
The bookmarks, settings etc are never treated by a browser. The XMB or whatever plugin is reading all these things stored in the hdd and registry file and is communicated back and forth with the "browser", aka the box.
I do not know if we can mod these rcos. My theory of another debug menu somewhere was correct, inside the rco you can find
Code:
<Item name="opt_debug_item_selftest_localfile"
Hehe,
Plus a dozen other debug options. There is an entire page for debugging, but I do not know how to active it. Those decrypted rcos are so text lengthy that I can get lost in it,
@sandungas , we need your brainstorming here.
We can attack the engine from the inside SILKPADD and from the outside RCO and other commands. From the inside can prove cool enough. You can use a game which launches it and then replace the error code with a HTML/JS trainer for modding, cheats.
From outside we have to explore further, but I have a dozen of things in mind.
