No, it doesn't sadlyIf you press start, I'm pretty sure it will accept your pin. Maybe it's doing an all new setup...
No, it doesn't sadlyIf you press start, I'm pretty sure it will accept your pin. Maybe it's doing an all new setup...
Yes of course. You just put the Luma payload on the SD card as normal.Quick Question:
Is it possible to install a full CFW (such as luma) to use with this? Or would that cause a brick?
I'm confused. First it showed nothing when you boot (I assume a black screen), then it's asking for a PIN, which means you need to enter a PIN. This has nothing to do with the OTP or SHA. You just need to enter a PIN and press START. Or if you already had 3DSafe installed, just enter the current PIN.Hi, I've been using this for a while (since 0.8 to be exact) and I think updating from 0.8 to 0.11 bugged it and probably bricked it (hopefully not, I can't afford a hardmod ). I used 3DSafe updating guide and everything went fine until I restarted after installing the payloads, then it didn't even show a setup or something like that to get my sha.bin, it booted as if nothing happened. Now it's asking for a 10 characters pin (max characters on 0.8 was 8) with no way to proceed. I have my otp, that "sha.bin" file can be generated after my otp file right..? How would I go to manually get my sha.bin using my otp to give that a shot? I hope I didn't brick in such a stupid way like this...
Hahahaha I'mYes of course. You just put the Luma payload on the SD card as normal.
I'm confused. First it showed nothing when you boot (I assume a black screen), then it's asking for a PIN, which means you need to enter a PIN. This has nothing to do with the OTP or SHA. You just need to enter a PIN and press START. Or if you already had 3DSafe installed, just enter the current PIN.
This does that too. Instead of loading arm9loaderhax.bin it loads 3dsafe/emergency.bin.Hahahaha I'm
Glad I got it to install on my
New console after it bricked on my last, best a9lh thing I've ever seen I won't even update the the new a9lh CTRNAND SD-lesss because of this, thanks Mashers
It booted normally after the update, asking for a Pin. Thing is, it's asking for a 10 buttons length Pin, after a put my old 8 buttons Pin pressing start will show that forgot password screen. I think I just need to get that sha.bin (which the program didn't give to me) from my otp file to fix my problem, would you mind helping me out?Yes of course. You just put the Luma payload on the SD card as normal.
I'm confused. First it showed nothing when you boot (I assume a black screen), then it's asking for a PIN, which means you need to enter a PIN. This has nothing to do with the OTP or SHA. You just need to enter a PIN and press START. Or if you already had 3DSafe installed, just enter the current PIN.
It booted normally after the update, asking for a Pin. Thing is, it's asking for a 10 buttons length Pin, after a put my old 8 buttons Pin pressing start will show that forgot password screen. I think I just need to get that sha.bin (which the program didn't give to me) from my otp file to fix my problem, would you mind helping me out?
Does it say 'Please enter your 3DSafe PIN..." or "Please enter a new 3DSafe PIN..." ?It booted normally after the update, asking for a Pin. Thing is, it's asking for a 10 buttons length Pin, after a put my old 8 buttons Pin pressing start will show that forgot password screen. I think I just need to get that sha.bin (which the program didn't give to me) from my otp file to fix my problem, would you mind helping me out?
Yeah I think the hashing algorithm is either different or the data are stored in a different format as I had the same problem. You can't just hash the file using shasum and get the same result.In theory sha.bin is just the SHA-256 hash of the otp.bin, but I hashed my otp.bin and got a different result to sha.bin.
Does it say 'Please enter your 3DSafe PIN..." or "Please enter a new 3DSafe PIN..." ?
--------------------- MERGED ---------------------------
"Your 3DSafe pin" Everyone else I believe, updated from 0.10 which already had a 10 button length, but I don't know why updating from 0.8 didn't let me setup my sha.bin the first time, now I'm stuck in the lockscreen :/ I'd recommend including a step in the updating guide to erase the password before flashing the payloads to prevent issues like this.
So... I should still be able to recover my console using my otp file's sha256, right...? It's a New 3DS XL if that matters.
It's asking for a 10 buttons pin, but my old password was only 8 buttons long (max length on 0.8). So, after I put my pin, there are still 2 buttons to press to complete it, therefore, when I do it displays the "incorrect PIN" screen and asks for an otp (guess this text will be updated on 1.0). Also I tried putting a sha.bin file on SD returning the error "SHA bypass failed. Press any key to enter PIN." Sorry if i'm not clear enough, not an english native speaker.@A_Bricked_Guy
So it's asking for your current PIN, but when you enter it it doesn't accept it? Is that right?
Yeah I think the hashing algorithm is either different or the data are stored in a different format as I had the same problem. You can't just hash the file using shasum and get the same result.
It should continue past the PIN lock after entering your current PIN, even if the previous PIN wasn't 10 characters long. Once it gets a PIN which matches, it continues. You don't need to 'fill up' the 10 character buffer. If it doesn't continue past this point, that means you're entering the wrong PIN. Also, you can't just put any sha.bin file on there - it has to match the console.It's asking for a 10 buttons pin, but my old password was only 8 buttons long (max length on 0.8). So, after I put my pin, there are still 2 buttons to press to complete it, therefore, when I do it displays the "incorrect PIN" screen and asks for an otp (guess this text will be updated on 1.0). Also I tried putting a sha.bin file on SD returning the error "SHA bypass failed. Press any key to enter PIN." Sorry if i'm not clear enough, not an english native speaker.
That's really helpful actually, thanks. I'm just coming up with a way of converting an otp.bin to the correct hashed format using my own OTP.All the resources I can find say that only the first 0x90 bytes of the OTP are hashed to produce sha.bin.
But even when I truncate the file to that length, I don't get the correct hash.
Maybe it's just better to ask the 3DS to do it? Or maybe use one of those old Python tools for compiling A9LH back before Safea9lhInstaller did it.
@A_Bricked_Guy
Please can you send me your otp.bin? Once I've got a working method I'll send you your sha.bin to try to bypass the PIN lock.
Great, thanks. I'm just working with my own otp.bin at the moment to try to correctly convert it to the sha.bin file as the formats differ. Once I've got a working method I'll do the same with your otp.bin, send you back the sha.bin, and hopefully that will bypass the PIN lock.Sure! PM'd you
I found the problem with the OTP hash with the help of the guys on #cakey. It turns out it's because I was re-accessing the otp sha register each time I wanted to use it. I didn't realise it gets overwritten, so what gets dumped to sha.bin (and checked against) is not actually the otp sha256, it's something else that overwrites that area of memory.btw, did you try getting the hash of the 90 first bytes and use it in little endian ? (as in, start from right to left, basicly, take a normal sha256, and read it from right to left (byte after byte), that's the little endian representation of the sha hash)
I found the problem with the OTP hash with the help of the guys on #cakey. It turns out it's because I was re-accessing the otp sha register each time I wanted to use it. I didn't realise it gets overwritten, so what gets dumped to sha.bin (and checked against) is not actually the otp sha256, it's something else that overwrites that area of memory.
I've now changed 3dsafe so that the first thing it does in the main function of the stage 2 payload is to copy the hash into a global variable; this global variable is then used for all subsequent access to the otp hash. Doing this I was able to dump an otp hash which matches what I get when I manually hash my otp.bin.
Yeah I am too. Fortunately the hash used for A9LH was valid (though I would have discovered in testing if it wasn't). The only thing this affects is the bypass, and of course if a 3dsafe dumped sha.bin were to be used for something else. I'm working on an update now.I'm glad this was discovered! Using bad data and assuming it is the otp hash would be quite dangerous when it comes to a task like installing an a9lh key sector.
Looking forward to seeing a release of 3dsafe with this fix.