[Feature Request] PIN for Security™

[JoshuaDoes]

I'm requesting a PIN feature with optional usage for certain things. For example, being able to choose to have a PIN just to access the fastboot3DS menu, or even require it just to boot (both PIN modes being options found on most modern BIOSes).

These are my suggested uses for a PIN:

1. Booting the 3DS
2. Booting into the fastboot3DS menu
3. Booting specific boot slots rather than every single boot slot as 1. would do
4. Booting from specific files
5. Making NAND backups/restores
6. Flashing a firmware to FIRM1
7. Updating fastboot3DS with a new update

Before using fastboot3DS, I had Luma3DS's PIN feature enabled for both SD and NAND booting to prevent unauthorized access to my 3DS should it be stolen (without proper knowledge of how to delete the PIN file or swap boot.firm, of course, so it's not exactly that secure). However, with fastboot3DS replacing boot9strap and having an interface that can appear before Luma3DS and allow modifications to the system, I feel just a little less sane about leaving my 3DS around, as even if someone picks it up and doesn't know what they're doing, they can still do something they shouldn't.

I also apologize if the Issues section is not a proper location for a feature request, but I saw nothing in the README stating there was a specific location for them.

[LilithValentine]

It’s still not even that secure now with NTBoot. PINs on the 3DS are just a security blanket that honestly don’t keep your system that safe if it were stolen.

[uumas]

They keep it safe from most. Thieves, especially the random guy who finds my 3ds and decides to keep it will not know how to bypass the pin.

[d0k3]

I get both sides. Yes, in the days of ntrboot and Lazarus 3DS a PIN can't provide any real security against someone knowing what he's doing there. You'd actually have to secure the MCU with a PIN, and even if that was possible, it would be a major bricking risk.

On the other hand, some kid finding your 3DS, noticing right away that it is useless to them, may be more likely to return it.

Now, I'd say a PIN on it's own wouldn't do anything good, you'd need to have some owner info in there, too. Something like: "If found, please return to...". I'd even say that would increase the likelihood of a returned device more, cause the finder would feel more "guilty".

You could create something like that yourself by autobooting into a payload that would show exactly that on screen, and setting all your "real" payloads to somewhat cryptic button combos. I also get that the perceived safety of that would be less than the Luma button combo. Leaving that open for discussion now.

[JoshuaDoes]

