Homebrew Why is a payload still required for HBL?

[urherenow]

As far as I can tell, HBL isn't open source (nor the payloads). But... are there really no devs among the CFW creators capable of making their own?

This has been bugging me since a9lh, but now it's REALLY bugging me with b9s. We should already have all permissions required of the HBL, so why the need for a payload at all? There should be a stand-alone .cia that can launch directly from the home menu, and I'm not talking about hblauncher_loader (which STILL requires a payload for launching HBL).

 

[einhuman197]

Hbl only works with full os running and cfw patches farfar away from actual OS. Why are you frustrated. 4sec is not much.

 

[urherenow]

Hbl only works with full os running and cfw patches farfar away from actual OS. Why are you frustrated. 4sec is not much.

payloads have to be updated when the system is updated. O3DS already has issues with it (to the point that you need to trick the system by using the 11.2 payload and renaming it to look like it's an 11.4 payload).

I said, launch from the home menu, so of course the full OS is running. Duh. And with sigchecks patched via CFW or whatever method, there should be no reason that any other payload is needed.

 

[Hayleia]

Hbl only works with full os running and cfw patches farfar away from actual OS. Why are you frustrated. 4sec is not much.

This has nothing to do with what he asked for. Noticed how he mentioned a .cia.
edit: ninja'd

 

[einhuman197]

Oh. Yeh. Now I understand.

 

[urherenow]

hmmm... when I get home from work, I need to check this out and see if it's a solution: https://gbatemp.net/threads/cxitool-convert-3dsx-to-cia-directly.440385/

EDIT: tried a quick .cia conversion and HBL just freezes on the home screen. When I went to delete it, I noticed it was taking up 0 blocks (although it was clearly installed and *trying to run). I have no time to try a proper banner/logo and product code, etc to see if that's causing issues.

 

[Hayleia]

Now that I think of it, maybe there's a disgusting way to do things almost cleanly
Basically, the current cia needs a payload, right? But we don't want it on the SD card because we don't like clutter. Well then, why not include it in the cia? Like in its romfs for example? This way, nothing* to change to the way the cia works, and no payload on the SD card.

*I lied, there's one thing to change. If the payload is included in the cia, it means that we can't just update the payload after updating the firmware. We need to update the whole app. Apps can do that, but that's a thing that would have to be done in the HBL cia if we want it to work that way. And we would either need a "repo of HBL CIAs" to be able to download them from somewhere (so that the currently installed HBL can find its updated version) or a server that quickly generates the correct HBL CIA using the "existing repo of payloads".

 

[Slartibartfast42]

How do you get homebrew loader working with 11.4?

 

[PabloMK7]

While it is perfectly possible to include the payload into any CFW, it is irrelevant. You can already use hbl loader to load the payload, and nobody is going to make an standalone version just because a few seconds. It may also cause compatibility issues with some homebrew because the way 3dsx files work.

 

[Hayleia]

I don't think he's complaining about these few seconds. I think he's asking why. If we can execute what we want thanks to CFWs, why would we use a cia that mimics Cubic Ninja and loads a payload to load the HBL instead of... just loading the HBL you know? Why would we put code in 15 different locations instead of one? Yeah, of course, we can't just load the HBL interface without setting things up beforehand in order for 3dsx files to work, but why would this require a payload when the CIA could run with all permissions?

I'm not a HBL dev so I'm not saying the payload is not needed, but I agree with wondering why it would be.

 

[m1guelpf]

Now that I think of it, maybe there's a disgusting way to do things almost cleanly
Basically, the current cia needs a payload, right? But we don't want it on the SD card because we don't like clutter. Well then, why not include it in the cia? Like in its romfs for example? This way, nothing* to change to the way the cia works, and no payload on the SD card.

*I lied, there's one thing to change. If the payload is included in the cia, it means that we can't just update the payload after updating the firmware. We need to update the whole app. Apps can do that, but that's a thing that would have to be done in the HBL cia if we want it to work that way. And we would either need a "repo of HBL CIAs" to be able to download them from somewhere (so that the currently installed HBL can find its updated version) or a server that quickly generates the correct HBL CIA using the "existing repo of payloads".

Couldn't it do like yellows8 HBL loader, but saving the payload in the extdata or save instead of SD? That way, it would also be auto-updated...

 

[plug313]

I don't think he's complaining about these few seconds. I think he's asking why. If we can execute what we want thanks to CFWs, why would we use a cia that mimics Cubic Ninja and loads a payload to load the HBL instead of... just loading the HBL you know? Why would we put code in 15 different locations instead of one? Yeah, of course, we can't just load the HBL interface without setting things up beforehand in order for 3dsx files to work, but why would this require a payload when the CIA could run with all permissions?

I'm not a HBL dev so I'm not saying the payload is not needed, but I agree with wondering why it would be.

this is what he meant.

basically why do we need the HBL on a custom firmware? shouldn't the custom firmware be able to launch 3dsx files by itself without the need of payloads and other complications?

 

[GameInCanada]

has anyone tried running the homebrew launcher on 11.4 n3ds cfw without a payload? my system automatically is downloading it during HBL boot and putting it into my hblauncher folder. I didn't even know this was a thing till now, it doesn't name it otherapp.bin either?

 

[urherenow]

Couldn't it do like yellows8 HBL loader, but saving the payload in the extdata or save instead of SD? That way, it would also be auto-updated...

You need to re-read the OP.

One of several problems is that the payloads are not only different per firmware version, but also per 3ds model. None of your suggestions would work and we're still left with what we have already (hblauncher_loader). It's hard to speculate without source code, but the differing versions are most likely because they are built to hook the 3DS code at specific addresses, instead of simply searching for said address(es) every time. If CFW gives us what we need to run such a routine, there is no reason for this. If both the string of bytes to search for (for whatever needs to be hooked) changes, as well as the location, then I can understand why we need all the different payloads. Worst part is not being able to easily see what the payloads (in conjunction with HBL) are actually doing...

 

[adrifcastr]

well somone who woulf want to rewrite the hmenu would be able to make 3dsx userland homebrew "installable" like the ctr importable archives, but thats a whole bunch of work, and since a9lh the only actual cfw wad linux3ds, so if after 3 years noone made an actual cfw, then noone will make one now/drop it after he got bored

 

[The Real Jdbye]

As far as I can tell, HBL isn't open source (nor the payloads). But... are there really no devs among the CFW creators capable of making their own?

This has been bugging me since a9lh, but now it's REALLY bugging me with b9s. We should already have all permissions required of the HBL, so why the need for a payload at all? There should be a stand-alone .cia that can launch directly from the home menu, and I'm not talking about hblauncher_loader (which STILL requires a payload for launching HBL).

It is open source.
https://github.com/smealum/ninjhax2.x
https://github.com/smealum/3ds_hb_menu

There's no real reason why hblauncher_loader needs a separate payload, it's just easier that way. It makes maintaining hblauncher_loader simple, since most of the *hax work the same way.
The payload will need to be stored in some way, unless all the patches are hardcoded into hblauncher_loader, which wouldn't make much sense since it would make maintaining it much more difficult. Sure the payload could be moved to extdata or save data without too much effort but what's the point? Having the payloads easily user accessible on the SD card makes it easy to for example download the payload manually on a PC if your 3DS has no internet access, or do workarounds like renaming the 11.2 payload to 11.4. Is there anything wrong with storing it on the SD card?

The main payload was separated from the rest of the components a long time ago to make it easy to launch HBL from any entrypoint. I don't think undoing all that hard work would make much sense.

 

[TLNiles]

I guess it's mostly because payload support is maintained only by smea who don't really cares about CFW. Payloads exist so even non-CFW users would load them. Making HBL for CFW would be making separate thing, but since no one except smea and yellow8 seems to bother, it doesn't look like that anyone will ever make separate CFW version.

 

[urherenow]

It is open source.
https://github.com/smealum/ninjhax2.x
https://github.com/smealum/3ds_hb_menu

There's no real reason why hblauncher_loader needs a separate payload, it's just easier that way. It makes maintaining hblauncher_loader simple, since most of the *hax work the same way.
The payload will need to be stored in some way, unless all the patches are hardcoded into hblauncher_loader, which wouldn't make much sense since it would make maintaining it much more difficult. Sure the payload could be moved to extdata or save data without too much effort but what's the point? Having the payloads easily user accessible on the SD card makes it easy to for example download the payload manually on a PC if your 3DS has no internet access, or do workarounds like renaming the 11.2 payload to 11.4. Is there anything wrong with storing it on the SD card?

The main payload was separated from the rest of the components a long time ago to make it easy to launch HBL from any entrypoint. I don't think undoing all that hard work would make much sense.

Thanks for the reply, but it makes PERFECT sense. I'm talking about a9lh and b9s. For those who install it, why the need for any *hax at all? Why does nobody understand this question? Once you have a9lh or b9s you shouldn't need ANY *hax or ANY separate payload. It should just be able to work like any other program/game.

 

[The Real Jdbye]

Thanks for the reply, but it makes PERFECT sense. I'm talking about a9lh and b9s. For those who install it, why the need for any *hax at all? Why does nobody understand this question? Once you have a9lh or b9s you shouldn't need ANY *hax or ANY separate payload. It should just be able to work like any other program/game.

It does for the most part. Most homebrew is available in .cia format, and the ones that aren't can often be converted.
But due to how some homebrew relies on the environment set up by the *hax payload, some of them require reprogramming to work in .cia format.

 

[urherenow]

It does for the most part. Most homebrew is available in .cia format, and the ones that aren't can often be converted.
But due to how some homebrew relies on the environment set up by the *hax payload, some of them require reprogramming to work in .cia format.

Yup. That's the problem. cxitool can't fix everything

Thanks for the source links though. I forgot about it, although I did have the hb launcher source cloned already. Derp...

Although that's probably because I'm not entirely sure how to build ninjhax from source anyway (hb menu is no problem though).

X:\projects\ninjhax2.x>make all
make[1]: Entering directory `/x/projects/ninjhax2.x/firm_constants'
/bin/sh: line 0: cd: HOME not set
make[1]: *** [constants.txt] Error 1
make[1]: Leaving directory `/x/projects/ninjhax2.x/firm_constants'
make: *** [firm_constants/constants.txt] Error 2