0xFFFFFFFFailSploit Explanation

[Sirius]

I have a question, How do you inyect a shellcode or something like that? I know how to do that in savedata or in an image but not in the firmware, sorry if this sound very stupid

Advertising

[TiPi]

First find yourself a nice place to inject a little bit of code (f.e. bin loader, green screen flasher, ect..) in the exploited file (some1 explains it here), then re-cause the crash again, take a memdump using this command:

Code: Select all

savemem dump.bin 0x08800000  999999999

Note that 999999999 is way too big, but it makes sure you'll dump everything. The dump should be +/- 24 MB.
Then open up that dump in your favorite HEX-editor, and search for the 'injected' code inside the dump. Then take the offset of the code in the dump, and add 0×8800000 to it, you'll become the address you want to jump to.

Advertising

[Nickolas]

First find yourself a nice place to inject a little bit of code (f.e. bin loader, green screen flasher, ect..) in the exploited file (some1 explains it here), then re-cause the crash again, take a memdump using this command:

Code: Select all

savemem dump.bin 999999999

Note that 999999999 is way too big, but it makes sure you'll dump everything. The dump should be +/- 24 MB.
Then open up that dump in your favorite HEX-editor, and search for the 'injected' code inside the dump. Then take the offset of the code in the dump, and add 0×8800000 to it, you'll become the address you want to jump to.

Wow! It took me an hour to understand it from tuts all over the web and you explained it in a paragraph! You're quite the teacher....

[some1]

I have a question, How do you inyect a shellcode or something like that? I know how to do that in savedata or in an image but not in the firmware, sorry if this sound very stupid

err...what do you mean "inject shellcode into the firmware"? Although many people believe kernel exploits are *caused* like game mode sploits with the savedata or vsh sploits with media files, but they are not. Kernel exploits are not *caused* by the exploit-er at all, they are a bug that already exist in the firmware, all we do is find it and exploit it. So, when it comes to kernel exploits you don't have to "inject shellcode into the firmware" (w/e that means...unless you're talking about patching, which I wouldn't call shellcode), because you already need to have a usermode(or vsh mode) exploit to run the code to exploit the kernel.

[m0skit0]

Sorry some1, but I kind of disagree on some points.

Kernel exploits are not *caused* by the exploit-er at all, they are a bug that already exist in the firmware, all we do is find it and exploit it

No exploit is "caused". All exploits simply exploit an already existing vulnerability on the software (be it a game, VSH or the kernel, or Windows, or a hardware thingy, or even a person ). The exploiting technique used, as already stated before, depends completely on how's the vulnerability, as your example exploit and your reasoning when you found the vuln shows very well.

So, when it comes to kernel exploits you don't have to "inject shellcode into the firmware" (w/e that means...unless you're talking about patching, which I wouldn't call shellcode)

I totally disagree. Some kernel exploits actually inject shellcode into kernel space. And anyway, to effectively exploit the kernel, you have to put your code into kernel space and getting it to execute so it gets kernel privileges when running. Techniques might vary, but the objective is to get your code running on kernel mode. This obviously involves "injecting" your code into kernel space, be it a simple procedure or a more complicated one.

you already need to have a usermode(or vsh mode) exploit to run the code to exploit the kernel

Not really, you can use signed code.

[some1]

It really depends on how you look at things.

Sorry some1, but I kind of disagree on some points.

No exploit is "caused". All exploits simply exploit an already existing vulnerability on the software (be it a game, VSH or the kernel, or Windows, or a hardware thingy, or even a person ). The exploiting technique used, as already stated before, depends completely on how's the vulnerability, as your example exploit and your reasoning when you found the vuln shows very well.

Thats kind of true, again it depends on how you view it. Also depends on the kernel exploit. (I can go on more about this but I choose not to because it's kind of point-less imo)

I totally disagree. Some kernel exploits actually inject shellcode into kernel space. And anyway, to effectively exploit the kernel, you have to put your code into kernel space and getting it to execute so it gets kernel privileges when running. Techniques might vary, but the objective is to get your code running on kernel mode. This obviously involves "injecting" your code into kernel space, be it a simple procedure or a more complicated one.

Actually, you don't have to inject your code into kernel space to have kernel privileges, just have a kernel function with kernel privileges jump to your function and it too will have kernel privileges, even if you function is located in umem.

Not really, you can use signed code.

Yea, ofc, you need some way to run your own code, whether you get it from "signing", umode sploit, or vsh sploit.

[jigsaw]

Until yesterday I stared to check some1's code(reversed by LiquidZigong), and then I was googling around to see why 0xffffffff is NOP, w/o any clue.
Before I post the question I found this post. You are a genius, some1. =)

BTW, for those who want a book for finding kernel exploit, check this out: http://www.amazon.com/Guide-Kernel-Expl ... =1-1-fkmr0

Although this is not related to PSP or even MIPS, I feel the principle behind is just the same.

PS: By searching "sll $k1, $k1, 11" in all kernel modules could be a first step of looking for kexploit in PSP. (I guess)

[Sirius]

I tried to decompil it with prxtool but I got this error

Code: Select all

PRXTool v1.1 : (c) TyRaNiD 2k6
Built: Apr 26 2011 10:54:57
Loading http_storage.prx
Loaded PRX http_storage.prx successfully
prxtool: malloc.c:3096: sYSMALLOc: Assertion `(old_top == (((mbinptr) (((char *) &((av)->bins[((1) - 1) * 2])) - __builtin_offsetof (struct malloc_chunk, fd)))) && old_size == 0) || ((unsigned long) (old_size) >= (unsigned long)((((__builtin_offsetof (struct malloc_chunk, fd_nextsize))+((2 * (sizeof(size_t))) - 1)) & ~((2 * (sizeof(size_t))) - 1))) && ((old_top)->size & 0x1) && ((unsigned long)old_end & pagemask) == 0)' failed.
Abortado

It's the first time i get this error, anyone know why is this happening?

[m0skit0]

PRXTool bugs + Sony hiding stuff = search for a PRXTool update (I think someone posted a version with that bug fixed) or use another decompiler.

[some1]

Yea, coyotebean released patch, but not sure if it will affect this (worth a shot). Anyways, post exactly what switches you are using for prxtool.