PS3 [Research] LINK.XML information

Well, if the HEN Enabler js fails to launch when opened from link.xml, someone should maybe try in DEX with the Target Manager connected on PC (Rebug REX 4.84 & HEN Enabler 4.84 js). The TM console output should display the js errors IF there are errors.. And if there is none there (unlikely), the debug HEN payload should hopefully give enough UDP logs to get an idea of the problem.


Coro said:
you can pick the one with javascript support using "webkit=1". links to online html with js work...but xml-like enablers i have not seen working.
Click to expand...
That right, I forgot about that. ;-)
 
Last edited:
Offline JS definitely works via LINK.XML.

For example this works. (pkg attached)

Code: 
<link ver="1.0" webkit="1">
<url>javascript:window.resizeTo(1920,1080);eval('document.write(\47\74html\76\74body\76\74style\76html{left:-100%;position:relative;overflow:hidden}body{left:-100%;margin:0 0;}img{left:100%;position:relative;height:100%;}\74/style\76\74center\76\74img src="http://devil303.com/Ultimate_Toolbox/ps2_demo_covers/ops2m19se_full.jpg"/\76\74/center\76\74input autofocus type="radio" style="position:fixed;right:0;bottom:0;"/\76\74/body\76\74/html\76\47)');</url>
</link>

This simple example just moves the cursor to the bottom left, and shows an online PS2 cover image full screen with a transparent background. So offline JS definitely works, just not the HEN enabler for some reason. I know the enabler is a lot more complex though.
 

Attachments

Last edited:
esc0rtd3w said:
oh! awesome :) good to know
Click to expand...
Seems it only allows up to 2KB of offline JS to be loaded locally, Not sure if that is enough to do anything interesting. Do you know would 2KB be enough to get an exploit started that then loads more JS from an external file in the folder with the LINK.XML?

It would be cool if we could load large exploits from these WT (LINK.XML) "apps" as they survive FW reinstalls.
 
DeViL303 said:
Seems it only allows up to 2KB of offline JS to be loaded locally, Not sure if that is enough to do anything interesting. Do you know would 2KB be enough to get an exploit started that then loads more JS from an external file in the folder with the LINK.XML?

It would be cool if we could load large exploits from these WT (LINK.XML) "apps" as they survive FW reinstalls.
Click to expand...
I don't think it can be done in 2kb without some new exploit first enabling the browser to load local files, directly or indirectly.
Even if one managed to make a chain that loaded a file in memory using ROP in less than 2kb with the accompanying offsets & exploit code (I doubt it), the old exploit code used by HEN is only a one time per session ROP trigger, it cannot interact with javascript as is, the code is obsolete, it cannot load a file using ROP & make its data available to js then return execution to webkit until the ROP trigger is called again, like the js framework used in the Toolset (120kb minified) does.
On its own, the additional code necessary to do something similar would be way bigger than 2kb anyway, even minified..
 
Last edited:
DeViL303 said:
Ah, ok, well that's that then.

Sure being able to load online exploits via LINK.XML is a small step forward anyway.
Click to expand...
Sure.
Maybe something better will come along the day someone takes the time to RE the web browser utility to find out how exactly the local file system support gets enabled at browser startup, using that information we may be able to somehow fool the browser.
But in the meantime, as you all know, those esp8266 dongles to host the exploit files & serve them over http with a tiny Web server are cheaper than ever (5 to 10 bucks) & do a great job.
They can be used to serve exploits on the PS3 & on the PS4, they should serve us well on PS5 too.
A good investment for 5 bucks imho.
 
except the esp is extremely limited in terms of how much data it can handle. it's in the low MBs. I have a sandisk connect for the ps4, and it can handle about 8GBs, which is more than enough. esp stuff can't handle much, possibly not the xproject which I've been modding, since it's like 45MBs. I wouldn't trust it with the ps5. it can barely do the ps4.

you can compress stuff with the esp, I believe, though. orbis toolbox, for example, is about 446KBs, but can be compressed to around 150KBs, according to my friend who does esp builds of the ps4 hosts/payloads. I think the esp only has around 2MBs worth of space or so, so most things have to be sacrificed. they're cheap though. I think I bought my sandisk connect for around $10 when 8GBs existed. I don't think they sell them that small anymore, so they could be $20+ for 64GBs+. you only need whatever is smallest, since you won't be dumping games with it.
 
