Hacking [IDEA]arm9loaderhax boot without SD

[Wolfvak]

couldn't they do something "if file is not found, boot from firmware" ?

This is the problem exactly: the firmware (FIRM partitions) have been modded because that's the whole point of A9LH. You can get around it by loading+decrypting FIRM titles within CTRNAND, like what Luma/SaltFW does.

If you try to launch FIRM0, it'd just get stuck in a bootloop (stage1 gets activated, load+launch stage2, which loads and launches FIRM0, which activates stage1, load+launch stage2, ...)

 

[Salamencizer]

You'll have to wait a week because I'm contracted irl for the next week and then a bit. After that, I'll start working on ShadowNAND full speed and we'll see how it goes. I'm hopeful.

ShadowNAND HYPE!
I'm gonna sincerely wait, and thanks very much for working on this!

 

[Earth97]

This is the problem exactly: the firmware (FIRM partitions) have been modded because that's the whole point of A9LH. You can get around it by loading+decrypting FIRM titles within CTRNAND, like what Luma/SaltFW does.

If you try to launch FIRM0, it'd just get stuck in a bootloop (stage1 gets activated, load+launch stage2, which loads and launches FIRM0, which activates stage1, load+launch stage2, ...)

1. Bootrom reads FIRM0, but due to our payload presence, the signature check will fail.
2. It will read FIRM1 on top of FIRM0, and our payload will still be after it.
3. Check its RSA signature, since it's good it will jump to its arm9loader.
4. The arm9loader will use our crafted key to decrypt the ARM9 binary as garbage, then jump to the kernel entrypoint.
5. With our key the garbage kernel entrypoint will make the cpu jump to our payload location. --> Why not jumping to FIRM1's CTRNAND, which is unmodified?
6. Code execution!

If that is not possible, couldn't you store the cfwpayload near the ASM payload? I mean, we can jump to a SD-located payload, what about a FIRM0-located payload?

 

[Shadowhand]

With our key the garbage kernel entrypoint will make the cpu jump to our payload location. --> Why not jumping to FIRM1's CTRNAND, which is unmodified?

We need to decrypt the CTRNAND, and at that point, it becomes a CFW anyway.

EDIT: reading further, there's no "FIRM1's CTRNAND", so you're wrong on all accounts.

 

[Wolfvak]

1. Bootrom reads FIRM0, but due to our payload presence, the signature check will fail.
2. It will read FIRM1 on top of FIRM0, and our payload will still be after it.
3. Check its RSA signature, since it's good it will jump to its arm9loader.
4. The arm9loader will use our crafted key to decrypt the ARM9 binary as garbage, then jump to the kernel entrypoint.
5. With our key the garbage kernel entrypoint will make the cpu jump to our payload location. --> Why not jumping to FIRM1's CTRNAND, which is unmodified?
6. Code execution!

If that is not possible, couldn't you store the cfwpayload near the ASM payload? I mean, we can jump to a SD-located payload, what about a FIRM0-located payload?

At least you read delebile's writeup - that's some amazing progress right there. The problem is that BOTH FIRM0 AND FIRM1 are modded. Maybe there's some trickery with n3DS, but with o3DS it's outright impossible.

And by the way, do you even know what *the* (not *a*) CTRNAND is?

EDIT: Also, please check out the arm9loaderhax source, it'll all become clear at that point.

 

[funnystory]

So I was thinking, can we just use a SaltFW (SaltLite) payload to load arm9loaderhax without SD? Its size is super small, And it doesn't require any folder/firmware/etc for sigcheckpatching.
Is this possible?

I would love this

 

[Earth97]

At least you read delebile's writeup - that's some amazing progress right there. The problem is that BOTH FIRM0 AND FIRM1 are modded. Maybe there's some trickery with n3DS, but with o3DS it's outright impossible.

And by the way, do you even know what *the* (not *a*) CTRNAND is?

EDIT: Also, please check out the arm9loaderhax source, it'll all become clear at that point.

