Hacking List of possible ways to brick your 3DS/2DS/N3DS.

[KleinesSinchen]

[…]
If you delete the contents of the TWLNAND and then edit twlmbr.bin, then you will have a BSOD that can only be fixed by a hardmod.

No, just, no.

• This can be fixed with a hardmod – if a full backup image exists.
• If can be fixed with ntrboot (even without a backup to some degree).

Statements like this could make inexperienced people attempt unnecessary micro-soldering which can easily lead to frying the NAND.

Repairing (software based) 8046 BOOTROM ERROR should only be done with software methods (ntrboot).

Ntrboot method has been practically confirmed (beyond the theory) working for:

• Deleting all files from CTRNAND, TWLN with GodMode9 and removing B9S afterwards (booting to black screens)
• Overwriting twlmbr.bin with garbage data (showing 8046 BOOTROM ERROR)
• Overwriting FIRM0 and FIRM1 with garbage data (showing 8046 BOOTROM ERROR) → I did this one myself.
  
• Overwriting the complete NAND with garbage data (showing 8046 BOOTROM ERROR)

The first three examples are likely recoverable even without a backup (first one with data recovery software). The last one would be a case for Lazarus3DS leading to a suboptimal unbricking but somewhat working.

 

[Deleted User]

No, just, no.

• This can be fixed with a hardmod – if a full backup image exists.
• If can be fixed with ntrboot (even without a backup to some degree).

Statements like this could make inexperienced people attempt unnecessary micro-soldering which can easily lead to frying the NAND.

Repairing (software based) 8046 BOOTROM ERROR should only be done with software methods (ntrboot).

Ntrboot method has been practically confirmed (beyond the theory) working for:

• Deleting all files from CTRNAND, TWLN with GodMode9 and removing B9S afterwards (booting to black screens)
• Overwriting twlmbr.bin with garbage data (showing 8046 BOOTROM ERROR)
• Overwriting FIRM0 and FIRM1 with garbage data (showing 8046 BOOTROM ERROR) → I did this one myself.
  
• Overwriting the complete NAND with garbage data (showing 8046 BOOTROM ERROR)

The first three examples are likely recoverable even without a backup (first one with data recovery software). The last one would be a case for Lazarus3DS leading to a suboptimal unbricking but somewhat working.

I tested ntrboot on a bricked New 2DS XL that had been downgraded to 9.0 and then uninstalled CFW - it just wouldn't work. I thought it was because the contents of the TWLNAND had been erased, but you say otherwise. Since DS mode doesn't work with TWLNAND erased, then how could ntrboot work with TWLNAND erased, and if it does, then why doesn't it work for me?

 

[fmkid]

I tested ntrboot on a bricked New 2DS XL that had been downgraded to 9.0 and then uninstalled CFW - it just wouldn't work. I thought it was because the contents of the TWLNAND had been erased, but you say otherwise. Since DS mode doesn't work with TWLNAND erased, then how could ntrboot work with TWLNAND erased, and if it does, then why doesn't it work for me?

AFAIK, ntrboot doesn't nothing to see with TWLNAND (or TWL_FIRM), nor the entire NAND memory system, because is loaded by the bootrom (and depends exclusively from it).

 

[KleinesSinchen]

AFAIK, ntrboot doesn't nothing to see with TWLNAND (or TWL_FIRM), nor the entire NAND memory system, because is loaded by the bootrom (and depends exclusively from it).

Exactly. And this is well-documented.

I tested ntrboot on a bricked New 2DS XL that had been downgraded to 9.0 and then uninstalled CFW - it just wouldn't work. I thought it was because the contents of the TWLNAND had been erased, but you say otherwise. Since DS mode doesn't work with TWLNAND erased, then how could ntrboot work with TWLNAND erased, and if it does, then why doesn't it work for me?

===========================
This fits the original topic of the thread very fine. How to softbrick a N2DSXL?

• Downgrade N2DSXL to older than the special 11.4 that came with the first units of that model and uninstall CFW.

Why would anyone do this??
===========================

I hope it's not too much off-topic. The thread is about possible ways to brick. Why not elaborate a bit about the possibility to unbrick (ntrboot)?

