Homebrew ARM9Loader -- Technical Details and Discussion

[ChaosRipple]

Well, it was read, but not launched. I don't even know if it was decrypted.

If I understand how A9LH works, then it shouldn't be decrypted since the incorrect key will decrypt the FIRM and read it until it gets to the branch instruction jumping to your payload at the end of the FIRM.

 

[Mrrraou]

I just rechecked the whole process in the CCC vid.

It goes like this (to my understanding):

We have to keep in mind that FIRM0/1 consists of an ARM9 loader and an encrypted ARM9 binary.

1) Since the 3DS doesn't check the used key in NAND against a test vector to see if the key is valid, we can put in any key we want w/o the 3DS bothering.
2) We take a large FIRM0 (10.2 in the current implementation) and plug in our payload on top of the FIRM0 binary.
3) FIRM0 binary gets loaded into memory on boot and the hash check fails, because of our payload in place -> signature does not match.
4) FIRM1 gets loaded by the 3DS as a fail safe if anything is wrong with FIRM0, like a partition corruption OR if the hash does not match.
5) FIRM1 needs to be smaller than FIRM0 and vulnerable (9.0 - 9.2 in current implementation).
6) The 3DS doesn't clear the memory from the FIRM0 binary, but just puts FIRM1 on top of the FIRM0 binary.
7) This keeps our payload from FIRM0 in tact, because FIRM1 is smaller and therefore doesn't overwrite it in RAM.
8) The ARM9 loader from the FIRM1 binary decrypts our key from point 1).
9) Our decrypted key from NAND (point 1) is then used to decrypt the ARM9 binary of FIRM1 to garbage (since it's not the correct key).
10) ARM9 loader tries to execute this decrypted garbage data and with luck it executes a branch instruction, which jumps to our payload which is still in RAM from the steps where FIRM0 was involved.

Looking at this we see that FIRM0 has to fail in order for FIRM1 to get loaded and executed etc.
So we should probably be able to always use the latest NATIVE_FIRM as FIRM0, even in decrypted form + the payload attached for FIRM1.
Because the has check NEEDS to fail anyway and it only does that because FIRM0 comes with our payload ... so we can even use the latest decrypted NATIVE_FIRM + payload as FIRM0.

So it go like this:

1) Install latest decrypted NATIVE_FIRM + payload as FIRM0
2) Console boots and loads FIRM0
3) Hash check fails just like in the current implementation
4) Read steps 4) - 10) above
5) Payload gains ARM9 kernel execution and then bootstraps our unsigend and decrypted ARM9 binary from FIRM0 which (as we know) is the latest NATIVE_FIRM.

Okay. But do you have enough space ? And is loading it from a corrupted FIRM partition really worth it?

 

[FR0ZN]

Okay. But do you have enough space ? And is loading it from a corrupted FIRM partition really worth it?

It's not corrupted, according to the CCC talk, FIRM0 is just "corrupted" because the has check doesn't pass, because our payload is at the end of the FIRM0 binary.
So FIRM0 consists of 1) ARM9 loader 2) ARM9 binary and 3) the payload.

Once FIRM1 gets exploited and our payload gains execution, it could do two things:

1) Skip ARM9 loader from FIRM0 and decrypt the ARM9 binary on its own (because we have the keys) and executes it.

or

2) We just use the decrypted ARM9 binary from FIRM0 (latest NATIVE_FRIM) as our actual FIRM0 image, so it just consists of 1) decrypted ARM9 binary and 2) the payload.
Once the payload gains execution, it just executes FIRM0 (which is the decrypted ARM9 binary) minus the payload.
This should work, because a decrypted ARM9 bianry + payload would also not pass the hash check, just like our current implementation does not.

And then you have the latest NATIVE_FIRM on NAND + the latest FW titles from the corresponding FW as sysNAND.
This way we don't have to boot external NATIVE_FIRM images and don't have to mix up different NATIVE_FIRM version and other titles from the latest FW version.

So we would have 100% latest FW and all it's componends but in sig patched environment.

