Hardware nand flash dump (3ds xl)

  • Thread starter Thread starter lightenup
  • Start date Start date
  • Views Views 644,654
  • Replies Replies 1,973
  • Likes Likes 6
First of all congrants to both modders, I like the ease of use that corner microusb port gives and I also like the hidden under the cover way because of how the 3ds looks like normal. I think I would go for the microusb one though, I don't mind showing the 3ds is hacked, lol, and it is amazing how the microusb connector fits in and how that "female" screwhole column makes it stay where it is. It seems like it was put like that on purpose !

Ok, some other ideas:

- Use of a QSB to solder the connections. I guess we are still very few so noone will want to do such a thing, but a QSB like what TX does would be cool.
- we are still trying to figure out how the nand could be reseted/force-erased, etc. and I hope we manage to do so soon but, in case we can't, couldn't we just replace the whole nand chip ? current nand chips are regular 1GB nand chips, right ? ( I assume there's no propietary interfaces on them ) so we could maybe use those QSB to put our own eMMC interface nand chip or even a microsd card reader ( this may be a problem because similar toshiba nands are around 30MB/s speed and a class 10 microsd is around 14 MB/s ). This would go together with the connector and all, probably with a hole in the cover for easy access.

What do you guys think ?

EDIT: hmmm, this is probably too much, but it would be very cool to add a small smd microcontroller chip that would MITM all the console->nand traffic and would filter out the locking commands, etc. and, in case a password is sent, it could save it in the microcontroller eeprom for later access; this would be good to help against intentional bricking code, for example... hmmmm
 
First of all congrants to both modders, I like the ease of use that corner microusb port gives and I also like the hidden under the cover way because of how the 3ds looks like normal. I think I would go for the microusb one though, I don't mind showing the 3ds is hacked, lol, and it is amazing how the microusb connector fits in and how that "female" screwhole column makes it stay where it is. It seems like it was put like that on purpose !

Ok, some other ideas:

- Use of a QSB to solder the connections. I guess we are still very few so noone will want to do such a thing, but a QSB like what TX does would be cool.
- we are still trying to figure out how the nand could be reseted/force-erased, etc. and I hope we manage to do so soon but, in case we can't, couldn't we just replace the whole nand chip ? current nand chips are regular 1GB nand chips, right ? ( I assume there's no propietary interfaces on them ) so we could maybe use those QSB to put our own eMMC interface nand chip or even a microsd card reader ( this may be a problem because similar toshiba nands are around 30MB/s speed and a class 10 microsd is around 14 MB/s ). This would go together with the connector and all, probably with a hole in the cover for easy access.

What do you guys think ?

EDIT: hmmm, this is probably too much, but it would be very cool to add a small smd microcontroller chip that would MITM all the console->nand traffic and would filter out the locking commands, etc. and, in case a password is sent, it could save it in the microcontroller eeprom for later access; this would be good to help against intentional bricking code, for example... hmmmm
I can disable the cmd42 by setting a bite in the register, so when I get my arduino and manage to unbrick the 3ds,.i can write a program which disables the cmd42 forever... NO MORE BRICK THEN, and no need to remove the brick code then.
 
  • Like
Reactions: Elusivo
I can disable the cmd42 by setting a bite in the register, so when I get my arduino and manage to unbrick the 3ds,.i can write a program which disables the cmd42 forever... NO MORE BRICK THEN, and no need to remove the brick code then.


A very interesting read:

https://www.sdcard.org/downloads/pls/simplified_specs/part1_410.pdf

So is it possible the MMC is just simply locked in a bricked 3DS? Then it seems clear from the docs that if you know the locking password, you can unlock the MMC. When the MMC is locked you can't access the data in the NAND. You can however issue a force erase to a locked MMC, this will clear the password along with the contents of the NAND. This gives you a clean slate to which you can restore your backup image. Let us see if this turns out to be the case.
 
A very interesting read:

https://www.sdcard.org/downloads/pls/simplified_specs/part1_410.pdf

So is it possible the MMC is just simply locked in a bricked 3DS? Then it seems clear from the docs that if you know the locking password, you can unlock the MMC. When the MMC is locked you can't access the data in the NAND. You can however issue a force erase to a locked MMC, this will clear the password along with the contents of the NAND. This gives you a clean slate to which you can restore your backup image. Let us see if this turns out to be the case.
Thats what we are trying to do, but no one here has a bricked 3ds and an arduino
 
I can disable the cmd42 by setting a bite in the register, so when I get my arduino and manage to unbrick the 3ds,.i can write a program which disables the cmd42 forever... NO MORE BRICK THEN, and no need to remove the brick code then.

you mean you can put the nand in non-lockable state, right ? then no need to do the MITM, cool !; the MITM thing could still be useful to sniff traffic though, and maybe help those who already have their 3ds bricked by nand locking...
 
A very interesting read:

https://www.sdcard.org/downloads/pls/simplified_specs/part1_410.pdf

So is it possible the MMC is just simply locked in a bricked 3DS? Then it seems clear from the docs that if you know the locking password, you can unlock the MMC. When the MMC is locked you can't access the data in the NAND. You can however issue a force erase to a locked MMC, this will clear the password along with the contents of the NAND. This gives you a clean slate to which you can restore your backup image. Let us see if this turns out to be the case.

That's why I think sniffing the traffic may lead to discovery of this password... then there's also force-erasing and as a last chance thing even building a QSB board with a compatible built-in nand... E3 ? TX ?...
 
you mean you can put the nand in non-lockable state, right ? then no need to do the MITM, cool !; the MITM thing could still be useful to sniff traffic though, and maybe help those who already have their 3ds bricked by nand locking...
Yup, i can make the nand non-lockable, but after that you can never lock it again
 
also, would GW use a fixed password or generate one based on some later computable per 3ds algorithm ? they claim they can fix the bricks so it should be either fixed or computable password.

also, I assume people backed up their nand, so, what's the problem to do a force erase ? old interface ? but the how did they use the same interface to lock the nand ? if it has lock it should have force erase also, right ?
 
That's why I think sniffing the traffic may lead to discovery of this password... then there's also force-erasing and as a last chance thing even building a QSB board with a compatible built-in nand... E3 ? TX ?...


This is assuming that a force erase was not issued with a permanent write protect. The result is a permanent NAND bricking, the scorched earth option.
 
This is assuming that a force erase was not issued with a permanent write protect. The result is a permanent NAND bricking, the scorched earth option.

This I mean on an still not bricked 3ds ( I have my second hackable 3ds incoming in a few days and I wouldn't ming doing this myself ), so we can sniff the password when the locking is performed ( of course we should do thorough testing with a regular sd card first ); hopefully, if the password is fixed, we would be able to unlock such cases, right ? if the password is generated from per console data, then launcher.dat reversing would probably be better. Even the fixed password may be easier to obtain by such reversing, instead of the nand MITM during bricking operation, I don't know.

If you want, I could test that unbricking bit setting in my second 3ds... I bought a second obe with the intention on helping in the development of a "robust" unbricker/whatever...
 
Yup, i can make the nand non-lockable, but after that you can never lock it again

uhmm... what kind of side effect could that bring though ? I hope/assume gateway themselves are not using the feature for anything apart from bricking. And I can't think of anything nintendo would need this for. Damn, it would probably be a one-use-only 3ds hardener :D !

one question: this doesn't involve permanently losing write protection, right ? because that *might* be useful and maybe gateway is using it too... although any nand emulation should solely rely on function hooks in memory and not nand programming, but who knows...
 
If you want, I could test that unbricking bit setting in my second 3ds... I bought a second obe with the intention on helping in the development of a "robust" unbricker/whatever...
Pls do! I'm just afraid is if that is possible then next step for gateway is to really delete or corrupt the nand contents lol which would fuck up anybody who doesn't have a nand backup :p
 
Pls do! I'm just afraid is if that is possible then next step for gateway is to really delete or corrupt the nand contents lol which would fuck up anybody who doesn't have a nand backup :p


Which is why anyone using a card or maybe other means of the exploit should backup their nand ( three or more times/copies ). Btw, has anyone compared gateway-made backups with wired nand read backups ? does anyone know if a gateway-made backup is ok to write via wired nand ? has anyone tried ?
 
Which is why anyone using a card or maybe other means of the exploit should backup their nand ( three or more times/copies ). Btw, has anyone compared gateway-made backups with wired nand read backups ? does anyone know if a gateway-made backup is ok to write via wired nand ? has anyone tried ?

Another user confirmed in a thread that flashing the nand backup made by gateway works.
Inaki I dont think that it will affect anything if I set the disable lock bit. Our code is very alpha atm, and sometimes it f*ck up, ryuga 'bricked' his sd card somehow when trying to set the temp_write_protect bit, and my arduino still didnt arive so we cant test our code anymore.
 
Another user confirmed in a thread that flashing the nand backup made by gateway works.
Inaki I dont think that it will affect anything if I set the disable lock bit. Our code is very alpha atm, and sometimes it f*ck up, ryuga 'bricked' his sd card somehow when trying to set the temp_write_protect bit, and my arduino still didnt arive so we cant test our code anymore.

I have a couple of arduinos at home one is a teensy one and then I have a mega 2560 also; they both have 1 or 2 io pins ruined though ( long story lol )...

I'd like to do tests with several microsd cards I have first. Maybe he broke the sdcard because of incorrect voltage levels :?
 
I have a couple of arduinos at home one is a teensy one and then I have a mega 2560 also; they both have 1 or 2 io pins ruined though ( long story lol )...

I'd like to do tests with several microsd cards I have first. Maybe he broke the sdcard because of incorrect voltage levels :?

Nah, it was correct voltage, he uses a SD shield with voltage dividers, the MBR got deleted somehow, or accidentally locked the card with cmd42.
 
I have a bricked 3ds and could buy an arduino to try the code.
I wouldn´t know what to fix though because I know nothing about programming.
But I would be glad to help anyway I can.
This is the thing I need?
http://articulo.mercadolibre.com.ar...-tarjetas-sd-micro-sd-spi-arduino-arm-pic-_JM

that is only the shield, you need the arduino board too (together they are around 15$, not a lot), and you need some soldering skills to solder 5 points on the card (SPI needs an extra wire on dat 3 for CS).
 

Site & Scene News

Popular threads in this forum