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

[Billy Acuña]

(Trying to copy files without using C printing functions hurts my brain...)

I know that feel bro [emoji14]

 

[mashers]

I know that feel bro [emoji14]

I managed it in the end. It was ridiculous

 

[mashers]

I've just pushed pre-release version 0.7 to GitHub. This update brings the following changes:

• 3DSafe can now boot without an SD card present. To accomplish this you will need to boot 3DSafe and then press the R button from the options screen to update the files on CTRNAND. This will copy /3dsafe/emergency.bin to your NAND. If you try to boot without the SD card, 3DSafe will attempt to boot this payload. A modified Luma payload is included in the release archive and preconfigured to boot SysNAND CFW. Replacing this with a different payload is possible, but not recommended as changes were required to the payload to achieve booting from CTRNAND.
• Owner contact details (lost.bin) are also copied to CTRNAND, meaning they will be displayed even if no SD card is present. The first time you boot 3DSafe with a lost.bin present on the SD card it will automatically be copied to CTRNAND. If you change the lost.bin on your SD card, boot 3DSafe and press the R button from the options screen to re-copy the file.
• The PIN request can now be toggled from the options menu. If you know your 3DS is in a safe place, you can disable the PIN lock in order to boot directly to the 3DSafe options menu without having to enter your PIN.

This release includes new graphics assets as well as the emergency.bin payload. It is highly recommended that you delete the /3dsafe folder from the root of your SD card and replace it with the one from this release. This will ensure all of the necessary files are present.

The installation instructions have also been updated. Instructions have been added for updating lost.bin, and instructions have also been added for updating from a previous version.

Please remember that this is pre-release software. Bugs may still be present. Always ensure you have an up-to-date NAND backup and a copy of your OTP in case of issues with 3DSafe.

 

[MadMageKefka]

Just wondering: what kind of risks are there with this project? Im full aware the installation has the same risks as installing a9lh, but I more mean the settings that write to the ctrnand. Does changing those types of things risk brick at all? Even with unlikely situations like an sd read error or god knows what. I just want to know exactly what Im getting into. I dont really understand a9lh on a technical level, just the basic idea of it.

 

[mashers]

Just wondering: what kind of risks are there with this project? Im full aware the installation has the same risks as installing a9lh, but I more mean the settings that write to the ctrnand. Does changing those types of things risk brick at all? Even with unlikely situations like an sd read error or god knows what. I just want to know exactly what Im getting into. I dont really understand a9lh on a technical level, just the basic idea of it.

I've put checks in along the way to see whether things like write operations were successful, but they only return their success or failure once the operation has been attempted.

Having said that, the actual risks with regard to CTRNAND write operations are pretty much the same as they would be if you were writing to a memory stick or SD card. Although SysNAND seems scary, it's actually just flash memory with encrypted FAT partitions. Once they're decrypted, writing to them is technically the same as copying a file to a memory stick.

If the write were to fail, the risks are that the file being written would be corrupted. Like with any storage device, the filesystem (in this case FAT) takes care of writing the file to the correct place, so a failure should result in only that file becoming corrupt.

In theory I suppose it is possible that a catastrophic failure could corrupt the filesystem or overwrite the wrong part of the filesystem, but I can't think of any situation in which that would happen, and the likelihood of such an event would be the same as if you were copying the files to a memory stick.

In short, the SECOND most dangerous thing about installing 3DSafe is the process of installing it, and thanks to SafeA9LHInstaller that's pretty safe. The MOST dangerous thing is that because this is pre-release software, so it hasn't been tested by a large group of users yet (AFAIK). I use it constantly so I'm pretty sure that there's nothing devastating in terms of bugs.

One final point to make, is that writing to CTRNAND is a different part of NAND. Even corrupting CTRNAND should leave A9LH alone, so you should always be able to boot Decrypt9 and restore a NAND backup should the worst happen.

 

[MadMageKefka]

I've put checks in along the way to see whether things like write operations were successful, but they only return their success or failure once the operation has been attempted.

Having said that, the actual risks with regard to CTRNAND write operations are pretty much the same as they would be if you were writing to a memory stick or SD card. Although SysNAND seems scary, it's actually just flash memory with encrypted FAT partitions. Once they're decrypted, writing to them is technically the same as copying a file to a memory stick.

If the write were to fail, the risks are that the file being written would be corrupted. Like with any storage device, the filesystem (in this case FAT) takes care of writing the file to the correct place, so a failure should result in only that file becoming corrupt.

In theory I suppose it is possible that a catastrophic failure could corrupt the filesystem or overwrite the wrong part of the filesystem, but I can't think of any situation in which that would happen, and the likelihood of such an event would be the same as if you were copying the files to a memory stick.

