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

[Sonansune]

well, you do know that the this pin lock payload doesn't encrypt the nand, right ?

with decrypted nand, you can extract the pin data stored in the nand, in case if you forgot the pin....
otherwise, you have to hardmod and restore an old backup nand.
well..... only if OP successfully implement the nand r/w

 

[duffmmann]

This is very cool, but ultimately I can't say I have a need for it. I'm not too concerned about my 3DS being stolen, and even if it were I doubt I'd find it again simply because the person who stole couldn't get access into the actual system. PIN or not, I'm likely not seeing my stolen system again. Still, good job, I'm sure there are people that would want something like this.

 

[Sonansune]

This is very cool, but ultimately I can't say I have a need for it. I'm not too concerned about my 3DS being stolen, and even if it were I doubt I'd find it again simply because the person who stole couldn't get access into the actual system. PIN or not, I'm likely not seeing my stolen system again. Still, good job, I'm sure there are people that would want something like this.

I WONT LET YOU HAVE WHAT I LOST

 

[astronautlevel]

locks should not exist on houses because you may forget your key somewhere, and then a locksmith will ransom your home in exchange for money .....come on guys we dont need this buzzfeed BS on here

That's not what we're saying, we're saying that if a proper PIN implementation was made, anyone could take the code, toss a message saying "If you want the pin, pay X money to this bitcoin address," stick it in a fake a9lh update, and send it to someone.

 

[gamesquest1]

something very satisfying in knowing a scummy theif doesn't get to enjoy the stuff he stole

That's not what we're saying, we're saying that if a proper PIN implementation was made, anyone could take the code, toss a message saying "If you want the pin, pay X money to this bitcoin address," stick it in a fake a9lh update, and send it to someone.

the only place you should be running a9lh updates from is reliable/trusted sources, and a normal .3ds/.3dsx files wouldn't have the correct permissions to overwrite a9lh

 

[Billy Acuña]

Noticed that this doesn't boot without SD :/

 

[duffmmann]

I WONT LET YOU HAVE WHAT I LOST

I guess that is ultimately what it comes down to. As much solace as that situation might bring me, it wouldn't change the fact that I'd still be bummed the hell out that I no longer had my N3DSXL.

Frankly, what I'd really love is some sort of homebrew that auto loads with A9LH when you boot up, so that when the 3DS is connected to wifi, it reveals it's approximately location on a computer program of sort. I don't think you need built in GPS to get an approximate location with wifi (though I may be wrong) so I'd think that such an application might be possible. Now granted if someone stole my 3DS it's possible they may rarely if ever use the Internet, but at least such an application would give me a fighting chance of tracking down my theoretically stolen 3DS.

 

[Billy Acuña]

2.- Dunno if you made screendeinit after the pin or just set brightness to 0, you should deinit the screen after the pin thing since most of the payloads has his own screeninit code.

Nevermind, looks like just BootCtr9 losses compatibility with this...

 

[MistWisp]

So if this is a shadowNAND fork it does have the FIRM write protection still right?
Also, https://postimg.org/gallery/14kth52vi/a6624b12/

 

[Billy Acuña]

So if this is a shadowNAND fork it does have the FIRM write protection still right?
Also, https://postimg.org/gallery/14kth52vi/a6624b12/

It doesn't boot without SD, I think @mashers will reimplement it when it gets pin.txt into nand support.

 

[osm70]

I completely agree with you 100%. A passcode or protection is completely useless at protecting data and property if it can be bypassed.


As @mashers suggested, you could fork the code and add your own secret backdoor combo in that people wouldn't be able to find online.


Luma3DS has a PIN option now that restricts booting the 3DS or using payloads that can be removed from the SD card if needed.


I think you're mixing two things together. The passcode is what encrypts the iPhone, not Find my iPhone Activation Lock. With a passcode data is encrypted so it cannot be directly read, however you can still factory restore the iPhone and load a backup and set a new passcode. Find my iPhone Activation Lock is a server side account feature that prevents you from setting an iPhone up without first disabling it, which can be done by providing the account details on the phone, via the iCloud Website or by submitting a proof of purchase to Apple and having them remove it.


While most ransomware infects your device through a malicious file, it's unlikely that this would occur on a 3DS. Yes, you could fork this repo, put in PIN generation code based on something unique like the serial number and then release it to the scene disguised as something else. But there's already tons of home-brew out that can be misused like this. A modified FBI can delete all your titles or tickets or saves. Modified JKSM could backup all your saves to a password protected ZIP and then ransom them off. Modified Decrypt9 could uninstall A9LH or flat out brick your console. This is not the first and will not be the last home-brew that could be cloned, modified and released maliciously. I don't think this possibility should stop anyone from developing home-brew.

I took the iOS apart at took a look at how it works. I can't say i really understand it, but I am sure that iOS is installed encrypted and gets decrypted upon activation. And Apple won't remove it even if you give them a proof of purchase. I know someone who lost access to his account. He had proof of purchase, but Apple told him that they don't do that.

 

