Hello everyone,
I pretty recently analyzed the Gateway launcher and understand (mostly) how it works. In the spoiler is a basic rundown.
As of January 21, 2015, I have a new launcher, but it has not been tested yet. It is for 9.2 only.
Knowing all of this, functions located at various parts in memory, and where gateway stores its data, I should be able to replace gateway's code with my own, which will be...I'm not sure yet. Probably a cfw or modification of a cfw since that will allow for the most stuff. I'm still considering exactly what to put in there and I may end up making my own thing that'll install a piece of software to allow execution of any launcher stored on the SD card (much like HBC). I might also write a piece of software that will take any existing launcher.dat and make it executable by the website exploit. I'll think about it.
Now, all I'm going to be doing with the exploit itself is modifying the gateway launcher since the website exploit doesn't allow for the execution of unsigned code, and the gateway launcher does.
I'll keep this thread updated with progress and a date/time.
I pretty recently analyzed the Gateway launcher and understand (mostly) how it works. In the spoiler is a basic rundown.
As of January 21, 2015, I have a new launcher, but it has not been tested yet. It is for 9.2 only.
The website exploit blindly runs the file "Launcher.dat" on the root of the SD card. I will not explain how the website exploit works. Since the website exploit does not have kernel access, it's up to the launcher to get access itself through another exploit, which in this case is gspwn. I'm not gonna explain how that works, either. After the initial payload has been successfully executed, the rest of the process is taken care of in the launcher. Here are the three stages of the launcher:
Stage 1: Basically setup. Code and information is copied to the memory to allow for referencing and execution later.
Stage 2: Owning the ARM11 kernel. This exploit overwrites the kernel data to allow for the exploitation of the ARM9 kernel.
Stage 3: Owning the ARM9 kernel. Basically causes the ARM11 kernel to overwrite data at a specific memory location from a pointer to code that was agreed to be valid by both kernels. After the data is overwritten, the ARM11 kernel resets, and the ARM9 waits for the kernel to boot again. After it is ready, ARM9 executes the code at the location that has the overwritten code. This code can (probably) be anything since it is being executed by the ARM9 kernel, which always has full permission to execute any code. This is the most interesting stage.
Stage 1: Basically setup. Code and information is copied to the memory to allow for referencing and execution later.
Stage 2: Owning the ARM11 kernel. This exploit overwrites the kernel data to allow for the exploitation of the ARM9 kernel.
Stage 3: Owning the ARM9 kernel. Basically causes the ARM11 kernel to overwrite data at a specific memory location from a pointer to code that was agreed to be valid by both kernels. After the data is overwritten, the ARM11 kernel resets, and the ARM9 waits for the kernel to boot again. After it is ready, ARM9 executes the code at the location that has the overwritten code. This code can (probably) be anything since it is being executed by the ARM9 kernel, which always has full permission to execute any code. This is the most interesting stage.
Now, all I'm going to be doing with the exploit itself is modifying the gateway launcher since the website exploit doesn't allow for the execution of unsigned code, and the gateway launcher does.
I'll keep this thread updated with progress and a date/time.