In short, the SECOND most dangerous thing about installing 3DSafe is the process of installing it, and thanks to SafeA9LHInstaller that's pretty safe. The MOST dangerous thing is that because this is pre-release software, so it hasn't been tested by a large group of users yet (AFAIK). I use it constantly so I'm pretty sure that there's nothing devastating in terms of bugs.

One final point to make, is that writing to CTRNAND is a different part of NAND. Even corrupting CTRNAND should leave A9LH alone, so you should always be able to boot Decrypt9 and restore a NAND backup should the worst happen.

Thanks for such a detailed response! The last paragraph pretty much nulled 90% of my fears. As excited as I am for this, I will be waiting for a stable release, since this will be installed on my majoras mask console and I dont want to take any unnecessary risks. I have been watching this thread multiple times a day and it just gets better and better! Really glad you didn't give up when you had trouble gaining NAND access. This project is exactly what I have been looking / asking for since I first learned of 3DS hacks! Please keep up the FANTASTIC work!

 

[mashers]

Thanks for such a detailed response! The last paragraph pretty much nulled 90% of my fears. As excited as I am for this, I will be waiting for a stable release, since this will be installed on my majoras mask console and I dont want to take any unnecessary risks. I have been watching this thread multiple times a day and it just gets better and better! Really glad you didn't give up when you had trouble gaining NAND access. This project is exactly what I have been looking / asking for since I first learned of 3DS hacks! Please keep up the FANTASTIC work!

No worries buddy! I'm glad you're excited about this project. If it helps, as long as you have a NAND backup there's actually no way you can permanently brick your 3DS. The very worst case scenario if you did somehow brick is that you would have to send your 3DS off for hardmodding so you can re-flash the NAND. Hard modding costs very little and there are several trusted members here who can do it for you.

But, as I said, the risk is very small anyway. Nonetheless, it's definitely advisable to wait for a stable release, which will no doubt come once the final features have been added and more intensive testing has been done.

 

[Ichigo1000]

May i ask what is an adapted luma payload? Does it mean a stripped down version of luma without all the extra features, just like what luma's a9lh fork used to boot without an sd?

Or is it a full luma cfw? I heard aurora did not want to include the full luma in the nand because it can cause unnecessary wear to the nand chip, since it has a limited of read and write cycles.

Also, if the pin is removed, will it boot straight into the home menu, much like stock a9lh? If yes, how do you go to the options?
And if not is there an option to disable options menu from popping up each boot?

 

[XRaTiX]

The no-SD boot it was I waited for,good work,I'll wait for the stable release ,once is uploaded I'll install it right away!

Keep up the good work!

 

[nedron92]

