Hacking Has anyone with a brick been able to recover?

[Quicksilver88]

Well now my point is has anyone tried it, as I have seen no discussion of it in any threads? As we know you can do the hardware mod...I am wondering if anyone with the hardware mod and a backed up Nand (both via the hardware method and the Gateway Nand method) has tried to restore their good Nand after the brick?

I heard someone did try to restore it and it was not possible so that would seem to mean the brick did more than just wipe the sysnand, it as others here seem to be suggestion must have wiped other low level chip firmware on the SD or Nand controller/interface chip?

 

[FR0ZN]

We already know it's the eMMC which went fubar after GWs magic.

 

[inian]

Well now my point is has anyone tried it, as I have seen no discussion of it in any threads? As we know you can do the hardware mod...I am wondering if anyone with the hardware mod and a backed up Nand (both via the hardware method and the Gateway Nand method) has tried to restore their good Nand after the brick?

I heard someone did try to restore it and it was not possible so that would seem to mean the brick did more than just wipe the sysnand, it as others here seem to be suggestion must have wiped other low level chip firmware on the SD or Nand controller/interface chip?

yes, i have tried this are results for the moment - http://gbatemp.net/threads/nand-flash-dump-3ds-xl.350668/page-44#post-4883527

 

[Quicksilver88]

Ianan,

Thanks for the link to the other thread.....so it looks like you are waiting for the other reader that lordofthereef recommended? Question is he and others have used that reader but did he actually recover from a brick with it?

From what iCEQB said it if its the eMMC then without some sort of additional hackery or a way to deliver a payload with command to reset/restore the eMMC the bricked users are screwed?

 

[Huntereb]

If only we knew... /sarcasm. Check the first page of this subforum.

So there is a known way to fix this? From what I've been hearing, the way they've pulled this off is more devastating than it sounds.

 

[bkifft]

Ianan,

Thanks for the link to the other thread.....so it looks like you are waiting for the other reader that lordofthereef recommended? Question is he and others have used that reader but did he actually recover from a brick with it?

From what iCEQB said it if its the eMMC then without some sort of additional hackery or a way to deliver a payload with command to reset/restore the eMMC the bricked users are screwed?

as far as i'm aware of (disclaimer: i've only looked at pcb shots, not at the real thing) the 3DS only uses the 4 pin connection also used for the dump mod to communicate with the eMMC (other pins/contactpoints used are only different voltage supplies).

if the brick is reversible at all it should therefore be possible using said four wire interface. problem is: until it's clear what exactly happened it can't be undone.

 

[Moquedami]

I copy this here too
I'm still trying to recover the brick, and after 3 memory readers, checking my solderings, and trying in both laptop and desktop, I might be making some progress.
Now Windows detects a removable unit but doesn't say the size.
USB Image Tool reads it as Generic Storage device USB Size: 1.000.341.504 bytes
And both USB Image Tool and Win 32 Disk Imager let write the unit with the nand.bin
Problem is that after a while both report error.

For USB Image Tool:
Error: Could not write to the USB device (Code: 0)!
Please close all open explorer windows for this device

For Win 32 Disk Imager:
An error ocurred while attempting to write data to handle. Error 19: the media in Writting protected.

I don't know if this is caused by my SD adapter or actually is the famous eMMC thingy
I put the little plastic jumper of the writting lock in its original position, but since I had to rip the adapter open, I don't know if it's ok.
Just in case I covered all with tape but doesn't change the result.

 

[olfa]

some infos from inian test
[ 1409.756123] sd 7:0:0:0: [sdb] CDB:
[ 1409.756125] Read(10): 28 00 00 00 00 00 00 00 08 00
[ 1409.756134] end_request: I/O error, dev sdb, sector 0
[ 1409.756137] Buffer I/O error on device sdb, logical block 0
[ 1409.756151] sdb: unable to read partition table
[ 1409.889007] sd 7:0:0:0: [sdb] Test WP failed, assume Write Enabled
[ 1409.892010] sdb: detected capacity change from 1000341504 to 0 <== this was solved by reverting to old linux kernel 2.6.x
[ 1409.893150] sd 7:0:0:0: [sdb] Asking for cache data failed
[ 1409.893155] sd 7:0:0:0: [sdb] Assuming drive cache: write through
[ 1409.893160] sd 7:0:0:0: [sdb] Attached SCSI removable disk
[ 1576.024331] CE: hpet increased min_delta_ns to 229090 nsec

