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

[LongTimeLurker]

Not to sound like a douche

Wow, you really did though. Dude chill, he's just happy and it's not like you released this.

 

[dark_samus3]

Not to sound like a douche, but pretty much everyone and their grandmother found the aes ecb hack, including the whole #ctrdev channel months back. I personally found it right after the ccc conference, I am pretty sure I wasn't the only one. The vulnerability is plain obvious when you know the slightest thing about AES implementation.

Envoyé de mon SM-G935F en utilisant Tapatalk

well, yeah, I never said it was some huge achievement. It's cool, it requires a bit of lower level knowledge to find and I didn't have much experience when I found it. You're right it's quite obvious, I never said it wasn't (it's obvious to the point that I can't understand why nintendo would not have seen it...). Point is, it's my first thing, and no matter how simple it is, it's still a bit ethereal to have something I found come to fruition, but it's starting to sink in

 

[jimmyleen]

In order to use this you still need to downgrade but only to version 9.2, no higher or lower.

I repeat only downgrade to version 9.2...if possible.

 

[Myria]

Not to sound like a douche, but pretty much everyone and their grandmother found the aes ecb hack, including the whole #ctrdev channel months back. I personally found it right after the ccc conference, I am pretty sure I wasn't the only one. The vulnerability is plain obvious when you know the slightest thing about AES implementation.

Envoyé de mon SM-G935F en utilisant Tapatalk

I remember knowing about the ECB trick a while ago. It was rather obvious. I just didn't think that there would be a viable option, because I had thought that the branch window was much narrower (such as in how arm9loaderhax now works). I hadn't thought of relying upon the boot ROM not clearing ARM9 WRAM to make the viable branch 'window' much larger.

Also, there is the matter of dark_samus actually doing all the research and manual checking of all the possible choices. That's where a lot of the effort was.

 

[mathieulh]

well, yeah, I never said it was some huge achievement. It's cool, it requires a bit of lower level knowledge to find and I didn't have much experience when I found it. You're right it's quite obvious, I never said it wasn't (it's obvious to the point that I can't understand why nintendo would not have seen it...). Point is, it's my first thing, and no matter how simple it is, it's still a bit ethereal to have something I found come to fruition, but it's starting to sink in

Well, it only works because they forgot to check the second key against a test vector. Of course it would have been safer if they had been using AES CBC instead (there was no point in using ECB, that's just very bad implementation from the get go in that specific usage), of course it would have been a whole lot safer to have hashed the keystore and encrypt said hash using an RSA private key.
That said, this would have killed the whole kernel9 loader hack in the first place. Nintendo shouldn't trust people developers working on security implementations when those do not know about the basis of cryptography. (A fact which they have plainly demonstrated)

Envoyé de mon SM-G935F en utilisant Tapatalk

 

[mathieulh]

I remember knowing about the ECB trick a while ago. It was rather obvious. I just didn't think that there would be a viable option, because I had thought that the branch window was much narrower (such as in how arm9loaderhax now works). I hadn't thought of relying upon the boot ROM not clearing ARM9 WRAM to make the viable branch 'window' much larger.

Also, there is the matter of dark_samus actually doing all the research and manual checking of all the possible choices. That's where a lot of the effort was.

I had though of using the vram (or basically any ARM9 accessible memory that could be filled before reboot) but judged it too dangerous, since ram is volatile by nature and one wrong thing can get you a very easy brick.

In fact you can make the widow even wider by wrapping around in memory.

That's one of reasons I (and others didn't get it to work) we focussed on having an implementation that would load the payload from nand rather than memory, which narrowed things down as to what addresses could be jumped to (even when wrapping addresses around) by a fairly large margin, so we were waiting for more FIRM from Nintendo to see if they'd ever release one that would allow for a safer implantation.

