0xFFFFFFFFailSploit Explanation

[some1]

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:

Code: Select all

sltiu      $v1, $a0, 2
beqz       $v1, loc_0000005C

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:

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, 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:

Code: Select all

0x00000060: 0x02348821 '!.4.' - addu       $s1, $s1, $s4

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?

Advertising

[Dbrandy]

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.

Gosh, well analysed.. Respect to you 'some1', you just too good.

Advertising

[Zecoxao]

So THAT was the reason you kept asking about vsync 0xFFFF some time ago . Nicely done

[the-green]

thanks some1...excellent job

[bluemimmosa]

@some1

Code: Select all

 sltiu      $v1, $a0, 2   ;here $a0 is checked against 2, if its less than 2 then $v1 is set 0 otherwise 1
 beqz       $v1, loc_0000005C   ;branch to loc_0000005C if $v1 is 0

well now what i didnt understand was the following comments..

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, 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.

Well, where are the global variables, are you referring to $s1 and $s3 here as global variables, since they are preserved across function calls, ie caller saved..


now, since you said arg0 was sll'd , i dont see sll instruction there too, so how was it shifted left, and i know it writes -1 in s3,

so i hope for a step by step explanation,
thanks in advance,,.,

[wololo]

@Mods: Is this the right section?

Yup.

[djmati11]

Maybe an tutorial how to find kxploit. xD

Can you publish other kxploits?

[RaFa]

Can you publish other kxploits?

I don't think that is good idea... If he has plans for releasing he should first wait SONY to patch this one and then releasing the others one by one.

[npt]

Maybe an tutorial how to find kxploit. xD

Can you publish other kxploits?

Of course he is not going to publish those. Think about it. What sense would that make? : )

Regards,

npt

[The Z]

Can you publish other kxploits?

I don't think that is good idea... If he has plans for releasing he should first wait SONY to patch this one and then releasing the others one by one.

He should keep one, for the next "big" new feature of new OFW ^^