Maybe some files that could be exploited are:
- /dev_flash/vsh/resource/silk_webkit/data/CEHtmlUI.bin
- /dev_flash/vsh/resource/silk_nas/data/CEHtmlUI.bin
- /dev_flash/vsh/resource/silk_nas/data/CEPhWeb.bin
- /dev_flash/vsh/resource/silk/data/CEHtmlUI.bin
- /dev_flash/vsh/resource/silk/data/CEPhWeb.bin
These files contain the HTML pages for the following errors:
- Request Timed Out
- Cannot find server
- Network Error
- The Cannot Be Displayed Error
- Page Unavailable Error
- Cannot Find Dns Error
- Network Setting Error
- SSL Version Error
- SSL Alert Handshake
- Request Timed Out
Before <!DOCTYPE you will find the size the of HTML code. I think it could be increased to handle a larger page size. Maybe the SWF file could be embedded as a base64 encoded data URI into one of these pages. Also javascript or embedded images could be used.
If that works, only the error should be triggered with a bad link in the bookmark.
We already looked into this briefly a couple of years ago, iirc at the time we found that there was an obstacle to using this method although I don't remember what it was exactly, I only recall doing a few tests & discussing it with esc0rtd3w & lmn7.
I think there should be some traces in the forum.
Of course it does not mean that it is not feasible, not in any way, just that we obviously decided not to push on in that direction at the time because it was not that straightforward.
The whole error redirection process deserves more research though, one would expect it to be exploitable & when there is a will there is a way.
I figured it out again.
Code:
src="wboard://localhost/list?type=psn&x=0"
So the key here is it needs to be reading them from the nsx xml (for SWF, PNG will read from USB), and it will only read the first column. So every third item will show up. 1, 4, 7, 10, etc.
The other thing is SWF files seem to only work from within a subfolder. I can not seem to get SWF working when on the root of a category, this ruins any chance of an auto HEN enabler with this method. PNGs will load in the root of a category.
Nice one, figuring this out again.. ;-)
So if I understand correctly, what we talked about is possible, we can launch a swf locally from /dev_usbxxx.
However what we cannot do is launch a swf from the root of any category (meaning no automatic swf launch after boot, the user would have to intervene manually with the pad). Is that right?
And seemingly, according to your socat logs, the browser is not in play at all for the rendering. I think I will have to look at the faust sprx to get some answers, or at least try to.. lol
You did that on OFW with a swapped sprx? If so, it confirms there is a way to run local Flash exploits using the Quick Preview, it is good news no matter how we look at it.
But it's weird how s#ny manages its revocation system, one would assume that a 4.84 DEX vsh module would be revoked on 4.88 CEX OFW to avoid exactly what we are looking into or HFWs like the ones using the old webkit, that is another example of the same gross security oversight.
They removed every possibility of running custom swf or browser files locally but they let you use an older DEX module that can run custom swf files locally, undoing most of their efforts. Oh dear..
They do quite well with the big complex parts of security features and yet they always manage to mess up the details.
