SPU LS Overflow Exploit: Difference between revisions
(hope this is alright...) |
No edit summary |
||
| Line 5: | Line 5: | ||
This code would replace a part of a loaders code, meaning we can execute at a higher level.<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 /> | 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 /> | |||
<br /> | <br /> | ||
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 /> | 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 /> | ||
Revision as of 13:51, 22 April 2011
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.
This means if the right SELF is made, it could replace existing code.
Perhaps:
Make a SELF with a large header, containing arbitrary code at a certain offset
This code would replace a part of a loaders code, meaning we can execute at a higher level.
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.
[What do you mean with "where the LS ends and code begins"? (as the loader's code is located in the LS)]
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.