UNDOCUMENTED Module Attributes

[KickinAezz]

What are these modes 5006, 5007, 0006, 0002, 3007 and 7007?

There's NO public documentation available!

-305

[SilverSpring]

Groepaz docs have a little. But my best guesses:

u8 at offset 0x4 of prx (from yapspd):
0 - NONE
1 - SCE_MODULE_ATTR_CANT_STOP
2 - SCE_MODULE_ATTR_LOAD
4 - SCE_MODULE_ATTR_START

Flags can be OR'd.

u8 at offset 0x5 of prx:
00 - None (defaults to User mode)

01 - ??
02 - POPS/Demo
04 - Gamesharing
08 - VSH
(these can be OR'd)

10 - Kernel mode
20 - Uses memlmd lib
40 - Uses semaphore lib
80 - ??
(these can be OR'd)

so 0x7007 would mean something like: kmode/uses memlmd/uses semaphore/loads/starts/cant stop

[KickinAezz]

wohoo. Very nice info! Thanks.

[crazyc]

This is off-topic, but while we're talking about undocumented flags, in sceKernelCreateSemaphore in the attr field:

2 - Allow user thread to wait on kernel semaphore
4 - Allow user thread to signal kernel semaphore

[SilverSpring]

This is off-topic, but while we're talking about undocumented flags, in sceKernelCreateSemaphore in the attr field:

2 - Allow user thread to wait on kernel semaphore
4 - Allow user thread to signal kernel semaphore

Ive only ever seen 0 & 1 used for attr in:
SceUID sceKernelCreateSema(const char *name, SceUInt attr, int initVal, int maxVal, SceKernelSemaOptParam *option);

0 used only in user modules
1 used only in kernel modules

Also, before anyone gets confused, when I wrote "40 - Uses semaphore lib", I meant the library that SCE labelled "semaphore" in memlmd.prx, ie. the KIRK engine. No relation to kernel semaphores. And seeing how the function names in that lib bare no relation either, my best guess in the lib naming is to prevent suspicion and hope people wont look into it (yeah right :P).

[crazyc]

Ive only ever seen 0 & 1 used for attr in:
SceUID sceKernelCreateSema(const char *name, SceUInt attr, int initVal, int maxVal, SceKernelSemaOptParam *option);

Trust me on this, until I set attr to 6, I got SCE_KERNEL_ERROR_ILLEGAL_PERM trying to use a semaphore created in kernel mode in a user thread.

[SilverSpring]

yes I just meant in sce modules, I've only seen 0 & 1 used, but I dont know the meanings.

EDIT:

Well anyway, as long as we're on the topic of undocumented flags, here are some the u8 flag in the prx compression header (compression header - first 0x80 bytes of prx):

u8 at offset 0x7C of prx: ~PSP executable type flag

0x00 - not executable file (ie. not ~PSP file)
0x01 - 1.00 bogus module (module attr flag of 0x1000)
0x02 - Kernel module (module attr flag of 0x1000)
0x03 - vshmain module (module attr flag of 0x0800)
0x04 - user module (module attr flag of 0x0000)
0x05-0x08 not used (returns 0x80020148 error if try to load)
0x09 - UMD game executable (module attr flag of 0x0000)
0x0A - gamesharing executable (module attr flag of 0x0400)
0x0B - unknown (module attr flag of 0x0400)
0x0C - MS updater (module attr flag of 0x0800)
0x0D - Demo executable (module attr flag of 0x0200)
0x0E - unknown (module attr flag of 0x0600)
0x0F-0x11 not used (returns 0x80020148 error if try to load)
0x12 - unknown (no attr flag)
0x13 - unknown (no attr flag)
0x14 - POPS executable (module attr flag of 0x0200)
0x15 - unknown (module attr flag of 0x0200)
0x16 - unknown (module attr flag of 0x0600)

Each exe type can be decrypted by a corresponding mesg_led function.

Which are:

0x00 - N/A
0x01 - (not decrypted with mesg_led)
0x02 - (not decrypted with mesg_led)
0x03 - sceMesgLed_driver_55E4F665
0x04 - sceMesgLed_driver_DFF0F308
0x05-0x08 - N/A
0x09 - sceMesgLed_driver_3702348B
0x0A - sceMesgLed_driver_8F096FEC
0x0B - sceMesgLed_driver_4A680E6B
0x0C - sceMesgLed_driver_AA59DE09
0x0D - sceMesgLed_driver_5FDB29F3
0x0E - sceMesgLed_driver_28BC34E1
0x0F-0x11 - N/A
0x12 - sceMesgLed_driver_739D8E56
0x13 - sceMesgLed_driver_ED47F024
0x14 - sceMesgLed_driver_418BC5CF
0x15 - sceMesgLed_driver_07037789
0x16 - sceMesgLed_driver_7EDF7F6E

[KickinAezz]

Quoting ^.

What does decrypt mean in this situation? like
pass 0x16 and it returns 0x0600?

4m psp.

[SilverSpring]

It means an encrypted ~PSP file with 0x16 at offset 0x7C can be decrypted with the function sceMesgLed_driver_7EDF7F6E.

The 0x600 is the module attribute of that particular ~PSP file (ie. at offset 0x04). I just listed the module attributes for completeness, it has nothing to do with the encryption. Just so you can see what type of modules they were.

For example, if you opened up a MS updater executable, you would find 0x0C at offset 0x7C. And the updater has module attributes 0x0800 (at offset 0x4). To decrypt the MS updater, you can use sceMesgLed_driver_AA59DE09 to decrypt it.

[KickinAezz]

oh! Thanks.

And Great project you got! *2 thumbs up*

[KickinAezz]

How come even with 0x0001|0x0002|0x0004 mod attr flags, a user mode module doesn't remain "persistent" across game mode once started as a VSH Plugin?