Hacking 3DS unbricking progress

[mr. fancypants]

People with limited skills might want to adopt a wait and watch approach. Let this solution be tested by more experienced people and let this evolve.

Good job guys, those who are working on this! I don't have a bricked 3DS but this shall help a lot of people out there.

same thought keep up the good work guys !!!

 

[the-green]

Nice work, hope it will give us something interrestin in the futur.

 

[Ryft]

I wonder if someone with a bricked 3DS would be willing to send it to one of you guys so you can test it personally. Might be easier for the initial test, but I understand it's hard to trust random strangers on the internet.

 

[Quicksilver88]

Well the 52 dollar question then is does the 3DS Nand still support the SPI functions/interface. I am guessing if it does then people will be restoring bricks before we know it.

Look at the bright side, anyone who uses this to restore a brick will then have a hardware modified 3DS. You can then upgrade/downgrade at will and while EmuNand could eventually end the need for that, it is still very useful for those that really want to the best of all possible solutions.

As others have stated, in theory a pogo pin solution should be possible for 3DS XL (someone in another thread has done this or been working on it). I think the problem is you need small pogo pins and the tester in the other thread used the pogo pins from his old xbox mod.

What some enterprising sort with the know how and equipment should do once this bricking solution gets cooked is offer a service to unbrick 3DS and install a micro usb port for a reasonable fee (I would do it myself but I have a day job so don't really need the extra income).

 

[krisztian1997]

For the 3DS XL it would be posible to make an unbricker device and also a NAND flasher, using a battery cover/bottom case which has pogo pins and an PIC in it, just take out the screws, remove the bottom of the console, put on the flasher bottom, unbrick the console with it then flash the nand using a PC.

 

[Coto]

remember SPI (1bit mode) uses 3.3V and 5 wires SCLK,CS,MOSI(DO),MISO(DI),VCC
SD mode (1 bit) uses CLK,GND,CMD,VCC,DAT0 uses 3.3V/1.8V ! be careful here!
SD mode (4 bit) uses CLK,GND,CMD,VCC,DAT0,DAT1,DAT2 uses 3.3V/1.8V ! be careful here!

that means if you use a SPI programmer/ SD reader/rasp pi/doorstep clock/whatever/ if voltage comes from 3.3v you reduce it to 1.8V so you don't fry the eMMC controller, or arduino interface.

 

[krisztian1997]

remember SPI (1bit mode) uses 3.3V and 5 wires SCLK,CS,MOSI(DO),MISO(DI),VCC
SD mode (1 bit) uses CLK,GND,CMD,VCC,DAT0 uses 3.3V/1.8V ! be careful here!
SD mode (4 bit) uses CLK,GND,CMD,VCC,DAT0,DAT1,DAT2 uses 3.3V/1.8V ! be careful here!

that means if you use a SPI programmer/ SD reader/rasp pi/doorstep clock/whatever/ if voltage comes from 3.3v you reduce it to 1.8V so you don't fry the eMMC controller, or arduino interface.

We use SPI, and Roland's code can detect if the SD card returns that we are using the wrong voltage and breaks the initialization, which stop the communication with the card imediatly.

 

[bkifft]

let me add my status update:

with the help of my trusting betatester inian we've got CID and CSD read from a bricked 3DS using the original 4 wire HW mod via a raspberry pi SD slot.

for anyone interested the CSD is 00900F00320F5903B9FFFF87FF964050 which, as long as i haven't miscalculated, says that there is no global write protect set. (wont post the CID, unique traceable number n stuff)

oh and btw: the init sequence is different for MMC, at least in SD mode.

the SD mode (not SPIO mode) sequence is:

notation CMD[cmdindex]([argument])

CMD0(0x0) -> CMD1(0x40FF8080) repeat untill reply has bit 31 set (aka. reply & (1 << 31) == 1) ->
-> CMD2(0) reply is CID -> CMD3([RCA]<<16) (i used 0xBEEF as RCA, old habits) ->
-> (if CSD wanted: CMD9([RCA]<<16) reply CSD) -> CMD7([RCA]<<16)

which leaves the card in transfer state waiting to receive CMD42.

 

[krisztian1997]

let me add my status update:

with the help of my trusting betatester inian we've got CID and CSD read from a bricked 3DS using the original 4 wire HW mod via a raspberry pi SD slot.

for anyone interested the CSD is 00900F00320F5903B9FFFF87FF964050 which, as long as i haven't miscalculated, says that there is no global write protect set. (wont post the CID, unique traceable number n stuff)

oh and btw: the init sequence is different for MMC, at least in SD mode.

the SD mode (not SPIO mode) sequence is:

notation CMD[cmdindex]([argument])

CMD0(0x0) -> CMD1(0x40FF8080) repeat untill reply has bit 31 set (aka. reply & (1 << 31) == 1) ->
-> CMD2(0) reply is CID -> CMD3([RCA]<<16) (i used 0xBEEF as RCA, old habits) ->
-> (if CSD wanted: CMD9([RCA]<<16) reply CSD) -> CMD7([RCA]<<16)

which leaves the card in transfer state waiting to receive CMD42.

You can send commands to the SD card using a raspberry pi ? If yes, can you try write/reading a block and then see what error it returns.

 

[bkifft]

You can send commands to the SD card using a raspberry pi ? If yes, can you try write/reading a block and then see what error it returns.

sure. i'll have to look up data transfer mode anyway (as CMD42 takes the payload as regular DATA write if i've read the specs correctly).

