Homebrew ARM9Loader -- Technical Details and Discussion

  • Thread starter Thread starter Selver
  • Start date Start date
  • Views Views 579,370
  • Replies Replies 4,025
  • Likes Likes 42
Can someone explain what people mean by "Goodbye emunand" and the benefits of it? From what I'm getting is that it is safe enough to have only sysnand and maybe even have a completely updated sysnand with the ability for homebrew to be installed, and sigpatches still.
 
Can someone explain what people mean by "Goodbye emunand" and the benefits of it? From what I'm getting is that it is safe enough to have only sysnand and maybe even have a completely updated sysnand with the ability for homebrew to be installed, and sigpatches still.
well some people don't want emunand now that we have this bootloader for a9lh that can load decrypt9. what I suggest though it to keep emunand just incase you may ever need it again as a testing field of sorts.
 
well some people don't want emunand now that we have this bootloader for a9lh that can load decrypt9. what I suggest though it to keep emunand just incase you may ever need it again as a testing field of sorts.
You can easily regain an emuNAND though. I made an emuNAND backup (9.2) before I deleted my emuNAND, in case I ever need it. I also didn't delete the data for that NAND in my Nintendo 3DS folder.
 
  • Like
Reactions: klear
Can the A9LH payload be coded so that if it doesn't detect the payload on the SD, it launches normally to sysnand?
AFAIK, this isn't possible since FIRM0/1 are corrupted, and AL9H payloads boot FIRM off of the SD card.

Well, the FIRM0 and FIRM1 partitions are only 4MB in size. Therefore, this is DEFINITELY doable, and there are many options.

  • On the N3DS with the 1.8GB flash, just use SysNAND that follows the [last partition listed in the] partition table... you have hundreds of megabytes to play with.
  • If O3DS and N3DS w/1GB flash have 4MB extra space at the end, can also just use the space after the [last partition listed in the] partition table on those.
  • Sacrifice some or all of the TWL NAND (DSi) partition (e.g., some/all of twlp) to store "real" firmware
Given the following:
  • Each firmware partition is 4MB in size.
  • The new3ds 9.0 firmware is less than 1MB.
  • payload_stage1.bin compiles to a relatively tiny size... less than 5k.
Therefore, additional options exist:
  • Save a second copy (or two) of the firmware, starting at 2MB into FIRM0 partition.
  • Save a few thousand copies of the 5k that was overwritten by the payload_stage1.bin file in the unused space of the FIRM0 partition.
  • Sacrifice the 192k AGB_FIRM GBA SaveGame area.
  • Save lots of copies of that 5k past the declared end of the last partition (CTR NAND)... the eMMC device probably has a few extra sectors, if flash drives for PCs are any hint to eMMC behavior.
  • Do all three! A second copy of firmware at 2MB offset, a few thousand copies of the original 5k that was corrupted at 3MB offset, and lots of copies of the 5k past the last partition. (yes, listing this for emphasis only)
Accordingly, it's just a matter of analyzing which of the options would be "best", in terms of specific needs.
Let's get creative!

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

CTRNAND is encrypted, so it would require having read access to it. You would need to setup the console unique keys for this. I don't know if you would have enough space for that.

Hi Mrrraou,

There is *LOTS* of unused space with A9LH. Look at how much is (un)used space in FIRM0. With a firmware that's less than 1MB, and a 4MB partition, I'd say the only tough part is the initial loader. There's not even any need to encrypt the data. :)
 
Last edited by Selver,
That's something my bootloader already does(on the devices it works).


Maybe I will try to port ctrbootmanager, after my bootctr like bootmanager is working, and nobody did it already till then. While Bootctr is more simple, ctrbootmanager has a nice ui, so especially with screen init it would be an interessting project :)
CtrBootManager is already worked on and progress is going well :p
 
Correct me if I'm wrong:

With the new bootloader we can...
- Load any CFW (including GW).
- Load almost any homebrews (I know that Decryp9 needed some modification, perhaps kernel stuff?)
 
Right now with a9lh we can


