0xFFFFFFFFailSploit Explanation
Posted: Sun May 29, 2011 4:08 pm
So, this is going to be an explaination of my 6.38/6.39 kernel exploit which was used in my downgrader, 6.39 ME, and 6.39 Pro.
After the Genesis Competition was announced, I set a goal, to find a kernel exploit and port Davee's 6.35/6.31 downgrader. Now, having zero experience in finding kernel exploit, this seemed very unlikely to happen, but I was determined.
After two weeks of searching, I had successfully found three kernel exploits, one which I released in my downgrader. So, this kernel exploit was found in http_storage.prx, in the function sceHttpStorageOpen. This vulnerability allowed me to write -1 to anywhere in memory, including kernel memory.
Now, how it works:
As you can see, they do indeed have checks on arg0(but forget to do k1 checks), which is supposed to be only 0 or 1, however, instead of returning an error, they foolishly do some more code, even though they know that a0 is something other than 0 and 1:
Okay, as you can see here (earlier arg0 was sll'd by 2 into s1), it adds the sll'd arg0 to a global variable, and then writes -1(in register s3) to that address.
Okay, now, here was the hard part, finding how to use -1 to gain kernel mode. This wasted ALOT of my time, at least one month I would say, trying to find some type of struct or global variable to set to -1 to gain kernel mode. Especially since, -1 as an instruction (vsync 0xFFFF) was crashing the psp.
After lots of searching through asm, I revisited -1 as an instruction, and I finally realized what the exception truly meant, "Coprocessor Unusable", it suddenly hit me, VFPU isn't enabled!
So, once adding VFPU attributes to the thread, I could then use -1 (vsync 0xFFFF) as if it were a nop, I add -0x990 to the global variable to overwrite the adding of the global:
And finally, I can now write directly to any address, and I use this to nop/vsync out sceKernelPowerLock.
@Mods: Is this the right section?
After the Genesis Competition was announced, I set a goal, to find a kernel exploit and port Davee's 6.35/6.31 downgrader. Now, having zero experience in finding kernel exploit, this seemed very unlikely to happen, but I was determined.
After two weeks of searching, I had successfully found three kernel exploits, one which I released in my downgrader. So, this kernel exploit was found in http_storage.prx, in the function sceHttpStorageOpen. This vulnerability allowed me to write -1 to anywhere in memory, including kernel memory.
Now, how it works:
Code: Select all
sltiu $v1, $a0, 2
beqz $v1, loc_0000005C
Code: Select all
loc_0000005C: ; Refs: 0x00000034 0x000000D4
; Data ref 0x000009F0 ... 0xFFFFFFFF 0xFFFFFFFF 0x00000000 0x00000000
0x0000005C: 0x267409F0 '..t&' - addiu $s4, $s3, 2544
0x00000060: 0x02348821 '!.4.' - addu $s1, $s1, $s4
0x00000064: 0x8E240000 '..$.' - lw $a0, 0($s1)
0x00000068: 0x04820005 '....' - bltzl $a0, loc_00000080
0x0000006C: 0x0240D821 '!.@.' - move $k1, $s2
0x00000070: 0x0C0001B3 '....' - jal IoFileMgrForKernel_810C4BC3
0x00000074: 0x2413FFFF '...$' - li $s3, -1
0x00000078: 0xAE330000 '..3.' - sw $s3, 0($s1)
0x0000007C: 0x0240D821 '!.@.' - move $k1, $s2
Okay, now, here was the hard part, finding how to use -1 to gain kernel mode. This wasted ALOT of my time, at least one month I would say, trying to find some type of struct or global variable to set to -1 to gain kernel mode. Especially since, -1 as an instruction (vsync 0xFFFF) was crashing the psp.
After lots of searching through asm, I revisited -1 as an instruction, and I finally realized what the exception truly meant, "Coprocessor Unusable", it suddenly hit me, VFPU isn't enabled!
So, once adding VFPU attributes to the thread, I could then use -1 (vsync 0xFFFF) as if it were a nop, I add -0x990 to the global variable to overwrite the adding of the global:
Code: Select all
0x00000060: 0x02348821 '!.4.' - addu $s1, $s1, $s4
@Mods: Is this the right section?
. Nicely done 
