thats great!!
do we no longer need to re enable Han every time? , i hope only once offline with a system update that been edit and injected with Han
I am afraid that no matter how advance the scene gets in the HAN field, it always require at least one small amount of time for activation,triggering in a way or another.
Also, if im right... i think is better to display the info in the GUI with the ID most at left, in this order:
ID - start - size - data
That has been done. You can now even sort the column. this can provide useful to the eye to see any sort of pattern.
Also, for the "size" i think is better to display the size of the real data (instead of the size that appears in the index)
I have not changed this yet. All I have to od is subsctract 4 from the current size but that can be confusing for data which is not text.
For better documentation, as obviously editing one of or more of those 64kb max pages to get a different outcome is only interesting if you can load it/them, it could be very helpul to add ways to trigger each error whether it's a js command or a setting to change.
True, someone needs to document all the cases when those errors happen.Not neccesary errors though. What do you think 64Kb at max?
For a fast test, search for this pattern (this is what i did to realize how much it was matching with the others and to crop some images manually): 0x00000008434542696E617279000000000009696D6167655C706E67
It contains the "CEBinary" and is repeated 14 times (one for every PNG file)
After it comes 4 bytes that indicates the size of the PNG file, so basically the structure is this:
0x00000008434542696E617279000000000009696D6167655C706E67
4 bytes (indicates PNG size)
lot of bytes (the PNG file)
And so on...
So for rebuilding purposes we dont really need to know how it works, because is static
Is better to find how it works, sure, and i think you re on the good road
To think about this is better to think in how the file is processed by the PS3
When the PS3 reads the "index table" it doesnt know (yet) if the data is a string or a file
So... the next step, when processing the first bytes of the metadata for the "data" entry is common (for strings and files)
This is the point where the PS3 realizes if what is reading is a string or a file
Doing binary searches for known patterns is bad. We have to fully understand this. The file from the PS3 is most likely processed in this way:
The data is needed from a specific ID. The index table is searched for that ID. Even if we adding the same ID more than once it would probably get only the first one. Then data is extracted given the start position and size.
That's it. Here we should stop talking about these .bin contains. That's all they do. Their structure is so simple. The contina itself know nothing about HTML, string, encoding, images or whatever. It simply holds these entry.
The extract data(buffer) is then parsed by the browser. Again, we no longet have anything to do with webcoreapp.bin at all! The browser modules should check the first 4 bytes and calculate the sum.
If the calculated size is = buffer size - 4 bytes, then it's a string, the 4 bytes are removed and the remaing bytes are further processed, encoding etc...
If the calculated size < buffer size - 4 bytes , then the browser know that it's not a string. But it must know the file type. The file type comes from the first string immediately after the 4 bytes with the calculated size.
To further proceed we need to know the supported filetypes: Right now we know:
CEBinary
CEDialog - No much is know about this, but it seems to contains CELabel , CEButton, etc.. So far only found in one of the .bin in the silk folder.
If it is CEBinary, then we have 4 more bytes for calculating size and then we have another string, image\png, image\gif, image\gifPushed. So that, these are the one I know. After than , 4 more bytes for the size of the real and true data and then the data. This is hte only way the browser can functions.
Not sure if i got what you mean, but i think there are only 12 error messages (repeated for 20 languages), and not so sure how much useful are going to be the others, im not sure when are triggered
As I said above, we don't have to limit ourselves to errors only.
The most important "unknown" at this point are the IDs for every entry... are obviouslly IDs because the PNG files doesnt have a filename (so there is no other way to identify PNG files, other than his ID, or his position inside the webcoreapp.bin structure, but identifying them based in the position is retarded, sony would not do this... so yeah is an ID for sure)
I guess is the web browser who "searches" for this IDs but how is made ?, maybe there is a huge list of IDs somewhere in the source code, or are working as references, or dunno
Knowing that could unlock some surprises
Yes, there are certainly IDs. No position based thing here. The web brwoser does check about the ID. If you would like to know the equivalent string value of ID, you can decrypt silk.sprx, silk_webkit.sprx and extract the string for them. You will get some really cool stuff, something llke msg_error_certificate invalid etc..
Edit: i mean... by adding to the file other IDs (to do different things), either to display text messages, or to load files
We can add and change but we need to tell the browser which ID to get, and right now we can only change the ID data.
NewFile mentioned one (GIF support), im wondering where you found this ?, you mentioned other files but which ones ?
There are in there. In the other .bin files. You can tell from the next string aster CEBinary , we had a image\gif in there.
Btw... can you make a list of other files using this same structure ?
Pretty much all the .bin files in silk, silk_nas and silk_webkit folder. Thanks
@esc0rtd3w . We might try to dig in older firmwares to see what we get.
This is something important to know to decide how to publish all this info in wiki, by now it could fit in a wiki page named "Silk container"... but only if the other files shares the magic "SILK" (or "SILKPADD")
Silk Container seems good enough,. All other files contain SILKPADD. IF they do not the editor will refuse to load it.
For instance, one of them (iirc, it's the first "The page cannot be displayed" error in the bin file) seems to be triggered when you load a page from an existing ip address but without server listening on the expected port.
As a matter of fact, that error also gives the specific error ID so idifferent type of errors can lead to that single page.
Currently, I think this method is the best choice we have for a local exploit implementation. Unlike bookmarks & other methods to persist the data that can be used to achieve the same kind of goal but under heavy constraints, webcoreapp.bin proves a reliable way to store up to 64kb of code. Additionally, webcoreapp.bin cannot be erased accidentally by the user.
Why 64kb at max?
Now to implement something decent, we need to find ways to trigger not just one but all those errors, like I explained above. If we do find appropriate js trigger calls, with 12 error pages, I could make a local toolset with up to 10 or 11 local exploit pages 4.0 style which each require between 128kb & 192kb once optimised & minified. The local toolset could even easily be multilingual as error pages are already implemented in several languages in the bin file, loading according to the xmb language settings.
Yes, it can be multilinguar but you do not really need to have different 10 or 11 pages. Yo ucan have different ones, one for dumping, one for flashing, one for HAN etc. You can still keep a lot of code in an erorr entry and use tricks like CSS display:none, to mae a kind of menu, like the user is actually navigating , when it's just one page.
