About sceKernelLoadExec (LoadExecForUser)

[m0skit0]

Recent Medal of Honor Heroes format-string exploit by kwsgs has an SDK included for making binary files that can be loaded and executed by the exploit. But unfortunately, the linker will not recognize sceKernelLoadExec(), although compiler does (as psploadexec.h is included on his sdk.h. Does someone knows a reason for this to happen?

MoHH exploit: http://pspupdates.qj.net/PSP-homebrew-M ... aid/132897

I know that sceKernelLoadExec() is exported in LoadExecForUser library with NID 0xBD2F1094, but how would I use this information to call it :P? I found this function in loadexec_01g.prx kernel module, and did a quick code to locate this module (sceLoadExec) in memory with sceKernelFindModuleByName() and of course it's on kernel memory. So now I know where the function resides, but can't call it because the exploit is user mode. I guess I have to use a system call but I don't know how this mechanism works on PSP.

Well as you can see, I have very little knowledge about how linkage is done on PSP, so any useful info or link about this would be very well appreciated.

Hope you can help, and thanks in advance!

[Torch]

Even if you manage to call loadexec you can never launch anything because the kernel isn't HENned. Well maybe you can launch an official EBOOT. You need to use a kernel exploit first to patch the checks before you can loadexec any homebrew.

[m0skit0]

Yes, you're right, I totally missed that (stoopid me!) :P

Ok then, any info about how ELF's external symbols are resolved? Or info about how sceKernelLoadExec behaves to load EBOOTs? Can't find a damn thing besides disassemmblies...

[whistler]

Even if you manage to call loadexec you can never launch anything because the kernel isn't HENned. Well maybe you can launch an official EBOOT. You need to use a kernel exploit first to patch the checks before you can loadexec any homebrew.

well how did the gta savegame exploit/eloader do it?

[whistler]

Even if you manage to call loadexec you can never launch anything because the kernel isn't HENned. Well maybe you can launch an official EBOOT. You need to use a kernel exploit first to patch the checks before you can loadexec any homebrew.

well how did the gta savegame exploit/eloader do it?

and why was fanjita attempting the very same thing with the gripshift exploit?

[Torch]

well how did the gta savegame exploit/eloader do it?

and why was fanjita attempting the very same thing with the gripshift exploit?

It wasn't simply a loadexec; That will reboot the kernel. Its obviously handling lots of other things to allow you to load an ordinary EBOOT into memory and run it as transparently as possible. Otherwise they wouldn't take months to develop it.

Ok then, any info about how ELF's external symbols are resolved? Or info about how sceKernelLoadExec behaves to load EBOOTs? Can't find a damn thing besides disassemmblies...

Normal imports are linked by the loader based on Module name, Library Name and NID hardcoded (by the compiler) in the module when it is loaded.

You can declare an import for late linking. i.e the module that you are importing from is not yet loaded. You module will execute fine in other parts of code except for a call to that import. When the module you are importing from is loaded at a later time then your module will up updated on the fly.

Syscalls also hardcoded in the module according to Module name, Library name and NID. When the kernel mode module exporting the Syscalls are loaded each one is assigned a Syscall NUM. When your module is loaded the corresponding Syscall NUM is inserted in your module.

[m0skit0]

Thanks Torch for the reply. Actually I'm trying to make an EBOOT loader, just to fully understand how this process is done by FW's function sceKerneLoadExec(). I'm not digging into sceKernelLoadModule() as PRXs should be similar but relocatable (or I'm wrong?).

Its obviously handling lots of other things to allow you to load an ordinary EBOOT into memory and run it as transparently as possible.

Do you have an idea about what considerations should be taken into account about loading an EBOOT?

Normal imports are linked by the loader based on Module name, Library Name and NID hardcoded (by the compiler) in the module when it is loaded.

Can you give me a bit more detail about this? I mean, the loader needs to be in kernel mode to do this resolving? Does it search through the entire ELF to find the imports? Or do some ELF section or PBP header contain this info for the loader, so the resolving is done faster?

When the module you are importing from is loaded at a later time then your module will up updated on the fly.

Then the loader does not act about resolving in case of late linking? Or simply it checks about the library availability then do the resolving or not depending on this?

And about syscalls, how the loader resolves the syscalls? :P

Please give me as many technical details as you can. And sorry about the number of questions and noobishness :P I'm just hoping to understand this better ;)

[Torch]

Thanks Torch for the reply. Actually I'm trying to make an EBOOT loader, just to fully understand how this process is done by FW's function sceKerneLoadExec(). I'm not digging into sceKernelLoadModule() as PRXs should be similar but relocatable (or I'm wrong?).

EBOOT.PBP is just a package that contains the executable (relocatable PRX) along with other metadata. (You can use a static ELF with some restrictions, but the correct way is to use a PRX.)

sceKernelLoadModule() just loads a module immediately alongside whatever else is already running. Every module loaded has an entry point which starts executing when you sceKernelStartModule. Usually used for some initialization. Which means you can load a module and it can take over the PSP and not return to your application. Export only modules just return immediately after load&start.