I wouldn't worry about space in NAND, because the FIRM0/1 will only get bigger when Nintendo release new FW updates and they have them 2 times in there!
So our smaller 9.0 NATIVE_FIRM as FIRM1 will always give us enough space to mess with FIRM0.

 

[dkabot]

It's not corrupted, according to the CCC talk, FIRM0 is just "corrupted" because the has check doesn't pass, becuase our payload is at the end of the FIRM0 binary.
So FIRM0 consists of 1) ARM9 loader 2) ARM9 binary and 3) the payload.

Once FIRM1 gets exploited and our payload gains execution, it could do two things:

1) Skip ARM9 loader from FIRM0 and decrypt the ARM9 binary on its own (because we have the keys)

or

2) We just use the decrypted ARM9 binary from FIRM0 (latest NATIVE_FRIM) as our actual FIRM0 image, so it just onsists of 1) Decrypted ARM9 binary and 2) the payload.
Once the payload gains execution, it just executes FIRM0 (which is the decrypted ARM9 binary) minus the payload.

And then you have the latest NATIVE_FIRM on NAND + the latest FW titles from the corresponding FW as sysNAND.
This way we don't have to boot external NATIVE_FIRM images and don't have to mix up different NATIVE_FIRM version and other titles from the latest FW version.

So we would have 100% latest FW and all it's componends but in sig patched environment.

If you want to theorize about this, you might want to join #Cakey on freenode, apparently an SD-less firmlaunch is in the plans.

6:10 PM <Plailect> also we need firmlaunch from nand so we can boot without an SD card

Edit: Apparently it was a grave mistake to name it. I shall accept my sentence with dignity.

 

[RednaxelaNnamtra]

I released a new alpha of my bootloader for arm9loaderhax. This release fixed some of the problems, which prevents the usage of the sd card.
Also it added support for using a folder named "arm9loaderhax" for the bootconfig and logfile.
Alpha 0.2

 

[runetoonxx2]

soo how long do we have to wait for screen init to work

 

[Svaethier]

soo how long do we have to wait for screen init to work

it already works but the official release isn't out yet until the updater dark samus is working on is out for the public to test.

 

[Zyrmkel]

soo how long do we have to wait for screen init to work

However long it takes to clean the code up all nice and neat

 

[dubbz82]

soo how long do we have to wait for screen init to work

Whenever the devs feel it's in a sufficient state to be released to the general public. An approximate timeline is somewhere between five minutes from now and five years from now.

 

[Supster131]

Whenever the devs feel it's in a sufficient state to be released to the general public. An approximate timeline is somewhere between five minutes from now and five years from now.

I'm working on stage2 right now... maybe tomorrow or the next day...

 

[dark_samus3]

Well there is screen init code on my github... you can compile like regular arm9loaderhax and use the installer again, though currently I recommend only people with hardmods test at the moment... I'm currently working on the payload installer and as soon as it stops giving me issues and enough people with hardmods have tested the payloads I'll make a release with the installer, updated stage2 payload, and a few payloads that are able to take advantage of screeninit

 

[RednaxelaNnamtra]

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.

 

[roflpwnt]

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.

Just tested and working perfectly.

 

[Supster131]

Just tested and working perfectly.

Yup, works fine for me too... welp good bye emuNAND!

Edit: screen just glitches out for a second when booting into AuReiNAND.

 

[Svaethier]

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.

not sure how to get this to work with cakesfw xD i just get a black screen with the a9lh.bin.

 

[runetoonxx2]

to test do i just extract that sht to my sd root?

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

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.

?

 

[Toiry921]

to test do i just extract that sht to my sd root?

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


?

Just my rule but if you don't know what you are doing probably not a good idea to do it, especially for test.

 

[RednaxelaNnamtra]

not sure how to get this to work with cakesfw xD i just get a black screen with the a9lh.bin.

you need all files exept the readme fiel on your sd card. After that simple configure it like bootctr for cake and set the screenEnabled option to 1 for cakes.

 

[Svaethier]

you need all files exept the readme fiel on your sd card. After that simple configure it like bootctr for cake and set the screenEnabled option to 1 for cakes.

tried that, like I said the a9lh bin causes a black screen.

 

[runetoonxx2]

will test for aurei