Homebrew Clarification Thread - What is going on?

[dark_samus3]

Yes, because you need an ARM9 exploit.

Arm9loaderhax would get n3ds users CFW on the latest FW

 

[Mrrraou]

N3DS users? No. O3DS users? For sure

Well, they would need particular hardware for ntrcardhax. With downgrading, you don't need any.

 

[Alex Spady]

Thanks for the information. Greatly appreciated.

 

[Mrrraou]

Arm9loaderhax would get n3ds users CFW on the latest FW

Too complicated to setup, it takes really too much time, and has to be bruteforced for each N3DS.

 

[dark_samus3]

Too complicated to setup, it takes really too much time, and has to be bruteforced for each N3DS.

How does it have to be bruteforced?

 

[dankzegriefer]

Yes, because you need an ARM9 exploit.

But isn't the ARM9 9.2 exploit reinstalling the old DS Profile thing to exploit the DS Profile Bug?

 

[Mrrraou]

How does it have to be bruteforced?

You have to make the N3DS decrypt random garbage, and hopefully get the first correct instructions that jumps to your payload and run it, without destroying the N3DS.

--------------------- MERGED ---------------------------

But isn't the ARM9 9.2 exploit reinstalling the old DS Profile thing to exploit the DS Profile Bug?

No. 9.2 has memchunkhax (which has a higher success rate than memchunkhax2) and firmlaunchhax.

 

[dankzegriefer]

You have to make the N3DS decrypt random garbage, and hopefully get the first correct instructions that jumps to your payload and run it, without destroying the N3DS.

--------------------- MERGED ---------------------------


No. 9.2 has memchunkhax and firmlaunchhax.

Oh, excuse me incorrectness.

 

[dark_samus3]

You have to make the N3DS decrypt random garbage, and hopefully get the first correct instructions that jumps to your payload and run it, without destroying the N3DS.

--------------------- MERGED ---------------------------


No. 9.2 has memchunkhax (which has a higher success rate than memchunkhax2) and firmlaunchhax.

Right, but the garbage should be the same each time (provided ofc that the same firmware version is there and the same key is used to decrypt it)

 

[ChaosRipple]

Right, but the garbage should be the same each time (provided ofc that the same firmware version is there and the same key is used to decrypt it)

Yes but everyone's console is encrypted with a different key I believe.

 

[dark_samus3]

Yes but everyone's console is encrypted with a different key I believe.

For arm9loader? The thing that they have to send the SAME firmware image to every console (for each firmware version ofc), already encrypted? Yeah pretty sure it's the same key

 

[Selver]

arm9loader loads FIRM from NAND. But arm9loader is decrypted and loaded by the bootloader. And the keyslot is cleared, because the payload is executed after arm9loader. So you can't regenerate the decryption keys. And the problem, is that you have to bruteforce to have something bootable and that does "what you want".

The brute force is not as bad as one might first think. The reason? ARM9 instruction structure:
Bits 31-28 == Condition as to whether to jump or not jump
Bits 27-25 == Must be 101b, so that's a one in eight chance
Bit 24 == Link bit, where 0b is to branch, and 1b is to branch with link (both potentially useful)
Bits 23-0 == Offset to jump to

Therefore, there is approximately a one in 128 chance that the first (garbage decrypted) instruction ARM9loader jumps to would itself be a jump. But, if not a jump, maybe the one following it is a jump (etc.). So, really, only the address bits matter. Thus, 2**24 / (bytes of hax NOP) is the probability of jumping to the hax.

