are UIDs random?

[wololo]

Does anybody know how the SceUIDs are generated by the kernel? I've thought for a long time that they were random, but
1) it can't be purely random since the system has to maintain a list, and there cannot be any duplicate
2) Empirically, I've seen that:
- they all end in odd numbers: 1, 3, 5, 7, 9, B, D, F
- they start with 0, and the second number seems to be loosely linked to the "type" of object being referenced.

Does anybody have the source code for the generation of these numbers?

Usefulness: I am running in some cases where "guessing" these numbers could help me improve HBL's "free memory" step...

[wth]

indeed, in the case of my game exploit with the gpu crashing where I need to sceGeListDeQueue as many qids as possible, I actually only have the last qid of the game since it's always stored in the variable, but if we managed to guess some somehow it could help a lot

[jigsaw]

There's no global SceUID generator. It's different from module to module.
Think about file descriptor and thread id. The values of fd and tid can overlap and there's no problems w/ it, coz those belong to different modules.

EDIT: However, for some certain kmod, there must be a way to predict the pattern of UIDs. If this is key to the user exploit you mentioned, pls let me know which kmod u r interested in.

[FrEdDy]

Actually I've done some research on this (iirc powe.prx UIDs, but it should be similar for other mods too).
UIDs are actually pointers to data structures in kernel space, when the module is requested an UID, it allocates space for the struct, does some shifting on the address, and returns the result.

[garrei]

1) it can't be purely random since the system has to maintain a list, and there cannot be any duplicate
2) Empirically, I've seen that:
- they all end in odd numbers: 1, 3, 5, 7, 9, B, D, F
- they start with 0, and the second number seems to be loosely linked to the "type" of object being referenced.

why dont you just write a script with those boundaries?... im not sure how you'd go about that last bit though

[wololo]

garrei: that's pretty much what I did, but it's a bit of "hit and miss" right now...

FrEdDy: thanks for the info.So can UIDs be "guessed" based on the address in ram of the structure? Is the shifting algorithm known?

jigsaw: thanks. The specific one I'm looking at is the result of a sceKernelAllocMemory call (Sony's malloc), but I was also looking for a more generic answer, which you gave.

[FrEdDy]

garrei: that's pretty much what I did, but it's a bit of "hit and miss" right now...

FrEdDy: thanks for the info.So can UIDs be "guessed" based on the address in ram of the structure? Is the shifting algorithm known?

jigsaw: thanks. The specific one I'm looking at is the result of a sceKernelAllocMemory call (Sony's malloc), but I was also looking for a more generic answer, which you gave.

I did reverse it, should find it. Anyways it wasn't power.prx that I reversed but callbacks. Still, structures are in kmem (at least callbacks) so you can't really know where they are from usermode unless mods are always loaded to the sane address.

[jigsaw]

The specific one I'm looking at is the result of a sceKernelAllocMemory call (Sony's malloc)

Why I cant find this function? Do u mean sceKernelAllocPartitionMemory ?

[wololo]

Do u mean sceKernelAllocPartitionMemory ?

Yes

[jigsaw]

Do u mean sceKernelAllocPartitionMemory ?

Yes

This is a really tough one. I have to say I dont know all the details so dont blame me if Im wrong.

UID for sysmem is generated in subroutine SysMemForKernel_0A34C078 (660).
More specifically, value of $s2 at 0x0000B27C. You'll see why it's always odd, coz it's been logic-orred with 0x1.

$s2 is calculated by 2 factors, one of which is return value of sub_0000A9F8, which resorts to sub_00003020.

sub_00003020 is the core function for allocating memory. It returns a pointer to a piece of memory, based on given heap (a struct which holds all info related to a arena for memory allocation), size, and alignment requirement.

So in brief, SysMemForKernel_0A34C078 (sceKernelCreateUID) returns a value which is bound to the address of allocated memory.
To be able to predicate the UID, you will need to know the details and sequence of each allocation ever happened to given partition (user partition, I suppose) after game boot. Sounds impossible but I can assure you it's doable, and it's easier than it sounds.

However I'm not so keen on it coz it requires ALOT effort. Besides, there's another factor that makes up the UID, which is ... see 0x0000B258. This, I have not investigated what the hell it is. So this is a possible block point.