Editing SPU LS Overflow Exploit

From what I can understand, the code that the loaders use to verify the SCE header doesn't check the size before it moves the header into isolated memory.<br />
This means if the right SELF is made, it could replace existing code.<br />
Perhaps:<br />
Make a SELF with a large header, containing arbitrary code at a certain offset<br />
This code would replace a part of a loaders code, meaning we can execute at a higher level.<br />
Finding the right offset to put the code must be the hardest part, as you'd have to figure out where the LS ends and code begins.<br />
<br />[What do you mean with "where the LS ends and code begins"? (as the loader's code is located in the LS)]<br />
Wasn't really aware of that, I guess that means we'd have to dump the LS somehow to find where the code is.
<br />
----
Your shell code would have to overwrite an area of the LS that gets executed. There will be an amount of guesswork as to the offset since we cannot see the code. The code would begin copying areas of the LS into the shared LS, You would need some PPU code to read the shared LS and dump the information. The implementation of this exploit is rather difficult due to the fact we cannot see the code in the first place, and it will not give a clean dump.
[[User:Admin|Admin]] 16:17, 22 April 2011 (CDT)
----
So maybe it would be a good idea to first try it with metldr as we can pass our modified loader without having to flash it.
Also the SCE header is usually not that big but it needs to be tested to which offset in the LS the data gets copied. If the offset is after the executable code the header will need to be rather big as we are trying to overwrite the code, so the address needs to wrap around to zero IMHO.
----
Please give your ideas/workings here, I figured using the devwiki would be better than forum threads since they are just full of people wanting a simple solution, lets work together instead.<br />