Homebrew ARM9Loader -- Technical Details and Discussion

[Selver]

No, sysNAND blocksize doesn't vary, however blocksize across programs/devices can vary so sometimes the program you're using will set the blocksize to something different, that is what I meant haha, sorry for the confusion

Thanks for the response. Glad to know 3DS is currently using fixed block size.

 

[fr3quency]

What this guy said.
Whatever version your emunand is/was, your sysnand will now be after doing that.

But will emuNAND(which was sysNAND before) have a9lh installed? So a9lh will be installed on both emuNAND(formely sysNAND where I had originally installed a9lh) AND sysNAND(formely emuNAND) ?

 

[RednaxelaNnamtra]

Hey, here is a new dev build of bootctr9, I think I will release it tomorow together with the source, if there is no bigger bug.
I added a new section for the bootctr9 options like logging and screen init at boot.
I added my configuration as fast example how to configure it, I also sligtly modified the ascii bootscreen, and added an extended ascii bootscreen, which shows the loaded payload.
Also there are now two possible deleays, one for the key input in the BOOTCTR9 section, and one which sets the time the splashscreen for the cfw is shown(for example to show instructions and start pressing the button for your cfw payload).
As additional feature I added support to the bootloaderloader(arm9loaderhax.bin) to load the arm9bootloader from an arm9loaderhax folder(the same folder where you can put the boot configuration into).
I will add a full description about the changes with the release.

 

[Shadowtrance]

But will emuNAND(which was sysNAND before) have a9lh installed? So a9lh will be installed on both emuNAND(formely sysNAND where I had originally installed a9lh) AND sysNAND(formely emuNAND) ?

No, a9lh will only be on the nand you installed it on if you use that process to swap. the a9lh install doesn't touch the CTRNAND partition at all.

 

[TimX24968B]

Hi TimX24968B,

I'm the original poster. I tried to give a comprehensive overview of what the original flaw was, as described in the original ccc talk in December 2015. This thread has since grown, and so I've been keeping the first post updated as things solidify. In answering your question:

1. For understanding the A9L bug, the original few posts is the comprehensive tutorial.
2. For dumping the OTP, there is a comprehensive tutorial, because that portion has stabilized.
3. For building of A9LHax, well...
   1. Proof-of-concepts exist in many branches, showing it works
   2. Users who don't already compile sources from GitHub might not easily do this
   3. Implementations are in such flux, that it's not ready if you're not building it yourself....
4. For installation of A9LHax, simply run .3dsx after it's built
5. For payloads that work with A9LHax, well...
   1. The list is still changing quickly
   2. There is a tiny payload that simply waits for a button press, and shuts off the console
   3. Other payloads exist, but how they work is changing too rapidly to suggest anything other than going to the source for those
6. For anything else, can you help me understand the question more specifically?

Thanks!

I finally found one (not on here, but I feel like it should have been), but personally, I'm more interested in finding out what it really is necessary for and the steps on installing/setting it up rather than proofs of concept and understandings. Thats why I was considering waiting until a full release for something like this.

 

[Ekaitz]

Small question guys, about Arm9LoaderHax compilation because I don't understand something and I think that one of you may have a guess about my small issue.

I finally installed every tools on OS X to do some 3DS compilation. (devkitpro/devkitarm/pycrypto for A9LH...)
I've got a working setup on Windows 10.

