Archaemic wrote:Yeah, there are a handful of modules floating around below 0x82000000 that I dumped a while ago. I guess their location can change though.
As for memory mapping, the Vita most definitely has virtual memory mapping, pretty much by necessity. The Vita's OS is built off of FreeBSD and the hardware has an MMU, so it'd be practically impossible for it to not have virtual memory mapping
FWIW, the PSP did NOT have an MMU and everything was physical memory addressing, but it still had memory protection on kernel addresses and unmapped regions of the address space, so reading from some memory would still cause an abort. Just because it has a 4 GiB address space doesn't mean the whole thing is filled.
Ok. And what about other processes' memory. Is there any protection on it. Suppose you start a game, come back to the desktop and start the webbrowser with the exploit and try to read the memory region containing the game (randomly to try to find it). Will there be other protection preventing you to do this ?
Yes, that's half the point of virtual memory. Each process can only see its own memory--the kernel is the only portion of the OS that can see the whole set of physical memory. The address you see in a process is just an arbitrary mapping passed down from the kernel; it (usually) has no actual relation to where in physical memory those pages reside.
Archaemic wrote:Yeah, I have a ~7.9MB dump starting at 0x81B00000 that's the bulk of WebCore. It's from 3.01 though.
Also of note: kernel interfaces start somewhere above 0xE0000000. I have some small dumps from 0xE0001000 and 0xE0006000, but again on 3.01. I haven't poked at 3.18 at all.
E] SceLibKernel starts at 0xE0001000, it seems.
E2] For those curious, the Vita DOES use WebKit2, hence why crashing the web page doesn't take down the whole browser. There's a process separation model, so the actual process running the web page is a different process than the GUI. This'll probably wrinkle some things, but that's kind of the point. More info on WK2 is on this pretty out-of-date page: https://trac.webkit.org/wiki/WebKit2
Yeah, it also explains why every time the web page crashes, the memory mapping is different and everything has to be resolved again (i.e. it's actually an entirely new process).
Archaemic wrote:Yeah, I have a ~7.9MB dump starting at 0x81B00000 that's the bulk of WebCore. It's from 3.01 though.
Also of note: kernel interfaces start somewhere above 0xE0000000. I have some small dumps from 0xE0001000 and 0xE0006000, but again on 3.01. I haven't poked at 3.18 at all.
E] SceLibKernel starts at 0xE0001000, it seems.
E2] For those curious, the Vita DOES use WebKit2, hence why crashing the web page doesn't take down the whole browser. There's a process separation model, so the actual process running the web page is a different process than the GUI. This'll probably wrinkle some things, but that's kind of the point. More info on WK2 is on this pretty out-of-date page: https://trac.webkit.org/wiki/WebKit2
I don't think it's WebKit2 but the vita does use process sandboxing. SceWebBrowser (NPXS10003) is the browser app (defining the gui, menus, etc) and SceWebCore (NPXS10017) is the WebKit renderer process. In fact, other system apps that use webkit (email, maps, etc) also invoke SceWebCore to do the rendering. Although WebKit is the renderer, most of the rest of the components are sony made. They like using heavy metals as their library names. SceWebCore has the 0x8000 auth id flag set, which isn't set for any other vs0 eboots. This likely is the flag for limited system access.