Hacking 3DS unbricking progress

[ryuga93]

or by using the diagnostic mode of gateway several times on 2.0b2. You can brick your device insanely fast that way

7.x　is not likely able to run gateway...

 

[Deleted User]

Whoops, sorry. I didn't read that :x

 

[obcd]

Congratulation bkifft and the anonymous revealer of the passkey calculation algorith.

So, my question, did they use the same password to temporary write protect the eMMC as well?

A remark: Be very carefull while experimenting with the write protect command. If you set the permanently write protect, there is no way to reverse this. You'll end up with a 3ds brick.

Another question. There is a way to disable the eMMC option to password protect it's access. (To avoid accidentally locking it like that) Would enabling such give protection against the gateway brick, or would the write protect setting still cause troubles? (Not sure if that gets disabled as well. Not even sure if it can be didsabled the same way.)

 

[greyneon]

Can't use gateway. It's having realnand 7.x

So is a force brick doable? ;-) i have no issues with disabling it. Money is not an issue here

 

[gamesquest1]

Can't use gateway. It's having realnand 7.x

So is a force brick doable? ;-) i have no issues with disabling it. Money is not an issue here

yes you can force brick with the software just press L on the menu, .......just make sure you backup your nand first......just in-case something goes wrong

 

[bkifft]

Congratulation bkifft and the anonymous revealer of the passkey calculation algorith.

So, my question, did they use the same password to temporary write protect the eMMC as well?

A remark: Be very carefull while experimenting with the write protect command. If you set the permanently write protect, there is no way to reverse this. You'll end up with a 3ds brick.

Another question. There is a way to disable the eMMC option to password protect it's access. (To avoid accidentally locking it like that) Would enabling such give protection against the gateway brick, or would the write protect setting still cause troubles? (Not sure if that gets disabled as well. Not even sure if it can be didsabled the same way.)

MMC/SD write protection isn't password based, it's just setting a single bit in the CSD for the global ones (perm and temp alike, done via flipping said bits in the CSD and writing it back completely (CMD27 PROGRAM_CSD)) or specific segments (kinda like sectors of HDs) by using CMD28 SEND_WRITE_PROT.

I just am not able to get CMD27 on the Pi to work yet.

And yeah: the CSD bits TEMP_WRITE_PROTECT and PERM_WRITE_PROTECT sit side by side (bits 12 and 13 (counting from the right starting at 0)), which is scary close, but luckily makes it impossible to set the wrong one on accident resulting from bit order shenanigans.

And I'm still hesitant at touching the one time programmable lock and writeprotect disable bits.

Can't use gateway. It's having realnand 7.x

So is a force brick doable? ;-) i have no issues with disabling it. Money is not an issue here

Sadly locking and subsequent unlocking via the tools would only prove that the connection and communication is working, not that the unlock of a launcher.dat brick works. While krisztian1997 and I got the locking/unlocking working quite some time ago, I still had to tinker with the unlock password generation, byte order stuff (in the end i bruteforced all possible bit/byte/wordorder combinations of the CID and the keystream). So we'd need a tester with a genuine launcher.dat locked 3DS to be sure it works.

But hey, if money ain't an issue: there are still <4.5 devices in the wild.
Joking aside, don't you want one which can run unsigned code?

edit: I like how the board software eats sentences when you mistype @ user tags -.-

 

[Moquedami]