I love that work, if it become a stable release I will install it (:

But, like it's mentioned here, will be there an option to boot straight into arm9loadhax.bin (mostly Luma) if PIN is toogled to OFF?
and show options-menu only if you want it - that would be awesome as hell ^^.
(But key combo is not good at all, cause if you use Luma3DS payloads...but what is, if ..and only if you press/hold Home-Button at boot/power-on
it shows the options Menu of 3dsSafe? Is that even possible..because the Home-Button doesn't have any effect at all at this early boot-stage or?)

 

[hippy dave]

Hope the dog is ok

 

[A_Bricked_Guy]

Will constantly updating this payload mess up 3DS' Nand? Should I wait for a final release?

 

[mashers]

May i ask what is an adapted luma payload? Does it mean a stripped down version of luma without all the extra features, just like what luma's a9lh fork used to boot without an sd?

Or is it a full luma cfw? I heard aurora did not want to include the full luma in the nand because it can cause unnecessary wear to the nand chip, since it has a limited of read and write cycles.

Also, if the pin is removed, will it boot straight into the home menu, much like stock a9lh? If yes, how do you go to the options?
And if not is there an option to disable options menu from popping up each boot?

It's a full Luma payload with the config loading/saving removed and hard coded to boot SysNAND. I understand about not wanting to write large files to NAND many times, but I have never heard of limited read cycles on a NAND. If that were the case then simply booting the 3ds would eventually wear out the NAND. Realistically the emergency payload is a 42kb file which only needs to be written to NAND once, so it's really not going to damage your NAND.

If the PIN is disabled, it goes to the 3DSafe options menu directly. I was thinking of making it skip this unless a key is pressed, but I don't want to interfere with other payloads checking for held keys. I'll look into it though

The no-SD boot it was I waited for,good work,I'll wait for the stable release ,once is uploaded I'll install it right away!

Keep up the good work!

Thanks

I love that work, if it become a stable release I will install it (:

But, like it's mentioned here, will be there an option to boot straight into arm9loadhax.bin (mostly Luma) if PIN is toogled to OFF?
and show options-menu only if you want it - that would be awesome as hell ^^.
(But key combo is not good at all, cause if you use Luma3DS payloads...but what is, if ..and only if you press/hold Home-Button at boot/power-on
it shows the options Menu of 3dsSafe? Is that even possible..because the Home-Button doesn't have any effect at all at this early boot-stage or?)

I don't know if I can check for the home button but I'll look into it. If not, would a d-pad key be ok? I don't think Luma uses it for switching payloads.

Hope the dog is ok

He's fine, thanks buddy

Will constantly updating this payload mess up 3DS' Nand? Should I wait for a final release?

NANDs have thousands of rewrite cycles, maybe more. Updating this a few times isn't going to contribute significantly to wear on the NAND.

 

[mashers]

(Tagging @Ichigo1000 @nedron92 as they specifically asked for this feature)

I've just uploaded pre-release 0.8 to GitHub. This brings the following changes:

• If the PIN lock has been disabled from 3DSafe options, 3DSafe will now boot directly to your arm9loaderhax payload (or emergency payload) without showing the options screen.
• If you want to show the options screen while booting, hold the UP button while powering on your 3DS. The options screen will then be displayed, and from here you can re-enable the PIN or change other 3DSafe settings.
• The options will still be displayed on boot automatically if the OTP bypass is used.

Please remember that this is pre-release software. Bugs may still be present. Always ensure you have an up-to-date NAND backup and a copy of your OTP in case of issues with 3DSafe.

 

[metroid maniac]

It's a full Luma payload with the config loading/saving removed and hard coded to boot SysNAND.

Can I use any a9lh payload? It seems like SaltFW is perfectly suited for this.
Is there any reason you made that modified Luma payload instead of just using an existing minimal CFW like SaltFW?

This emergency payload is copied into the CTRNAND filesystem, right?

 

[mashers]

Can I use any a9lh payload? It seems like SaltFW is perfectly suited for this.
Is there any reason you made that modified Luma payload instead of just using an existing minimal CFW like SaltFW?

I tried SaltFW but it wouldn't boot. It worked if I put the payload on SD card and booted it from 3DSafe that way, but once it was on NAND, it just hung on a black screen when I tried to boot it. Luma worked, so I used that.

This emergency payload is copied into the CTRNAND filesystem, right?

Yes, it's stored on CTRNAND so it can boot without the SD card.

 

[metroid maniac]

I tried SaltFW but it wouldn't boot. It worked if I put the payload on SD card and booted it from 3DSafe that way, but once it was on NAND, it just hung on a black screen when I tried to boot it. Luma worked, so I used that.
Yes, it's stored on CTRNAND so it can boot without the SD card.

Wow, thanks for the prompt response!
I'm a little uncertain about installing a prerelease a9lh fork that hasn't been so rigorously tested, as the last thing i need is another bricked 3DS, but 3DSafe seems like it's bringing a lot of useful features to the table.

I kind of have to wonder now why ShadowNAND decided to implement its miniCFW all in the stage2 payload rather than just booting it out of a binary in CTRNAND. ShadowNAND's approach seems like a lot more work for less functionality.

Anyway great work, and cheers I look forward to making the most of this software.

 

[mashers]

Wow, thanks for the prompt response!
I'm a little uncertain about installing a prerelease a9lh fork that hasn't been so rigorously tested, as the last thing i need is another bricked 3DS, but 3DSafe seems like it's bringing a lot of useful features to the table.

I kind of have to wonder now why ShadowNAND decided to implement its miniCFW all in the stage2 payload rather than just booting it out of a binary in CTRNAND. ShadowNAND's approach seems like a lot more work for less functionality.

Anyway great work, and cheers I look forward to making the most of this software.

I do agree that waiting for more testing to be done is wise. I'll be asking for confirmation from testers shortly so I can confirm that it works in a range of devices and regions.

As for why ShadowNAND implemented stage2 miniCFW, well it's slightly more convenient because you don't have to install anything to CTRNAND, but it's so much more flexible if you install it in CTRNAND. Stage2 is limited on size, but booting a payload after stage2 from CTRNAND allows much bigger payloads.

 

[MadMageKefka]

@mashers Just a reminder, weren't you going to add instructions for people installing from a9lh v1? I'm pretty sure the only difference is that they would need the file aeskeydb.bin at the root of their SD, since v1 didn't use it, but I don't see that anywhere in your guide.

 

[mashers]

@mashers Just a reminder, weren't you going to add instructions for people installing from a9lh v1? I'm pretty sure the only difference is that they would need the file aeskeydb.bin at the root of their SD, since v1 didn't use it, but I don't see that anywhere in your guide.

Thank you for the reminder. I completely forgot about about this. I'll add it asap.