I'm trying to understand how A9LH works without coding skills, what I write is most likely uncorrect and I would appreciate it if you were so kind to correct me.
You mod FIRM0 to house an ASM payload. In order for the hax to work, FIRM1 must be mods-free, otherwise it won't be validated during hash check. Am I wrong?
I thought CTRNAND was part of the FIRM0/1, isn't it?

 

[Shadowhand]

I'm trying to understand how A9LH works without coding skills, what I write is most likely uncorrect and I would appreciate it if you were so kind to correct me.
You mod FIRM0 to house an ASM payload. In order for the hax to work, FIRM1 must be mods-free, otherwise it won't be validated during hash check. Am I wrong?
I thought CTRNAND was part of the FIRM0/1, isn't it?

Watch this, it'll help you understand things easier.

 

[Wolfvak]

I'm trying to understand how A9LH works without coding skills, what I write is most likely uncorrect and I would appreciate it if you were so kind to correct me.
You mod FIRM0 to house an ASM payload. In order for the hax to work, FIRM1 must be mods-free, otherwise it won't be validated during hash check. Am I wrong?
I thought CTRNAND was part of the FIRM0/1, isn't it?

CTRNAND is a completely separate partition from FIRM0/1, you can read more here

Yes, FIRM1 stays the same... what doesn't is the key used to decrypt it, it now jumps into our stage1. There's two ways to work around it:
1. Decrypt it with the correct key, which works, but it's even better to just do it the Luma way, simply decrypting FIRM from the CXI content

2. Load a decrypted firmware from the SD card, which in this case is not valid because one of the conditions in this situation is SD card-less boot

 

[Earth97]

CTRNAND is a completely separate partition from FIRM0/1, you can read more here

Yes, FIRM1 stays the same... what doesn't is the key used to decrypt it, it now jumps into our stage1. There's two ways to work around it:
1. Decrypt it with the correct key, which works, but it's even better to just do it the Luma way, simply decrypting FIRM from the CXI content

2. Load a decrypted firmware from the SD card, which in this case is not valid because one of the conditions in this situation is SD card-less boot

If 1. is a thing, what is keeping us from loading that decrypted FIRM?

 

[Wolfvak]

If 1. is a thing, what is keeping us from loading that decrypted FIRM?

Nothing is stopping us, nothing stopped Aurora and as such she implemented it in Luma. Have you kept up with development ?

EDIT: As a matter of fact, it's SaltLite's only way of loading firmware, since it ditched load from SD support (a good decision IMHO). Its disadvantage is that it breaks NTR support, since most NATIVE_FIRM CIAs installed currently are 10.4, while NTR works on 10.2 in n3DS and 9.6 in o3DS

EDIT 2 : Also check out the first point here https://github.com/AuroraWright/Luma3DS/commit/7dbded99a22cad84772490baee9d4913c4d1987e

 

[Earth97]

I've read something but I was not sure I had got it the right way. Does this mean booting without SD is already possible using Luma/will be possible soon?

 

[Wolfvak]

I've read something but I was not sure I had got it the right way. Does this mean booting without SD is already possible using Luma/will be possible soon?

No, I think that's not Aurora's intention. However it's @Shadowhand's ShadowNAND which is trying to accomplish just that. There's no config and firmware is loaded from CTRNAND directly, so there's no reason to use an SD card. Several fixes have to be made, but the main concept is there.

 

[The Catboy]

couldn't they do something "if file is not found, boot from firmware" ?

the hability to not using a sd card would be great, so you could use the console with a broken sd card reader
and it would be helpfull to noobs, currently there is a change of blackscreen that a simple fix is ejecting and putting back the sd card, some noobs start the console without the card and think its broken..
and plus it doesn't make sence that you require something to boot the console...

Actually the latest build just shuts down when you turn it on without an SD card.

 

[Pikm]

So I was thinking, can we just use a SaltFW (SaltLite) payload to load arm9loaderhax without SD? Its size is super small, And it doesn't require any folder/firmware/etc for sigcheckpatching.
Is this possible?

