Homebrew Why is the 3DS's OTP required for the A9LH process? (Curious, not a support question)

[Eradigon]

I don't know a lot about the technical workings of the 3DS and 3DS homebrew but I have some understanding of how it works. I get that the OTP is a console-unique key that is generated on startup, and I know why you have to downgrade to a pre-3.0 version to obtain it. My question is why is it needed to install A9LH? It isn't a useful encryption key in itself, right? From what I read it just is used by the console to obtain other keys, but nobody knows how it does this. So what is the OTP useful for in the A9LH process?

 

[Nyap]

I don't know a lot about the technical workings of the 3DS and 3DS homebrew but I have some understanding of how it works. I get that the OTP is a console-unique key that is generated on startup, and I know why you have to downgrade to a pre-3.0 version to obtain it. My question is why is it needed to install A9LH? It isn't a useful encryption key in itself, right? From what I read it just is used by the console to obtain other keys, but nobody knows how it does this. So what is the OTP useful for in the A9LH process?

-snip-
actually nvm

 

[Eradigon]

-snip-
actually nvm

I know you said nvm, but I already read that link. It describes how the OTP is dumped and why we need to downgrade for it but not what it's actually used for.

 

[Skyshadow101]

I know you said nvm, but I already read that link. It describes how the OTP is dumped and why we need to downgrade for it but not what it's actually used for.

I think it's used for the keys that A9LH needs at startup. Don't quote me on it though, I'm just as clueless as you are.

 

[Halvorsen]

Upon my understanding, it's an area that the console's encryption keys derive from.
Meaning, at least in this case, we can inject payloads into FIRM0 and FIRM1 without the firms detecting it and refusing to boot.

When a FIRM is found to be invalid, it panics and jumps to a seemingly random point. A payload is inserted right where it jumps. However, if either of the FIRMs fail to have the console specific encryption, it refuses to launch.


