Hardware nand flash dump (3ds xl)

[krisztian1997]

Look at this http://yourcmc.ru/wiki/images/5/55/EMMC_JESD84-A441.pdf at page 79-80, according to that its posible to erase the lock from the eMMC controller

Forcing erase:
In case that the user forgot the password (the PWD content) it is possible to erase all the card data content
along with the PWD content. This operation is called Forced Erase.
• Select the card (CMD7), if not previously selected already.
• Define the block length (CMD16) to 1 byte (8bit card lock/unlock command). Send the card
lock/unlock command (CMD42) with the appropriate data block of one byte on the data line including 16 bit CRC. The data block shall indicate the mode ERASE (the ERASE bit shall be the only bit set).

and because the nand from the 3ds is v4.4, only the userdata will be deleted from the NAND not the boot sectors too.

 

[Elusivo]

Can those CMD instructions be issued by a program in a computer through a sd card reader to the 3ds? I have no idea how those things work ... in the pdf it also talks about the Smart Report Output Data, can't that be used to get a report of what is causing the read/write error?

 

[Gizmo1k]

someone needs to make a new threads for attempting to recover bricks. they just muddying the waters here.

 

[krisztian1997]

Can those CMD instructions be issued by a program in a computer through a sd card reader to the 3ds? I have no idea how those things work ... in the pdf it also talks about the Smart Report Output Data, can't that be used to get a report of what is causing the read/write error?

Nope, most of the SD card readers have a microcontroller inside of them which handles the low-level communication. I think that its posible to talk with the microcontroller directly using an arduino or raspberry pi

someone needs to make a new threads for attempting to recover bricks. they just muddying the waters here.

No one is willing to use their console to test random stuffs, also I don't think that most of them own an arduino or raspberry pi to try to communicate with the controller directly.

 

[Quicksilver88]

An interesting notion is that Gateway can fix this brick.....it is yet to be confirmed but if someone with. Gateway that bricks would send them their rig and Nand backup then we would know if they can really restore....but lets assume they can...

How would they do that or what equipment would they have that enables it? Maybe an raspb pi as some have suggested and maybe they did use the lock feature and they know the unlock code....but how are they delivering it?


I have a different train of thought, first is the eMMC a shared interface.....meaning does it handle communications to both the system Nand and the SD card interface.

Here is my thinking what the Gateway team has done with EmuNand is redirect Nand read/write to the SD card. They said when testing the new EmuNand safeguard feature that they bricked and fixed many times. The Pandora battery trick on the PSP essentially forced the system to boot from the MS slot and not the internal nand. If you didn't have a specially prepared 'magic stick' the system would appear bricked when a pandora battery was in place.

So what if the Gateway brick (and latest feature they were working on) is that they are forcing the eMMC to seek the SD slot to boot the system bios? Someone with a brick should take the backup of their 4.x bios and raw write it to an SD with winimage, insert, cold boot and just see what happens.

Does this sound crazy (I know its not impossible)? What I wonder is if Gateway was trying thru eMMC reprograming to get the system to cold boot into EmuNand from SD to avoid the entire 4.5, exploit, launcher process and eliminate any chance of updating sysnand because you direct boot from the SD.

 

[Arras]

An interesting notion is that Gateway can fix this brick.....it is yet to be confirmed but if someone with. Gateway that bricks would send them their rig and Nand backup then we would know if they can really restore....but lets assume they can...

How would they do that or what equipment would they have that enables it? Maybe an raspb pi as some have suggested and maybe they did use the lock feature and they know the unlock code....but how are they delivering it?


I have a different train of thought, first is the eMMC a shared interface.....meaning does it handle communications to both the system Nand and the SD card interface.

Here is my thinking what the Gateway team has done with EmuNand is redirect Nand read/write to the SD card. They said when testing the new EmuNand safeguard feature that they bricked and fixed many times. The Pandora battery trick on the PSP essentially forced the system to boot from the MS slot and not the internal nand. If you didn't have a specially prepared 'magic stick' the system would appear bricked when a pandora battery was in place.

So what if the Gateway brick (and latest feature they were working on) is that they are forcing the eMMC to seek the SD slot to boot the system bios? Someone with a brick should take the backup of their 4.x bios and raw write it to an SD with winimage, insert, cold boot and just see what happens.

Does this sound crazy (I know its not impossible)? What I wonder is if Gateway was trying thru eMMC reprograming to get the system to cold boot into EmuNand from SD to avoid the entire 4.5, exploit, launcher process and eliminate any chance of updating sysnand because you direct boot from the SD.

You can't backup the 3DS "bios". It's impossible. Also, the only reason magic memory sticks worked on the PSP was that it was a built-in safety mode.

 

[XpertXP1]

Has anyone tried fixing a bricked 3DS with SMI Mass Production Tool...I know its a shot in the dark, but worth the try, i have used to to fix thumb drives in the past with write ability locked...just a thought http://usb-fix.blogspot.com/p/smi.html

 

[TheBorg]

An interesting notion is that Gateway can fix this brick.....it is yet to be confirmed but if someone with. Gateway that bricks would send them their rig and Nand backup then we would know if they can really restore....but lets assume they can...

How would they do that or what equipment would they have that enables it? Maybe an raspb pi as some have suggested and maybe they did use the lock feature and they know the unlock code....but how are they delivering it?


I have a different train of thought, first is the eMMC a shared interface.....meaning does it handle communications to both the system Nand and the SD card interface.