I do agree that owner information should be something that can be set and shown, and I do see the point that it could be a separate payload that boots into the CFW. But the issue with that is fastboot3DS would need to be able to tell the payload what boot slot is being used or where the location of the selected FIRM is, and just doing that for every single payload could be a bit of a hassle (if I'm thinking about this correctly, that is).

Yes, it may be a "security blanket," but for a lot of people like me it does keep most people I know out of the system. I've only actually found maybe 3 people in the town I'm in that actually know how the 3DS works and could bypass it, whereas most others would be clueless at the PIN screen.

I personally vouch for the PIN feature with owner info should the 3DS be lost or stolen (as in most case scenarios, the person who sees a random 3DS and decides to take it probably isn't gonna know how to bypass it). Again, I know it's just a security blanket, but it at least saves from most scenarios rather than leaving the 3DS vulnerable to literally anyone.

Should it be implemented, I do have some ideas on how the PIN could be stored. And heck, it doesn't even have to be a PIN per se, it could be a password or an order of button combinations (like holding A+B+X, then letting go and holding L+R+Y, etc). I know it's never going to be 100% secure without somehow having MCU access to flash it, but it still doesn't hurt to prevent most scenarios rather than leave all of them possible as I noted earlier. It's like an unlocked Android bootloader, you can secure everything up to the main boot program but you can't prevent people from deleting/altering the files that add that security.

Edit: There's a reason I put ™ in the title, because I know it's not 100% secure.

[profi200]

I'm with the others. I think this is rather snake oil than security. Not sure if we will implement it.

[JoshuaDoes]

It isn't actual security, but if you think about it anything similar to projects like this with a feature like that isn't actual security, however it's the next best thing to modifying the MCU and still deters most incidents.

For example, roughly a year ago I was living in another city with my grandma. Someone else who lived in the house with us loved to steal things from people and sell them to her friends, and one time she tried taking my 3DS but was dumbfounded when she tried turning it on and saw the Luma3DS PIN screen and then tried returning it to where she found it (me of course being there before she got back and thus knowing the above). If it wasn't for the "blanket security" of that PIN feature, I'd have lost my 3DS for good and probably still wouldn't even have another one due to current financial issues.

[LilithValentine]

Setting Luma3DS with Quiet, autoboot, and a pin would get the same results for the situation you just discribed. Otherwise a thief who knows about anything about the scene would be able to remove the pin with NTRBoot.

[LilithValentine]

My suggestion would easily stop any pety theif and saves far more time than implementing a whole new feature.

[profi200]

Luma's pin is saved in the config. It's enough to delete a file and it's gone. The usual setup is b9s -> Luma which means any idiot can bypass it with 5 min. googling. So this is totally useless even moreso with ntrboot.

[LilithValentine]

Well actually you can save the pin on the nand. Although that method was easily bypassed by placing anothey CFW (or even GM9) on the SD as the boot.firm. At least with FB there is no true “default” boot path. So if the autoboot is set to /nand/boot.firm, the placing a boot.firm on the (micro)SD doesn’t supersede

[LilithValentine]

the nand boot.firm. So my suggestion is technology safer with FB, granted the other person knows nothing about the 3DS scene. Of course with that in mind, it doesn’t matter what boot method you are using if the other user is completely unaware of what they are getting into. If they see a pin and are spooked by it, then it doesn’t matter what’s launching that pin. If they see a pin and aren’t spooked, then it again doesn’t matter how that pin got there.

[uumas]

I think this is on par with b9s. With this the Luma pin can be bypassed by holding home, on b9s it can be bypassed by changing boot.firm on sd. It would be great to have pin be directly integrated to fastboot, because that would make ntrboot the only way to bypass it.

[profi200]

You forgot hardmods. They can bypass it as well.

[LilithValentine]

Basically it doesn’t matter what protection you are using. If the theif isn’t scared by it and or knows how to remove it, a pin is redundant. If you have Luma3DS with a pin and the theif is scared, then it doesn’t matter what the entrypoint is.

[d0k3]

Seconding what Lilith said. The pin protection can also be in Luma when quietly chainloaded from fb3ds, won't make much of a difference. I'd assume there not that many professional 3ds thieves out there for it to matter.

Still thinking through the possibilities, though. Owner info would in fact be nice.

[LilithValentine]

I like the information idea though. Really gives a more personal touch to the system

[ghost]

Saving the info on the Nand wouldn’t hurt either :P :)

[profi200]

But it would complicate removing the pin if you forgot it.

[LilithValentine]

I would hope the same person smart enough to hack their system is smart enough to know how to use NTRBoot. No matter shake a stick at it, NTRBoot basically makes any “security” on the 3DS a joke.

[ghost]

Not everyone has a flashcart to use NTRBoot, and you'd usually need another 3DS to install NTRBoot so your 3DS would essentially be bricked in that case.

[LilithValentine]

You actually don’t need another 3DS to install NTRBoot, but that’s besides the point. My statement was more so to acknowledge anyone who can hack their system, should be aware of the methods to fix it if something were to go wrong. Although I honestly heavily suggest anyone in the 3DS hacking scene pick up a cart for the purposes of a dedicated NTRBoot cart. You never know where that will come in handy.

[NinjaBoyLao]

Honestly, personal info would be helpful to anyone with honest intent to return it if found, while also "guilt tripping" any would be thieves. I remember a successful "find & return" post I saw on the sub, iirc they found the owner due to bootscreen info or something from Luma. This was before b9s was a thing.

Also to speak to what JoshuaDoes suggested (as it seems to have gone mostly ignored) a button sequence followed by release and another button sequence could be implemented within fb3ds, and stored on the NAND, so that short of NTRBoot, even a knowledgeable thief would be stuck. (It could just be a simple PIN too ofc). I think the idea behind it is that only a person with a flashcart AND knowledge of the 3DS scene would be able to circumvent if the default firm was autobooted from /NAND/boot.firm. Buying a flashcart may require money the thief didn't have (thus the stealing in the first place). Apologies if this doesn't contribute to the discussion.

[profi200]

We are not throwing away the idea but we did not decide if this makes sense to implement and how to implement it yet. Having address and phone number as splash makes sense though and we are already working on custom splash support. I myself think it is not really securing anything. And we need to keep in mind not to "softbrick" peoples systems should they forget their pin. Only valid use case i see is keeping kids from messing with the system. But i don't think that's the right audience for fb in the first place. Parents just want to install shit and be done with it and not have a full blown bootloader.

[LilithValentine]

I would like to add that depth of protection pin security provides to the 3DS is all determined by whoever is in possession of the system or even if they turn it on. It doesn’t matter who’s proving the pin if the would be violator knows how to remove it, doesn’t care that it’s there, or simply sells the system without turning it on. At the same time if the person does see a pin and decides it’s something they can’t deal with, then returns the system. Once again it doesn’t matter if that pin is from Luma3DS+quiet or FB itself. Basically security measures like this always sound like a good idea, but you need to consider more factors and if it’s worth adding. You are no more nor less secure with a pin on Luma3DS + quiet, then you are with just a pin on FB. Edit: I suggest “quiet” as the other two have a bootsplash that will basically blow your security.

[Dimensional]

Reading up on all the suggestions, ideas, and pros/cons, I would like to input my own 2 cents. Making it write the data for the Pin to the nand and read from there, not from SD, would make it secure and prevent most every day thieves from getting in, as they won't go through the trouble to break the pin. In the cost/benefit of things, stealing a 3DS that is locked like this isn't worth the trouble.

But saving the data to the nand introduces another problem for the user. If they forget the pin, be it for not having it active or not using the system for a long time, then they lose access unless they can buy an NTRBoot card. So the cost for that is high for the user as well. Unless there is a recovery method.

I remember there was one Luma Based CFW made during A9LH that used a pin which was stored to the nand, and the only way to circumvent it was using a backup of your OTR. Since OTR was required to install CFWs back then, many people still had theirs backed up. However most people now days don't need it because of B9S able to run before anything else, and as such gives access to OTR.

Instead of just a standard pin, what if it was a combination with a PKI setup? The pin and a Public key file are stored on the nand, while a Private Key is made to be copied onto the PC and stored somewhere safe. The firmware first looks for the private key, and if it matches with the public, it unlocks the system without needing to enter the pin. If private key not found, then pin is asked for.

The biggest issue when making security features like PINs are how to make sure the baddies can't get in with a very simple fix, while making sure the owners aren't permanently locked out by their own stupidity. This again is one of the reasons better security for the 3DS isn't been a high priority for developers, because of limited support and the large chance user will get angry at the developers for something that was clearly the user's fault. Nobody wants to take the blame when something goes wrong that was clearly their fault, so they try to point fingers at everybody else who 'possibly' was involved, namely developers. Unless developers can create a centralized location to register 3DS systems with unique unlock codes for each one, similar to Nintendo's feature for unlocking the Built-In Pin, this feature isn't something developers would jump to make.

[profi200]

Meh, that would mean we have to make a RSA key pair generator with fancy GUI and all. Can't expect noobs to know how OpenSSL works.

[Moire9]

@Dimensional I remember that public-private key idea was used in some passthrough security program. Or, something similar at least. If you forgot your PIN, you could place a file that the program generated on setup on the root of the SD, which would allow you to bypass the PIN. I can't remember where I saw this tho. Perhaps not RSA based, but a backup system, like the system used to back up 2FA if you forget your pass.

[Moire9]

If this is implemented, we would have to make sure it is stored securely. As far as I can tell, FB3DS checks SD card for config before NAND, so that means that with the SD in, someone with a bit of google knowledge could edit the config file and remove the PIN from the SD config, and fb will load that. From there GM9 could be loaded to delete the NAND pin and boom, free 3DS. This is a loophole that could be easily closed, best solution would be to store the PIN in a seperate config file on NAND.

[Dimensional]

But that would create a big issue is the pin is forgotten on the nand, as it would effectively brick the console. And while the only way to fix a brick is through the B9S exploit, not many people would be willing to pay for a flash cart just do to that.

The issue solely about the pin, but a secure yet easy means of getting it reset or deleted in the event the owner forgets the pin. Only way I see how is through some online method like with any Password Recovery method. But that's very difficult because the network functions aren't easily accessible without the kernel apis, which means figuring out the asm code that can call the wireless card directly. Another option would be using a copy of the OTP record, as that's console unique, and having an online service that stores the bin file's data for said issue.

In fact, best way would be to create an online account system, the user has to log in, and either if the OTP is used it can only be downloaded by said user, or the system creates a different kind of one-time-pad so that if you lose your pin, it creates a recovery code that is console unique, and changes through the use of HOTP, where the user registered the hotp key online to your account. The user enters the response to the recovery challenge, and if it's correct allows the user to change the pin without knowing it.

On 4/27/2018 5:25 PM, SirNapkin1334 wrote:

If this is implemented, we would have to make sure it is stored securely. As far as I can tell, FB3DS checks SD card for config before NAND, so that means that with the SD in, someone with a bit of google knowledge could edit the config file and remove the PIN from the SD config, and fb will load that. From there GM9 could be loaded to delete the NAND pin and boom, free 3DS. This is a loophole that could be easily closed, best solution would be to store the PIN in a seperate config file on NAND.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/derrekr/fastboot3DS/issues/2#issuecomment-385109550, or mute the thread https://github.com/notifications/unsubscribe-auth/AEy14WCFdPuceakE8T8Xj4hhu_sVfHflks5ts5rjgaJpZM4RMBP6.

---

This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

[Moire9]

@Dimensional ntrboot....

I said that because that would protect against somebody doing 10 minutes googling. If you forgot your password, ntrboot would be the only option.

[MrTSXV]

It is not only a protection for thieves but also for children, a simple pin protection feature like luma offers that advantage, but maybe someday luma will be replaced by a another cfw missing that feature.

[LilithValentine]

@MrTSXV If your end goal is protecting against the unaware, then silent mode + Luma pin would accomplish the same results. It doesn't matter who provides the pin if the person isn't aware of how to remove it. I am not really for nor against adding a pin, but I also haven't seen a reason that doesn't have an alternative.

[uumas]

With Luma pin they can figure out how to remove it with 10 minutes of googling. Fastboot pin would require ntrboot to get rid of which makes it a lot more difficult than just deleting a single file on the sd.

[LilithValentine]

If they are smart enough to know what Luma3DS is and or actually google to remove the pin, then it doesn't matter who provides the pin. If it's only a scare tactic and fails to scare them, then the pin is redundant.

[uumas]

They can google "Enter the pin using ABXY and the DPad to proceed" to find out that it's Luma3ds and by googling "Luma3ds pin they'd find the Luma wiki page that also basically has a guide for thieves to remove it.

[d0k3]

It's actually still not decided wether something like this will be implemented or not, so I'm just giving you my 5 cents here.

First, forget about protection against "professional" thieves. We could use the pin to encrypt some crucial area of your NAND, providing maximum safety (works as long as no one comes around with a ntrboot card and Lazarus 3DS). But, you know, you guys won't be happy with this. I doubt that even one theft would be averted by this, and on the other hand we will have tons of bricks (or, at least, data loss), making you guys very unhappy.

Besides, do you think a thief would just return your console, noticing it's useless to them, or would said thief rather trash it?

Now, siblings and the like, for those, short-term protection is enough. Some minimum security will most likely drive them away. No need to put any thought into making it "safe" in that case. Luma's PIN protection is more than enough in that case.

Besides thiefs and siblings, there's a third kind of person that could get their hands on your console - the (hopefully honest) finder, and with those, you can actually increase the chance of you getting back your console a lot, simply by providing owner info at each boot. Personally, I think that's what makes sense the most.

Now, if you're running fb3ds, the owner info doesn't even need to be part of fb3ds. "ARM9 Owner Info" could simple be your autoboot homebrew payload. In other words, if no button combo is held at cold boot, your owner info would be displayed, and nothing else (all one could do is power off then).

[profi200]

You could argue, that the Luma pin doesn't work as good here, because you can still enter the fb menu and totally bypass it. You can do enough shit with that alone. In that case a force boot option would be needed blocking the menu.

[LilithValentine]

@profi200 Which is why I suggest silent mode. If the idea is simply to prevent someone who doesn't know how to remove the pin and doesn't know how to even start searching for this information, then it doesn't matter who provides the pin. The pin is simply a scare tactic and nothing more. But if someone sees the pin and is like, "I can google this shit," then the pin is completely redundant because the information to removing the pin is accessible to anyone willing to do the research. Although googling it myself showed that searching "remove pin from 3DS" actually doesn't bring up any information to removing Luma3DS pin from a 3DS. Basically it just seems like Luma3DS already provides the feature they are looking for. So long as the person doesn't know what they are doing, the user's pin is going to be solid. If the person knows that they are doing, then no amount of additional security is going to help them.

[uumas]

I think the turn away point for many would be when they'd need to order a flashcard from some "shady" site

[profi200]

@CrystaltheGlaceon If you refer to quiet mode then that will not block the menu.

[catfatwm]

i think most are missing the best aspect of the pin, its great if a toddler gets ahold of your console. i dont exactly want my 5 year accessing my scripts or anything and borking everything.

[Multimegamander]

eep

[d0k3]

Okay, after 1+ years of this issue being open, we decide to turn down the feature request and finally close it.

Reasoning: Well, you see the discussion above. Any safe solution (encrypting stuff, etc) is more likely to cause data loss (due to fogotten PINs) than it is to prevent even one theft (or loss of the 3DS console). If all you want to do is prevent a toddler or a sibbling from messing around with your console / GM9 / scripts, then an unsafe solution is enough. We already got an unsafe solution in Luma 3DS.

The idea of an owner info came up in the discussion above, and this is one thing that (imho) really makes sense. It will allow an honest finder to properly return your 3DS console. Even with that, we decide against including that in fastboot3DS.

However, I've got a little goody for you guys: ownerinfo.zip Just edit owner.txt to your liking and copy it to your 3DS SD card root. Use ownerinfo.firm as main payload in fastboot3DS, and boot your actual main payload (CFW in most cases) only via a "secret" keycombo. The result is, on any cold boot, your console will display your owner info unless your secret keycombo is held.

(ownerinfo.firm is a GM9 script runner, the script it is based on is included in the archive. If you think this should be more beautiful - write your own tool :^).)