Last edited by a moderator:
All you need on the esp is the html & js to exploit webkit (and breakout of the userland "jail" in which webkit lives when there is one), everything else can be loaded through other means as soon as userland code execution via ROP is obtained, it's only a matter of organisation, and that is true on ps3, ps4 & ps5.
 
Last edited:
yeah, you can have bin loader, I guess. that should work for anything. I heard you can't compress hen though. I think the full size of esp is 2.6MBs to be exact.

speaking of ps5, I read that the compression is very good with games unlike the ps4 which has extremely bad compression, hence the reason some games are much bigger than they need to be.
 
@
bguerville said:
Sure.
Maybe something better will come along the day someone takes the time to RE the web browser utility to find out how exactly the local file system support gets enabled at browser startup, using that information we may be able to somehow fool the browser.
But in the meantime, as you all know, those esp8266 dongles to host the exploit files & serve them over http with a tiny Web server are cheaper than ever (5 to 10 bucks) & do a great job.
They can be used to serve exploits on the PS3 & on the PS4, they should serve us well on PS5 too.
A good investment for 5 bucks imho.
Click to expand...
congrats on bg toolset (when it comes out)
 
Sorry to necro this thread but just FYI for anyone not aware. The smaller (2KB) limitation seems to be imposed only on LINK.XML for both Silk and Webkit. I remember testing both browsers years ago with many methods, and I discovered that the Silk browser accepts a longer module_action string than the Webkit browser. I don't know the exact limit though and at the time this didn't matter much to me, seeing as how the single exploit we had only worked in the Webkit browser.

This info isn't particularly useful for what the current objective seems to be but I thought it was worth mentioning in case anyone wants to take a deeper look.
 
lmn7 said:
Sorry to necro this thread but just FYI for anyone not aware. The smaller (2KB) limitation seems to be imposed only on LINK.XML for both Silk and Webkit. I remember testing both browsers years ago with many methods, and I discovered that the Silk browser accepts a longer module_action string than the Webkit browser. I don't know the exact limit though and at the time this didn't matter much to me, seeing as how the single exploit we had only worked in the Webkit browser.

This info isn't particularly useful for what the current objective seems to be but I thought it was worth mentioning in case anyone wants to take a deeper look.
Click to expand...
FYI
Not sure if you know this but the Flash 9 player plugin is supported by both browsers.

Over 18 months ago, I implemented a few replacement exploits for my Toolset project among which 2 versions of a same Flash 9 exploit, one for the PS3 Silk browser (no webkit) & one for the PS3 Silk Webkit browser.

This exploit is an "all in one", it can leak memory & it can be used to trigger ROP too. For the moment, I am keeping it safe in case s#ny decides to patch browser bugs in a future update, unlikely but you never know..
Anyway, all this to say that we could potentially use either of the 2 browsers if we had to, I have already confirmed as much privately when I executed custom ROP chains at will from the Silk (no webkit) browser at the time.

Also the Flash player is used directly in other XMB GUI features, not just in the browsers, a Flash exploit might be usable in those too, DeViL303 provided us with files to test the concept just a few weeks ago, unfortunately I have not had time to look into it yet, but I think it should work.
 
Last edited:
Hi, hope you're all well. Firstly I'd like to say thank you for your work and contributions! I'd like to ask some questions about LINK.xml. I've created PS3 and PSP portals which I have big ambitions for. I've attempted to create a pkg for the PS3 version which creates a web link on the xmb yadayada.. I've utilized the code mentioned here, my portal must use webkit. I've managed to get it running but only from the TV/Video Services category. When I attempt to change the category in PARAM.SFO to CB Network it throws up a display settings error. I've read everything in this thread and cannot find anymore information, perhaps I'm fundamentally misunderstanding something here? Cheers!
 
youdontfooljesus said:
Hi, hope you're all well. Firstly I'd like to say thank you for your work and contributions! I'd like to ask some questions about LINK.xml. I've created PS3 and PSP portals which I have big ambitions for. I've attempted to create a pkg for the PS3 version which creates a web link on the xmb yadayada.. I've utilized the code mentioned here, my portal must use webkit. I've managed to get it running but only from the TV/Video Services category. When I attempt to change the category in PARAM.SFO to CB Network it throws up a display settings error. I've read everything in this thread and cannot find anymore information, perhaps I'm fundamentally misunderstanding something here? Cheers!
Click to expand...

It will only work in this category column.
 
You must log in or register to reply here.

Similar threads

Back
Top