Here is my thinking what the Gateway team has done with EmuNand is redirect Nand read/write to the SD card. They said when testing the new EmuNand safeguard feature that they bricked and fixed many times. The Pandora battery trick on the PSP essentially forced the system to boot from the MS slot and not the internal nand. If you didn't have a specially prepared 'magic stick' the system would appear bricked when a pandora battery was in place.

So what if the Gateway brick (and latest feature they were working on) is that they are forcing the eMMC to seek the SD slot to boot the system bios? Someone with a brick should take the backup of their 4.x bios and raw write it to an SD with winimage, insert, cold boot and just see what happens.

Does this sound crazy (I know its not impossible)? What I wonder is if Gateway was trying thru eMMC reprograming to get the system to cold boot into EmuNand from SD to avoid the entire 4.5, exploit, launcher process and eliminate any chance of updating sysnand because you direct boot from the SD.

- Someone with a brick should take the backup of their 4.x bios and raw write it to an SD with winimage, insert, cold boot and just see what happens.
Test it, same result... no boot and read/write error.

 

[Gizmo1k]

- Someone with a brick should take the backup of their 4.x bios and raw write it to an SD with winimage, insert, cold boot and just see what happens.
Test it, same result... no boot and read/write error.

cool yeah they can do it in a new thread.

 

[_Tim_]

If whatever Gateway did to the eMMC can be undone (e.g. remove password protection, change partition size from 0 to original value, remove write protection, etc.) then you are going to need to communicate directly with the eMMC. The cheapest option would be to buy the "3.3V 5.5V FT232RL FTDI USB to TTL Serial Adapter Module for Arduino Mini Port" on eBay for $5 or the "Arduino Leonardo Pro Micro ATmega32u4 Module With 2 Row Pin Header 5V/16MHz" + "SD Card Module Slot Socket Reader for MP3 Arduino ARM MCU Read and Write OH" for $6.

 

[lordofthereef]

Nope, most of the SD card readers have a microcontroller inside of them which handles the low-level communication. I think that its posible to talk with the microcontroller directly using an arduino or raspberry pi


No one is willing to use their console to test random stuffs, also I don't think that most of them own an arduino or raspberry pi to try to communicate with the controller directly.

I have a raspberry pi that is collecting dust that I would be happy to donate to the cause if someone paid shipping and would be actually willing to risk their console.

I would also be willing to brick a console, perhaps, if someone was willing to send me the materials needed to brick it (basically a gateway since I do not have one). I can grab a US version with 4.1 or 4.4 pretty easily.

 

[krisztian1997]

I have a raspberry pi that is collecting dust that I would be happy to donate to the cause if someone paid shipping and would be actually willing to risk their console.

I would also be willing to brick a console, perhaps, if someone was willing to send me the materials needed to brick it (basically a gateway since I do not have one). I can grab a US version with 4.1 or 4.4 pretty easily.

Instead of donating it, you could try getting a cheap mmc card and communicate with it using SPI, and if that works then it should be easy to send any commands to the controller directly.

 

[gamesquest1]

Now all this is positive brain storming, and let's face it, may the "bricking" code is a blessing in disguise if it helps drive people's knowledge of even more functions of the 3DS. Although granted I do think this is going beyond the scope of this thread and maybe should get its own thread

Ps I know people who have been affected by this will in no way see it as a blessing, and I don't mean to offend if someone takes it the wrong way, I just mean it's good to see some drive for a change

 

[Daku93]

The Arduino can talk to the eMMC only in SPI Mode. And for the SPI mode to work you need a fifth connection to DAT3 (which is CS in SPI Mode) of the eMMC. CLK, CMD, DAT0 and GND are not enough.

 

[gamesquest1]

Pinout for dat 0-3 is already on http://3dbrew.org/wiki/Hardware#XL_model
So is this thing actually doable?

 

[Daku93]

It should be, yes.
But no one has tested it, yet and I don't want to solder in another wire...

 

[Moquedami]

If whatever Gateway did to the eMMC can be undone (e.g. remove password protection, change partition size from 0 to original value, remove write protection, etc.) then you are going to need to communicate directly with the eMMC. The cheapest option would be to buy the "3.3V 5.5V FT232RL FTDI USB to TTL Serial Adapter Module for Arduino Mini Port" on eBay for $5 or the "Arduino Leonardo Pro Micro ATmega32u4 Module With 2 Row Pin Header 5V/16MHz" + "SD Card Module Slot Socket Reader for MP3 Arduino ARM MCU Read and Write OH" for $6.

Im willing to buy those and try them in my bricked 3ds if someone can explain me the procedure.

 

[Quicksilver88]

So the idea is to hook a raspberry pi or arduino via SPI to the 3DS Nand and then are you looking to just read the flags and send commands to the eMMC to try to reset its state?

 

[obcd]

An arduino can talk to the eMMC in both modes as basically every gpio pin of it can be set as input or output and can be set high or low.
The arduino microcontroller only has hardware support for the SPI protocol.
This means that all other communication has to be emulated in software which is usually much slower than a dedicated hardware interface for the same purpose.
Arduino has 5V gpio voltage levels which is 2 high for interfacing an eMMC.
The raspberry uses 3V3 gpio voltage levels which might be what is needed?
The problem is finding (writing) the needed software to communicate with the eMMC at a level that shows us what is going on. Being able to read it's registers would already help a lot as some status bits might indicate the condition of the eMMC chip.

 

[obcd]

If they really locked the eMMC you will need the passkey to unlock it without erasure of it's contents
or you will need a working nand backup and a method to restore it.