WebKit ROP Chain Tutorials [Creation/Editing/Debugging] - PS3 Development

esc0rtd3w said:
any day now i will post them
Click to expand...

Hello! It's awesome what the team has achieved!!

I don't have any experience with ROP, so I have a question:
- I understand that the exploit let you call any function from any library already loaded in memory.
- Is it possible to execute code stored on a data area? Especifically: if I download a binary file or load an html page that shows a hand-crafted image containing a valid image header and ps3 code and functions; traces of the downloaded file or of the "corrupted" image probably remain loaded/stored in some memory area that I suppose the exploit could access if somehow we find it's address in memory... is it possible to call these functions or is this idea non-feasible ?
 
aldostools said:
Hello! It's awesome what the team has achieved!!

I don't have any experience with ROP, so I have a question:
- I understand that the exploit let you call any function from any library already loaded in memory.
- Is it possible to execute code stored on a data area? Especifically: if I download a binary file or load an html page that shows a hand-crafted image containing a valid image header and ps3 code and functions; traces of the downloaded file or of the "corrupted" image probably remain loaded/stored in some memory area that I suppose the exploit could access if somehow we find it's address in memory... is it possible to call these functions or is this idea non-feasible ?
Click to expand...
Unfortunately you cannot do that because only text segments of loaded self/prx are marked executable by the kernel/NX bit.
The kernel totally controls which areas get executable permissions & which areas don't. From userland, the permissions cannot be modified without defeating lv2 protection because all provisions to directly create an executable area or make an existing area executable have been removed by s#ny from syscalls & other accessible functions.
 
Last edited:
@esc0rtd3w thx for new test files but i think there is a bug in rename syscall if the file size is bigger than 70 kb it wont rename it can you check because i tried a few times and it didnt work with files bigger than 70 kb though it worked for files less than that
 
you have to be more specific than that. the rename chain does not care about file size, and the read/write chain is hard-coded to 320 bytes for testing. this can be manually changed to exact size of your input file, for now

the loader.js now also double-checks if converted unescape string for source path had added 00 to it, then the destination path offset automatically sets itself ahead by 0x1 byte to compensate. this has worked well during my testing
 
Last edited:
esc0rtd3w said:
you have to be more specific than that. the rename chain does not care about file size, and the read/write chain is hard-coded to 320 bytes for testing. this can be manually changed to exact size of your input file, for now

the loader.js now also double-checks if converted unescape string for source path had added 00 to it, then the destination path offset automatically sets itself ahead by 0x1 byte to compensate. this has worked well during my testing
Click to expand...
You say that is default 340 bytes but in syscall.js size is set 0x00000140 doesnt that means its 140 bytes?
 
k9mo said:
Found one online
65kb = 0xfde8
Accroding to converter
Click to expand...
You didn't account for the fact that 65kb is in probably referring to hexadecimal. Although technically it should be decimal, the kb & kib notation allowing to be sure of the base isn't always used & the old kb still usually means hexadecimal.

For ref.
0x10 = 16 bytes
0x10 * 0x10 = 0x100 = 16 *16 = 256 bytes
0x4 * 0x100 = 0x400 = 4 * 256 = 1024 bytes
So in the same way, 65(= 0x41} x 0x400 = 0x10400 bytes.
64kb would have been 0x10000 bytes, round hex number always a multiple of 16.
 
You must log in or register to reply here.

Similar threads

Back
Top