Homebrew Enabler for 2.71

[moonlight]

I did this thing to let the native loading of homebrew in 2.71 (until hard reset).

http://dax.lan.st/hen.rar

Notes about programming in 2.71:

- Homebrew has to be in prx format, at least atm. Furthermore, the main prx, the one in the pbp, has to be an user prx. However this user prx can load unsigned kernel modules from the memory stick, allowing kernel mode apps.

- There is no need for noplainmodule check patch or nodevicecheck patch, since those are done by the homebrew enabler.

- Try to use USE_KERNEL_LIBS = 1 in your kernel prx's. In 2.XX, the separation between user and kernel mode is higher than in 1.XX.
Some functions in "*ForUser" are now totally separated (different address) from their "*ForKernel" equivalents. A good example is ModuleMgr. If you are in a kernel prx and you call the sceKernelLoadModule of ModuleMgrForUser, you will get a "ILLEGAL_PERMANENT_CALL" error.

- Currently devhook emulated 2.71 is not supported. I'll try to add support to devhook, so programs for 2.71 can be developed in a 1.50

- See the source code of the samples to have a hint on how to program for 2.71.

[digihoe]

Wow!

Really nice!

[mbf]

Very, very nice one :)

Seems to be the definitive solution for running homebrew on 2.71... I wonder why there is so little feedback :/

Are there any limitations to what can be done compared to 1.5 (besides what's already in the README)? I'm more interested in limitations with harware access (like the ME).

[weltall]

how are the performances?
from my tests the same (user mode app => sexypsf) on 1.50 a song doesn't skip on 2.71 emulated trought devhook (and with the prx) the same song skips some times like something was using the cpu

[harleyg]

Nice one alex.

[moonlight]

Very, very nice one :)

Seems to be the definitive solution for running homebrew on 2.71... I wonder why there is so little feedback :/

Are there any limitations to what can be done compared to 1.5 (besides what's already in the README)? I'm more interested in limitations with harware access (like the ME).

There should be accesss to me, since there is kernel mode.
I guess that homebrew for 2.71 could be more interesting in the future with the release of the camera and gps.

[mbf]

There should be accesss to me, since there is kernel mode.
I guess that homebrew for 2.71 could be more interesting in the future with the release of the camera and gps.

Mhhh..... Deniska's Map This! with the Sony GPS .... ^_^

I'll try to port PSPRadio dynamic version to this.... BTW, the devhook version of PSP Radio *should* work just fine as-is. Then finally, PMP VLC with WPA WiFi :)

Anyone cares about porting PSPLINK?

[laichung]

yes , I cant wait to see your app comes out since I'm doing the usbacc.prx disass, but I cant run it on my 1.5 psp. Thank you very much!

Very, very nice one :)

Seems to be the definitive solution for running homebrew on 2.71... I wonder why there is so little feedback :/

Are there any limitations to what can be done compared to 1.5 (besides what's already in the README)? I'm more interested in limitations with harware access (like the ME).

There should be accesss to me, since there is kernel mode.
I guess that homebrew for 2.71 could be more interesting in the future with the release of the camera and gps.

[ahman]

Thanks Moonlight. I downloaded your latest HEN for devhook and did some testing with iR Shell. Within my kernel mode PRX, I can use sceKernelLoadModule to load unsigned kernel mode prx, but not unsigned user mode prx. I also noticed that your user mode sample prx can load both kernel mode & user mode prxes. I supposed this is due to the differences between sceKernelLoadModule for ModuleMgrForKernel versus ModuleMgrForUser. Will you consider patching ModuleMgrForKernel to support loading of user mode prx? Thanks in advance.

[moonlight]

Thanks Moonlight. I downloaded your latest HEN for devhook and did some testing with iR Shell. Within my kernel mode PRX, I can use sceKernelLoadModule to load unsigned kernel mode prx, but not unsigned user mode prx. I also noticed that your user mode sample prx can load both kernel mode & user mode prxes. I supposed this is due to the differences between sceKernelLoadModule for ModuleMgrForKernel versus ModuleMgrForUser. Will you consider patching ModuleMgrForKernel to support loading of user mode prx? Thanks in advance.

I didnt knew that. The kernel of 2.71 is very odd, it needs still a lot of patches He doesn't like pspsdk prx' ;) , there are not that much problems with $ce decrypted modules.

