Proposal for reducing configuration troubles

[wololo]

the current import_config files in HBL contain 2 "parts"
One is the addresses of stubs (specific to each game and each firmware), the second is the nids needed by HBL (common to all games and all firmwares).

I'm suggesting 2 things here, inspired by discussions we've already had in the past:

1) get rid of the stubs in the config files, and have HBL search for them dynamically.
There's a concern with time here, so I suggest we to cache the result in a file. When HBL runs, if the cached file exists, load the stubs addresses from there, otherwise search for the stubs in user memory.

2) move the rest of the import_config as well as sdk_hbl.S to the eLoader folder instead of each exploit subfolder

This should improve the porting speed

Advertising

[cscash241]

would option 1 mean one version of the exploit that would auto detect what game you are using??? if so that i like that idea

Advertising

[wololo]

Not entirely, but it would easy the porting process, by having HBL do more things automatically. I think it would require less memory dumps from users, and in theory we should be able to release a working version without requiring any memory dump (which is currently the longest part of the process)

[m0skit0]

1) get rid of the stubs in the config files, and have HBL search for them dynamically.

I already tried that some time ago. The problem is actually detecting the stub's descriptors correctly. It's not as easy as it seems and you will get a lot of false positives. Also parsing the whole p2 and p5 will slow down HBL quite a bit.

one version of the exploit that would auto detect what game you are using??? if so that i like that idea

This is a good idea, but it involves a lot more work that what you might think.

Another good idea would be having HBL as a PRX (or another relocatable format we can discuss) and relocated by the loader itself. This would rid of having to compile HBL for each exploit, since it can be loaded anywhere. The loader would detect the game, check what syscalls are resolved (it already does this) and load, relocate and resolve known syscalls for HBL. The main problem here is to load a PRX or create a design for a custom relocation format (which is not a good idea IMHO since we already have the PRX relocation coded).

[JJS]

The way p5 stubs are searched now is by a semi-automatic process. For each module a memory address is given that is just below the actual address of the stub for all firmwares. This minimizes the search times.

I think the same could be doable with the main user memory addresses. Either give approximate start addresses and the module name in exploit_config.h or just give the module names and search the whole memory. Then cache the results in a file.
The libraries are also always(?) in a certain memory region, there is sceKernelLibrary loaded at the bottom of user memory, the main game module gets always relocated to the same address which puts the stub somewhere around 0x08A00000 and the additional libraries must be at the top of user memory (0x09D0000+). So even on the first run, not all of user memory has to be searched.

[m0skit0]

I agree JJS, but that way you would still need to reference memory addresses, which would likely not be universal for any game, specially on p2, but also for newer firmware versions on p5.

he main game module gets always relocated to the same address which puts the stub somewhere around 0x08A00000 and the additional libraries must be at the top of user memory (0x09D0000+)

That might be true for new games, but not for old ones which are all static (main game module), thus loaded at 0x08900000.

But yes, I do agree that you won't have to search the whole user memory (p2+p5) but it would be close to the whole thing IMHO. The more you narrow it, the most likely it will eventually fail with a given game.

Also an idea to detect stub descriptors more correctly: implementing a method that checks whether the library name pointed by the supposed stub descriptor is actually a valid string, something fast (and ugly) like

Code: Select all

// p = pointer_to_library_name_found_on_supposed_stub_descriptor
int is_libname(char* p)
{
	return (p[0] >= 'A' && p[0] <= 'Z' && p[1] >= 'a' && p[1] <= 'z');
}

Of course we should check if other elements of the stub descriptors are valid as well (e.g. pointers can be masked with 0x0FFFFFFF if I'm not mistaken).

The main problem is recognizing a valid NID, since they're random (i know they're mostly SHA-1 of the original SCE function name, but this counts as good as random).

[coyotebean]

I usually start my search for module by using the module_info NID 0xF01D73A7