Can the A9LH payload be coded so that if it doesn't detect the payload on the SD, it launches normally to sysnand? That way we could boot even without an SD card. It would be pretty neat, but I don't know if it's doable.
AFAIK, this isn't possible since FIRM0/1 are corrupted, and AL9H payloads boot FIRM off of the SD card.
I've been lurking in this thread for some time now and wondered what will happen in case we will ever need an updated FIRM at one point in the future.
I know we can use FIRM launch for that or emuNAND.
But let's say we do it (imo) the right way and have a CFW for sysNAND w/o FIRM launch.
The way A9LH works is a corrupted FIRM0 (from 10.2) and an exploitable FIRM1 (from 9.0 - 9.2).
Wouldn't it be possible to boot the corrupted FIRM0 (which could always be the newest FIRM once it gets updated), once we gain ARM9 code execution?
Because of the payload FIRM0 is corrupted during boot if I'm not mistaken, but once we have ARM9 code execution, we should be able to boot it without caring about broken signatures.
Does anything of this make sense? Or is my understanding of A9LH wrong?
The question basically is, how could we use A9LH to have latest sysNAND (and corresponding NATIVE_FIRM from latest FW) on boot w/o FIRM launch and/or emuNAND ?
I know we can use FIRM launch for that or emuNAND.
But let's say we do it (imo) the right way and have a CFW for sysNAND w/o FIRM launch.
The way A9LH works is a corrupted FIRM0 (from 10.2) and an exploitable FIRM1 (from 9.0 - 9.2).
Wouldn't it be possible to boot the corrupted FIRM0 (which could always be the newest FIRM once it gets updated), once we gain ARM9 code execution?
Because of the payload FIRM0 is corrupted during boot if I'm not mistaken, but once we have ARM9 code execution, we should be able to boot it without caring about broken signatures.
Does anything of this make sense? Or is my understanding of A9LH wrong?
The question basically is, how could we use A9LH to have latest sysNAND (and corresponding NATIVE_FIRM from latest FW) on boot w/o FIRM launch and/or emuNAND ?
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.
In theory it should be possible to firmlaunch from nand, at least if we use the second one, because even if we broke the keystore, we know the real key, so if we hardcode it into the payload it would be possible(i think its the 10.2 firm version, since the first version checked the key they use). But I don't know if there is enough space to do this in the payload.
But firm was read before arm9loaderhax ran, so shouldn't the keys for firm already been set up, or is the bootrom clearing them before jumping to arm9loader?
Every thing else firm should do after you jumped to it.
When I installed arm9loaderhax it worked really fast.
Right now I'm installing it on my 3ds and it performs "Install NAND backup..." for a long time.
In the bottom left of top screen hex numbers are changed fast.
Is this OK?
Right now I'm installing it on my 3ds and it performs "Install NAND backup..." for a long time.
In the bottom left of top screen hex numbers are changed fast.
Is this OK?
A9LH installer starts by restoring NAND.bin if it exists, so it's normal for now.
Once it's done with that, you're in the danger zone.
Well, it was read, but not launched. I don't even know if it was decrypted.
Ok, it seems, like it does something if i have nand.bin file in root.
https://github.com/delebile/arm9loa...payload_installer/installer/source/nand.c#L53
Is this dangerous?
--------------------- MERGED ---------------------------
https://github.com/delebile/arm9loa...payload_installer/installer/source/nand.c#L53
Is this dangerous?
--------------------- MERGED ---------------------------
Oh, so it simply restores my nand backup and if it's actually good 9.2 sysnand backup, then I'm fine?
Yes. It most likely was since the Decrypt9 used at the end of the OTP guide to restore wants the SysNAND at NAND.bin.
Once it restores, it installs A9LH proper.
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.
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.
Similar threads
- No one is chatting at the moment.
-
-
-
-
-
-
@
Psionic Roshambo:
I think I have convinced them that multiplexing a polarized Lazer for fiber optic networking is a good idea lol -
-
-
-
-
-
-
-
@
a_username_that_is_cool:
Happy early birthday (we need a word for the day before someones birthday)+1 -
-
-
-
-
-
-
-
-
-
-