This also means we (the folks from #ctrdev at least) didn't work on a memory based implantation (as in, filling memory, rebooting and waiting for the cpu to jump to the payload we filled before reboot), even though we had the theory worked out, we didn't even seek/bruterforce a working instruction that'd jump to a proper memory address (even though a couple were spotted during brute force attempts if memory serves me right)

One other major drawback of this approach is that it does not allow for an easy, bruteforce free hardmod a9lh, something we were hoping for in the event that a firmware with no process9/kernel9 vulnerability ever shows up.

Envoyé de mon SM-G935F en utilisant Tapatalk

 

[Myria]

Well, it only works because they forgot to check the second key against a test vector. Of course it would have been safer if they had been using AES CBC instead (there was no point in using ECB, that's just very bad implementation from the get go in that specific usage), of course it would have been a whole lot safer to have hashed the keystore and encrypt said hash using an RSA private key.

AES-CBC would have just changed the types of attacks that were possible. For example, a trivial manipulation would have been to force a key of all zeroes by setting the second block equal to the first.

Fundamentally, the flaw is the lack of validation on the key. RSA here wouldn't be any more secure than simply a test vector like is done with the first key.

 

[dark_samus3]

AES-CBC would have just changed the types of attacks that were possible. For example, a trivial manipulation would have been to force a key of all zeroes by setting the second block equal to the first.

Fundamentally, the flaw is the lack of validation on the key. RSA here wouldn't be any more secure than simply a test vector like is done with the first key.

sure, but one RSA block at the beginning would have been simpler and less likely to be forgotten...

 

[JackyD]

Will this process work on the O3DS as well or is it N3DS exclusive?

 

[mathieulh]

AES-CBC would have just changed the types of attacks that were possible. For example, a trivial manipulation would have been to force a key of all zeroes by setting the second block equal to the first.

Fundamentally, the flaw is the lack of validation on the key. RSA here wouldn't be any more secure than simply a test vector like is done with the first key.

RSA would have been more effective as it'd exist to validate the whole keystore as opposed to a single block, and the developer wouldn't have forgotten to implement a second test vector and call the function.

I might also add, in the case of CBC that a 00ed key is all you could have tried, as opposed to every single ecb block that's part of the keystore (basically every individual keys in there) making it a whole lot harder to yield proper results during a bruteforce attempt.

Of course it wouldn't be perfect, but I am fairly confident OTP-less a9lh would likely have been avoided.

Envoyé de mon SM-G935F en utilisant Tapatalk

 

[dark_samus3]

Will this process work on the O3DS as well or is it N3DS exclusive?

Will people ever learn to read?

 

[brigcaster]

Well, I guess Plaicect's new revision is going to be like two lines long

Will this process work on the O3DS as well or is it N3DS exclusive?

Only N3DS due to different crypto setup apparently

 

[SciresM]

That's one of reasons I (and others didn't get it to work) we focussed on having an implementation that would load the payload from nand rather than memory, which narrowed things down as to what addresses could be jumped to (even when wrapping addresses around) by a fairly large margin, so we were waiting for more FIRM from Nintendo to see if they'd ever release one that would allow for a safer implantation.

This also means we (the folks from #ctrdev at least) didn't work on a memory based implantation (as in, filling memory, rebooting and waiting for the cpu to jump to the payload we filled before reboot), even though we had the theory worked out, we didn't even seek/bruterforce a working instruction that'd jump to a proper memory address (even though a couple were spotted during brute force attempts if memory serves me right)

Isn't this kind of silly? My implementation relies on exactly one instruction still being in memory post-reboot -- that's really very safe, considering the RAM uncleared on reboots flaw is well-tested. Everything else is loaded from NAND per normal A9LH (in fact, the single instruction I rely on being in RAM is just a branch to normal A9LH payload).

I do agree bruteforce free hardmod a9lh would have been nice, but I also don't see how you could get NAND payload loading out of a single branch? You'd know better than I would, I'm sure, but I don't actually understand the principle there. Unless, of course, you mean you were hoping for a branch to the normal A9LH payload location.

 

[einhuman197]

Does this installer dump a otp.bin when it installs a9lh? If not can we access the otp.bin when we have a9lh? Just a question, already have a9lh.

 

[SciresM]

Does this installer dump a otp.bin when it installs a9lh? If not can we access the otp.bin when we have a9lh? Just a question, already have a9lh.

No, this does not dump OTP.bin, and cannot dump OTP.bin -- it's called OTPless for a reason!

 

[Clydefrosch]

I'm trying to understand the vuln the best I can and from the looks of it, this may be one of the biggest hits to 3ds security yet. And yeah, N shooted in the foot yet again. I bet gateway people will feel stupid once they find this out. And of course they will get this.

is it really? it only works on already exploitable systems and just makes something currently easy a bit easier.

 

[einhuman197]

No, this does not dump OTP.bin, and cannot dump OTP.bin -- it's called OTPless for a reason!

K thanks.

 

[Salamencizer]

Nice work, I'll probably use this when I buy a new 3ds

It depends. Most ARM9 exploits also require an ARM11 kernel exploit

Sounds great, because I heard that the dev working on the arm9 exploit for 11.x had also found an arm11 kernal vuln

 

[JackyD]

Well, I guess Plaicect's new revision is going to be like two lines long


Only N3DS due to different crypto setup apparently

Thanks. Makes sense.

 

[thisisallowed]

In order to use this you still need to downgrade but only to version 9.2, no higher or lower.

I repeat only downgrade to version 9.2...if possible.

Any version with an arm9 exploit works

 

[Chuu]

slightly off topic, but how do you even go about finding your own vulns?