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.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'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
This does that too. Instead of loading arm9loaderhax.bin it loads 3dsafe/emergency.bin.
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?
Last edited by A_Bricked_Guy,
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 ---------------------------
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.
@A_Bricked_Guy
So it's asking for your current PIN, but when you enter it it doesn't accept it? Is that right?
So it's asking for your current PIN, but when you enter it it doesn't accept it? Is that right?
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.
Last edited by A_Bricked_Guy,
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.
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.
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.
@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.
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.
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.
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.
Could a 3dsafe user of a USA New 3DS XL running on sysnand 11.1 please PM me? I need an sha dump from 3dsafe for testing purposes. Thanks in advance.
Similar threads
- No one is chatting at the moment.
