syscall 0x0 explanation

<artart78> will be easier probably ;)
<artart78> hi Felix91 by the way
<artart78> geecko: have you RE'ed that sceGe_lazy function entirely so we can take a look at it?
<geecko> only a part of it
<geecko> wait a sec
<artart78> weird fact: this function is called by no firmware module apparently, but is a kernel function
<geecko> it is incomplete and mostly unverified
<geecko> but here it is: http://pastebin.com/WafaUFcJ
<Felix91> Hey artart
<artart78> hm, not really helpful since the sub call doesn't appear in it
<artart78> now I'm really wondering: what the heck is that function!?
<geecko> put the subcall just before "$at = 0" :p
<Felix91> It looks quite ugly, that function.
<artart78> it is completely unused
<artart78> so maybe just debugging stuff?
<geecko> so i can drop it ? :o
<Felix91> Hmm, not sure, as Sony normally just writes return 0; for debug functions. However, the left entire unused modules on the FW so it could be debug.
<Felix91> *they
<artart78> that function was added in 4.xx apparently
<Felix91> well, as long as there is no call to that function, you can leave it out.
<artart78> geecko: yes, probably
<artart78> would be interesting to know what it does though
<geecko> how did you verify that it is not called?
<artart78> no occurence of the "sceGe_lazy" string in the other PRXes, which would be needed for them to import it
<geecko> ok
<artart78> that function wasn't here in 3.52 and was here in ~4.01
<geecko> what is libsceGe_lazy.a?
<artart78> oh wait
<artart78> this function actually *is* used
<artart78> my bad
<geecko> ew
<artart78> not as an export
<artart78> but it's the second argument ($a1) passed to sceKernelSetUsersystemLibWork()
<geecko> :o
<geecko> you are right
<geecko> s/0x140/sceGe_lazy_31129B95/ :D
<artart78> so
<artart78> it can be accessed either inside sysmem (but I don't think it is, I don't want to search for it but according to the big part of sysmem I RE'ed which is still lying on my computer) or through sceKernelGetUsersystemLibWor
<artart78> k
<artart78> which is an user call!!
<geecko> so? ôo
<artart78> and guess which module uses sceKernelGetUsersystemLibWork()?? ge.prx!
<geecko> makes sense :p
<artart78> so
<Felix91> Indeed, inside sysmem (sceKernelSetUsersystemLibWork(), Sony bitwise AND's a value (based on $k1) with its address and makes an illegal address check based on that result. It does not call it.
<artart78> sceKernelGetUsersystemLibWork() + 8 contains the function
<artart78> Felix91: hm? what are you talking about?
<artart78> oh nvm
<artart78> I hadn't understood
<artart78> well it could call it at another place using the pointer it stores
<artart78> which is what I'm too lazy to look for ;) but from what I've seen, it's not called
<artart78> geecko: !!!!!!
<geecko> wut
<Felix91> Ah, Yeah, I did not see the sw $a1, 8($a3) at the end of that function :p
<artart78> *(int *)(str2 + 204) = ((g_AwQueue.syscallId << 6) & 0x03FFFFC0) | 0xC;
<artart78> the syscall id IS replaced!
<artart78> hurrah!
<Felix91> Right, I did not see it being called inside sysmen at some point on first view.
<artart78> g_AwQueue.syscallId = sceKernelQuerySystemCall((void*)sceGeListUpdateStallAddr);
<geecko> sceGeListUpdateStallAddr it is?
<artart78> that stuff make sense
<artart78> and I've also found one of the issues why ge.prx couldn't work lol
<artart78> hm wait actually since I'm using the original usersystemlib.prx, using that "+ 204" shouldn't cause any problem, nvm
<artart78> the function seems to only be called with ONE game
<artart78> ULJM05086
<artart78> Genso Suikoden 1
<artart78> okay so I got it all
<artart78> tell me if you need explanations geecko
<geecko> so which function is called?
<artart78> 0x03E00008
<artart78> would that be a jr $ra by any chance?
<artart78> *checks*
<artart78> yes! great
<artart78> soooo
<artart78> * some studio created the game Genso Suikoden 1, calling sceGeListUpdateStallAddr "all the time" (don't really know actually)
<Felix91> hehe
<Felix91> pretty great analysis
<artart78> * PSP updated its firmware, and that game was calling too many times that function for it to work correctly on higher firmware versions/other hardwares
<artart78> * Sony created the sceGe_lazy_... function because the guys from this studio are LAZY and didn't do things correctly
<artart78> * that function is stored using sceKernelSetUsersystemLibWork(), and ge.prx recovers it using sceKernelGetUsersystemLibWork()
<artart78> * ge.prx modifies that 'syscall' call for the syscall id to match sceGeListUpdateStallAddr's one, which means, for that 'sub_' called by sceGe_lazy to call sceGeListUpdateStallAddr
<artart78> * if the game name matches (Genso Suikoden 1), ge.prx replaces this game's call to sceGeListUpdateStallAddr by a call to its sceGe_lazy function
<artart78> that's all
<artart78> btw, obvious kernel exploit there
<geecko> dafuq :o
<Felix91> Exactly, excellent work here, artart. It took me a bit longer than you to figure that out.
<Felix91> Heh, that's why I always enjoyed working with you.
<artart78> (kernel exploit for Genso Suikoden 1 only though ;p)
<artart78> Felix91: thank you :)
<geecko> how can you exploit it?
<artart78> hm actually maybe not that easy due to $k1 checks upon sceKernelSetUsersystemLibWork() addresses
<artart78> ah but nvm, that'd only allow user access since the function is called by the game anyway
<artart78> nvm
<geecko> it is a great discovery though
<Felix91> Alright, I'm out. There was finally some PSP dev talk again, haha
<artart78> yes :)
<artart78> bye Felix91
<artart78> hope we can talk again soon about more interesting PSP stuff ;)
* Felix91 est parti (Quit: Leaving)