No, because arm9loaderhax is built to run an arm9loaderhax.bin from the SD card on boot. If it doesn't find one, the system turns off.

 

[astronautlevel]

No, because arm9loaderhax is built to run an arm9loaderhax.bin from the SD card on boot. If it doesn't find one, the system turns off.

This is entirely possible, but it's somewhat of a pain.

First of all you need a way to read files off the NAND via arm9 - this definitely possible, but difficult when you consider the space limit of k9lh payloads.

You'd then need a payload that's small enough to fit in the NAND (smaller the better, mainly for DSiWare and stuff). In addition, it would need patches for FIRM write protection at the very least, and would need to be able to load firmware.bin from NAND. SaltFW works perfectly for this, as it is relatively lightweight and contains necessary patches. Another option would be Mizuki.

Like I said, it's possible but a pain. Most developers aren't going to be working on it given that it's relatively low priority as few people boot without an SD card. I would be looking into it if I had a hardmod, but since I don't I'm too afraid to brick

 

[daxtsu]

This is entirely possible, but it's somewhat of a pain.

First of all you need a way to read files off the NAND via arm9 - this definitely possible, but difficult when you consider the space limit of k9lh payloads.

You'd then need a payload that's small enough to fit in the NAND (smaller the better, mainly for DSiWare and stuff). In addition, it would need patches for FIRM write protection at the very least, and would need to be able to load firmware.bin from NAND. SaltFW works perfectly for this, as it is relatively lightweight and contains necessary patches. Another option would be Mizuki.

Like I said, it's possible but a pain. Most developers aren't going to be working on it given that it's relatively low priority as few people boot without an SD card. I would be looking into it if I had a hardmod, but since I don't I'm too afraid to brick

I was actually looking into it before I bricked my N3DS as a result of it. I'm waiting on an N3DS XL compatible USB reader for my hardmod to arrive though, so I'm not going to play with fire until I can put it out, so to speak.

 

[Salamencizer]

No, because arm9loaderhax is built to run an arm9loaderhax.bin from the SD card on boot. If it doesn't find one, the system turns off.

You didn't get what I meant. The idea was to replace the payload on the FIRM0/FIRM1(which boots a payload on the SD Card) with one of a CFW whose size is Super Small, Like that of SaltLite.
Our Glorious ShadowHand is working on ShadowNAND. Can't wait to test it out.

 

[daxtsu]

You didn't get what I meant. The idea was to replace the payload on the FIRM0/FIRM1(which boots a payload on the SD Card) with one of a CFW whose size is Super Small, Like that of SaltLite.
Our Glorious ShadowHand is working on ShadowNAND. Can't wait to test it out.

I don't think there will be enough room to do that with stage2. Fatfs makes up a huge chunk of stage 2, and there's barely much room left to add the crypto stuff to mount CTRNAND and read stuff off it. It would make more sense to have stage 2 do this:

1. Check SD for an A9LH payload. If it had one, boot it. If not, check NAND.
2. Mount CTRNAND and set up crypto stuff for reading files.
3. Check CTRNAND for an A9LH payload. If it has one, great, boot it. If not, shutdown the console.

That would be a simple and relatively safe way of doing it. You'd just stick Salt or Mizuki (or some other CFW, whatever you want) on CTRNAND and then just boot it.

 

[Salamencizer]

I don't think there will be enough room to do that with stage2. Fatfs makes up a huge chunk of stage 2, and there's barely much room left to add the crypto stuff to mount CTRNAND and read stuff off it. It would make more sense to have stage 2 do this:

1. Check SD for an A9LH payload. If it had one, boot it. If not, check NAND.
2. Mount CTRNAND and set up crypto stuff for reading files.
3. Check CTRNAND for an A9LH payload. If it has one, great, boot it. If not, shutdown the console.

That would be a simple and relatively safe way of doing it. You'd just stick Salt or Mizuki (or some other CFW, whatever you want) on CTRNAND and then just boot it.

Yeah something like this. As I said, ShadowHand is working on it.