[mbf]

Mhhh... interesting, that's also what I was looking for when speaking of limitations ;)

Moonlight, could you give us a bit more background info regarding kernel/user separation in 2.71?

I was concerned about calling custom kernel mode libs from userland but looks like the kerneldumper sample does that just perfectly. I have however a couple of questions that are not really specific to HEN but I haven't found any answer anywhere else (may move that to another thread later ;)

In libkdumper/main.c:

Code: Select all

PSP_MODULE_INFO("LibKDumper", 0x1006, 1, 0);

/* Define the thread attribute as 0 so that the main thread does not get converted to user mode */
PSP_MAIN_THREAD_ATTR(0);

• What does the 0x1006 module attribute stand for? 0x1000 for kernel mode, but what about the 6?
• Also, since you don't link with newlib, is the PSP_MAIN_THREAD_ATTR necessary? I also suppose no main thread is created either which is ok for a pure library PRX.

In the exports stub for the prx:

Code: Select all

STUB_START "KernelDumper",0x40090000,0x00020005

• What does the 0x40090000 stand for? I know that it's related to kernel/user mode and delayed linking but I haven't found any clear documentation regarding this with all known values.
  EDIT: some info here about late binding (what I initially called delayed linking). Still doesn't explain the 0x4000 though :(
• The higher 16 bits of 0x00020005 correspond to the number of entries in the stub, but what about the lower 16?

Thankies :)[/url]

[moonlight]

The 6 of 0x1006 is nothing specific.

I've just realized seing the modules of sce that they use the number 6 for modules that would act like a library, altough it would work fine with 0x1000, 0x1007 or whatever (x & 0x1000 = 0x1000) you want :)
(libpsar.prx 0x1006, libhttp.prx 0x0006, etc) Although it could be a coincidence ;)

The PSP_MAIN_THREAD(0) was not necessary, but i just am used to put it.

Regarding to those numbers, they were generated automatically with psp_build_exports, and i don't know exactly their meaning.
The 0x4001 inside the .exp file is for the prx to export his functions to user mode modules. (via syscall)

I'l try soon or later to bypass some more protections. Still, it's better to compile kernel modules with USE_KERNEL_LIBS = 1, to avoid it using functions intended for user modules.

[mbf]

Thanks for the clarifications :)

The 0x4001 inside the .exp file is for the prx to export his functions to user mode modules. (via syscall)

Ok. Looking at the devhook SDK, the DevHookForKernel lib is flagged as 0x00010000 and DevHookForUser is flagged 0x40090000....

So we could deduce something like:

Code: Select all

#define MODULE_TYPE_KERNEL 0x0001
#define MODULE_LATE_BIND   0x0008
#define MODULE_FOR_USER    0x4000 // i.e. callable from userland, or generate syscalls, or whatever :(

Also, regarding the 0x1006, could it be related to SCE_MODULE_ATTR_CANT_STOP, SCE_MODULE_ATTR_LOAD and SCE_MODULE_ATTR_START? (see http://hitmen.c02.at/files/yapspd/psp_d ... ml#sec26.5)

Still, it's better to compile kernel modules with USE_KERNEL_LIBS = 1, to avoid it using functions intended for user modules.

That makes perfect sense, and unless there's a good reason to do it, I would not even let kernel modules call user ones as that would break the very idea of privilege separation.

@ahman: any good reason to load unsigned user mode PRXs from a kernel one?

[laichung]

Thanks moonlight for HEN for devhook, now I can test those 2.7 modules. But I dont know why those Kprintf function in PSPSDK make my app return and give error "SCE_KERNEL_ERROR_LIBRARY_NOTFOUND = 0x8002013c"

After take a look at the src of PSPSDK about debug, I found those kprintf handler require kd/sysmen.prx. And I think it should load when the PSP boot (from the pspbtcnf*.txt file). I also try to load it again from my app and loading error return. So anyone know what happen?

Ps, I included -lpspdebug in my Makefile. And it can build runnable app if I dont call pspDebugInstallKprintfHandler function.

Thanks

[moonlight]

Thanks moonlight for HEN for devhook, now I can test those 2.7 modules. But I dont know why those Kprintf function in PSPSDK make my app return and give error "SCE_KERNEL_ERROR_LIBRARY_NOTFOUND = 0x8002013c"

After take a look at the src of PSPSDK about debug, I found those kprintf handler require kd/sysmen.prx. And I think it should load when the PSP boot (from the pspbtcnf*.txt file). I also try to load it again from my app and loading error return. So anyone know what happen?

Ps, I included -lpspdebug in my Makefile. And it can build runnable app if I dont call pspDebugInstallKprintfHandler function.

Thanks

KPrintf is a kernel export (KDebugForKernel). You cannot use it in the main prx which is a n user one.

[mbf]

Tried SysMemUserForUser_13A5ABEF (sceKernelPrintf) instead?

[ahman]

I didnt knew that. The kernel of 2.71 is very odd, it needs still a lot of patches He doesn't like pspsdk prx' ;) , there are not that much problems with $ce decrypted modules.