error on read/write (even with dd)
root@Microknoppix:/mnt/sda3/3DSTEST# head /dev/sdb
head: cannot open `/dev/sdb' for reading: No medium found

==============
know if you have free time and skils, look at this : http://lxr.free-electrons.com/source/drivers/mtd/nand/nand_ids.c
(or this http://www.raspberrypi.org/phpBB3/viewtopic.php?t=14317&f=72 )

 

[obcd]

Micro sdhc cards have an option to write protect the card. If such is enabled, you need to send a code before it unlocks.
eMMC uses pretty much the same interface, so it might have such features as well. Maybe their even exist features to lock the read mode untill a valid password is sent to the card. A normal cardreader (like used to dump the eMMC) isn't capable of sending such low level commands.
So, it's very well possible that Gateway simply locked the eMMC with a password.
In such case, the 3ds won't be able to read from it either. Gateway might be able to fix the issue since they know the unlocking password.
If they would have wiped clean the eMMC, they wouldn't have a way to recover the eMMC contents either, as those are encrypted with a console specific key.
I don't think they have way to recover that key on a non working 3ds.
There are some datasheets in the wild describing the samsung eMMC devices. Maybe they could provide more detailed information about possible options to lock the device.

If my theory is correct (they usually aren't), than to unbrick the device, you would need the following:

1. Reverse engineer the gateway code to figure out the password used to lock the eMMC.
2. Build a hardware device capable of sending the unlocking command to the eMMC.
3. Use the device to send the unlock code (and disable locking afterwards) to fix the brick.

Remember, this is just a theory.

 

[bkifft]

Micro sdhc cards have an option to write protect the card. If such is enabled, you need to send a code before it unlocks.
eMMC uses pretty much the same interface, so it might have such features as well. Maybe their even exist features to lock the read mode untill a valid password is sent to the card. A normal cardreader (like used to dump the eMMC) isn't capable of sending such low level commands.
So, it's very well possible that Gateway simply locked the eMMC with a password.
In such case, the 3ds won't be able to read from it either. Gateway might be able to fix the issue since they know the unlocking password.
If they would have wiped clean the eMMC, they wouldn't have a way to recover the eMMC contents either, as those are encrypted with a console specific key.
I don't think they have way to recover that key on a non working 3ds.
There are some datasheets in the wild describing the samsung eMMC devices. Maybe they could provide more detailed information about possible options to lock the device.

If my theory is correct (they usually aren't), than to unbrick the device, you would need the following:

1. Reverse engineer the gateway code to figure out the password used to lock the eMMC.
2. Build a hardware device capable of sending the unlocking command to the eMMC.
3. Use the device to send the unlock code (and disable locking afterwards) to fix the brick.

Remember, this is just a theory.

yes, that's only a theory, but not a far fetched one.

While i don't think they used some type of key (Xbox (without 360 or one) HD anyone?) or deleted the data (i still believe that whole bricking is a side effect of their "accidental update protection" code) i agree with you in your general assumptions.

As far as i know SD cards don't have a minimum clock speed. Thus one would also be able to send the right commands using physical switches.

So it should be easy to use any kind of interface that offers four toggleable outputs (raspberry pi, usb2comport adapters, whatever one has available).

As soon as the correct command sequence required for the unlock becomes known, that is.


p.s.: as there are 2 different eMMC in enduser 3DS(xl) devices (samsung and toshiba): anyone reported a trend if one got bricked more often? or one not at all as of yet? as if it happens to both i'd say its unlikely they did something manufacturer specific, which would make figuring out what exactly they did easier as the general SD/MMC specs are public as far as i know.

 

[Cyberdrive]

Cross-posted from the thread full of white noise:

Page 14 of http://www2.lauterbach.com/pdf/emmcflash.pdf looks like the sort of thing we have been looking for here.

Configuration of the eMMC registers... it actually looks like this brick should be quite easy to fix, using the same solder points as the nand dumping, I think.

It will require some special software though.

 

[obcd]

If you use physical switches to send the commands, you will make errors and it won't work.
The first generation xboxes indeed used a similar protection mechanism built in the ata command set to lock their harddisk.
eMMC largely uses the MMC interface protocol which is a standard. So the locking mechanism could be equal for both brand of eMMC devices.
The Samsung datasheets weren't very detailed. Maybe the Toshiba ones are better?

 

[Cyberdrive]

p.s.: as there are 2 different eMMC in enduser 3DS(xl) devices (samsung and toshiba): anyone reported a trend if one got bricked more often? or one not at all as of yet? as if it happens to both i'd say its unlikely they did something manufacturer specific, which would make figuring out what exactly they did easier as the general SD/MMC specs are public as far as i know.

The following was reported in NAND dumping thread:

Spoiler

hello

1) sorry for my very bad english

in my opinion all sd redear are good for reading 3ds nand

the problem is all 3ds don't have the same nand cheep

to read the nand you have to (temporary) brick the 3DS
you connect the SD reader, start the 3ds, have blue screen(brick), and then dump

i have 2 3DS witch dont have the same nand cheep (great)

the first dump without problem (the SD reader brick the 3DS)

the second refuse to dump (with the same sd reader , the SD reader don't brick the 3DS)

solution
shortcut clock and ground
power on 3DS === blue screen (brick)
remove the short cut
connect the SDreader
and dump

my SD reader is a 1$ comming from DX.....

a+

which seems to suggest that different chips react differently, which may or may not be used by manufacturer-specific code. And I haven't seen innards of the bricked handhelds here on GBAtemp other than in aforementioned thread.

 

[npbg6464]

Unlike hard drives, most common types of flash memory can't be protected with a password - this is a part of the ATA specification implemented in hard drive controllers only. But according to this datasheet: http://pdf.datasheetarchive.com/indexerfiles/Datasheets-AQ2/DSAAQ0030862.pdf (Samsung eMMC controller - no idea if it's the same one the 3DS uses), in section 6.3, there's an interesting flag that can be set in the CSD register that will write protect the memory (there's also a write-once flag for permanent write protect, if 3DS's eMMC CSD register contains that flag and it was set, there's nothing at all that can be done). The CSD register (of the eMMC controller in the datasheet above - again, I have no idea which controller the 3DS uses as I don't have one) can be written to with command 27h. Perhaps this will help someone.

 

[obcd]

http://rere.qmqm.pl/~mirq/JESD84-A44.pdf

page 62 looks interesting. Haven't looked at it yet. (7.6.13)

Unsure if an eMMC protected like that would still return it's proper geometry.
It also seems possible to disable this protection feature. Not sure if that's permanent or could be undone.

 

[obcd]

If the problem would be write protect, the device would still give it's correct geometry (size) I assume.

 

[bkifft]

If you use physical switches to send the commands, you will make errors and it won't work.

I take it you never booted a computer by hand using flip switches then? Good times i tell you.

@thread: what baffles me most is that the change is non volatile, as i havent found any kind of mode toggle yet which survives a power cycle..

http://rere.qmqm.pl/~mirq/JESD84-A44.pdf

page 62 looks interesting. Haven't looked at it yet. (7.6.13)

Unsure if an eMMC protected like that would still return it's proper geometry.
It also seems possible to disable this protection feature. Not sure if that's permanent or could be undone.

damn -.-

 

[obcd]

I remember the PDP 11 but never worked with one...

If you programmed a wrong byte in there, you could correct it afterwards.
You also had a large number of lights to check your work. (address lines and memory contents.)

 

[justinkb]

We need some info on whether emmc interface is properly standardized. I linked to a datasheet with relevant emmc register configuration info in another thread.

In any case, as I read it's a samsung controller, it's likely there is some open source code available from samsung dev site (from code for android devices, which might use the same controllers).

 

[obcd]

The datasheet for which I gave the link describes the eMMC 4.4 standard protocol.
The device could already be on the eMMC 4.5 standard protocol. (Backwards compatible I assume)
Maybe we should start with finding the exact type number of the chip and a detailed datasheet of it.
A low level sd card interface might be able to read the registers and find out if the device is in a locked state.

So, yes, the emmc interface is properly standardised.
There are also some manufacturer specific commands for low level debugging and firmware upgrades.