Homebrew [Release] Homebrew Emergency Launcher

[Xenosaiga]

The newest version breaks for me somehow... It only launches a black screen.

 

[Xenosaiga]

I seem to have fixed my issue.

Edited the boot configure file and added a delay of 100 to Default boot.

 

[mid-kid]

Well, I tried to find how to filter main.c out, it didn't work. I will try those instructions after you merge my fixes, though. I needed to fork it anyways to fix the warns (I will delete the fork if all works out in the end).

Anyway, since you're here @mid-kid, let me ask you something: is there any difference between load_arm9_payload() and load_arm9_payload_from_mem() (aside that the second one expects the payload in the memory already)? Because I tried to use load_arm9_payload, and while this works with /Cakes.dat it does not seem to work with /rxTools/sys/code.bin. I had to do something similar to what is included in CakeBrah's main.c to make it work with both.

If load_arm9_payload() does not work as it should, why not transform this function to do something similar in what is included in main.c already, loading the payload in memory and calling load_arm9_payload_from_mem() in the end? I could even do this if you want, and do another PR (however, it would be better to first merge the other PR so there is no conflict).

Edit: forgot to mention, I actually did not use load_arm9_payload() since it does not support offset parameter, so I included the modification from @d0k3. However, the modification should have worked. Ideally, the new function should be similar to what main.c does, however including parameters to pass both payload offset and payload size, like the modification from @d0k3. This would make this function actually useful, and I would not have to write a wrapper in my program.