QUESTION: What encryption is used for FIRM0 and FIRM1?
(e.g., using XORPAD? true encryption? other?

IFF they are encrypted by a simple XOR (e.g., similar to XORPAD usage), then arm9loader is much more powerful. Why? It might allow one to seed a known memory location with instructions of choice, because use of XOR creates an "Oracle" and the non-clearing of the memory bypasses signature requirements.

Still a bruteforce? Yes.
Significant reduction in overall system security? It definitely appears to be...

 

[ChaosRipple]

For arm9loader? The thing that they have to send the SAME firmware image to every console, already encrypted? Yeah pretty sure it's the same key

I can't say so for sure since I don't fully know the 3DS. But yes, it would be the same firmware image to every console. It can however, be encrypted afterward with a console specific key before storing it. That's the only way I'd see the bruteforce being required for every console.

 

[dark_samus3]

I can't say so for sure since I don't fully know the 3DS. But yes, it would be the same firmware image to every console. It can however, be encrypted afterward with a console specific key before storing it. That's the only way I'd see the bruteforce being required for every console.

I guess if you look at the post above yours the bruteforce isn't in a key, it's more of just a "get lucky with garbage jumping to your payload" kind of bruteforce (I misunderstood this too)

 

[Mrrraou]

QUESTION: What encryption is used for FIRM0 and FIRM1?
(e.g., using XORPAD? true encryption? other?

It's AES-128-CTR. (thanks motezazer for the precision)

 

[ChaosRipple]

I guess if you look at the post above yours the bruteforce isn't in a key, it's more of just a "get lucky with garbage jumping to your payload" kind of bruteforce (I misunderstood this too)

Well, if that's the case then wouldn't that mean we'd only need 1 key? Someone would just need to luckily get the bruteforce so that it would jump to the right location and then share the key he used? Because then if we were to use the same key, we'd get the same decrypted data with the same jump instruction. Unless there's something I don't understand. O:

 

[dark_samus3]

The brute force is not as bad as one might first think. The reason? ARM9 instruction structure:
Bits 31-28 == Condition as to whether to jump or not jump
Bits 27-25 == Must be 101b, so that's a one in eight chance
Bit 24 == Link bit, where 0b is to branch, and 1b is to branch with link (both potentially useful)
Bits 23-0 == Offset to jump to

Therefore, there is approximately a one in 128 chance that the first (garbage decrypted) instruction ARM9loader jumps to would itself be a jump. But, if not a jump, maybe the one following it is a jump (etc.). So, really, only the address bits matter. Thus, 2**24 / (bytes of hax NOP) is the probability of jumping to the hax.

QUESTION: What encryption is used for FIRM0 and FIRM1?
(e.g., using XORPAD? true encryption? other?

IFF they are encrypted by a simple XOR (e.g., similar to XORPAD usage), then arm9loader is much more powerful. Why? It might allow one to seed a known memory location with instructions of choice, because use of XOR creates an "Oracle" and the non-clearing of the memory bypasses signature requirements.

Still a bruteforce? Yes.
Significant reduction in overall system security? It definitely appears to be...

I'm not sure it's XORpad (one may be able to be generated, not sure) but this is kinda what I was saying, basically we craft a specific key(Y?) For each specific FW image, someone with a hardmod could find the most consistent one and we could probably craft a very specific FW that basically has almost everything we could want in terms of jumping exactly where we want

--------------------- MERGED ---------------------------

Well, if that's the case then wouldn't that mean we'd only need 1 key? Someone would just need to luckily get the bruteforce so that it would jump to the right location and then share the key he used? Because then if we were to use the same key, we'd get the same decrypted data with the same jump instruction. Unless there's something I don't understand. O:

We don't want/need a key... We actually REPLACE a key with a bad one, modify firm0 with a payload, arm9loader sees that it's bad and loads the (smaller) firm1 image, leaves the payload at the end of the image, decrypts to garbage (since we replaced the key) garbage jumps to the hax payload and you have super early arm9 execution

 

[ChaosRipple]

We don't want/need a key... We actually REPLACE a key with a bad one, modify firm0, with a payload, arm9loader sees that it's bad and loads the (smaller) firm1 image, leaves the payload at the end of the image, decrypts to garbage (since we replaced the key) garbage jumps go the hax payload and you have super early arm9 execution

Yes, I understand that part. When I said a key, I meant a randomly generated one to replace the actual one that is being used. If the firmware image is not encrypted with a console specific key, then when someone discovers one randomly generated key that is able to decrypt the image to garbage, then he would be able to share it with everyone, right?

 

[dark_samus3]

Yes, I understand that part. When I said a key, I meant a randomly generated one to replace the actual one that is being used. If the firmware image is not encrypted with a console specific key, then when someone discovers one randomly generated key that is able to decrypt the image to garbage, then he would be able to share it with everyone, right?

That's what I was trying to say earlier

 

[ChaosRipple]

That's what I was trying to say earlier

But that contradicts the entire point of why each console would require its own bruteforce. I need someone who understands the 3DS well to explain that. Lol.