[astronautlevel]

the only place you should be running a9lh updates from is reliable/trusted sources, and a normal .3ds/.3dsx files wouldn't have the correct permissions to overwrite a9lh

I agree, that doesn't mean everyone will do it, though.

 

[MistWisp]

Added a cool PIN input & error interface and SELECT button to clear the last input in my fork, sent a pull request :3

 

[Ryccardo]

Well, obviously, but this is one of the few things that can be used for actual ransomware, which gives people an actual reason for implementing it (money). It's not like the other examples which could simply brick a console, there's no reward for someone malicious there.

Inb4 Brickway rebrands this too

 

[mashers]

It doesn't boot without SD, I think @mashers will reimplement it when it gets pin.txt into nand support.

This is possible, but I can't work out how ShadowNAND boots without SD. It seems to just boot a payload from SD and error if there isn't one present. I'll consider it though.

Added a cool PIN input & error interface and SELECT button to clear the last input in my fork, sent a pull request :3

I'm working on integrating bits of GodMode9 for NAND reading/writing, and at the moment my local copy won't build. Once I've got that sorted I'll take a look at your pull request.

 

[SomeGamer]

I'm not. I'm simply sharing a project I decided to work on for myself. If some other people find it useful then fine. But if others don't, I don't care.

Don't get me wrong, I do care about your app, I was waiting for one like this since I found out about ShadowNAND. And I see you're still deciding on how to do the NAND stuff, I'm sure you'll come up with something better! (Did I see parts of GM9 being implemented?) Sorry if it came off rude, it wasn't my intention.

 

[DocKlokMan]

I took the iOS apart at took a look at how it works. I can't say i really understand it, but I am sure that iOS is installed encrypted and gets decrypted upon activation. And Apple won't remove it even if you give them a proof of purchase. I know someone who lost access to his account. He had proof of purchase, but Apple told him that they don't do that.

iOS is not installed encrypted, but it does need outside authentication before unlocking the bootrom to apply an iOS update or restore. As for removing Activation Lock, they certainly do accept proof of purchase as a means to remove a device from an account. I know, I do it about twice a day and sometimes more. Point is, iPhone's are not bricked, you just may not have enough valid information for them to do anything about it. This home-brew though, even more secure then Apple. With great security also comes great responsibility. @mashers could make it worse by putting a timer between each incorrect guess (don't do this @mashers, should someone pull the battery and reset their date/time they'd really be screwed).

 

[osm70]

iOS is not installed encrypted, but it does need outside authentication before unlocking the bootrom to apply an iOS update or restore. As for removing Activation Lock, they certainly do accept proof of purchase as a means to remove a device from an account. I know, I do it about twice a day and sometimes more. Point is, iPhone's are not bricked, you just may not have enough valid information for them to do anything about it. This home-brew though, even more secure then Apple. With great security also comes great responsibility. @mashers could make it worse by putting a timer between each incorrect guess (don't do this @mashers, should someone pull the battery and reset their date/time they'd really be screwed).

Well, I might be completely wrong, but the Setup.app application (internally known as Purple Buddy) decrypts something in the /System folder.

 

[Hayleia]

Not sure if it was discussed before, but @cearp's post gave me an idea (no, it isn't about a backdoor).
What about giving this utility two modes, a locked mode and an unlocked mode?

Basically, the locked mode asks you for the pin to boot, then it goes into unlocked mode. In unlocked mode, you can turn your 3DS on and off without any pin input (useful if you were doing a lot of stuff with H9, D9, whatever and don't want to be bothered with your pin, or if you are at home and know you are safe). And using a key combo (that doesn't need to be secret) at boot, you can choose to put it back to locked mode.

For example, (and that's where @cearp's post comes in), the 3DS knows it's "unlocked" when a certain file is present on the SD, and to go back to locked mode, the utility just has to delete this file (and if the SD isn't present, the 3DS is automatically in locked mode).
But this is not a backdoor because this file here would have to contain a hash of the password or something, this way, an external user can't easily just put a file on the SD to unlock the console.

And btw, this also solves the "what if I forget my password" problems, one would just have to go in unlocked mode (at a time you remember your pin) and save your "unlocked" file on your PC. A stealer doesn't have that file so you're still safe.

 

[caitsith2]

I don't know if it's possible to verify that the OTP matches the specific console it's from. And let's face it, anybody who's using this should already have a safe copy of their 3DS NAND and OTP. So why not just store the PIN in a text file in the same place?

Even though you can't read the OTP from the area, there is still a way to verify that the OTP file belongs to THAT console. Remember that the OTP was used to generate that consoles encrypted secret sector. What you do, is read out the secret sector, attempt to decrypt that secret sector using that OTP, and verify the decrypted key 0 within secret sector matches the value it is expected to have.