I compiled a version of A9LH using FIX94 fork. (https://github.com/FIX94/arm9loaderhax)
On Windows, after the compilation, I get an installer with:
2 210 236 octets

On OSX, after the same process that seems to work flawlessly, my file is:
2 210 228 octets

(4 octets, nearly nothing but eh, maybe important)
Obviously, the checksums are different.

And I don't understand why...
Everything seems to be ok on both systems...
What could possibly create that kind of difference between two files using the same source with the same OTP?
Maybe something is wrong with my OS X setup?

Any help would be greatly appreciate!

EDIT: And yes, I made the installer multiple times, every time I've got the same file on Windows and the other one on OSX.

 

[Selver]

Didn't someone run into issues when trying that on N3DS though? Or was that something else?

The warning you are thinking about may be part of the OTP guide? The issues there relates to downgrading an N3DS to use O3DS firmware (such as 2.1). To do that, it requires decryption / re-encryption, to account for the differences between O3DS and N3DS?

 

[Selver]

I finally found one (not on here, but I feel like it should have been), but personally, I'm more interested in finding out what it really is necessary for and the steps on installing/setting it up rather than proofs of concept and understandings. Thats why I was considering waiting until a full release for something like this.

Hi TimX24968B,

Sorry I don't have what you need. There is no packaged, polished A9LH solution yet. There are many investigations and Proof-of-Concept builds, and lots of payload development that appears to be happening, of course. Many who are investigating this have dumped their OTP simply because it's a step known to be needed for any A9L based hax. Compiling A9LH is documented, of course, and differs very little from any other homebrew compilation. But, it still means you have to compile, which is a high hurdle for many.

On the plus side, the high hurdle does reduce the number of people who accidentally brick their 3DS.

 

[TimX24968B]

Hi TimX24968B,

Sorry I don't have what you need. There is no packaged, polished A9LH solution yet. There are many investigations and Proof-of-Concept builds, and lots of payload development that appears to be happening, of course. Many who are investigating this have dumped their OTP simply because it's a step known to be needed for any A9L based hax. Compiling A9LH is documented, of course, and differs very little from any other homebrew compilation. But, it still means you have to compile, which is a high hurdle for many.

On the plus side, the high hurdle does reduce the number of people who accidentally brick their 3DS.

OK, thanks for clearing that up for me. I guess I will just have to wait until something of the like comes along in that matter.

 

[democracy]

I'd be lying if I didn't say I'm dying for the update to this highly anticipated Arm9 update, remind of when I was a kid waiting for Christmas...

 

[RednaxelaNnamtra]

So, here is the 0.4 Alpha of BootCTR9
Its now possible to configure screeninit at start and for payload loading seperately, also I added the BOOTCTR9 section for the config file, for every setting that has nothing todo with the payloads(like logging and the time to wait for a key before booting the default section).
Also I added support for the ascii splash(fallback if splash is set to 1), and an extendet ascii splash(showen if splash is set to 2, or as fallback for 3). this extendet fallback shows the loaded payload.
Also its now possible to place the arm9bootloader.bin inside of the "arm9loaderhax" folder.
For all changes and a how to use check the github release Page and the example configuration. Also check the commit descriptions for an advanced changelog.

Edit: Since I think the full release is near, I updated the readme to show most of the configurations I added:
Readme

 

[RednaxelaNnamtra]

Here is a additional small update for BootCTR9 0.4.1 Alpha
In this small update I only added the possibility to set the screen brightness when screen init.
To configure it simply set "screenBrightness" inside of the "BOOTCTR9" section to a value between 0x0 and 0xFF.

 

[9thSage]

Here is a additional small update for BootCTR9 0.4.1 Alpha
In this small update I only added the possibility to set the screen brightness when screen init.
To configure it simply set "screenBrightness" inside of the "BOOTCTR9" section to a value between 0x0 and 0xFF.

This is a good addition! I was wondering though, is there any chance of making this option configurable on a per-payload basis? I like having the backlight off when I'm just booting into NAND/EmuNAND but of course, if you have it off you can't see any other payloads that might need the screen (like Decrypt9WIP). If it's too much work, I understand...it's not really a big deal, I would just like the way that looks better asthetically. Btw, thanks a lot for the bootloader...it's been incredibly useful.

 

[RednaxelaNnamtra]

This is a good addition! I was wondering though, is there any chance of making this option configurable on a per-payload basis? I like having the backlight off when I'm just booting into NAND/EmuNAND but of course, if you have it off you can't see any other payloads that might need the screen (like Decrypt9WIP). If it's too much work, I understand...it's not really a big deal, I would just like the way that looks better asthetically. Btw, thanks a lot for the bootloader...it's been incredibly useful.

I through about adding it, and I think I will add it, but first I need to think about how I will implement it.

 

[Mthodmn101]

This is a good addition! I was wondering though, is there any chance of making this option configurable on a per-payload basis? I like having the backlight off when I'm just booting into NAND/EmuNAND but of course, if you have it off you can't see any other payloads that might need the screen (like Decrypt9WIP). If it's too much work, I understand...it's not really a big deal, I would just like the way that looks better asthetically. Btw, thanks a lot for the bootloader...it's been incredibly useful.

might want to check out https://github.com/FIX94/arm9select

 

[ketal]

Is there anyone with the screeninit version installed willing to test a thing? I'm not sure I have installed the updated stage 2 and I want to be sure before injecting it again

 

[Psi-hate]

Is there anyone with the screeninit version installed willing to test a thing? I'm not sure I have installed the updated stage 2 and I want to be sure before injecting it again

I have screeninit and all that. What do you need tested? In about an hour or two, I can test.

 

[ketal]

I have screeninit and all that. What do you need tested? In about an hour or two, I can test.

won't say publicly, will send a pm

 

[Supster131]

Is there anyone with the screeninit version installed willing to test a thing? I'm not sure I have installed the updated stage 2 and I want to be sure before injecting it again

Wouldn't mind helping out, I won't be home for another 3-4 hours though.

 

[PsyJED]

Is there anyone with the screeninit version installed willing to test a thing? I'm not sure I have installed the updated stage 2 and I want to be sure before injecting it again

I'd love to test it, I have a O3DS hard modded and ready to go.