My custom AuReiNand boot image. (splash.bin on this post)
[made with https://xem.github.io/3DShomebrew/tools/image-to-bin.html]
bP942ep.png



well, thanks to bilis for all his help and answering all of my noob questions, and for his screen init code and other code and stuff he's provided me that's made all of this possible, we now have a nice installer... get it while it's hot guys :)

directions: run the installer with the provided stage0x5C000 from your EXISTING arm9loaderhax install




Cheers to @Supster131 for posting this in #cakey IRC

a9lh users only
USE AT YOUR OWN RISK


This is a early port of Decrypt9WIP that will work in conjunction with @RednaxelaNnamtra 's port of bootctr.

Just to be safe create the file "root:\rei\installeda9lh"


Add a entry in your boot_config.ini and hold A on boot to load.


Code:
[KEY_A]
path = /Decrypt9WIP.bin
screenEnabled = 1
delay = 100
offset = 0
payload = -1


Here is a alpha alpha version of my bootloader(including the bootloaderloader), were I included the screen init code, I added the "screenEnabled" value to the configuration file, to allow turning screen init on and off for payloads(default is off). 0 means off, 1 means on.
 

Attachments

Last edited by roflpwnt,

Well, certainly there's a lot of space when barely anything is initialized, but we don't really need to load the FIRM from NAND do we?
If the a9lh installer did a FIRM0, FIRM1 and 0x96 sector for N3DS backup before installing a9lh, as discussed in pages before, we could automatically recover sysnand functionality at will (if the install didn't brick, of course, but in that event you could inject the auto-backups with a hardmod and recover the system).

Then you could boot your very own FIRM0 in your SD (idk if it needs to be decrypted, maybe) without any patches using ie. Cakes. That should boot you into a very, very vanilla sysnand. You will be unprotected to some things (like updating sysnand) but meh.
 
  • Like
Reactions: Selver
Hello everyone I have been reading this thread for days, but I believe I have missed a few parts. First of all, I have a 10.6 emuNAND (running rxTools) and a clean 9.2 sysNAND (downgraded from 10.3, but I deleted all of the extra title so it can be considered vanilla). I have seen people saying they boot sysNAND instead of emuNAND. Why?[emoji14]This is preposterous to my eyes as I'm used to emuNAND. xD Is it because it gets loaded with SIG checks patched? Couldn't it be done right now with rxTools?

Also, the philosophy behind this is to load sysNAND? What about firm 0 and firm 1? Shit I have so many questions I can't even answer properly. xD Anyone got a thread/github link that explains most of those cool stuff? It's way too different than menuhax :|
 
Hello everyone I have been reading this thread for days, but I believe I have missed a few parts. First of all, I have a 10.6 emuNAND (running rxTools) and a clean 9.2 sysNAND (downgraded from 10.3, but I deleted all of the extra title so it can be considered vanilla). I have seen people saying they boot sysNAND instead of emuNAND. Why?:PThis is preposterous to my eyes as I'm used to emuNAND. xD Is it because it gets loaded with SIG checks patched? Couldn't it be done right now with rxTools?

Also, the philosophy behind this is to load sysNAND? What about firm 0 and firm 1? Shit I have so many questions I can't even answer properly. xD Anyone got a thread/github link that explains most of those cool stuff? It's way too different than menuhax :|
From what I'm getting is that with A9LH, it patches the sysnand to where it loads a payload from the SD at boot. This is what makes the system boot faster than before. If you swap your 10.5 emunand with your 9.2 sysnand through this tutorial (https://gbatemp.net/threads/tutorial-swap-sysnand-and-emunand-arm9loaderhax-only.415724/), then when you boot your console, it will load a CFW over your sysnand, with whatever patches it comes with. This even allows only having to install gba games on sysnand, so it saves space. It also makes booting a little bit more quicker, since it isn't slowed down by loading from the firmware from the SD card.
 
  • Like
Reactions: fr3quency
From what I'm getting is that with A9LH, it patches the sysnand to where it loads a payload from the SD at boot. This is what makes the system boot faster than before. If you swap your 10.5 emunand with your 9.2 sysnand through this tutorial (https://gbatemp.net/threads/tutorial-swap-sysnand-and-emunand-arm9loaderhax-only.415724/), then when you boot your console, it will load a CFW over your sysnand, with whatever patches it comes with. This even allows only having to install gba games on sysnand, so it saves space. It also makes booting a little bit more quicker, since it isn't slowed down by loading from the firmware from the SD card.

Well, you got close. It patches the sysnand but it doesn't load anything from the SD. It writes a payload into the sysnand itself and with a little trickery it makes the system jump into it like it was the real system firmware. This little payload chainloads an arm9 payload on the SD. This arm9 payload is in charge of getting your system to boot from there. In case of a CFW, it could straigh-boot emunand or sysnand.

You could see a cfw for a9lh more like a firmware selector rather than a cfw. (It does some patching around there but meh.
 
Last edited by Urbanshadow,
  • Like
Reactions: fr3quency

Site & Scene News

Popular threads in this forum