Hacking [Release] 3DSafe: In-NAND PIN lock for 3DS

[mashers]

I found a bug on 0.11 version, on the screen to enter the pin. Every time we tap on a key (like A, B, X, Y L, R etc) the screen «bug».

What do you mean? What actually happens?

 

[nooby89]

I will make a video later.

 

[Aurora Wright]

"If you have neither sha.bin nor a NAND backup
If you have neither of these files then unfortunately your 3DS is essentially bricked, as you will not be able to bypass the PIN lock unless you can somehow remember your PIN. This is why the installation instructions stress the need to back up both of these files safely during 3DSafe installation."
This is not true by the way, because A9LH Stage 2 is not encrypted so you can just replace it with an hardmod

 

[metroid maniac]

"If you have neither sha.bin nor a NAND backup
If you have neither of these files then unfortunately your 3DS is essentially bricked, as you will not be able to bypass the PIN lock unless you can somehow remember your PIN. This is why the installation instructions stress the need to back up both of these files safely during 3DSafe installation."
This is not true by the way, because A9LH Stage 2 is not encrypted so you can just replace it with an hardmod

I didn't test it but I noticed in the code that if 3dsafe is unable to mount the CTRNAND partition it will boot safearm9loaderhax installer and let you install a new a9lh fork.

This behaviour seems strange though, why not just boot a payload from SD?

I don't think anyone using 3dsafe is concerned about anyone performing a hardware attack on the console to gain entry, mind.

 

[mashers]

@Aurora Wright
True. I'm not sure how to go about describing that, since it could enable a hacker to disable the PIN lock on a stolen 3DS.

While you're reading, I was wondering if you might know the answer to something. I'm trying to reinstate otp.bin verification, and now that I'm simply checking the sha.bin against the leftover hashes in memory I'm thinking of just hashing the OTP and then doing the same with the resulting hash. I've got a weird problem though. I've read the otp file to a buffer and then fed that into sha_quick() (from sha.h); however, this function always puts the actual OTP hash (the one in memory) into the result buffer, even if the otp.bin on the SD card is invalid. So, I'm wondering: is this sha function supposed to be usable for hashing other data, or is it specific to getting the otp hash from memory?

I didn't test it but I noticed in the code that if 3dsafe is unable to mount the CTRNAND partition it will boot safearm9loaderhax installer and let you install a new a9lh fork.

This behaviour seems strange though, why not just boot a payload from SD?

I don't think anyone using 3dsafe is concerned about anyone performing a hardware attack on the console to gain entry, mind.

This is mostly to make it inconvenient for a thief if they happened to steal a 3DS which had a problem mounting CTRNAND for some reason. They would be able to re-flash a different payload, but wouldn't be able to do anything else until they did this. This means that if somebody stole a 3DS in such a condition, they would only be able to use it if they knew about 3DS hacking.

 

[metroid maniac]

@Aurora Wright
True. I'm not sure how to go about describing that, since it could enable a hacker to disable the PIN lock on a stolen 3DS.

As a suggestion;
Encrypt stage2 with the OTP hash when installing it with safea9lhinstaller, and stage1 decryts with the same hash on boot.
Or perhaps perform a hash over stage2, encrypt the stage2 hash with the OTP hash, and use that to verify the integrity of stage2.

This is an unlikely scenario though, I think anyone who knows how to NAND mod a console and inject a stage2 payload into NAND won't need to steal one

 

[mashers]

As a suggestion;
Encrypt stage2 with the OTP hash when installing it with safea9lhinstaller, and stage1 decryts with the same hash on boot.
Or perhaps perform a hash over stage2, encrypt the stage2 hash with the OTP hash, and use that to verify the integrity of stage2.

This is an unlikely scenario though, I think anyone who knows how to NAND mod a console and inject a stage2 payload into NAND won't need to steal one

That's actually a really good idea. It does, however, introduce an extra burden on the user during installation (i.e. to encrypt the payload first).

 

[metroid maniac]

That's actually a really good idea. It does, however, introduce an extra burden on the user during installation (i.e. to encrypt the payload first).

I'm sure a minor mod to safea9lhinstaller could do either of those things at install time.

 

[mashers]

I'm sure a minor mod to safea9lhinstaller could do either of those things at install time.

Also true. I could bundle the modified version with the release, and the built-in one could handle it too (though it would need to know whether the user was installing a 3DSafe payload). I'll consider this for a future release.

 