An official repair method (Nintendo should have properly signed ntrboot carts) relying on contents on the softbricked NAND would not be very helpful.

Failing to ntrboot can have multiple reasons (that is really too much off-topic now) but it should even work when the NAND chip has been physically removed (desoldered). It works but sometimes ntrboot is tricky to pull off. I did it on my unmodified N2DSXL for getting the universal legit CIA of Mario Kart 7. That thing was stubborn as a mule and needed a dozen tries while I can pull off the trick on a N3DS on pretty much every try.

So let's see… https://www.3dbrew.org/wiki/Bootrom#Non-NAND_FIRM_boot says

Non-NAND FIRM boot
Boot9 can also boot from non-NAND. For this, a different set of RSA pubks are used(separate pubks for retail/devunit like NAND). The spiflash FIRM image for this is also encrypted with AES-CBC using a normal key stored in prot_boot9(separate for retail/devunit). This encryption is basically used instead of what is used for NAND-firm-partitions. This encryption is only used for the FIRM sections, the FIRM header is used raw. The AES keyslot for this is only overwritten afterwards when booting from non-NAND fails. AES keyslot 0x3F is used for this.


CTR_word[0] = firmimageoffset;//FIRM section offset from FIRM header
CTR_word[1] = outbufaddr;//FIRM section load addr
CTR_word[2] = readsize;//FIRM section size
CTR_word[3] = readsize;//FIRM section size

When booting from NAND fails, boot9 will then attempt to boot from Wifi SPI-flash(this only triggers when the wifi module hw is properly accessible/connected, which is normally the case). The base offset for spiflash FIRM is 0x400. Note that this region(all data prior to offset 0x1F300) is write-protected by the spiflash(not writable from 3DS-mode / DS-mode).

Additionally, if the shell is closed and a special key combination (Start + Select + X) is held, boot9 will attempt to boot from an inserted NTR cartridge before booting from NAND. Note: While normally on O3DS/2DS the console will not turn on if the shell is closed (or this is faked by holding a magnet to the console), when this special key combination is held holding down the power button will cause boot to occur anyway.

For non-NAND booting, NCSD / FIRM-backup is not used.

⇒No matter what nonsense somebody wrote to the NAND, ntrboot is the method of choice for undoing the damage. That is the theory… and as I explained in my previous post this theory has been verified. I know of no other gaming console where the modding community achieved this kind of brick-resistance and full system control milliseconds after power on independently from the actual operating system (maybe Fusée Gelée on early Switch models – but I know nothing about the Switch) .

 

[Deleted User]

S

Exactly. And this is well-documented.


===========================
This fits the original topic of the thread very fine. How to softbrick a N2DSXL?

• Downgrade N2DSXL to older than the special 11.4 that came with the first units of that model and uninstall CFW.

Why would anyone do this??
===========================

I hope it's not too much off-topic. The thread is about possible ways to brick. Why not elaborate a bit about the possibility to unbrick (ntrboot)?

An official repair method (Nintendo should have properly signed ntrboot carts) relying on contents on the softbricked NAND would not be very helpful.

Failing to ntrboot can have multiple reasons (that is really too much off-topic now) but it should even work when the NAND chip has been physically removed (desoldered). It works but sometimes ntrboot is tricky to pull off. I did it on my unmodified N2DSXL for getting the universal legit CIA of Mario Kart 7. That thing was stubborn as a mule and needed a dozen tries while I can pull off the trick on a N3DS on pretty much every try.

So let's see… https://www.3dbrew.org/wiki/Bootrom#Non-NAND_FIRM_boot says

⇒No matter what nonsense somebody wrote to the NAND, ntrboot is the method of choice for undoing the damage. That is the theory… and as I explained in my previous post this theory has been verified. I know of no other gaming console where the modding community achieved this kind of brick-resistance and full system control milliseconds after power on independently from the actual operating system (maybe Fusée Gelée on early Switch models – but I know nothing about the Switch) .

So how does it boot without the TWLFontTable file? If it can boot without it, then why does it need it to boot NTR carts normally?