Just pushed a couple more changes. Thanks to
Netrix, the exploit's success rate has improved (avoids trashing the memory heap allowing a more predictable behavior) and it now supports basic struct handling (based on js-struct.js).
I've improved the module loading functions (you can now list/dump each module individually, e.g.: list_modules("SceLibc", true)), added loading of a new module SceCommonDialogMain (needed parameters just like ScePaf), corrected ScePaf loading parameters and implemented a path conversion test function to handle the "vs0:data/external/webcore" path.
Some modules were dependent on SceCommonDialogMain, so try using load_sysmodules1() and load_sysmodules2() to see which ones can be dumped now.
Xeeynamo wrote:app0:/eboot.bin is an encrypted SELF right? It's known where the executable is located in RAM? 'cause I cannot find it. At 0x18 of the eboot.bin I found 0x0001A678 (located in SCE header section) and at 0xB8 I found 0x00012e68 (located in ELF header section) but they point to nothing if I sum them to 0x8x000000.
Use the new convert_path function to see how the WebKit application maps itself. Uncomment the "Directory listing test" and it will now list the WebKit's directory in addition to the "app0:" path.
It's not clear were the executables get loaded, but try looking into some of the .suprx files that can be retrieved from this path and compare the offsets in their headers with their location in the RAM.
BATMAN-787 wrote:Netrix wrote:BATMAN-787 wrote:no progress for 3.18 yet?
This works fine on 3.18.
so is it to poke around or it will let you r/w something?
You can do plenty with this on 3.18, including memory reading, module dumping and support URI calls.
