In the 32c3 derrek showed us a new ARM 11 Kernel exploit. It´s basically memchunkhax2. I started this thread to focus the new exploit. People in this forum who knows well about exploitation and want to make code to get ARM 11 Kernel code execution can help, so that this project will suceed.
Github Page: https://github.com/julian-20/Memchunkhax2
recording of the talk:
Supported firmwares: 10.3 and all lower firmwares, N3DS + O3DS
How does the exploit works:
Github Page: https://github.com/julian-20/Memchunkhax2
recording of the talk:
Supported firmwares: 10.3 and all lower firmwares, N3DS + O3DS
How does the exploit works:
The svc ControlMemory() can allocate and free memory pages in the FCRAM. Each memory region in the FCRAM has a memchunkheader. The memchunkheader contains the size of the memory region(in pages), a pointer to the previos free memory region and a pointer to the next free memory region. The svc ControlMemory() uses these headers.
The exploit(s) are the facts, that the memchunkheaders are stored in the FCRAM and a problem inside the ControlMemory() svc.
ControlMemory() maps the header to user-space before it reads the next pointer. In a small period of time, we can change the next pointer with the help of a second thread.
With the help of svcCreateAddressArbiter, we can check, that the next pointer is user-space accessable, because it returns an error if it´s not user-space accessable. So we can overwrite the next pointer, before it get reads by ControlMemory().
We use this possibility to let the next pointer points to AXI WRAM.
We need there also a memchunkheader for the ControlMemory(), but we can´t write there. So we use much KObjects, which are stored inside AXI WRAM. Than we write the size into one of the atributes and a pointer to itself. ControlMemory() will then map the kobjects to user-space. Now we are able to overwrite the *vtable(a pointer, which points to a list, which cointains a list with pointer pointing to virtual functions).
From here it´s only speculation:
Then we override the pointer to change one of the functions(as an example the destructor function). Then we call svc CloseHandler and "BOOM"
sry for my bad english
The exploit(s) are the facts, that the memchunkheaders are stored in the FCRAM and a problem inside the ControlMemory() svc.
ControlMemory() maps the header to user-space before it reads the next pointer. In a small period of time, we can change the next pointer with the help of a second thread.
With the help of svcCreateAddressArbiter, we can check, that the next pointer is user-space accessable, because it returns an error if it´s not user-space accessable. So we can overwrite the next pointer, before it get reads by ControlMemory().
We use this possibility to let the next pointer points to AXI WRAM.
We need there also a memchunkheader for the ControlMemory(), but we can´t write there. So we use much KObjects, which are stored inside AXI WRAM. Than we write the size into one of the atributes and a pointer to itself. ControlMemory() will then map the kobjects to user-space. Now we are able to overwrite the *vtable(a pointer, which points to a list, which cointains a list with pointer pointing to virtual functions).
From here it´s only speculation:
Then we override the pointer to change one of the functions(as an example the destructor function). Then we call svc CloseHandler and "BOOM"
sry for my bad english
Last edited by julian20,