Hacking 3DS unbricking progress

[bkifft]

I was thinking: a phone could serve the cause, as they have direct mmc controllers. what would be needed for it to work? just a linux kernel without the emmc subsystem, right?

Should work.

You'd need to boot it somehow without eMMC access (init ramdisk for example, don't know if phone bootloaders support them) and research how the eMMC/SD slot access works on that device (my tool is specific for the Pi's SoC)

 

[michyprima]

Should work.

You'd need to boot it somehow without eMMC access (init ramdisk for example, don't know if phone bootloaders support them) and research how the eMMC/SD slot access works on that device (my tool is specific for the Pi's SoC)

actually, Android phones boot off a boot partition. the kernel is at the beginning of it, then there's the initramfs "glued" to the end. it contains the classical linux things, like init and busybox. removing the Android startup files should leave enough room to do what I was thinking. we also would need a kernel with enabled console, or all we would see would be a black screen.

could work. I have a water damaged galaxy s2 to do tests on eheh

 

[khalaan]

You could use adb for your console

 

[bkifft]

actually, Android phones boot off a boot partition. the kernel is at the beginning of it, then there's the initramfs "glued" to the end. it contains the classical linux things, like init and busybox. removing the Android startup files should leave enough room to do what I was thinking. we also would need a kernel with enabled console, or all we would see would be a black screen.

could work. I have a water damaged galaxy s2 to do tests on eheh

who needs an open shell session on the device when one got a running sshd?

 

[michyprima]

who needs an open shell session on the device when one got a running sshd?

eheh! little question: where did you find the constants for the Pi chipset?

 

[bkifft]

eheh! little question: where did you find the constants for the Pi chipset?

in the peripherals datasheet of it's SoC: http://www.raspberrypi.org/wp-content/uploads/2012/02/BCM2835-ARM-Peripherals.pdf , EMMC starts at page 55.

 

[michyprima]

in the peripherals datasheet of it's SoC: http://www.raspberrypi.org/wp-content/uploads/2012/02/BCM2835-ARM-Peripherals.pdf , EMMC starts at page 55.

thanks. will need to find something similar for the exynos then...

 

[Lucard]

Hello,

i have worked to unbrick the 3DS with the raspberry pi but i cant load the raspberry pi special System.

I have test a other System and it works fine... only on the 3DSUnbrick System it does nothin. Pi red lamp is on and thats all...

Have anyone a idea ???

 

[bkifft]

Hello,

i have worked to unbrick the 3DS with the raspberry pi but i cant load the raspberry pi special System.

I have test a other System and it works fine... only on the 3DSUnbrick System it does nothin. Pi red lamp is on and thats all...

Have anyone a idea ???

basic debugging question: you have written the supplied image to an SD card as well as an USB stick and plugged both into the Pi? If so something might have gone wrong while flashing the image, try and reflash both.

edit: if it doesn't work then: check if on windows you see the fat partition on the SD as well as the USB. if one of them isn't showing the device it's supposed to be on is most likely broken.

 

[gamesquest1]

Hello,

i have worked to unbrick the 3DS with the raspberry pi but i cant load the raspberry pi special System.

I have test a other System and it works fine... only on the 3DSUnbrick System it does nothin. Pi red lamp is on and thats all...

Have anyone a idea ???

Have you tried another SD card, I had a similar problem with a SD card, if the raspberry doesn't read anything from SD when it's turned on it doesn't to anything and has no output on screen

 

[Lucard]

Hello,

i have write the Firmware to the USB and the SD Card.
On Windows the Fat partition on USB and sd card is showing.

I have the original firmware RAW from the Homepage to test the SD card and all works with it.

When i change the original Firmware files (in the fat partition, kernel and someone) with the files from the 3dsbackup Os it loads and all works.
but when i try the 3dsunbrick program it says its the flase kernel with sd supord.

 

[gamesquest1]

https://drive.google.com/file/d/0B4Gv-RnAT-F_THRPT21NWjNWVXc

Write that image to both the SD and the USB, if you are not connected to a network copy this file to the USB and rename to RPU.zip
https://github.com/bkifft/RPU/archive/master.zip

 

[Lucard]

Dont Work =(

Its not start the pi lamp is red and nothin...
When i change from a original firmware the fat partition files it loads but i cant use the 3dsunbricker ... it says flase kernel i brought a kernel without sd...

 

[bkifft]

Dont Work =(

Its not start the pi lamp is red and nothin...
When i change from a original firmware the fat partition files it loads but i cant use the 3dsunbricker ... it says flase kernel i brought a kernel without sd...

If the message you are getting is "It seems the MMC/SD drivers are loaded. Please boot a kernel without them." that means that the MMC/SD drivers are loaded and running.

and in regards to the mini linux image not booting I've got a suspicion...

Could you please try booting the official unaltered raspbian image from SD with the usb stick unplugged, plug it in (after the system finished booting and you loged in) and do a "ls /dev/sd* -al" (without the "") and check if there are results besides sda, sda1 and sda2?

if so (for example there are also "sdb1" and so on or an "sda" with a number bigger than 2) your keyboard might have integrated flash storage or you usb stick got an extra partition.

in that case use another keyboard (if you get sdb results) or another usb stick (if you get sda results with a number bigger than 2).

if you get no results on the ls for some reason linux doesn't like your usb stick, in this case try another one.

edit: in case your usb keyboard got flash storage you can also boot with the keyboard detached and only plug it in after the system booted and you are at the login: prompt.

edit2: in case you don't have another usb stick and you got an sda3, you can also use another SD card (also flashed with the image) in an usb sd reader.

 

[gamesquest1]

Thinking about it it could be one of those usb drives with random apps On a locked partition, if 2 different drives appear when you plug it into a pc that's probably the issue

I think bkifft has covered most issues you could be having in last post, just try a different SD and USB to eliminate any issues that could be coming from them, and wait until login prompt before plugging anything else in apart from Hdmi usb and SD card

 

[pietahpoeh]

Just an idea.
Is it possible to log the password when the bricking appears?

additional hardware may be required for example a logic-analizer.

 

[bkifft]

Just an idea.
Is it possible to log the password when the bricking appears?

additional hardware may be required for example a logic-analizer.

It's possible. eMMC communication is only specified at a max rate of 52MHz, a data rate which even the cheapest logic analyzers should be able to sample nowadays.

Possible problems:

You'd need to sniff all data channels (as data transfer usually is done parallel on multiple lines if they are available) and I'm not sure how many there are on the 3DS. For unbricking purposes we use only one, but the 3DS should utilize more. Then you'd have to figure out how to interweave that multi channel communication to the single lock data payload (which shouldn't be impossible as it's specified in the JEDEC specs, just happens to be way above my head (software only guy here)).

Also that would only lead to universally usable results if the lock uses a common password for all 3DSes or the locking password gets generated in an insecure way. If it's generated using the AES engine in a secure operation mode (and here even ECB aka the one blockcypher operation mode you should never use has to be classified as secure) you'd just be able to sniff your 3DSes unique password.

Btw: As far as I know someone is already working in that direction.

 

[pietahpoeh]

I doubt that the aesengine is used for generating the password.
I assume, when the emmc is locked the AES engine is unusable.
In that case it would also be very hard for the gateway-team to do an unlock.

The password can also depend on the serialnumber of the 3ds or it may be just a common key

It also can be a random key which makes an unlock very hard. ( only bruteforce )

 

[bkifft]

I doubt that the aesengine is used for generating the password.
I assume that when the emmc is locked the AES enging is unusable.
In that case it would also be very hard for the gateway-team to do an unlock.

The password can also depend on the serialnumber of the 3ds or it may be just a common key

It also can be a random key which makes an unlock very hard. ( only bruteforce )

I doubt it to be a random password, as GW stated (condensed and paraphrased) "If you should brick legit, we'll unbrick. Please also send a NAND dump if possible." -> they can unlock without the dump, but it's more complicated for them or they just want the ability to fix corruption type bricks, too.

If it is a console specific non random password that can be generated even from a locked device there aren't that many options, as NAND content for example would be a no go.
Strongest contender in my opinion would be the CID (the unique eMMC serial number), as it's available even on locked devices and you get it in the eMMC startup sequence anyways (some other tempers speculated it to be the CID too if i remember correctly).

And yeah: you can't use the AES system on a bricked 3DS, as you can't execute code on it (at least I'm not aware of some kind of NAND independent recovery mode).
But you can use the AES engine of an unbricked 3DS, you could even set up an automatic unlocking station: microcontroller based tool reads bricks eMMC status (and perhaps console specific information), sends data to working 3DS running custom AES crunch code (e.g. via IR based UART), working 3DS sends AES result back to microcontroller, microcontroller does the unlock.

Still that would be way more difficult than simply doing a force erase and flashing the dump back.


edit: Easiest possibility would be a fixed, open, console independent password though.

So let's keep or fingers crossed for that one.

 

[gamesquest1]

Yeah I don't think anyone with a bricked console and no nand dump should give up just yet, I think once we find out a way of trying to unlock, you never know the actual key might be fairly simple.....could be a default simple password like 000000 or even be the same key used for all 3ds's you never know, if you have a bricked 3ds with no password, I would say maybe waiting a few weeks for further investigation would be wise