sceKerneLoadExec reboots the kernel (thus freeing up all the user memory again) and basically performs the same actions of sceKerneLoadModule and sceKernelStartModule after extracting the PRX from the EBOOT. The module in the EBOOT is the same as any other module.

Do you have an idea about what considerations should be taken into account about loading an EBOOT?

I've never worked on that level. I would assume it involves manually loading, relocating and linking the module. The list of externals which are currently available on the system are obtained by analyzing the game that is exploited, or finding the corresponding modules and locating their functions and these are manually linked to the module you want to load. The Sony loader wouldn't link your unsigned module anyway. Really have no idea. Probably should ask fanjita or someone who knows how eLoader works. Wonder if something loaded with eLoader can load further modules on its own @_@

Can you give me a bit more detail about this? I mean, the loader needs to be in kernel mode to do this resolving? Does it search through the entire ELF to find the imports? Or do some ELF section or PBP header contain this info for the loader, so the resolving is done faster?

There are a couple of kernel modules responsible for maintaining exports, loading, linking etc. Modules are more or less a standard ELF structure. I don't know much about this. Probably works similar to any other ELF loader. PBP has nothing to do with this.

Then the loader does not act about resolving in case of late linking? Or simply it checks about the library availability then do the resolving or not depending on this?

It probably keeps track of imports flagged for late linking. Since imports are identified by module name & lib name, module manager can easily know when that module is loaded at a later point and update all the pending imports.

And about syscalls, how the loader resolves the syscalls? :P

When a module that exports a syscall is loaded, that syscall is assigned a unique syscall number. It keeps track of the syscall (identified by module, library, NID), its corresponding syscall number, and its function address in a table.

When a module that imports that syscall is loaded, the loader searches for that corresponding module name, lib name and NID in the table and find the syscall number. That number would be replaced in the instruction of your module like "syscall #NUM". When this is executed it jumps to the corresponding function address in kernel memory for that #NUM.

Please give me as many technical details as you can. And sorry about the number of questions and noobishness :P I'm just hoping to understand this better ;)

I'm a noob in these things myself :/

[m0skit0]

EBOOT.PBP is just a package that contains the executable (relocatable PRX)

Well, that's not exact as far as I know. PBPs contains static ELFs (always load at same address), but PRX is a relocatable ELF. Thus EBOOTs doesn't contain PRX.

sceKerneLoadExec reboots the kernel (thus freeing up all the user memory again) and basically performs the same actions of sceKerneLoadModule and sceKernelStartModule after extracting the PRX from the EBOOT.

Thanks for pointing the difference between sceKernelLoadModule() and sceKernelLoadExec(). But as I said, EBOOTs don't contain PRXs.

I would assume it involves manually loading, relocating and linking the module.

I've done the loading part, which I think is the easiest one... No need for relocating as EBOOT's ELF are static (no info about relocation), so now I need to perform the hardest part: linking. But I have no clue about how to do so. So time to think and assimilate what you've told me here :)

The list of externals which are currently available on the system are obtained by analyzing the game that is exploited, or finding the corresponding modules and locating their functions and these are manually linked to the module you want to load.

That's very interesting, thanks for pointing that out.

Modules are more or less a standard ELF structure.

They're a specific Sony ELF type, aka PRX :)

Probably works similar to any other ELF loader.

The problem is ELF loaders are system-dependent :P

PBP has nothing to do with this.

Well, PBP headers say the loading mode (user/kernel) and a bunch of other things too.

It probably keeps track of imports flagged for late linking.

Hmmm, I wonder how that is defined on the ELF...

Anyway, do you know where I can contact fanjita? Or else I would have to reverse sceLoadExec... too big :P

[Torch]

Well, that's not exact as far as I know. PBPs contains static ELFs (always load at same address), but PRX is a relocatable ELF. Thus EBOOTs doesn't contain PRX.

The recommended method for any 3.xx firmware and later application is to pack a PRX in the EBOOT.

Back in 1.50 people used to compile kernel mode static ELFs and put them in EBOOTs. Thus the EBOOT used to directly start their application in kernel mode. The can't be done in 3.xx and later. If you don't put a PRX in your EBOOT you'll have incompatibilites with various firmware.

Thanks for pointing the difference between sceKernelLoadModule() and sceKernelLoadExec(). But as I said, EBOOTs don't contain PRXs.

Look at any modern homebrew, they are all user mode PRXs in an EBOOT, as they should be.

PBP has nothing to do with this.

Well, PBP headers say the loading mode (user/kernel) and a bunch of other things too.

The 32bit address at offset 0x20/4 in the EBOOT points to starting offset of the PRX. Near this address you will find info about the PRX whether its kernel/user etc. The header you are seeing is actually the header of the PRX inside the EBOOT. The PRX offset will be very close to the beginning of the EBOOT so you might have mistaken it as part of the EBOOT header. You can dump the data from that address from any EBOOT and see that it is a PRX (may need to be decrypted/decompressed first).

It probably keeps track of imports flagged for late linking.

Hmmm, I wonder how that is defined on the ELF...

Better look at the source code of the PRX builder from the toolchain. Can't really do anything useful without thorough understanding of the file format.