[metroid maniac]

I want to keep rolling with this idea of a secure boot sequence for an a9lh fork. Not because I want it practically implemented, but because I want to see just how far it can get.
My knowledge is limited so I'm sure I'll fuck up somewhere, mind.

OK, so stage1 is embedded in FIRM0, overwriting its top couple KB. Stage1 is encrypted by the same console-unique keystream that FIRM is.
My understanding of DSiWare and AUTOFIRM downgrades is that by knowing what the plaintext of FIRM should be and what the ciphertext installed to FIRM0/1 is, it can deduce the xorpad used to encrypt/decrypt any FIRM and thus insert an encrypted, downgraded FIRM.

I'm not sure why only minor FIRM downgrades are possible (11.0 -> 10.4 but not 11.0 -> 9.2).

So if the attacker knows that keystream by correctly guessing 3dsafe and its version, what could they accomplish?
Install an alternate stage1?
Install a vanilla FIRM?

EDIT: I just installed the latest 3dsafe. My ramblings will have to wait; but I really want to consider how it might be possible to mitigate the known-plaintext attack

3dsafe 0.11 installed without issues.
When it booted to the menu, the option to dump sha.bin was not listed on the main menu. I'm using the text based menu, not the graphical one. I'm not sure if this is intentional or an oversight.
The sha.bin bypass worked.

However, I found something weird... When I computed the sha256 hash of my otp.bin manually with my computer, I found that it was different to the hex value in sha.bin that 3dsafe gave me. I'm not sure what's going on here.

Deleting sha.bin caused 3dsafe to work as expected.

I haven't found anything else of note.

 

[astronautlevel]

I'm not sure why only minor FIRM downgrades are possible (11.0 -> 10.4 but not 11.0 -> 9.2).

I can answer this.

It has to do with how the home menu actually checks for the kernel version. There are three parts of the kernel version - MAJOR VER . MINOR VER - REVISION VER. If the Minor Ver is lower than the required Minor Ver, the application won't boot. You can install a 10.4 nfirm (2.50-11, rev might be wrong) because the minor ver (50) is the same as the required minor ver by the home menu. However, the 9.0.0 nfirm (2.46-0) has a lower minor version than the version required by the 11.1 home menu.

 

[metroid maniac]

I can answer this.

It has to do with how the home menu actually checks for the kernel version. There are three parts of the kernel version - MAJOR VER . MINOR VER - REVISION VER. If the Minor Ver is lower than the required Minor Ver, the application won't boot. You can install a 10.4 nfirm (2.50-11, rev might be wrong) because the minor ver (50) is the same as the required minor ver by the home menu. However, the 9.0.0 nfirm (2.46-0) has a lower minor version than the version required by the 11.1 home menu.

Thank you very much, that makes sense. I just didn't know if the bootloader checked or if it happened after NATIVE_FIRM loaded.

OK, so mitigating the known plaintext attack...

As far as FIRM0 goes, we don't care about anything but having a valid header and the stage1 overwriting its last few kilobytes. The remainder of FIRM0 can be garbage and that's OK for a9lh purposes.
If you just overwrite FIRM0 with random data, that leaves an attacker only being able to learn the xorpad for the stage1 area.

safeA9LHinstaller specifies a maximum stage1 size of 0x1E70 which I think refers to about 7.5KB. Why not place the known stage1 blob at a random offset in this region?
The "random" jump from the decrypted FIRM1 will go to the expected stage1 entrypoint, which would be a jump to where the real stage1 is now positioned. You could fill the rest of the 7.5KB with garbage and that leaves the attacker only knowing the plaintext of the top few bits of the jump instruction.
I think that rules out any possibility of an attacker injecting anything useful into FIRM0, whether a legitimate FIRM or a replacement stage1. But that still leaves FIRM1...

FIRM1 in an a9lh'd 3DS is legitimate. The attacker can likely get the xorpad from that, and there's nothing really you can do to stop that.
On the O3DS you might therefore be able to install the FIRM for 11.1 (or whatever the home menu needs) then I think you can go ahead and get the console to boot again.
On the N3DS, perhaps not. The keystore is still corrupted, and therefore N3DS NATIVE_FIRM won't decrypt correctly (assuming it uses the same key as the one you modified for a9lh; however if you're anticipating this attack you could corrupt all the keys you don't need to use with garbage anyway)