This brick code is not even written correctly (else this unbricker wouldn't work). So they even failed at programming brick code.

This part got me wondering: so the original intention of the code was to render the 3ds unrecoverable? That`s harsh beyond reason

 

[obcd]

Thanks for explaining bkifft. I should have looked it up in the specs instead of being lazy...

 

[krisztian1997]

This part got me wondering: so the original intention of the code was to render the 3ds unrecoverable? That`s harsh beyond reason

Don't think so, it was part of the anti-update function but when they failed to make it work, they just reused it for something else (remember how they said that they bricked some of their consoles but unbricked them)

 

[Foxi4]

I think it's very unlikely that the Gateway team intended all this to go public - that's like shooting yourself in the foot. They probably (wrongly) assumed that when cloners copy-paste their code without looking through it thoroughly (which is practically what they did) and notice that their systems are bricking during tests, they won't release the firmware at all. Of course that didn't happen since that's just giving too much credit to clone cart manufacturers, hence we have the current debacle. That, and the code was clearly flawed since Gateway didn't take into account that on occasion functions fail for reasons other than cloning. Worst-case scenario, they wanted the 3DS'es of clone users to brick and put the blame on cloners, which is a more malicious but equally likely scenario.

 

[bkifft]

This part got me wondering: so the original intention of the code was to render the 3ds unrecoverable? That`s harsh beyond reason

I also don't believe their intent was to kill consoles, only cripple them.
But they seem to have failed at only triggering said code on non legit launcher.dat versions (which in itself is more than questionable) and using the 3DSes AES engine to generate the password in a mode that makes using the AES engine useless, sniffing out the lock communication when the brick code gets triggered and tinkering around with the result would have lead to the unlock keystream anyways.
They could as well have used an AES mode which really does encrypt the message (in this case the CID) using AES. Thanks to the 3DS keyscrambling that would have meant that one really would have had to generate the unlock password for a brick on a working 3DS which would have been a PITA (force erase would have worked none the less).

Thanks for explaining bkifft. I should have looked it up in the specs instead of being lazy...

No problem. In case I would have had to look it up my reply would have been RTFM though.

 

[Coto]

Many thanks to the random guy who posted the SD CID xor custom key response from AES to allow card access. I may think of certain someone, but..

While I'm not that extremist on the "piracy" subject, some random device enabling piracy has no rights whatsoever to render your. YOUR device unusable.

and thanks to bkifft, ryuga93 and krisztian1997 for the effort involved

 

[Deleted User]

So does this mean users with 7.x on real nand can flash someone elses nand using raspberry pi?

 

[R4iFanboi]

So does this mean users with 7.x on real nand can flash someone elses nand using raspberry pi?

You wish!

The NAND itself is encrypted and we don't know the keys.

 

[gamesquest1]

posted a quick video tutorial up here
http://gbatemp.net/threads/video-gu...isting-nand-dump-using-the-new-method.362609/
it not great camera work, and it not pretty, but should be good for people to understand the whole process before starting

 

[Bug_Checker_]

Spoiler

MMC/SD write protection isn't password based, it's just setting a single bit in the CSD for the global ones (perm and temp alike, done via flipping said bits in the CSD and writing it back completely (CMD27 PROGRAM_CSD)) or specific segments (kinda like sectors of HDs) by using CMD28 SEND_WRITE_PROT.

I just am not able to get CMD27 on the Pi to work yet.

Spoiler

And yeah: the CSD bits TEMP_WRITE_PROTECT and PERM_WRITE_PROTECT sit side by side (bits 12 and 13 (counting from the right starting at 0)), which is scary close, but luckily makes it impossible to set the wrong one on accident resulting from bit order shenanigans.

And I'm still hesitant at touching the one time programmable lock and writeprotect disable bits.



Sadly locking and subsequent unlocking via the tools would only prove that the connection and communication is working, not that the unlock of a launcher.dat brick works. While krisztian1997 and I got the locking/unlocking working quite some time ago, I still had to tinker with the unlock password generation, byte order stuff (in the end i bruteforced all possible bit/byte/wordorder combinations of the CID and the keystream). So we'd need a tester with a genuine launcher.dat locked 3DS to be sure it works.

But hey, if money ain't an issue: there are still <4.5 devices in the wild.
Joking aside, don't you want one which can run unsigned code?

edit: I like how the board software eats sentences when you mistype @ user tags -.-

Have you tried reading the whole register of CSD? Changing what is needed changing and then writing the whole register of CSD back @ one time(not just individual bits)?

http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&p=1131182

Anyway bravo on the progress so far.

 

[Mr_Pichu]

Update: RPU can now unlock the eMMC...

... p.s. I'll use this opportunity to once again draw attention to step 18 of the guide *nudge nudge wink wink know what i mean*

It was rumored that password likely had something to do with zeros. It is great that the password algorithm has been finally cracked, now all those held hostage can eventually be freed.

Thanks again goes out to the tireless efforts of the gbatemp community.

 

[krisztian1997]

It was rumored that password likely had something to do with zeros. It is great that the password algorithm has been finally cracked, now all those held hostage can eventually be freed.

Thanks again goes out to the tireless efforts of the gbatemp community.

I said that stupid thing with the password being zero, because someone posted a part of the bricking code but it was incomplete, later I got the entire code and there it was completely different.

 

[bkifft]

Have you tried reading the whole register of CSD? Changing what is needed changing and then writing the whole register of CSD back @ one time(not just individual bits)?

http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&p=1131182

Anyway bravo on the progress so far.

Thanks for the input, but that's exactly what I've been trying to do. CMD27 (PROGRAM_CSD) should work exactly like a single sector data write (or as a matter of fact the lock/unlock CMD42), taking the full new CSD as the data payload. But neither flipping the write protect bit nor changing the CSD checksum seem to stick.
I believe I've got some byte/wordorder foul ups in there and decided to take a few days break time from this project to get a clear head and fresh start again.

I said that stupid thing with the password being zero, because someone posted a part of the bricking code but it was incomplete, later I got the entire code and there it was completely different.

Don't chastise yourself over this, others believed that, too.

 

[philroy]

can anybody help me out with a good diagram of where to put my wires on my sd card and to the 3dsxl mobo to unbrick my 3ds any suggestion welcome got everything running on my pi thanks to bkifft video so just need the soldering points