Advertising
[Suggestion] HBL as signed EBOOT
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.
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.
Re: [Suggestion] HBL as signed EBOOT
I think it's possible to increase compatible HBs by importing all the user NIDs, then there is no syscall estimations, right ?
Re: [Suggestion] HBL as signed EBOOT
We somewhat discussed that I think, and IMO that would bloat HBL's size too much, leaving not enough room for big homebrews and actually decreasing compatibility. It might be worth a try though.
Advertising
I wanna lots of mov al,0xb
"just not into this RA stuffz"
"just not into this RA stuffz"
Re: [Suggestion] HBL as signed EBOOT
You can cover the vast majority of homebrew with a rather smallish set of NIDs. I could see an improvement in adding a few NIDs from sceImpose, sceHprm and sceUsb.
Also with the current design the NID table is limited in size, so that it is very much possible to overflow it when the homebrew uses some user mode libraries (net, mp3). If all theoretically necessary NIDs should be made available the way the NIDs are handled has to be changed overall.
What I could imagine is to only extract information about the lowest NID and the gap from the imports and to store those. Then you would never run the risk of overflowing the table with useless NIDs and could still estimate every syscall.
Edit: In fact you only need exactly two known NIDs per library to use perfect syscall estimation. Namely the first and the last export of the library. Only importing those would automatically keep the NID table small and there would only be a change necessary to get_klowest_syscall() so that the lowest syscall and gap can be extracted from the known NIDs. Nope, scratch that. It doesn't give the lowest syscall.
Also with the current design the NID table is limited in size, so that it is very much possible to overflow it when the homebrew uses some user mode libraries (net, mp3). If all theoretically necessary NIDs should be made available the way the NIDs are handled has to be changed overall.
What I could imagine is to only extract information about the lowest NID and the gap from the imports and to store those. Then you would never run the risk of overflowing the table with useless NIDs and could still estimate every syscall.
Edit: In fact you only need exactly two known NIDs per library to use perfect syscall estimation. Namely the first and the last export of the library. Only importing those would automatically keep the NID table small and there would only be a change necessary to get_klowest_syscall() so that the lowest syscall and gap can be extracted from the known NIDs. Nope, scratch that. It doesn't give the lowest syscall.
Re: [Suggestion] HBL as signed EBOOT
There are A LOT of things that can be improved on HBL, since when I initially designed it, I lacked much knowledge, which now, with the knowledge we have, can be made much more efficient, faster and smaller. I already proposed a complete re-design in the past. Now I'm not coding for PSP anymore, but if someone feels like doing it, go ahead.
I wanna lots of mov al,0xb
"just not into this RA stuffz"
"just not into this RA stuffz"
-
- Posts: 286
- Joined: Thu Nov 25, 2010 6:32 pm
Re: [Suggestion] HBL as signed EBOOT
The EBOOT is 5.5MB and yet it's mostly imports. Why does the imports take so much space?
"If you have specific questions ... don't hesitate to ask as the more generic the question is the more philosophic the answer will be" - PSPWizard
Re: [Suggestion] HBL as signed EBOOT
They don't. The 5.5 MB is mostly padding to reach the same size as the demo from which the header is copied. This is just a limitation of the signing process. The unencrypted PRX is only 26 KiB.Strangelove wrote:The EBOOT is 5.5MB and yet it's mostly imports. Why does the imports take so much space?
Re: [Suggestion] HBL as signed EBOOT
By the way I believe the signed version of TN Hen is much smaller (a few hundred kB), so I'm assuming we can do better than 5.5MB. Did he use a different wrapper maybe?
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!
Looking for guest bloggers and news hunters here at wololo.net, PM me!
Re: [Suggestion] HBL as signed EBOOT
TN-C is signed using the sukkiri demo headers (instead of World Tour Soccer 2), with gzip compression. I tried yesterday to do the same with HBL but it crashes. I don't know what the problem is since it works with over hbs and the same method, maybe my code is buggy.Wololo wrote:By the way I believe the signed version of TN Hen is much smaller (a few hundred kB), so I'm assuming we can do better than 5.5MB. Did he use a different wrapper maybe?
Edit : my mistake, I tested it on a hbl version I build from SVN, but I think I was missing something. Anyway, with the current signed HBL r113, decrypted with prxdecrypter, it works just fine with my app
Here is HBL r113 EBOOT.PBP repacked with sukkiri1 demo headers & gzip compression : download (621KB)
It may be possible to do better if we could find demos with smaller data.psp.
Re: [Suggestion] HBL as signed EBOOT
this isnt really signed its just a trick as mathieulh told me on irc.
why dont u go on pspdemocenter and look on page 3, there are really small demos there
why dont u go on pspdemocenter and look on page 3, there are really small demos there