so, after some deliberation with Zer0Tolerance, we decided to release an updated version of the lv2 exploit that my friend released a long time ago.
First, some notes:
This exploit was patched on 4.40, NOT on 4.45
There isn’t just ONE non checked pointer, there are FOUR! they are all 4 now checked in 4.40
/*
* lv2 SysCall 670 (0x29E): sys_rsx_context_allocate
* @param context_id (OUT): RSX context, E.g. 0x55555555 (in vsh.self)
* @param lpar_dma_control (OUT): Control register area. E.g. 0x60100000 (in vsh.self)
* @param lpar_driver_info (OUT): RSX data like frequencies, sizes, version… E.g. 0x60200000 (in vsh.self)
* @param lpar_reports (OUT): Report data area. E.g. 0x60300000 (in vsh.self)
* @param mem_ctx (IN): mem_ctx given by sys_rsx_memory_allocate
* @param system_mode (IN):
*/
/*
After some verification it turns out that 4 pointers aren’t checked
They are:
context_id
lpar_dma_control
lpar_driver_info
lpar_reports
we can write values at:
rsx_context + 0x04 (4Bytes) – context_id
rsx_context + 0x20 (8Bytes) – lpar_dma_control
rsx_context + 0x30 (8Bytes) – lpar_driver_info
rsx_context + 0x40 (8Bytes) – lpar_reports
to properly specify a kernel address use ULL for big numbers
*/
you can test this for instance on a 4.21 cfw console by specifying an address in one of the parameters and then dumping memory before and after running the syscall. just be careful that you need to be able to write to that region! https://www.sendspace.com/file/rnf0eg
^
link to the exploit
Many thanks to @IronMan and @AlexAltea for the help. this exploit will be even better later, so stick around
Visit the forum for more help:
[Release] rsxploit updated and working
