How does kxploit work?
How does kxploit work?
Hi, I'm wondering how the kxploit actually works. I understand that the kernel locks out running unsigned binaries, and that kxploit gets around this and then launches an unsigned binary (an .elf)... but I havnt heard anything of how they did this (technically). Is it code?? A buffer overflow of some kind?
If its code I would assume that we could write more code (loaders for homebrew elfs that turn on USB functionality while running the app) into the exploit without having to write another loader.
Right now Im writing a wifi app and I'm (attempting) to write a loader that loads up the wifi modules and then runs my app, so that my app can be in user mode instead of kernel mode, which should allow me to use the Home key.
Thanks!
-Bill
If its code I would assume that we could write more code (loaders for homebrew elfs that turn on USB functionality while running the app) into the exploit without having to write another loader.
Right now Im writing a wifi app and I'm (attempting) to write a loader that loads up the wifi modules and then runs my app, so that my app can be in user mode instead of kernel mode, which should allow me to use the Home key.
Thanks!
-Bill
Kxploit is not code - it's akin to a swap trick. The magic of creating an app or "app loader" is in the ELF, and has nothing to do with kxploit. ELFs that load with kxploit can run unmodified on the 1.0 firmware.
All I'm saying is that kxploit is not very interesting itself, but the apps you can run by using it are.
All I'm saying is that kxploit is not very interesting itself, but the apps you can run by using it are.
Well, basically, both firmware 1.0 and 1.5 can run unencrypted, unsigned binaries. They blocked this in 1.51.
1.0 will run an unsigned binary in a PBP file without worry.
1.5 will refuse to run an unsigned binary in a PBP file, but will execute a bare elf file if you can provide that file after the PSP has already loaded the PBP.
So all kxploit does is create two directories, the PSP sees one as corrupt (and shows the corrupt icon) and one as valid. Once you launch the valid one, the PSP incorrectly parses the "%" sign as part of a standard printf-style formatting string, and so removes it, and then finds the elf file and loads it.
Memory stick swap works in the same way - it finds the pbp first on the first memory stick, and then finds the elf on the second after having run the pbp from the menu.
1.51 & 1.52 (not sure about 2.0) both contain the printf formatting bug, so you can still use the directory structure as in 1.5, but t he ability to launch an unsigned, raw elf file has been removed. So all that is left is a buffer overrun exploit, but that will be incredibly difficult to master, as you need to know exactly what code will be overwritten, and then since the program that has been exploited will be encrypted, it will be expecting your buffer overrun code to be encrypted too...
1.0 will run an unsigned binary in a PBP file without worry.
1.5 will refuse to run an unsigned binary in a PBP file, but will execute a bare elf file if you can provide that file after the PSP has already loaded the PBP.
So all kxploit does is create two directories, the PSP sees one as corrupt (and shows the corrupt icon) and one as valid. Once you launch the valid one, the PSP incorrectly parses the "%" sign as part of a standard printf-style formatting string, and so removes it, and then finds the elf file and loads it.
Memory stick swap works in the same way - it finds the pbp first on the first memory stick, and then finds the elf on the second after having run the pbp from the menu.
1.51 & 1.52 (not sure about 2.0) both contain the printf formatting bug, so you can still use the directory structure as in 1.5, but t he ability to launch an unsigned, raw elf file has been removed. So all that is left is a buffer overrun exploit, but that will be incredibly difficult to master, as you need to know exactly what code will be overwritten, and then since the program that has been exploited will be encrypted, it will be expecting your buffer overrun code to be encrypted too...
-
- Posts: 47
- Joined: Thu Jan 20, 2005 4:35 am
I think the best shot at any new exploits will have to be savegame based. Are any people currently investigating this at all?Woogie wrote:So all that is left is a buffer overrun exploit, but that will be incredibly difficult to master, as you need to know exactly what code will be overwritten, and then since the program that has been exploited will be encrypted, it will be expecting your buffer overrun code to be encrypted too...
Hmm, IIRC, with the new layout and all, we don't discuss exploits here anymore :P.Warren wrote:I think the best shot at any new exploits will have to be savegame based. Are any people currently investigating this at all?Woogie wrote:So all that is left is a buffer overrun exploit, but that will be incredibly difficult to master, as you need to know exactly what code will be overwritten, and then since the program that has been exploited will be encrypted, it will be expecting your buffer overrun code to be encrypted too...
Not to be on the soap box or anything, but isn't it pointless to create homebrew if the amount of people with homebrew able PSPs dwindle? We already know the Euros are stuck with 2.0. Without exploits to open the doors in the future firmware all of this homebrew development is rather mute if you ask me.
It would be pointless, if the point was to provide software for others to use.
That may be the case for some, but certainly not all homebrew programmers. I'd say most do it just for the experience, either for finding their way into a game-related job or just because its very interesting to take apart and conquer the latest nifty piece of hardware.
Just because people don't get to run the latest emulators doesn't mean everyone packs it up and goes elsewhere. With the noise level lowered, it may even improve for those of us truly interested in the subject.
That may be the case for some, but certainly not all homebrew programmers. I'd say most do it just for the experience, either for finding their way into a game-related job or just because its very interesting to take apart and conquer the latest nifty piece of hardware.
Just because people don't get to run the latest emulators doesn't mean everyone packs it up and goes elsewhere. With the noise level lowered, it may even improve for those of us truly interested in the subject.
Homebrew on 2.0
I used to think I was smart, but I've been learning so much
from the developers in this forum. I am very
impressed with their levels of competence...from figuring
out the GU, to figuring out the ME, to setting up the kernel
stubs webpage, to archiving all the modules, to listing the
part numbers of all the components on the board, and many
other smart advances that don't come immediately to mind.
It saddens me to think that I might not read posts of that
caliber anymore. And there is currently no place else
to read about things like that.
So, I think the answer lies somewhere in between what
you two are saying. It's not pointless to continue, but I do
think that it makes sense to continue to discuss exploit
research. It is, after all, a very academically demanding
type of research and I'm learning more than ever about
OS internals through it.
So, I agree that piracy and warez/emuz kiddiez
are annoying and I don't want to encourage piracy at all.
(Just rent the games till you find one you like, then buy it!)
However, as the author of a popular program (PSPKick),
I have received *large* numbers of requests for people
with 1.51/1.52 who want to run it, yet can't. I feel
these people's frustration, the ones who have legitimate
desire to run homebrew. Many of them never had a chance.
So, I would like to see exploit research discussion continue, because it
will enable large numbers of users to use legitimate homebrew
and because it will enable a lot of people to learn how to code
from unsung experts. And if we can figure out a way to enable
homebrew without enabling piracy (and I know that's a big IF),
I am all for it.
Please take these comments into consideration.
Sincerely,
Noah Vawter
from the developers in this forum. I am very
impressed with their levels of competence...from figuring
out the GU, to figuring out the ME, to setting up the kernel
stubs webpage, to archiving all the modules, to listing the
part numbers of all the components on the board, and many
other smart advances that don't come immediately to mind.
It saddens me to think that I might not read posts of that
caliber anymore. And there is currently no place else
to read about things like that.
So, I think the answer lies somewhere in between what
you two are saying. It's not pointless to continue, but I do
think that it makes sense to continue to discuss exploit
research. It is, after all, a very academically demanding
type of research and I'm learning more than ever about
OS internals through it.
So, I agree that piracy and warez/emuz kiddiez
are annoying and I don't want to encourage piracy at all.
(Just rent the games till you find one you like, then buy it!)
However, as the author of a popular program (PSPKick),
I have received *large* numbers of requests for people
with 1.51/1.52 who want to run it, yet can't. I feel
these people's frustration, the ones who have legitimate
desire to run homebrew. Many of them never had a chance.
So, I would like to see exploit research discussion continue, because it
will enable large numbers of users to use legitimate homebrew
and because it will enable a lot of people to learn how to code
from unsung experts. And if we can figure out a way to enable
homebrew without enabling piracy (and I know that's a big IF),
I am all for it.
Please take these comments into consideration.
Sincerely,
Noah Vawter
In a happy and perfect world we wouldn't have to worry about piracy or getting hit by lawyers just for poking our noses into the hardware we've purchased. We don't live in that world, unfortunately...
Regardless, getting a psp with an exploitable firmware is trivial at the moment and when combined with the real lack of true exploit discussion on these forums it really made sense to avoid the whole mess and just not talk about discovering new methods here. This may change in the future - but for now this is the way we've chosen to run these forums.
Instead, we can focus our efforts on improving our understanding of the psp itself, and on producing free and legal alternative to signing your soul away to Sony.
Regardless, getting a psp with an exploitable firmware is trivial at the moment and when combined with the real lack of true exploit discussion on these forums it really made sense to avoid the whole mess and just not talk about discovering new methods here. This may change in the future - but for now this is the way we've chosen to run these forums.
Instead, we can focus our efforts on improving our understanding of the psp itself, and on producing free and legal alternative to signing your soul away to Sony.
Don't get me wrong, there was far too many posts about nonsense, none of which did anything exemplary or even tried any of what being said as an idea. If getting rid of the forum entirely is what it takes to keep the garbage out, then I suppose that is what needs to be done. But to completely sweep exploits under the proverbial rug, just doesn't really seem fitting to me, since it is the reason that homebrew can run on 1.50 PSPs and certainly is more legitimate than say a mod chip.
I have noticed a *ton* of nonsensical GARBAGE on this forum. Random 13yo kids who think they have a clue how any of this stuff works. They should stay out of the way of the people who do understand and have put lots of effort into figuring out how things work.
Its crazy how they could come up with something like how loading up a blank signed ELF would work. :P
It makes me wonder how many of the exploit-ists on here are actual PSP devs.
-Bill
Its crazy how they could come up with something like how loading up a blank signed ELF would work. :P
It makes me wonder how many of the exploit-ists on here are actual PSP devs.
-Bill