[m0skit0]

I think you're mistaken PRXs with generic PSP ELFs... Most EBOOT are static, thus not PRX (PSP Relocatable Executable), and they're definitely not relocatable. You can check it with readelf command in Linux. And also you can check that all (at least all that I've seen) EBOOTs have their entry point at 0x08900018 (dont quote me on the address, just saying it by memory).

Can't really do anything useful without thorough understanding of the file format.

I perfectly understand ELF format. PRX are just a type of ELF, so... And I keep thinking that EBOOT's ELFs are not always PRXs, as their ELFs are not relocatable...

Please check this: http://advancedpsp.freeforums.org/psp-m ... s-t88.html

When the PSP kernel loads and starts a module such an application, it reads the EBOOT.PBP file, extracts the ELF or PRX module (which, for the purposes of this tutorial are fundamentally the same thing, barred a few details such as fixed or relocatable memory addresses), parses the module sections, performs some linking to “connect” module imports with already loaded module exports and system syscalls, creates a copy in memory and proceeds to execute the module entry point.

Well I guess I'll have to reverse engineer sceKernelLoadExec() anyway :P

[Torch]

That is an ancient document from years ago.

As per the latest firmware this is how it is for EBOOTs:
Normal case is a standard user mode PRX.
You cannot use a kernel PRX. (Even on Custom Firmware)
You cannot use a kernel ELF. (Even on Custom Firmware)
You CAN use a user mode static ELF, but you cannot load a kernel module from this.

How do homebrew get kernel mode if they use static ELFs?? The only way is to use a user PRX, and then load a kernel PRX to do you kernel mode stuff. A static user mode ELF cannot load a kernel PRX.

On the 1.50 kernel you could but a kernel ELF in the PRX and your app would directly have kernel mode. That's why half the old applications broke on the Slim that didn't support 1.50 kernel. The ones that used user mode static ELFs alone worked on M33 CFW.

This old stuff will still work from the GAME150 folder on a Phat PSP with the 1.50 kernel subset.

Even if there is some official EBOOT that uses a static ELF, it doesn't matter because all > 3.xx homebrew uses a PRX in their EBOOT, and the purpose of making an eLoader is to run homebrew EBOOTs.

[m0skit0]

Man, I've done a EBOOT that loads a kernel PRX that dumps kernel memory.

http://advancedpsp.freeforums.org/kmemd ... b-t63.html

How can you say you cant load kernel PRXs in CFW?

[Torch]

Man, I've done a EBOOT that loads a kernel PRX that dumps kernel memory.

http://advancedpsp.freeforums.org/kmemd ... b-t63.html

How can you say you cant load kernel PRXs in CFW?

Just looked at that app.

If that works on 5.00M33 then there must be a new patch in M33 that allows loading kernel PRX from a user ELF. Its 100% not possible few firmwares ago. It was a requirement that the EBOOT contained a user PRX if you wanted to load a kernel PRX.

Why do you want to deviate from standards everyone is following? Everyone builds PRXs for 3.xx EBOOTs. Remember you are trying to load other people's homebrew, not only your own.

In fact IIRC even allowing static user ELF to be used in EBOOT itself was a patch. Its not supported by the firmware.

[m0skit0]

Which standards everyone use? I'm using ps2dev.org PSPSDK downloaded right from subversion. That's not the standard?

The EBOOTs I'm talking about are made from those sources I gave you, using the ELFs generated by psp-gcc, before embedding them on the PBP. And all are static, no relocation table on ELF, same loading address on ELF's program header (0x08900018 if i'm not mistaken). But PRXs do are relocatable. So there are two executable types: ELF and PRX, afaik.

Please do not take my posts as flaming, I just want to learn :)

[Torch]

Which standards everyone use? I'm using ps2dev.org PSPSDK downloaded right from subversion. That's not the standard?

The EBOOTs I'm talking about are made from those sources I gave you, using the ELFs generated by psp-gcc, before embedding them on the PBP. And all are static, no relocation table on ELF, same loading address on ELF's program header (0x08900018 if i'm not mistaken). But PRXs do are relocatable. So there are two executable types: ELF and PRX, afaik.

Please do not take my posts as flaming, I just want to learn :)

The toolchain will always generate a static ELF in every case because thats how it was designed in the beginning. It cannot natively generate a PRX.

For new firmware YOU are supposed to convert the ELF into PRX to be 100% compatible with latest firmware. The BUILD_PRX = 1 is provided in the makefile to automate this.

Yes static user ELF also works, but just because it works doesn't mean its the correct way. That you can now load kernel PRX from a static ELF is news to me.

Take for example the new IRShell that supports multitasking. It allows you to load an EBOOT in the extra 32 MB of RAM on the Slim. How will this work if you made your EBOOT with a static ELF??? It only works if the EBOOT contains a PRX. He wouldn't have bothered with implementing such a thing if everyone used static ELFs in their EBOOT.

Just add a BUILD_PRX = 1 to to you makefile.kmain
Your app will work fine.

[m0skit0]

Ok, I got the point, finally xD

Thanks man