Homebrew [RELEASE] CtrBootManager/CtrBootManager9

[OperationNT]

Hello Searinox,
I took the following capture from the latest Luma3DS (version 6.6):

patchMemSearch=636F6E6669672E62696E;
patchMemOverwriteStr=conf1.bin;
patchOccurence=0;

As you can see, there is absolutly no additional memory space for this string so the replacement mustn't be longer than 10 characters (including the dot and the extention).

 

[Searinox]

I had it figured out just a bit ago! Yes I renamed the config.bin to another name of the exact same length. Thanks for the post anyway. I was failing on OverwriteStr, I guess the W version of it WStr does Unicode? Also I set patchOccurence=1.

 

[OperationNT]

Yes, "patchMemOverwriteWStr" is supposed to be for Wide characters. But it only works with ASCII characters because a true unicode support would be a little bit complicated and would ask much more code in CtrBootManager9 (so "CtrBootManager9.bin" file size would drasticly increase). The current implementation simply adds a null byte between each character:

patchMemOverwriteStr=config.bin; <=> patchMemOverwrite=636F6E6669672E62696E00;
patchMemOverwriteWStr=config.bin; <=> patchMemOverwrite=63006F006E006600690067002E00620069006E0000;

 

[Searinox]

I think I have a problem. It seems to be taking either one patch but not the other.

Here's my setup:

1. Download arm9loaderhax.bin and put it as _boot_lk.bin in the luma folder, that is:

\luma\_boot_lk.bin

2. Set up ctrbootmanager9 for startup, and create the following config file:

[general]
brightness=2;
timeout=0;
recovery=3;
default=0;
screeninit=1;
splashTop=clear;
splashBot=clear;

[theme]
bgTop1=800000;
bgTop2=800000;
bgBottom=800000;
highlight=A04000;
borders=FFFF00;
font1=FFFF00;
font2=FFFF00;

[entry]
title=Luma-Kecleon EmuNAND;
path=/luma/_boot_lk.bin;
offset=0;
patchMemSearch=730064006D0063003A002F00610072006D003900;
patchMemOverwriteWStr=sdmc:/luma/_boot_lk.bin;
patchOccurence=0;
patchMemSearch=636F6E6669672E62696E;
patchMemOverwriteStr=lk-emu.cfg;
patchOccurence=0;
key=-1;

[entry]
title=Hourglass9;
path=/luma/_boot_hourglass9.bin;
offset=0;
key=-1;

[entry]
title=Decrypt9;
path=/luma/_boot_decrypt9.bin;
offset=0;
key=-1;

[entry]
title=GodMode9;
path=/luma/_boot_godmode9.bin;
offset=0;
key=-1;

[entry]
title=Luma-Kecleon SysNAND;
path=/luma/_boot_lk.bin;
offset=0;
patchMemSearch=730064006D0063003A002F00610072006D003900;
patchMemOverwriteWStr=sdmc:/luma/_boot_lk.bin;
patchOccurence=0;
patchMemSearch=636F6E6669672E62696E;
patchMemOverwriteStr=lk-sys.cfg;
patchOccurence=0;
key=-1;

3. Booting into the first enry, set up emuNAND Luma
4. Booting into the 2nd entry, set up regular sysNAND Luma
5. Attempt to boot NDS mode from a cart or via system settings -> DS connections

On emunand only, when booting the entry one of two things will happen, without much consistency:

1. Either your emunand boot config will be saved to config.bin instead of lk-emu.cfg(sdmc path patch doesn't work)
2. Or your console will power off when attempting to enter DS mode(config.bin patch doesn't work)

If I remove either one of the patches the other works but never both. I tried occurence=1 too, I can't seem to get 2 patches going at the same time whatever I do. I picked path length to be exactly that which it replaces in both cases to minimize any issues but still won't work.

I should mention something more: When the sdmc path patch fails, it doesn't hang in a black screen like it used to when there was no path at all. If no path is specified then Luma tries to reboot into TWL through a command to arm9loaderhax.bin which obviously won't work since it's the boot manager and not Luma, which is why we patch the path in the first place. The result is -supposed- to be a hang. Except now, what I get is a complete system shutdown, which IIRC is indicative of the path not being found, meaning that perhaps it does edit something, but does it incorrectly? I can't see what it's trying to load.

SOME TIME LATER:

I guess I should have listened to your advice in the first place and not tried to be a smartass. The reasoning in my head was to keep the config filename the same as the original as to neither write up more bytes nor write too few and leave part of the original string trailing my patch.

Your conf1.bin suggestion was perfect and your talk of no more extra space went over my head originally as just common sense, I didn't realize all its implications at first. It did not occur to me that when I was trying to write up a string of the same length, I was also adding another 0x00 byte at the end, which stomped over the adjacent memory area. Everything is working now and it was a problem on my side. If I absolutely wanted a same-length name, I should have specified the exact bytes and not a string.

Cheers m8!

 

[Vieax]

First of all nice work man , its amazing !
Does this also work for the n3ds xl panda ?

 

[OperationNT]

Hello,
I have no idea what is a "n3ds xl panda", a limited version? It perfectly works on my New3DS XL and it should work on any other 3DS.

 

[human_kirby]

Hello,
I have no idea what is a "n3ds xl panda", a limited version? It perfectly works on my New3DS XL and it should work on any other 3DS.

Its a development unit. However, since it probably a9lhaxed, it should work just the same as every other unit regarding bootmanagers. Just try it, worst case is that yoou have to change your payload on the sd card.

 

[Vieax]

ok thanks for the replys , Ill try it out

 

[Billy Acuña]

@OperationNT
Now we have B9S, so I think we need Sighax supporr for this one.

 

[Dracari]

@OperationNT
Now we have B9S, so I think we need Sighax supporr for this one.

Deffo for sure, i've been using this since early Menuhax days into A9LH now we need this into SigHax.

 

[GothicIII]

@OperationNT:

I would also be very happy for sighax support. This bootloader is really handy and extremely useful. It would be a huge waste if its not useable anymore.
Btw. I think it's a very shitty choice from aurorawright for dropping a9lh support all of the sudden and forcing everyone to move to sighax.

 

[Hayleia]

Btw. I think it's a very shitty choice from aurorawright for dropping a9lh support all of the sudden and forcing everyone to move to sighax.

I'd say it's not that of a bad thing. I mean, there was support for both menuhax and a9lh for a long time, because one was "safe" and one was "dangerous". Now, b9s isn't that much more dangerous than a9lh (I mean from the point of view of the noob who installs it). So everyone on a9lh can move on to b9s.

Except, don't do this day one with no deprecation process. Menuhax people were given time to switch from their deprecated setup to a newer one but the switch to b9s is just sudden with dropped support for the rest and now we're all left with no boot managers -.-

 

[Dracari]

this does need Work , Firmtool Does convert it and it Does boot, but trying to launch Luma's boot.firm (hasto be renamed to .bin for it to recognize it) causes a Crash.

 

[Billy Acuña]

this does need Work , Firmtool Does convert it and it Does boot, but trying to launch Luma's boot.firm (hasto be renamed to .bin for it to recognize it) causes a Crash.

Of course, all Bootloaders/CFWs needs to be recompiled with SigHax support, if not they will not work properly.

 

[Platinum Lucario]

This is unfortunate that I cannot use bootloaders with b9s. I wonder how the menuhax variation of ctrbootmanager will even be able to be recompiled to work with sighax support? I really don't see this happening, unless some custom firmware will continue support for older exploit entry points (if even possible at all).

 

[OperationNT]

I just installed B9S on my 3DS. Now, I need some time to understand how Luma3DS and GodeMod9 works with this new entry point to see if I can port CtrBootManager9.

 

[Dracari]

I just installed B9S on my 3DS. Now, I need some time to understand how Luma3DS and GodeMod9 works with this new entry point to see if I can port CtrBootManager9.

all the luck to ya.

 

[OperationNT]

Solution:
Use firmtools from here:
https://github.com/TuxSH/firmtool/releases
Call the command:
firmtool.py build CtrBootManager9.firm -n 0x23F00000 -e 0 -D CtrBootManager9.bin -A 0x23F00000 -C NDMA -i
Profit!

I add the file to the Github release.
It seems CtrBootManager9 can boot all the previous ".bin" and ".dat" files .

 

[Dracari]

Solution:
Use firmtools from here:
https://github.com/TuxSH/firmtool/releases
Call the command:
firmtool.py build CtrBootManager9.firm -n 0x23F00000 -e 0 -D CtrBootManager9.bin -A 0x23F00000 -C NDMA -i
Profit!

I add the file to the Github release.
It seems CtrBootManager9 can boot all the previous ".bin" and ".dat" files .

seems more to it than that, when i did the same thing earlier and used it to load Luma, Luma shat itself. w/ a crash.

that and new payloads/b009 executables will be in .firm

 

[Billy Acuña]

Solution:
Use firmtools from here:
https://github.com/TuxSH/firmtool/releases
Call the command:
firmtool.py build CtrBootManager9.firm -n [emoji354]0000 -e 0 -D CtrBootManager9.bin -A [emoji354]0000 -C NDMA -i
Profit!

I add the file to the Github release.
It seems CtrBootManager9 can boot all the previous ".bin" and ".dat" files .

Fair enough.
I'll wait for .firm payloads support ^ ^