That's where the OTP comes into play. Insert our payload, then encrypt it with our console-specific key. That's why we can use modified firms since the console sees the FIRMS as legit (because it's using the console specific key, from the OTP)
Though, I could be mistaken in part of this.

 

[Eradigon]

Upon my understanding, it's an area that the console's encryption keys derive from.
Meaning, at least in this case, we can inject payloads into FIRM0 and FIRM1 without the firms detecting it and refusing to boot.

When a FIRM is found to be invalid, it panics and jumps to a seemingly random point. A payload is inserted right where it jumps. However, if either of the FIRMs fail to have the console specific encryption, it refuses to launch.


That's where the OTP comes into play. Insert our payload, then encrypt it with our console-specific key. That's why we can use modified firms since the console sees the FIRMS as legit (because it's using the console specific key, from the OTP)
Though, I could be mistaken in part of this.

Thanks!

 

[Halvorsen]

Thanks!

Welcome. I think I may have felt some info out however. :/
So, these FIRMS are run immediately when you press the power button. It's what eventually loads native_firm, and then finally the HOME Menu. FIRM0 is the first that's run, and if it's found to be invalid in any way (like, in the case of a power outage during an update, or ahem. hax), the console uses FIRM1. This is used to our advantage.

One of the reasons a9lh exists is because of it randomly jumping to random instructions if a firm is found to be invalid. Using the OTP allows us to launch the FIRM without it refusing to boot, but since it fails another seperate integrity check, it still panics. But we injected our payload to where it jumps, so it unknowingly reads our instruction, which is arm9loaderhax. Profit.

 

[Swiftloke]

Completely untrue. The OTP is not used for any kind of FIRM encryption at all. Rather, the OTP is used in FIRM decryption.
The OTP is used to calculate keys that are used in arm9loader to decrypt FIRM0 & FIRM1. The FIRMs are signed by Nintendo, which obviously we can't change and still have signed. However, what we do is add a payload to the end of FIRM0. Because FIRM0 isn't signed, the arm9loader does not jump to it and reads the backup FIRM1, which is smaller, and thus our payload isn't unloaded when the valid FIRM1 is read and prepared to jump to. Now here's where the OTP comes into play. Simplified to an extreme, the FIRM1 is signed by Nintendo, but that doesn't mean it has to be read correctly, thanks to the unsigned keystore flaw. Because the keys are derived from the OTP, we obtain our OTP to mathematically determine a very special key. This key, when used by the arm9loader to decrypt FIRM1, will decrypt FIRM1 to, at the point where ARM9 jumps in, have an instruction to jump to our payload, still loaded in at the end of memory. Rekt.
I hope this answered any questions, and wasn't too confusing. Tell me if there's something I didn't cover, or doesn't make sense
Something else to mention: FIRM0 is the only integrity check that's failed. The arm9loader does not check the keystore, which unknowingly leads itself to its doom.

 

[Eradigon]

Completely untrue. The OTP is not used for any kind of FIRM encryption at all. Rather, the OTP is used in FIRM decryption.
The OTP is used to calculate keys that are used in arm9loader to decrypt FIRM0 & FIRM1. The FIRMs are signed by Nintendo, which obviously we can't change and still have signed. However, what we do is add a payload to the end of FIRM0. Because FIRM0 isn't signed, the bootrom does not jump to it and reads the backup FIRM1, which is smaller, and thus our payload isn't unloaded when the valid FIRM1 is read and prepared to jump to. Now here's where the OTP comes into play. Simplified to an extreme, the FIRM1 is signed by Nintendo, but that doesn't mean it has to be read correctly, thanks to the unsigned keystore flaw. Because the keys are derived from the OTP, we obtain our OTP to mathematically determine a very special key. This key, when used by the bootrom to decrypt FIRM1, will decrypt FIRM1 to, at the point where ARM9 jumps in, have an instruction to jump to our payload, still loaded in at the end of memory. Rekt.
I hope this answered any questions, and wasn't too confusing. Tell me if there's something I didn't cover, or doesn't make sense
Something else to mention: FIRM0 is the only integrity check that's failed. The arm9loader does not check the keystore, which unknowingly leads itself to its doom.

Thank you, this makes perfect sense (I'm fairly knowledgeable about the internal workings of software and encryption).

 

[Swiftloke]

Thank you, this makes perfect sense (I'm fairly knowledgeable about the internal workings of software and encryption).

Woohoo! If that's the case, then I succeeded in what I set out to do

 

[RednaxelaNnamtra]

Welcome. I think I may have felt some info out however. :/
So, these FIRMS are run immediately when you press the power button. It's what eventually loads native_firm, and then finally the HOME Menu. FIRM0 is the first that's run, and if it's found to be invalid in any way (like, in the case of a power outage during an update, or ahem. hax), the console uses FIRM1. This is used to our advantage.

One of the reasons a9lh exists is because of it randomly jumping to random instructions if a firm is found to be invalid. Using the OTP allows us to launch the FIRM without it refusing to boot, but since it fails another seperate integrity check, it still panics. But we injected our payload to where it jumps, so it unknowingly reads our instruction, which is arm9loaderhax. Profit.

not 100% percent right, we are putting our payload at the end of a firm version that is bigger, after this we are using the OTP's hash to encrypt our own firm encryption keys, where we changed the key that firmware 9.6+ uses on the new 3DS, and copy this to the nand. Because of this, the 3ds firmloader will decrypt firm 1, where we used the smaller 10.2 firm, to garbage. And because the firm1 is smaller than firm0 our payload is still left in the memory. So after the 3ds decrypted it the 3DS tries to jump to this garbage, where the first instuction is a jump our payload, because of our specific key, that we brute forced before.
So while firm0 is skipped, because we modified it and broke its signature, the signature of firm1 is still valid, because its an untouched firm without any modifications. On the other side we modified the key storage, which doesn't have a signature, which causes the brick on new 3DS systems, if we update Firm to a legit one, because it will still try to decrypt it to garbage.

Edit: @Swiftloke was a bit faster xD

 

[Swiftloke]

not 100% percent right, we are putting our payload at the end of a firm version that is bigger, after this we are using the OTP's hash to encrypt our own firm encryption keys, where we changed the key that firmware 9.6+ uses on the new 3DS, and copy this to the nand. Because of this, the 3ds firmloader will decrypt firm 1, where we used the smaller 10.2 firm, to garbage. And because the firm1 is smaller than firm0 our payload is still left in the memory. So after the 3ds decrypted it the 3DS tries to jump to this garbage, where the first instuction is a jump our payload, because of our specific key, that we brute forced before.
So while firm0 is skipped, because we modified it and broke its signature, the signature of firm1 is still valid, because its an untouched firm without any modifications. On the other side we modified the key storage, which doesn't have a signature, which causes the brick on new 3DS systems, if we update Firm to a legit one, because it will still try to decrypt it to garbage.

Edit: @Swiftloke was a bit faster xD

Damn you just got ninja'd harder than titanium

 

[RednaxelaNnamtra]

Completely untrue. The OTP is not used for any kind of FIRM encryption at all. Rather, the OTP is used in FIRM decryption.
The OTP is used to calculate keys that are used in arm9loader to decrypt FIRM0 & FIRM1. The FIRMs are signed by Nintendo, which obviously we can't change and still have signed. However, what we do is add a payload to the end of FIRM0. Because FIRM0 isn't signed, the bootrom does not jump to it and reads the backup FIRM1, which is smaller, and thus our payload isn't unloaded when the valid FIRM1 is read and prepared to jump to. Now here's where the OTP comes into play. Simplified to an extreme, the FIRM1 is signed by Nintendo, but that doesn't mean it has to be read correctly, thanks to the unsigned keystore flaw. Because the keys are derived from the OTP, we obtain our OTP to mathematically determine a very special key. This key, when used by the bootrom to decrypt FIRM1, will decrypt FIRM1 to, at the point where ARM9 jumps in, have an instruction to jump to our payload, still loaded in at the end of memory. Rekt.
I hope this answered any questions, and wasn't too confusing. Tell me if there's something I didn't cover, or doesn't make sense
Something else to mention: FIRM0 is the only integrity check that's failed. The arm9loader does not check the keystore, which unknowingly leads itself to its doom.

To be completely correct, its not the bootrom that decrypts the firm, its the arm9loader, that got added on the new 3DS, and because of that its called arm9loaderhax

 

[Swiftloke]

To be completely correct, its not the bootrom that decrypts the firm, its the arm9loader, that got added on the new 3DS, and because of that its called arm9loaderhax

I'll update that, thanks. I always leave something out >:/

 

[Friendsxix]

Completely untrue. The OTP is not used for any kind of FIRM encryption at all. Rather, the OTP is used in FIRM decryption.
The OTP is used to calculate keys that are used in arm9loader to decrypt FIRM0 & FIRM1. The FIRMs are signed by Nintendo, which obviously we can't change and still have signed. However, what we do is add a payload to the end of FIRM0. Because FIRM0 isn't signed, the bootrom does not jump to it and reads the backup FIRM1, which is smaller, and thus our payload isn't unloaded when the valid FIRM1 is read and prepared to jump to. Now here's where the OTP comes into play. Simplified to an extreme, the FIRM1 is signed by Nintendo, but that doesn't mean it has to be read correctly, thanks to the unsigned keystore flaw. Because the keys are derived from the OTP, we obtain our OTP to mathematically determine a very special key. This key, when used by the bootrom to decrypt FIRM1, will decrypt FIRM1 to, at the point where ARM9 jumps in, have an instruction to jump to our payload, still loaded in at the end of memory. Rekt.
I hope this answered any questions, and wasn't too confusing. Tell me if there's something I didn't cover, or doesn't make sense
Something else to mention: FIRM0 is the only integrity check that's failed. The arm9loader does not check the keystore, which unknowingly leads itself to its doom.

You forgot the best part! Arm9loader generates two keys -- the old one that was compromised right away, and the new one Nintendo hastily generated in response. The reason the exploit works is because, while the original key was actually verified before it was used, the second key is not!

 

[Swiftloke]

You forgot the best part! Arm9loader generates two keys -- the old one that was compromised right away, and the new one Nintendo hastily generated in response. The reason the exploit works is because, while the original key was actually verified before it was used, the second key is not!

Not necessarily related to the explanation of arm9loaderhax itself. Because so many people like that post, I might include that bit of info in a separate thread explaining arm9loaderhax in general.
Would you all like that? /:/
Also, it's two different versions of arm9loader, not keys.

 

[BothyBhoy]

Not necessarily related to the explanation of arm9loaderhax itself. Because so many people like that post, I might include that bit of info in a separate thread explaining arm9loaderhax in general.
Would you all like that? /:/
Also, it's two different versions of arm9loader, not keys.

yes please.......would make a very interesting read!!!!!,,

 

[RednaxelaNnamtra]

@Swiftloke I think its the bootrom that checks the signatures, while the arm9loader is part of the firm partition and does the encryption of the (arm9-) firm inside of the firm partition. But im not 100% sure atm.

 

[Friendsxix]

Not necessarily related to the explanation of arm9loaderhax itself. Because so many people like that post, I might include that bit of info in a separate thread explaining arm9loaderhax in general.
Would you all like that? /:/
Also, it's two different versions of arm9loader, not keys.

No, it's not only a different version -- it's a different key.

EDIT: Watch at 55:03.

 

[RednaxelaNnamtra]

No, it's not only a different version -- it's a different key.

EDIT: Watch at 55:03.

Yes, they where wrong, its a different version of the arm9loader, that uses a different key.