Homebrew [Coming Soon] OTPless A9LH installation on N3DS (no 2.1 downgrade)

[ihaveahax]

"The NAND keystore must be encrypted with console-unique data; therefore, this is not achievable on Old 3DS or 2DS."
But why doesn't this work on the Old 3DS? Can someone with better knowledge explain this please?

the key sector is normally only included on New 3DS. for Old 3DS, you need to place it in NAND, but you need the OTP hash to do that already, and to do that, you have to go to 2.1.

 

[gatao30cm]

Will I have to downgrade my emunand to 9.2 when this gets releases? Or Just having a sysNand ond 9.2 with updated emunand is enough?

 

[nyder]

Cool, sounds great. Been lazy and haven't done my N3DS yet. Guess now I'll just be waiting on the public release version. Keep up the great work.

 

[Halvorsen]

"The NAND keystore must be encrypted with console-unique data; therefore, this is not achievable on Old 3DS or 2DS."
But why doesn't this work on the Old 3DS? Can someone with better knowledge explain this please?

IIRC the new 3DS uses a new layer of encryption that the old 3DS simply doesn't have.

 

[evandixon]

This reminds me of Gateway Fastboot, in the sense that both are not ready for general use, come with obvious warnings saying to not use without a hard mod, and that people are inevitably going to try it anyway.

 

[Giodude]

This reminds me of Gateway Fastboot, in the sense that both are not ready for general use, come with obvious warnings saying to not use without a hard mod, and that people are inevitably going to try it anyway.

gateway fastboot?

 

[DeslotlCL]

Just because of this i might finally get a new 3ds for myself this upcoming christmas...

 

[Inochi.no.Zenmai]

There's literally no reason to keep a New 3DS without an A9LH setup after this gets widely tested and finally released to the public.

 

[Urbanshadow]

the key sector is normally only included on New 3DS. for Old 3DS, you need to place it in NAND, but you need the OTP hash to do that already, and to do that, you have to go to 2.1.

The OTP hash is available without downgrading to 2.1. Check 3dbrew for more details on that. And I don't get it why can't work for O3ds too (given the need for arm9 code execution).

 

[ihaveahax]

The OTP hash is available without downgrading to 2.1. Check 3dbrew for more details on that. And I don't get it why can't work for O3ds too (given the need for arm9 code execution).

to get the OTP hash without going to 2.1, you would need to do this otpless method, which is impossible on Old 3DS since the key sector is not there, therefore you can't do arm9loaderhax. until you go to 2.1 to get the otp and the hash of it.

otpless works because you can copy key0 to key1, put 10.0 New 3DS FIRM in firm0, put a payload into arm9 memory, reboot, and get the otp hash from there and install proper a9lh.

 

[astrangeone]

Hmmm...fascinating, but I think I'd hold off on testing.

 

[Swiftloke]

to get the OTP hash without going to 2.1, you would need to do this otpless method, which is impossible on Old 3DS since the key sector is not there, therefore you can't do arm9loaderhax. until you go to 2.1 to get the otp and the hash of it.

otpless works because you can copy key0 to key1, put 10.0 New 3DS FIRM in firm0, put a payload into arm9 memory, reboot, and get the otp hash from there and install proper a9lh.

So this OTPless method is a jump not to the end of firm0, but to somewhere in arm9 RAM? I'm assuming this is what's meant by "close enough". But I thought the OTP was locked by arm9loader by the time arm9loaderhax is achieved? I'm aware that the OTP hash is avaliable, (obviously) but how? Isn't it a key slot not cleared by arm9loader 1? If so, how does that work because arm9loader 2 is what's used to gain code execution?

 

[ihaveahax]

So this OTPless method is a jump not to the end of firm0, but to somewhere in arm9 RAM? I'm assuming this is what's meant by "close enough". But I thought the OTP was locked by arm9loader by the time arm9loaderhax is achieved? I'm aware that the OTP hash is avaliable, (obviously) but how? Isn't it a key slot not cleared by arm9loader 1? If so, how does that work because arm9loader 2 is what's used to gain code execution?

when you copy key0 to key1, 10.0 FIRM jumps to a place in memory (this happens to be arm9 memory) that can be modified and is executable.

the otp is locked, but all you need is the otp hash. (or, technically, the hash of the first 0x90 bytes of the otp). arm9loader doesn't clear the hash from the SHA registers, so it can be re-used.

 

