3DS Unbricking Possible!

  • Thread starter Thread starter YoshiInAVoid
  • Start date Start date
  • Views Views 46,820
  • Replies Replies 78
  • Likes Likes 24
Status
Not open for further replies.
Currently I'm working on getting an as small as possible raspian image done (780 MB atm) as my upstream speed sucks balls and i don't want to wait 20h for the upload to finish.

Tomorrow or wednesday I should receive my MMC card to "refine (a blatant euphemism for throw out of the window and rewrite) my code.

I've already taken wednesday to friday off (gotta burn some of my overhours anyway and this project is a good reason to finally do it.)

So there should be a not-yet-public beta version available soon and the public release soon+a bit longer (see what i did there, GW?).

Edit: if you'd be willing to participate in said closed beta I'll gladly send you the links.
Yes, please! PM me a beta as soon as it's ready :)
 
GREAT WORKS! we wait a good proof (with photo or video) about this unbrick!!!!
see ya Brickway... gbatemp defeat the enemys!!!!
 
could the same MOD be installed onto the 3DS, or is there not enough room in the guts. great work by the way..........................sudeki300

There is no good place for the micro USB, I would have to cut a hole in the plastic.

damn! i just need to comment on how nice that looks

Thank you!
 
si ont as pas de dump il reste l'emunand reccuperable avec emunand tool,j'ai fait comme sa pour une 3ds sans dump orig ,pour les sd non compatible dump sd avec testdisk-6.14.win pour avoir acces a la partition cachée,ouvrir hxd et changer 3DSCARDNAND en R4IGOLDNAND et le programme fonctionne et réccupere l'émununand
Could you... talk in english ?
 
ple666:
you can use EmuNAND_tool only if you kept a copy of your 4.x emuNAND.
Most users used emuNAND to update to 7.x, I don't know if everyone keep a backup from each NAND version.
 
ple666:
you can use EmuNAND_tool only if you kept a copy of your 4.x emuNAND.
Most users used emuNAND to update to 7.x, I don't know if everyone keep a backup from each NAND version.
I have done backup for my 4.3 sysNAND and the 7.1 emuNAND.I think it is better to keep every version of the emuNAND you use.Who knows what will happen in the future
 
Great news! It also looks like these are the same pins used for dumping your nand (except dat3, which you do not need for that function). Someone should make a commercial product for the 3ds XL that allows for easy dump/restore, unbricking, and extends the battery.

Or maybe someone should make a commercial product that stops people from being total pirate scum.
 
The MSP430 by TI might also be a good microcontroller for this. It is $10, has SPI, runs on 3.3v out of box and is compatible with Arduino code via Energia IDE.
 
I was reading the instruction. so it's possible to unbrick without soldering and such by using raspberry pi? incredible.
 
I was reading the instruction. so it's possible to unbrick without soldering and such by using raspberry pi? incredible.
no you have to solder regardless of which method you use
 
There's a solderless solution for 3DSXL only, but you need to solder the pogo pins and RasPi together. Only the console's side is solderless.
For normal 3DS, you need to solder at least 1 very tiny point (the CLK) which is located at the back of the mother board.
 
Update: RPU can now unlock the eMMC.

The usual header: this will neither enable a downgrade nor running pirated porkemon [sic] on >4.5.

An anonymous source gave me the key required to generate the console specific eMMC lock/unlock password in exchange for posting his/her following statement in my initial release posts and the tool itself:

If you are reading this your 3DS has most likely been bricked by a Virus called Gateway 3DS. If so return it and get a refund immediately.
Because what they have done is they made a soft-mod for the 3DS but then decided that they would earn more money if they added their own AP.
They also added a lot of obfuscation (to prevent pirates from pirating their card and software), which most likely also is the reason why some versions are not stable (and the brick code is triggered). And as you already see on your 3DS they added brick code in the 2.0_2b Version. This brick code is not even written correctly (else this unbricker wouldn't work). So they even failed at programming brick code.
To sum it all up you bought a badly programmed Virus.

Buy your games, don't pirate them. You see what happens when you pirate. I hope you learned from your mistake.

The good news: this makes it possible to unbrick even if you don't have a prior NAND backup.

The bad news: for now it has to be done in a quite roundabout way: unlock the eMMC/NAND -> dump it -> relock the eMMC/NAND -> force erase -> flash the NAND image -> unbricked.

The reason for this detour is that besides being locked, the eMMC also gets write protected (just like some people had already stated) and I wasn't able to remove said write protection yet (in this context: if anyone got any idea how on earth i could get the Pi to do CMD27 like it's supposed to work please let me know).

But said write protection gets wiped by a force erase too, thus offering a working solution for now (although I'd have preferred a single keypress unlock and will keep working on that).

I just pushed the changes to github, either do the online or offline update as described in the guide to get the new version.

As i believe not everyone to be interested in the technical details I'll put them in a spoiler:
The lock/unlock password is generated by encrypting the console specific CID (the unique serialnumber of the eMMC) with GW's master AES key (which I don't and don't want to have) using the 3DS AES engine in CTR mode. I had to look that one up as I only ever use CBC and XTS: CTR uses the block cipher to generate a keystream to be xored to the plaintext with no cleartext or cyphertext feedback whatsoever. In other words: this keystream is constant for all 3DSes, thus enabling an unlock without using a working 3DS to generate the password. To get this keystream one has just to encrypt 16 bytes of 0x00, which my source did.

Lock/Unlock mechanism (in pseudocode, those functions are named differently and have different signatures on the 3DS as well as in RPU):
Code:
uint8_t CID_buffer[CID_length];
CID_buffer = read_CID(eMMC);
CID = AES_encrypt(CTR , GW_MASTERKEY, CID, CID_length ); //this is equivalent to CID = CID xor AES_encrypt(CTR , GW_MASTERKEY, 0x0, CID_length);
CID[0] = 5; //bit 0 and 2 set, meaning "set password" and "lock eMMC", for the unlock it's CID[0] = 2; //bit 1 set meaning "clear password" (unlock happens implicit)
CID[1] = 14; //next 14 bytes are the password
SD_command(eMMC, 42, CID, CID_length); //command 42 (lock/unlock) on the eMMC sending 16 bytes starting from &CID as data payload

Thanks GW for choosing the one AES mode which made this approach possible.

This is another piece of evidence that the bricking doesn't happen random, as (on the most objective level) the locking occurs using a deterministic (not random) console specific password. I don't want to and will not make any claims beyond that (even though personally I do believe it happens with intent as a clone deterrent gone horribly wrong, this IMHO still isn't decisive damning evidence).

Feasibility of the unlock -> dump -> lock -> force erase -> flash approach was proven by gamesquest1 (using the unmodified 2.0b2) and Inaki (using the region patched 2.0b2). Thanks for testing dudes.
Also thanks to krisztian1997, khalaan and of course the anonymous source. Love you guys (no homo).


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*
 
We have enough Gateway threads around here, lets try to consolodate at least a few of them. For updates and discussions about 3DS unbricking, please use this topic.
 
Status
Not open for further replies.

Site & Scene News

Popular threads in this forum