Do you know what the vshAvcResumeDebugGetVTimerBase (from sceVshBridge) does?
It... executes the games/homebrews in the memory stick!!!
Yeah, the code of this function (which can be called from vsh mode), simply sets the kernel mode and then execute the function LoadExecForKernel_28D0D249, which requires kernel mode and it's the one that does the real thing.
My question for those md5 experts... How big is the posibility of a collision between two strings that have sense? Do you think this is more probably a false name to fake us?
vshAvcResumeDebugGetVTimerBase, fake name or nid collision?
-
kuroitenchi
- Posts: 10
- Joined: Sun Apr 23, 2006 12:22 am
Great finding ! :) I think Mathieulh spoke somewhere on this forum of some hidden debug functions within vshbridge (without giving further details) it seems to be one of them.
I am no expert but I presume that it is just a forgotten debug function forgotten in the retail firmwares that doesn't do what it was meant to.
Anyway it's a great step into running kernel mode in 2.00 :)
I am no expert but I presume that it is just a forgotten debug function forgotten in the retail firmwares that doesn't do what it was meant to.
Anyway it's a great step into running kernel mode in 2.00 :)
This functions is actually the one that the vsh uses to execute our apps :)kuroitenchi wrote:Great finding ! :) I think Mathieulh spoke somewhere on this forum of some hidden debug functions within vshbridge (without giving further details) it seems to be one of them.
I am no expert but I presume that it is just a forgotten debug function forgotten in the retail firmwares that doesn't do what it was meant to.
Anyway it's a great step into running kernel mode in 2.00 :)
Maybe those functions that Mathieulh talked about are some like sceKernelLoadExecBufferPlain :D, sceKernelLoadExecFromHost and their vshbridge equivalents, which were misteriously removed in 2.00
But actually, i don't think it can be used to get access to kernel mode in 2.00. In 1.50, the LoadExec family of functions can execute unsigned elf's (but not unsigned prx's, not unsigned pbp's), that's why we have homebrew now a days, but that stupid error of sony was patched.
-
kuroitenchi
- Posts: 10
- Joined: Sun Apr 23, 2006 12:22 am
so, vshAvcResumeDebugGetVTimerBase cannot actually be used to run homebrews on 2.00 because LoadExecForKernel_28D0D249 wont run decrypted elfs ?
Last edited by kuroitenchi on Wed May 03, 2006 6:43 am, edited 2 times in total.
Exact. It has been patched in 2.00 (maybe it's also patched from 1.51)kuroitenchi wrote:so, vshAvcResumeDebugGetVTimerBase cannot actually be used on 2.00 because LoadExecForKernel_28D0D249 wont run decrypted elfs ?
It was one of the most stupid errors of Sony. In some parts they have put a lot of effort in security, but then they have lame mistakes like that...
-
kuroitenchi
- Posts: 10
- Joined: Sun Apr 23, 2006 12:22 am
Well from my point of view I don't think that fw 1.00 was what I'd call secured. You could run any decrypted elfs as long as it was packed within a pbp and reverse engeneering the how the pbp is done isn't rocket science.
I wonder what LoadExecForKernel_28D0D249 in newer firmwares need to actually execute an elf, does the elf only need to be encrypted, or does it needs to comply some other restrictions ?
I wonder what LoadExecForKernel_28D0D249 in newer firmwares need to actually execute an elf, does the elf only need to be encrypted, or does it needs to comply some other restrictions ?
There are alot of collisions in the md5 brute forcing because only 32bits of the md5sum are used by the nid. In all likelyhood it is the same function name as the unknown sceLoadExec one just with vsh at the front. We may never know the real name :(
And the elf will probably always need to in a ~PSP wrapper on the 2.0+ (and possible 1.51+) firmwares, that isn't to say of course that the elf has to be encrypted but we have yet to really determine what all the fields mean. Perhaps if people look hard enough there might be an exploit in the decryption code. Who knows if noone looks too hard :)
And the elf will probably always need to in a ~PSP wrapper on the 2.0+ (and possible 1.51+) firmwares, that isn't to say of course that the elf has to be encrypted but we have yet to really determine what all the fields mean. Perhaps if people look hard enough there might be an exploit in the decryption code. Who knows if noone looks too hard :)
Yeah, that worths a look :)TyRaNiD wrote: And the elf will probably always need to in a ~PSP wrapper on the 2.0+ (and possible 1.51+) firmwares, that isn't to say of course that the elf has to be encrypted but we have yet to really determine what all the fields mean. Perhaps if people look hard enough there might be an exploit in the decryption code. Who knows if noone looks too hard :)