The difference between both those functions is, indeed, that one loads the payload from a file.
The only thing I do in main.c is loading the file from a different offset.
When making it, I'd never really thought about CakeBrah being used as a library later on. It breaks compatibility with Brahma arm9 payloads.
But I could see adding an offset parameter to load_arm9_payload() would be useful (and I wouldn't mind adding it).

 

[m45t3r]

The newest version breaks for me somehow... It only launches a black screen.

I seem to have fixed my issue.

Edited the boot configure file and added a delay of 100 to Default boot.

Are you using .3dsx or payload files? N3DS or O3DS? CFW or Homebrew?

I focused in payload files for this release, so I didn't tested .3dsx as much, however I did make some tests and it did seem to work. I may return to the old delay method for .3dsx files, and keep the new method for payloads, if this helps.

The difference between both those functions is, indeed, that one loads the payload from a file.
The only thing I do in main.c is loading the file from a different offset.
When making it, I'd never really thought about CakeBrah being used as a library later on. It breaks compatibility with Brahma arm9 payloads.
But I could see adding an offset parameter to load_arm9_payload() would be useful (and I wouldn't mind adding it).

Well, the thing I find strange is, load_arm9_payload() and load_arm9_payload_from_mem() should be equivalent, however they're not. Like I said, rxTools' code.bin does not work with load_arm9_payload(), however it works with load_arm9_payload_from_mem() (after manually loading the payload in memory). Cakes.dat works with both.

I was thinking that the load_arm9_payload() should be something like this: https://gist.github.com/m45t3r/a577fa84adbfda62d9e7

Calling load_arm9_payload_from_mem() inside load_arm9_payload would helps maintainability of the code too, since any change in load_arm9_payload_from_mem() would be applied in both functions.

 

[Xenosaiga]

@m45t3r

.3dsx files with home brew on N3DS

Boot is emergency launcher.
Boot_default is grid launcher.
Boot_1 is Smealums launcher.

Almost always launched with Themehax.

 

[mid-kid]

Well, the thing I find strange is, load_arm9_payload() and load_arm9_payload_from_mem() should be equivalent, however they're not. Like I said, rxTools' code.bin does not work with load_arm9_payload(), however it works with load_arm9_payload_from_mem() (after manually loading the payload in memory). Cakes.dat works with both.

I was thinking that the load_arm9_payload() should be something like this: https://gist.github.com/m45t3r/a577fa84adbfda62d9e7

Calling load_arm9_payload_from_mem() inside load_arm9_payload would helps maintainability of the code too, since any change in load_arm9_payload_from_mem() would be applied in both functions.

Cakes.dat shoudn't load with load_arm9_payload. If it does, there's something really weird happening (the spider code is located at offset 0. Furthermore, rxTools' code.bin has the same layout as Cakes.dat, since they both use CakeHax).
The thing with load_arm9_payload and _from_mem is they both load the payload to g_ext_arm9_buf. One by reading from the file, the other by reading from a memory location.
Calling _from_mem from load_arm9_payload is pretty stupid, since you need a temporary storage which you copy the file to, to then copy it again to g_ext_arm9_buf. And tbh, there's barely any maintainability gains from doing it that way.

 

[m45t3r]

Cakes.dat shoudn't load with load_arm9_payload. If it does, there's something really weird happening (the spider code is located at offset 0. Furthermore, rxTools' code.bin has the same layout as Cakes.dat, since they both use CakeHax).
The thing with load_arm9_payload and _from_mem is they both load the payload to g_ext_arm9_buf. One by reading from the file, the other by reading from a memory location.
Calling _from_mem from load_arm9_payload is pretty stupid, since you need a temporary storage which you copy the file to, to then copy it again to g_ext_arm9_buf. And tbh, there's barely any maintainability gains from doing it that way.

Oh sorry, like I said before I included the modifications from @d0k3 for it: https://github.com/d0k3/BrahmaLoader/blob/loader2/source/brahma.c#L179. Maybe his modification is wrong, however at least looking for his code it seems right.

Anyway, why does load_arm9_from_mem() does a memcpy anyway? Looking at it, can't you simple data = g_ext_arm9_buf?

--------------------- MERGED ---------------------------

@m45t3r
View attachment 28400
.3dsx files with home brew on N3DS

Boot is emergency launcher.
Boot_default is grid launcher.
Boot_1 is Smealums launcher.

Almost always launched with Themehax.

Since I don't have many users in this homebrew I don't know how I could fix. Would need another O3DS user to see if I somehow messed up with something in this last release. I could go back to 100 ms for delay, however I remember that at 100 ms booting payloads was not working. 150 ms works for me in both.

 

[m45t3r]

@m45t3r
View attachment 28400
.3dsx files with home brew on N3DS

Boot is emergency launcher.
Boot_default is grid launcher.
Boot_1 is Smealums launcher.

Almost always launched with Themehax.

I tested and went back to 100 ms of delay, seems to work ok for me. However, since you're using Homebrew anyway, you could just set delay to 0 and get a faster boot.

 

[Xenosaiga]

I tested and went back to 100 ms of delay, seems to work ok for me. However, since you're using Homebrew anyway, you could just set delay to 0 and get a faster boot.

Faster boot means nothing if it fails 6 out of ten times!!!!


I would rather have a slower more stable boot that to have a faster breakable boot.

 

[m45t3r]

Faster boot means nothing if it fails 6 out of ten times!!!!


I would rather have a slower more stable boot that to have a faster breakable boot.

Yeah, I know, however I never had a failed boot in Homebrew Launcher with delay 0 (and this is what I set for my Homebrew Launcher entry since, forever).

Actually, the original code from mashers didn't had any of those delays, I included them since I am a rxTools/CakesFW user and this helps to improve boot rate in these cases. Homebrew Launcher it never helped at all.

 

[Xenosaiga]

Yeah, I know, however I never had a failed boot in Homebrew Launcher with delay 0 (and this is what I set for my Homebrew Launcher entry since, forever).

Actually, the original code from mashers didn't had any of those delays, I included them since I am a rxTools/CakesFW user and this helps to improve boot rate in these cases. Homebrew Launcher it never helped at all.

I'll mess around with it later when I'm back at home.

 

[Razor83]

This looks great! I just have a couple of questions;
-If I dont enter a 'default' setting in the boot_config.ini file, will this load the original System Menu if I dont hold any buttons?
-Is it compatible with Gateways launcher.dat?

I am hoping I can setup the boot_config.ini file likes this:-

[KEY_L]
path = /launcher.dat
delay = 150
payload = 1

[KEY_R]
path = /rxTools/sys/code.bin
delay = 150
payload = 1
offset = 0x12000

[KEY_SELECT]
path = /boot_hbl.3dsx
delay = 150

 

[mid-kid]

Anyway, why does load_arm9_from_mem() does a memcpy anyway? Looking at it, can't you simple data = g_ext_arm9_buf?

Because the function is meant for you to be able to free the memory in use after running it. Brahma also sets a max size for the payload, and aligns it, so you don't have to worry about it yourself.

 

[m45t3r]

This looks great! I just have a couple of questions;
-If I dont enter a 'default' setting in the boot_config.ini file, will this load the original System Menu if I dont hold any buttons?
-Is it compatible with Gateways launcher.dat?

I am hoping I can setup the boot_config.ini file likes this:-

[KEY_L]
path = /launcher.dat
delay = 150
payload = 1

[KEY_R]
path = /rxTools/sys/code.bin
delay = 150
payload = 1
offset = 0x12000

[KEY_SELECT]
path = /boot_hbl.3dsx
delay = 150

If you don't put a 'default' section, it it will default to /boot_default.3dsx. I don't know how you could call System Menu, probably using something similar that HANS use (however, remember that HANS is still closed source so I can't look at its source code), and even them remember that you still have *hax running underground, so it wouldn't act like the real System Menu at all (probably title loading wouldn't work, etc.)*.

DId not test with Gateway (did not have one), however unless Gateway have a .3dsx file compatible with Ninjhax or their .dat is compatible with CakeBrah (and it is probably not, they must have their own payload loader code), it is probably not compatible.

For the rest, yeah, it would work. However you probably want something to be your default boot. And just FYI, it will auto detect if a file is a payload (so you don't need to pass payload = 1), and 0x12000 is the default offset. 150 of delay is the default too (however, I changed to 100 in GitHub, this seems to work better with N3DS like @Xenosaiga reported).

*: what you can maybe try is creating a custom .3dsx file that loads the System Menu using HANS (http://wololo.net/2015/10/28/tutorial-hack-pack-3ds-rom-use-hans/), and put this as your default entry. However, I don't know if System Menu is even considered an application (probably it is not).

Edit: the question really is: what is the problem of pressing L when loading your system, so themehax is ignored and you will boot in System Menu? BTW, I think you're using themehax with autoboot on or you wouldn't ask this question.

 

[d0k3]

Cakes.dat shoudn't load with load_arm9_payload. If it does, there's something really weird happening (the spider code is located at offset 0. Furthermore, rxTools' code.bin has the same layout as Cakes.dat, since they both use CakeHax).
The thing with load_arm9_payload and _from_mem is they both load the payload to g_ext_arm9_buf. One by reading from the file, the other by reading from a memory location.
Calling _from_mem from load_arm9_payload is pretty stupid, since you need a temporary storage which you copy the file to, to then copy it again to g_ext_arm9_buf. And tbh, there's barely any maintainability gains from doing it that way.

Oh sorry, like I said before I included the modifications from @d0k3 for it: https://github.com/d0k3/BrahmaLoader/blob/loader2/source/brahma.c#L179. Maybe his modification is wrong, however at least looking for his code it seems right.

Anyway, why does load_arm9_from_mem() does a memcpy anyway? Looking at it, can't you simple data = g_ext_arm9_buf?

I think you both are right, the mem reading feature could have been implemented better. Will see about it once I get back to that code. Other than that... the code.bin has to be loaded from offset 0x1200, I think (not entirely sure, though). And if anything else doesn't work, please let me know.

 

[m45t3r]

I think you both are right, the mem reading feature could have been implemented better. Will see about it once I get back to that code. Other than that... the code.bin has to be loaded from offset 0x1200, I think (not entirely sure, though). And if anything else doesn't work, please let me know.

The offset was right, I am sure of it (and btw, it is 0x12000, not 0x1200).

 

[m45t3r]

I think you both are right, the mem reading feature could have been implemented better. Will see about it once I get back to that code. Other than that... the code.bin has to be loaded from offset 0x1200, I think (not entirely sure, though). And if anything else doesn't work, please let me know.

@d0k3, sorry, your code works perfectly.

The problem is, I used the wrong payload size. Originally I tried to use 0 (that tries to autodetect the payload size based on the actual file size), however since code.bin from rxTools is so big (almost 1MB), it would always use psize=ARM9_PAYLOAD_MAX_SIZE. Now, I don't know exactly why this break things, however it breaks.

@cpasjuste uses 0x50000 to limit the payload size (just FYI, ARM9_PAYLOAD_MAX_SIZE is 0x100000), while CakeBrah uses 0x10000. Just passed 0x10000 instead of 0 in the last parameter and magically rxTools' code.bin works. This may be why you had problems with BrahmaLoader too.

The sad thing is, 0x10000 seems to be too big for Cakes.dat, so the function returns 0 even when it should work.

 

[Argentlan]

in my case the emergency launcher always crash by default and only loads the boot that was in L trigger
when I notice that I have to remove the ";" in boot_config.ini to actually do something it works
I was just wondering why default_boot.3dsx came with ";" before the command by default

 

[d0k3]

@d0k3, sorry, your code works perfectly.

The problem is, I used the wrong payload size. Originally I tried to use 0 (that tries to autodetect the payload size based on the actual file size), however since code.bin from rxTools is so big (almost 1MB), it would always use psize=ARM9_PAYLOAD_MAX_SIZE. Now, I don't know exactly why this break things, however it breaks.

@cpasjuste uses 0x50000 to limit the payload size (just FYI, ARM9_PAYLOAD_MAX_SIZE is 0x100000), while CakeBrah uses 0x10000. Just passed 0x10000 instead of 0 in the last parameter and magically rxTools' code.bin works. This may be why you had problems with BrahmaLoader too.

The sad thing is, 0x10000 seems to be too big for Cakes.dat, so the function returns 0 even when it should work.

Well, I don't know about the ARM9_PAYLOAD_MAX_SIZE. 0x100000 always seemed arbitrary to me though.

Anyways, I've been trying this for the first time today, and by now it seems this has far surpassed it's initial purpose as an Emergency Launcher. The one, last killer feature that would make me jump ship from CTR Boot Manager (no offense meant for cpasjuste), is a launch menu. Ie. press a specific button to get into a menu containing multiple start entries. In theory, this should be possible by just adding CTR Boot Manager as one of the start entries, but in fact there are problems when launching CTR Boot Manager from Emergency Launcher (buttons don't work, boot rate for CFWs gets worse). For CTR Boot Manager, I've never managed to get WiFi working properly (N3DS v9.0.0 EUR), while Masher's stuff always did this fine, regardless of boot method.

 

[m45t3r]

in my case the emergency launcher always crash by default and only loads the boot that was in L trigger
when I notice that I have to remove the ";" in boot_config.ini to actually do something it works
I was just wondering why default_boot.3dsx came with ";" before the command by default

Actually, ; just indicate a comment in .ini files. So the [DEFAULT] entry was just a example. It should work though, since when the [DEFAULT] section is not set the values are loaded from the code itself, and are the same as commented in the config file.

Are you sure that if you comment out all entries in [DEFAULT] a file boot_default.3dsx does not work (crashes, etc.)? If not, this is probably a bug.

Well, I don't know about the ARM9_PAYLOAD_MAX_SIZE. 0x100000 always seemed arbitrary to me though.

Anyways, I've been trying this for the first time today, and by now it seems this has far surpassed it's initial purpose as an Emergency Launcher. The one, last killer feature that would make me jump ship from CTR Boot Manager (no offense meant for cpasjuste), is a launch menu. Ie. press a specific button to get into a menu containing multiple start entries. In theory, this should be possible by just adding CTR Boot Manager as one of the start entries, but in fact there are problems when launching CTR Boot Manager from Emergency Launcher (buttons don't work, boot rate for CFWs gets worse). For CTR Boot Manager, I've never managed to get WiFi working properly (N3DS v9.0.0 EUR), while Masher's stuff always did this fine, regardless of boot method.

I don't think it is arbitrary, it seems to be something related to the space in the VRAM. I actually calculated this value from the parameters that is defined in exploitdata.h.

Maybe it would be better to define psize parameter to maximum allowed payload size instead of a absolute value. This would make it work with rxTools, and would not break Cakes.dat.

I will probably rename this project and create a new topic. @mashers doesn't seem interested in this project anymore, and the fact that I don't have any control over OP is bad (since I can't edit the first topic to include the new features that I implemented). And well, HBL-emergency is a bad name considering the features this project supports now.

A menu wouldn't be a bad idea, however I probably wouldn't implement a menu so nice looking like CtrBootManager. Probably using ctrcommon?