NOTE: this is not a C course, so please do not ask C-specific questions. Those can be answered in any decent C book.
First of all, HBL is not a normal homebrew. Since it was aimed to be run through a game exploit, it's designed to be compiled as a plain binary (hbl.bin). It's not an ELF and thus it's not a PRX. Not an EBOOT either. HBL is injected into memory when loading the exploit, ends up in main memory and finally gets executing. Since HBL is way too big to fit inside an exploit, we choose to do a double loading scheme: first the exploit loads a loader which in turn loads HBL in memory. I'll take a tour into HBL's loader in this chapter.
The HBL loader is mainly the file loader.c. Let's take a walk through it. The loader entry point is
Code: Select all
void _start() __attribute__ ((section (".text.start")));
The rest of the function is pretty well commented to be self-explanatory, except this part
Code: Select all
if ((hbl_file = sceIoOpen(HBL_PATH, PSP_O_RDONLY, 0777)) < 0)
exit_with_log(" FAILED TO LOAD HBL ", &hbl_file, sizeof(hbl_file));
else
{
LOGSTR0("Loading HBL\n");
load_hbl(hbl_file);
LOGSTR0("Copying & resolving HBL stubs\n");
copy_hbl_stubs();
LOGSTR0("HBL stubs copied, running eLoader\n");
run_eloader(0, NULL);
}
while(1)
sceKernelDelayThread(100000);
Code: Select all
tGlobals * g = get_globals();
Code: Select all
run_eloader = sceKernelGetBlockHeadAddr(HBL_block);
The rest of the function is pretty well commented and self-explanatory. So when load_hbl ends executing, it's copy_hbl_stubs that comes next. This function resolves HBL imports. And what does this mean? It means it has to prepare HBL so it can execute system calls such as sceWhatever. When loaded HBL will not know where to find such calls, and the loader has to prepare it with a minimum so it can work on its own.
copy_hbl_stubs accesses a configuration file that stores information about HBL's imports, and where you can find the exploited game's stubs (system calls) among other stuff. You can easily follow the function since with all the comments and debugs it's self-explanatory. It first reads the location of the exploited game's stubs and compare them to HBL's stubs. If they match, the address of that stub is stored. Then it writes the resolved stubs to HBL's stubs (which are also stored into the scratchpad).
When copy_hbl_stubs ends run_eloader is next. As we saw before this transfers control to the hbl.bin file which starts HBL execution.
So this is all for now, hope you find it interesting. Any questions are welcome. On the next one I'll begin with the HBL proper.
Advertising