for safety reason i'll stick to reading though.

 

[olfa]

sure. i'll have to look up data transfer mode anyway (as CMD42 takes the payload as regular DATA write if i've read the specs correctly).

for safety reason i'll stick to reading though.

can you post the source code ? (or put in on github)
thanks

 

[Mr_Pichu]

Conditions are green it is a go for launch.

I was worried about there being a write protect on the NAND, I think many of us were not expecting this to be the case.

This is the datasheet for the Samsung KLM2G1DEHE-B101
http://web3032.sh1.magic2008.cn.m1.magic2008.cn/uFile/3032/201144131450191.pdf

 

[gamesquest1]

so is it confirmed working?

 

[helpwith3ds]

Do you guys think this unbricking progress will eventually help someone without a nand back up? Unfortunately was only using my r4i deluxe card for a few hours before brick and didn't get a chance to do a backup.

 

[Mr_Pichu]

Do you guys think this unbricking progress will eventually help someone without a nand back up? Unfortunately was only using my r4i deluxe card for a few hours before brick and didn't get a chance to do a backup.

It is possible, if we can determine the password that was used to lock the eMMC. Some say the password may be all zeros. We will have our answer soonish.

 

[gamesquest1]

backup should of been the first step in all cases, i have heard the password is unique per 3DS so wouldn't really be possible to retrieve, but there was also rumors of it being "0" so just wait a bit longer and see if its found out,

 

[mznova]

If this works, Gateway may stop trying to put brick codes in their firmware... Or they may attempt to do something worse. >_>

 

[krisztian1997]

If this works, Gateway may stop trying to put brick codes in their firmware... Or they may attempt to do something worse. >_>

Worst thing what they can do is transform the NAND into a ROM, by setting the permanent write protect to 1, but then if their code has bugs again like now and bricks a legit user, then the consoled is dead, and all what they can do is replace the NAND chip. Reflashing this specific eMMC chip looks imposible without special devices (like the ones used by chinese sellers to fake the SD card size), so they cant really do anything if we block the posibility to lock the nand using password.

 

[Ennea]

I kind of thought I'd be seeing a thread like this from you soon Thank you very much for all the effort you've already put into this, and thank you for everything that is to come. You've done a great service to the community.

 

[gamesquest1]

Worst thing what they can do is transform the NAND into a ROM, by setting the permanent write protect to 1

shhhhhhhhhhhh dont give them any more ideas XD