[Urbanshadow]

to get the OTP hash without going to 2.1, you would need to do this otpless method, which is impossible on Old 3DS since the key sector is not there, therefore you can't do arm9loaderhax. until you go to 2.1 to get the otp and the hash of it.

otpless works because you can copy key0 to key1, put 10.0 New 3DS FIRM in firm0, put a payload into arm9 memory, reboot, and get the otp hash from there and install proper a9lh.

Please confirm if I am wrong but:

Uncleared OTP hash keydata in console-unique 0x11 key-generation

Kernel9Loader does not clear the SHA_HASH register after use. As a result, the data stored here as K9L hands over to Kernel9 is the hash of OTP data used to seed the console-unique NAND keystore decryption key set on keyslot 0x11.

Retrieving this keydata and the NAND keystore of the same device allows calculating the decrypted New3DS NAND keystore (non-unique, common to all New3DS units), which contains AES normal keys, also set on keyslot 0x11, which are then used to derive all current New3DS-only AES keyXs including the newer batch introduced in 9.6.0-X. From there, it is trivial to perform the same key derivation in order to initialize those keys on any system version, and even on Old3DS.

...

Wouldn't this mean this is also applicable with some reworking to o3ds?

 

[Swiftloke]

when you copy key0 to key1, 10.0 FIRM jumps to a place in memory (this happens to be arm9 memory) that can be modified and is executable.

the otp is locked, but all you need is the otp hash. (or, technically, the hash of the first 0x90 bytes of the otp). arm9loader doesn't clear the hash from the SHA registers, so it can be re-used.

All right, that makes sense. Because the OTP hash is exposed, proper arm9loaderhax is installable. But why does it need arm9loader execution? Does something in the OS clear/overwrite the keyslot?

 

[ihaveahax]

Please confirm if I am wrong but:


Wouldn't this mean this is also applicable with some reworking to o3ds?

well, in short, if you can somehow get code execution right after kernel9loader without the key sector, then it would be possible on Old 3DS. note, this is virtually impossible. you cannot re-encrypt the key sector properly without the otp hash, and the only way to get that on Old 3DS is to go to 2.1.

if you try to put kernel9loader on old 3DS, it will hang before jumping to FIRM, since it will find the first key to be corrupt (when it isn't there at all).

All right, that makes sense. Because the OTP hash is exposed, proper arm9loaderhax is installable. But why does it need arm9loader execution? Does something in the OS clear/overwrite the keyslot?

because a bunch of other things are hashed (every single process that starts, for example), therefore the hash is long gone once you get code execution. so you have to get code execution after kernel9loader, but before NATIVE_FIRM.

 

[Swiftloke]

Please confirm if I am wrong but:


Wouldn't this mean this is also applicable with some reworking to o3ds?

No. I'm seeing other explanations on why it's not possible on o3DS, but they're not detailed at all and expect you to know everything about the 3DS. Let's fix that.
arm9loader never expects to be run on an old3DS, and Nintendo (obviously) never expected it to be run either. Because of this, there's no new3DS key store (secret store) encrypted with the OTP hash on the old3DS programmed into the console at the factory. Without any kind of key store (a garbage key or not) arm9loader will not be able to decrypt the rest of FIRM, as it will try to do. Putting in an unencrypted key store won't work either. arm9loader never expects an unencrypted key store, so it will try to decrypt it with the OTP. This will result in a garbage key being used to decrypt FIRM, and since the key generated is console unique (OTP, remember) it's not exploitable. Not putting in a key store at all will result in the same thing.
Therefore, the OTP is an absolute must to make arm9loader run at all on the o3DS. Because we have to encrypt the key store as valid, we have to have the OTP to encrypt it so that arm9loader will use it (properly, it expects the key store to be encrypted with the OTP) decrypt the FIRM with our garbage key, and jump to our payload.
It works on new3DS because the key store is already there.

 

[Naked_Snake]

Does this have to be done on 9.2 or can it be done on 10.x?

 

[ihaveahax]

Does this have to be done on 9.2 or can it be done on 10.x?

you need to go to 9.2 due to an arm9 kernel exploit

 

[Halvorsen]

There's literally no reason to keep a New 3DS without an A9LH setup after this gets widely tested and finally released to the public.

Unless you're me. xD