It seems the problem isn't related to pspsdk prx. I tried to use sceKernelLoadModule to load both "EBOOT.BIN" & "BOOT.BIN" from a UMD game disc within my kernel mode prx. It also failed with the same error code "80020148", same as loading a pspdk user mode prx. FYI, the UMD Game disc BOOT.BIN, EBOOT.BIN are also user mode modules.

@ahman: any good reason to load unsigned user mode PRXs from a kernel one?

Some of the stuff can't be done under a kernel mode prx, such as WiFi and you'll need to do it under a user mode prx.

[moonlight]

$ce libatrac3plus encrypted from firmware loaded fine for me and it's a user module.
However decrypted didn't load.
EBOOT.BIN... well, that's an special case.

All of them are probably patchable, i'll see.

[ahman]

$ce libatrac3plus encrypted from firmware loaded fine for me and it's a user module.
However decrypted didn't load.
EBOOT.BIN... well, that's an special case.

All of them are probably patchable, i'll see.

Thanks for looking into it, really appreciated.

[laichung]

So I should make a prx to call sceKernelRegisterKprintfHandler then load prx from the main prx, right? Thanks.

KPrintf is a kernel export (KDebugForKernel). You cannot use it in the main prx which is a n user one.

[mbf]

As moonlight pointed out, kprintf and sceKernelRegisterKprintfHandler are both kernel exports (KDebugForKernel). So yes, you could call kprintf from a kernel mode PRX used as a bridge.

Now remember that in most operating systems, kprintf is meant for kernel and drivers debugging where there is no easy (or guaranteed) way to output information.

[laichung]

Thanks for information

I want to use sceKernelRegisterKprintfHandler because I want to redirect the debug information on screen. May be I should build a Serial cable instead.

But I encounter a problem now. I write a simple prx with a function call sceKernelLoadModule to load a prx. I load that prx from main.prx then call that function, but it return "SCE_KERNEL_ERROR_ILLEGAL_PERM_CALL = 0x80020149". I already use KernelLIB and KernelLIBC. Is there anything I miss?

As moonlight pointed out, kprintf and sceKernelRegisterKprintfHandler are both kernel exports (KDebugForKernel). So yes, you could call kprintf from a kernel mode PRX used as a bridge.

Now remember that in most operating systems, kprintf is meant for kernel and drivers debugging where there is no easy (or guaranteed) way to output information.

[chunglam]

Hi Dark_AleX,
I ported my Devhook launcher mod to fw2.71 with HEN_C by reference the source code of your original launcher ported to fw2.71. Everything is fine until I exit the launcher. I know the HEN was removed from memory because DH need to take over control of PSP reboot, the problem is I can't reload HEN_C unless I cold restart PSP or I should reload the HEN_C module before exit to XMB? and how? Another question is it seems you include HEN_B for DH in your new release fw2.71se custom firmware, is there any specific reason to use HEN_B instead of HEN_C? Compatibility issue? Thanks in advance.

[tnt]

What about support for other fw revision like 2.6 ?