I'm not sure how the "OTPless install" works. If the only data needed to alter the contents of the keystore is to know both its plaintext and ciphertext, and the plaintext is the same for every a9lh installation (I'm not sure if the key for a good jump is bruteforced offline and shared between all installations or generated at install time; probably the former), then the attacker wins. He can restore an authentic keystore and I believe he can even learn the OTP hash. However I don't know how this exploit works, and I'm resting on the assumption that the keystore's plaintext and ciphertext are the only things you need to know.

Please someone smart, tear this analysis to bits! I want to make sure I've got my understanding right.

EDIT: you could probably keep the console from working with the vanilla FIRM simply by breaking the signature on sonething important like the home menu.

 

[Halvorsen]

Sometimes when coldbooting OR rebooting, the screen stays black on the HOME Menu for around 5 seconds then cuts back on. I'm using 0.10 on a USA o3DS.

 

[ADS3500]

Sometimes when coldbooting OR rebooting, the screen stays black on the HOME Menu for around 5 seconds then cuts back on. I'm using 0.10 on a USA o3DS.

I don't think that has to do with this because the same thing happened to me before I used this. Custom themes are probably the issue.

 

[mashers]

Sometimes when coldbooting OR rebooting, the screen stays black on the HOME Menu for around 5 seconds then cuts back on. I'm using 0.10 on a USA o3DS.

How do you know it's on the home menu if the screen is black?

 

[ghostpotato]

I did think about this and considered making it so you had to enter the old PIN before changing it. The problem here is that if you forget the PIN, you can bypass it but then wouldn't be able to change it. To be honest, you shouldn't be walking around with your OTP on your SD card anyway so this problem should never occur. If you're bypassing the PIN, you should then be changing it and immediately deleting the OTP anyway. If you leave it on the SD card, 3DSafe becomes pointless whether you can change the PIN or not.

@gamesquest1 @metroid maniac @ghostpotato @Skyshadow101
I hope you don't mind me tagging you all, but you were all kind enough to report back your test results. Before going to 1.0, I've just uploaded one more beta version. If you could give this a try I would really appreciate it. This version removes the OTP bypass and replaces it with SHA bypass. So, if you could try the following and let me know the outcome I would be really grateful:

1. Update to 3DSafe 0.11
2. Put otp.bin on the root of your SD card and verify that it no longer bypasses the PIN lock
3. Enter 3DSafe settings
4. Press L to dump the sha.bin to the root of your SD card
5. Reboot your 3DS and check it bypasses the PIN lock
6. Delete sha.bin from the SD card, reboot, and ensure the bypass no longer occurs

If you could let me know about each of those steps and whether each worked I would really appreciate it.

I can test this either tonight or tomorrow night with an 11.0.0-33U USA O3DS. Most likely tonight.

 

[Halvorsen]

I don't think that has to do with this because the same thing happened to me before I used this. Custom themes are probably the issue.

Why would I list it on 3DSafe's thread if the problem has nothing to do with 3DSafe...?

And no, this happens without an SD Card inside in the first place.
Even if it was a theme, it would permanently hang, not just go for a few seconds then pop back on.

How do you know it's on the home menu if the screen is black?

I can hear the sounds and even start an application before I actually see the screen. Maybe this has something to do with wonky screeninit code carrying over into the actual OS?

But no, this never happened before 3DSafe, and on none of my devices. Yes, I checked the files..

It isn't a big deal since it happens only once every like 15 boots, but still.

 

[ADS3500]

Why would I list it on 3DSafe's thread if the problem has nothing to do with 3DSafe...?

And no, this happens without an SD Card inside in the first place.
Even if it was a theme, it would permanently hang, not just go for a few seconds then pop back on.

It happened to me a lot before I used this, so it could just be a normal problem with some versions of arm9loaderhax.

 

[Halvorsen]

It happened to me a lot before I used this, so it could just be a normal problem with some versions of arm9loaderhax.

Well weird haha. I used every single version of it, Delebile's, Aurora v2/v3, ShadowNAND, and this one.

It's not a big of a deal, I really like this version the most tbh.

 

[ghostpotato]

@mashers I can't get 0.11 to install. I get "Error: the OTP hash or the NAND key sector are invalid" from SafeA9LHInstaller. The md5sums and my OTP are correct. I put the payloads at /a9lh. Any ideas?