Advertising (This ad goes away for registered users. You can Login or Register)

Adapting HBL to other exploits

This is the development forum of the half-byte loader project. For general Half Byte Loader questions, visit the Half Byte Loader forum.
Forum rules
This forum is for HBL Development discussions ONLY. For User support or HBL general discussions, go to viewforum.php?f=3 . Messages that are not development related will be deleted.
Locked
cscash241
Banned
Posts: 105
Joined: Mon Sep 27, 2010 6:52 pm

Adapting HBL to other exploits

Post by cscash241 »

Recovered from Advancedpsp
*Originally posted by Wololo

This is to discuss the best way to port HBL to other games, while keeping the changes as minimal as possible. From J416's port, after a quick glance, here's what I saw, and how I plan to merge it:

Basic idea: a specific included ".h" file for each exploit, in which we will put game-specific variables whenever needed

I believe in compile-time settings (.h file), at least for a first version. "config files" imply that the user should be able to tweak to their exploit, which IMO means they are ok programmers. In that case, I think compile-time configuration is as good (better?) than runtime configuration

- hardcoded Addresses in memory.c (list of threads to delete, etc...) -> move to "patapon.h", "minna1.h", etc... (+ need explanations on how to retrieve those values with psplink)
- stubs defined in eLoaderConf.rb (generate config/*) -> create a new eLoaderconf.rb for each exploit? will need memdumps from users on various firmwares + explanations on how to retrieve the stubs
- hardcoded load address in loader.h (where to load HBL in Ram) -> move to patapon.h etc...
- Makefile -> one makefile per exploit. defines which .h to load + other stuff. Ideally calls a common "Makefile" that defines everything that is shared by all games
- Firmware version computation + PSP Go detection (in utils.c ?) -> requires to get a bunch of user memdumps with various models/firmwares, and compare them
- Function Hooks: need to be conditionally compiled. (1 flag per function???). The flags will be defined in patapon.h, minna1.h, etc... (for example: #define HOOK_PEEK_POSITIVE_WITH_READ_POSITIVE or that kind of stuff). Let's define flags only if needed, as game exploits get discovered, we don't need thousands flags if all games use the hooks anyways.

Everything that is "game specific" (such as the sdk.S, generated config files, eLoaderconf.rb) should be moved in a game-specific subfolder (except the makefiles ?)

That's pretty much all I can think about for now, will update as I start working on the merges. Comments welcome

Important note: at least h.bin needs to be recompiled for each game. For this reason, I believe it is not worth the effort to move game-specific things into config files (versus .h files, I mean). In all cases, we will need to distribute different archives to avoid confusing the users anyways. (Firmware-specific things, on the other hand, are ok in config files, because of Ram usage constraints, we don't want to distribute one HBL per firmware, AND we don't want to store in Ram all information for all firmwares, I guess)
Advertising
m0skit0
Guru
Posts: 3817
Joined: Mon Sep 27, 2010 6:01 pm

Re: Adapting HBL to other exploits

Post by m0skit0 »

This also was solved (although not fully satisfactory IMHO).
Advertising
I wanna lots of mov al,0xb
Image
"just not into this RA stuffz"
JJS
Big Beholder
Posts: 1416
Joined: Mon Sep 27, 2010 2:18 pm
Contact:

Re: Adapting HBL to other exploits

Post by JJS »

What was not done at all is individual hooking code for the different exploits. They all still use the same overrides as Patapon.

I guess we should identify which hooks can be removed because they are known through the p5 stubs. I think this affects all (at least most) of the sceIO* hooks (and the respective tests) as well as sceCtrlPeekBufferPositive and scePowerGetBatteryLifePercent. There might be more, but this has to be checked. I see no reason why the p5 stubs would become unavailable in a future exploit, since the savedata utility functions will obviously be present in an exploitet game.


One of the last discussions in the old thread was about the free memory step and whether all functions are available for that from the game. Patapon has everything but sceKernelTerminateThread and no proper replacement for it whereas golf 1/2 has seKernelTerminateDeleteThread which should be used instead I think.
Locked

Return to “Half Byte Loader Development”