[SUGGESTION] Adding a possibility to boot sysNAND if no playload found and block FIRM partition update (normal FIRM and SAFE_MODE FIRM) when sysNAND is booted without playload?

[mariogamer2]

Think this is not possible since FIRM0 is "corrupted" after installing and the key used to decrypt arm9 binary give "a corruption".So I close.

[Hartie95]

It could be possible if we use the second firm partition and the real key, since firm1 is not corrupted, we only changed the key it uses to decrypt it, so if we do the encryption in our payload, we will be able to boot it(firm1 should be the 10.2 Firm).

[urherenow]

Why "should be"? Falling back to 10.2 would break decrypt9 and gateway compatibility. People who decide to upgrade sysnand with AureiNand aren't updating firm0 or firm1 because AureiNand blocks it (and native_firm is always loaded from SD in this case). People who keep 9.2 sysnand with an updated emunand would be fine (if keeping the 9.0~9.2 firm in firm1), but it would also confuse people when their system simply works, but no sigpatches, simply because their payload is bad or not setup correctly, but it booted anyway because of the fallback feature.

[ghost]

firm1 is partially corrupted though..open it in a hex editor and go to the end to see.

[Hartie95]

It should not, otherwise the 3ds would not try to boot it.

[pixel-stuck]

@hartmannaf it actually is, or at least in this fork it is, appended to the end of the firm1 binary is an unused stage 2 binary (not the one in sector 0x5C000), however it doesn't affect it since the header specifies the size of the firm and only reads that much... in my fork, since it's unused, I took that part out (and tested, works fine)

[Hartie95]

@dark-samus thanks for clarification. But since it doesn't effect the original contend(besides the unused area), it should still be possible to use it in theory as fallback. Interessting to know, that the 3ds only checks the area specified in the header.

[urherenow]

With a9lh, don't we have control early enough that signatures don't necessarily matter? Why not just patch the header to match then? Or is that what @hartmannaf is already suggesting?

[pixel-stuck]

@urherenow the bootrom checks the header so if it isn't valid then it isn't going to work...

@hartmannaf sure, that might work, until you try to boot it on an o3ds, or use it on a future firm which doesn't support the 10.2 firm that's used... then you'd need to swap the firm out, and probably go through another 12 million tries looking for the new key to decrypt the firm to garbage that will jump to the payload.... :P

[Hartie95]

@dark-samus Thats why I said in theory :) But maybe ,if there is an unused area in nand that we can use as firm fallback, this could be possible for o3ds and n3ds.

[jasondellaluce]

There actually is another way to boot the installed firmware, i'll probably add it to this setup. It will be part of the update i'm preparing.

[sykhro]

That would be part of stage 2, right?

[jasondellaluce]

Yes it is the most sensed thing to do.

[mariogamer2]

@delebile Does this is always doable (with the new title)? It will also be good to add support to SAFE_MODE FIRM.

[jasondellaluce]

Yes it is doable. The only problem would be for new3ds, where part of the keysector needed for decrypt the arm9bin is corrupted. This can be bypassed tho, since it actually is needed for the setuo anyways. I'll take the time to do this properly.

[mariogamer2]

@delebile Don't know if this can help: https://github.com/AuroraWright/arm9loaderhax/commit/c8e3af3bb293856247939b7be52338c1552d4bb9