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

Some help about HBL basics

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.
Libre
Posts: 47
Joined: Sat Jan 01, 2011 4:51 pm

Some help about HBL basics

Post by Libre »

In the process of trying to understand more deeply the basics of HBL, I'd like to start by modifying the launcher.
Basically, i'd like to store h.bin and maybe hbl.bin directly in the PSAR section of the launcher, and make it load them into memory directly from there instead of their actual locations.

I managed to get a working build of the launcher using MINPSPW 0.11.1 (didn't work with my linux psp toolchain), but of course, whenever I change the code, hbl crashes.
I'm kind of a quick learner but I'm missing basic knowledge about what (stubs I guess) I should try to modify in h.bin & hbl.bin in order to make it work, and how I could get the informations I would need.

Working with a PSP 3004 9g (can't downgrade to 6.20), It seems I'm also having some issues trying to use PSPLINK. Every command line triggers the same exception :

Code: Select all

modlist
Exception - Bus error (data)
Thread ID - 0x0408F569
Th Name   - PspLink
Module ID - 0x002B8647
Mod Name  - sceSystemMemoryManager
EPC       - 0x88002E78
Cause     - 0x9000001C
BadVAddr  - 0x29110FB4
Status    - 0x00088603
zr:0x00000000 at:0x00000000 v0:0x00000001 v1:0x00000074
a0:0x88231E18 a1:0x00000001 a2:0x88233B79 a3:0x882EACCC
t0:0x00000001 t1:0x8820D77C t2:0x00001000 t3:0x00000001
t4:0x00000001 t5:0x880157E0 t6:0x880151E8 t7:0x80020000
s0:0xDEADBEEF s1:0xDEADBEEF s2:0xDEADBEEF s3:0xDEADBEEF
s4:0xDEADBEEF s5:0xDEADBEEF s6:0xDEADBEEF s7:0xDEADBEEF
t8:0x00000004 t9:0x00000004 k0:0x00000000 k1:0x00000000
gp:0x88239190 sp:0x882EAC80 fp:0x882EBCE0 ra:0x88223F60
0x88002E78: 0x1169FF9D '..i.' - beq        $t3, $t1, 0x88002CF0
Usage: [opts]
host0:/>
Could someone point me to the right documentation, or confirm if I do need psplink or not (in which case I would have to try to make it work). Thanks.
Advertising
JJS
Big Beholder
Posts: 1416
Joined: Mon Sep 27, 2010 2:18 pm
Contact:

Re: Some help about HBL basics

Post by JJS »

Every time you change the launcher, you have to rebulid the exploit SDK. That means getting the addresses of the imported functions and the import stub address of the module.

To get the imported functions, you need prxtool and the launcher PRX. Run

Code: Select all

prxtool -f launcher.prx
to get the imports and exports of the module. Copy the output into the file "/SDK/functions.txt" and run "buildsdk.rb". This gives you the SDK in "sdk.S". Rename the file to "sdk_loader.S" and copy it into the "signed" exploit folder "/eLoader/signed/". There is a slight problem here: Prxtool didn't give me relocated addresses for functions, so I had to modify the script to add 0x08804000 to every address. Unfortunately I seem to have lost the script changes.


The address of the import stub can be retrieved from PSPLink. Run the launcher and then type in

Code: Select all

modimp @hbl_launcher
It will list all imports, and the stub address at the top.

Alternatively create a memory dump in PSPLink

Code: Select all

savemem 0x08800000 0x01800000 memdump.bin
and run "/eLoader/tools/stubs.rb".

Copy that address into the file "/eLoader/tools/imports.config generator/eLoaderconf.rb". The place where you want to copy is close to the top of the file, here:

Code: Select all

	"signed" => {
		"6xx" =>
			[
				0x088075F8 #hbl_launcher  < replace that address
			],
	},
Edit: I guess the stub address could also be read from the module info of the PRX. Probably prxtool gives it, but I cannot check on that now.

After all this run "/eLoader/tools/imports.config generator/eLoaderconf.rb" to build the config files and the "/eLoader/signed/sdk_hbl.S" file. Then rebuild HBL. You will also have to copy the new config file to the PSP.
Advertising
Libre
Posts: 47
Joined: Sat Jan 01, 2011 4:51 pm

Re: Some help about HBL basics

Post by Libre »

Thank you very much for such a detailed answer.

I guess I should start by trying to make PSPLINK work if I can't get the stub address from prxtool.

Edit : I get that from prxtool -d -u hbl.prx

Code: Select all

Debug: Size 16
Debug: Using Program Headers for binary image
Debug: Min Address 00000000, Max Address 0000AD50
Debug: Loading program 0 0x00000001
Debug: pData 0x807dfb0, iSize ad50, iBaseAddr 0x00000000, endian 0
Debug: Module Info:
Debug: Name: hbl_launcher
Debug: Addr: 0x00003740
Debug: Flags: 0x01010000
Debug: GP: 0x0000C8D0
Debug: Exports: 0x000035E0, Exp_end 0x000035F0
Debug: Imports: 0x000035F8, Imp_end 0x00003738
Is it correct if I take 0x000035F8 from last line and add 0x08804000 to obtain the stub address (0x088075F8) ?
JJS
Big Beholder
Posts: 1416
Joined: Mon Sep 27, 2010 2:18 pm
Contact:

Re: Some help about HBL basics

Post by JJS »

Libre wrote:Is it correct if I take 0x000035F8 from last line and add 0x08804000 to obtain the stub address (0x088075F8) ?
That looks correct to me.
Libre
Posts: 47
Joined: Sat Jan 01, 2011 4:51 pm

Re: Some help about HBL basics

Post by Libre »

JJS wrote:
Libre wrote:Is it correct if I take 0x000035F8 from last line and add 0x08804000 to obtain the stub address (0x088075F8) ?
That looks correct to me.
Yes it seems to be.

I did a quick modification to prxtool to add 0x08804000 to all the addresses, and I also had to fix the functions names, since the output from prxtool gave me generic names I had to replace (a simple script with an array of bad -> good names did the trick).

So currently I have a working HBL launcher including h.bin in the PSAR section. I'm going to try to include hbl.bin as well.

Thanks again for your help.

Edit: works with hbl.bin too :)
Libre
Posts: 47
Joined: Sat Jan 01, 2011 4:51 pm

Re: Some help about HBL basics

Post by Libre »

Edit: sorry for the double post, should I delete this one and edit my last ?

I managed to include the "config/imports.config_6xx" file as well, and it works but I had a little issue regarding current working directory, when I used relative paths. It seems that the CWD is lost between h.bin and hbl.bin. The config_initialize() function in config.c is called 2 times, I think 1 time when h.bin is loaded, and another 1 time when hbl.bin is loaded. The second time the CWD is different.

Since I don't want to use absolute path, I stored the correct CWD with the launcher at 0x8FFFEFF and got it back from there in the config_initialize() function.

Is there a correct and safer way to pass values between the launcher, h.bin and hbl.bin ?

Also, I'd like to know if it's possible, and how I could call getcwd() in h.bin and hbl.bin (missing reference issue). Should I take a look at the relative_to_absolute() function in hook.c instead ?
wololo
Site Admin
Posts: 3621
Joined: Wed Oct 15, 2008 12:42 am
Location: Japan

Re: Some help about HBL basics

Post by wololo »

Libre wrote:Should I take a look at the relative_to_absolute() function in hook.c instead ?
That would be the function you can use for this case, yes, but I don't remember us ever having cwd problems, especially in homebrews... but maybe between the *.bin files we should be passing additional parameters... I'm not sure anymore.
Are we even using relative_to_absolute anywhere in the code? I'm wondering if it's obsolete...
If you need US PSN Codes, this technique is what I recommend.

Looking for guest bloggers and news hunters here at wololo.net, PM me!
JJS
Big Beholder
Posts: 1416
Joined: Mon Sep 27, 2010 2:18 pm
Contact:

Re: Some help about HBL basics

Post by JJS »

Wololo wrote:Are we even using relative_to_absolute anywhere in the code? I'm wondering if it's obsolete...
Good question. Could very well be that all filepaths that HBL uses internally are absolute paths that are constructed with #defines.

The homebrew games get their path in argv[0] from HBL and then their linked-in PSPSDk newlib handles the relative to absolute path translation.


Edit: Maybe it would be interesting to check the method of putting homebrews into an ISO. With that all of HBL could be packed into the eboot and files would be present on a virtual UMD drive. But I don't know if the kernel removes that association when unloading the main module. But now thinking about it, it probably becomes unavailable since it is possible to access the real UMD drive through the Patapon 2 exploit HBL even though that demo uses an NPUMD image.
Libre
Posts: 47
Joined: Sat Jan 01, 2011 4:51 pm

Re: Some help about HBL basics

Post by Libre »

Actually I don't think I'll need the getcwd, but thanks for the tips. Maybe later I'll try to add some zlib functions too...

I managed to include every file used by the hbl in the PSAR section, and make it work (just played gPSP 0.9 with it with no 'ms0:/hbl' folder needed).
So everything is packed in the EBOOT (whose data.prx is signed with sukkiri1), including the wMenu EBOOT.PBP. The only remaining files are the wMenu resources in the 'Res' folder.

Here is this version of HBL r115M (distrib), if you want to try it (1684KB EBOOT + Res).

I'm glad I created this post, working on this is very interesting and I already learned so much things about hbl, thanks to you for helping me starting :)

Is it ok if I try to make a generator wich will use the hbl as a loader to make signed ELFs work ? For those hbs I can't convert from ELF to PRX.
JJS
Big Beholder
Posts: 1416
Joined: Mon Sep 27, 2010 2:18 pm
Contact:

Re: Some help about HBL basics

Post by JJS »

Wow, that is pretty sweet. Good job!
Libre wrote:Is it ok if I try to make a generator wich will use the hbl as a loader to make signed ELFs work ? For those hbs I can't convert from ELF to PRX.
Sure, the code is licensed under the GPL.

But I am wondering if the problem with the existing loader is just that it compiles the ELF into the loader. Therefore the ELF has to fit into the gap between 0x08804000 and 0x08900000 or it overwrites itself when the loader tries to copy it over to 0x08900000. I think this is why large homebrews like ScummVM don't work with it. Maybe modifying the loader to put the ELF into the PSAR would already solve the issue.
Locked

Return to “Half Byte Loader Development”