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

  • Thread starter Autz
  • Start date
  • Views 99,503
  • Replies 144
  • Likes 12

Have you bricked your 3DS with one of these?


  • Total voters
    277

vilator

Member
Newcomer
Joined
Aug 2, 2006
Messages
16
Trophies
0
XP
255
Country
hey kinda random question here, I tried soldering, gave up as I'm bad and decided to get a cart, I took off the wires but I left the two wires on the back of mobo connected, the cmd and data (I was lazy, probably should have just taken it off). I was having problems with soldering since I think I made the solder contact too big and had it crossed with gnd. So I put everything back together, 3ds boots fine, is it fine if I follow the guide now? or would the bad solder on the data or cmd point cause flashing problems?
 

Autz

Well-Known Member
OP
Member
Joined
Feb 18, 2016
Messages
575
Trophies
0
Age
27
XP
368
Country
Venezuela
Added brick when erasing sysNAND titles. Also, i modified the first one so it can apply to any kind of physical damage, even sending it directly to the sun.
 
  • Like
Reactions: Deleted User
D

Deleted User

Guest
Added brick when erasing sysNAND titles. Also, i modified the first one so it can apply to any kind of physical damage, even sending it directly to the sun.
ok
im gona now make the bare minimum nand
cuz ive been experimenting with the system and what titles it can work without
that rule can be more specific when im done, in 99999999999999999999999999 nand restores
ive got 3 titles so far that are not needed, cuz ive only done 3 so far XD
 

marazzmatika

Naive guy
Member
Joined
Jul 10, 2018
Messages
145
Trophies
0
XP
298
Country
Russia
I made this post for pure informative purposes. My goal here is not to scare someone which is new in all of this CFW stuff, but for people to evaluate possible risks to see if it is worth to do what they want to do (like migrating from MenuHax to A9LH, or A9LH to B9S).

There's certain considerations to take into account, and each varies on situations, but i will make a little summary of all that:

1.- double-check the requirements and steps of the tutorials.

2.- Always have a NAND backup with you.

3.- Always follow the tutorials step by step exactly as written. Don't skip anything on the subject.


If your console receives several hits, like punching it, let it fall, gunfire, place it underwater... his vital components will have several damages, and obviously resulting into a brick.

Let's suppose that you want to update/downgrade your sysNAND using SysUpdater. If your console is for example "EUR" and you install an "USA" cia pack, you will brick your console.

If you have a N3DS and you use files that meant to be used on O3DS (mainly update/downgrade stuff or NAND restore), you will brick your console.

Every process involving modification on sysNAND is *Extremely* delicated, so if you're doing something like a sysNAND downgrade or modifying some NAND titles and your console shuts down or interrupts the process somehow, your system will brick.

Sometimes you met all the requirements and needed care to do whatever you're going to do (IE: Arm9LoaderHax tutorial). But all these process not only relies on files or steps, but also of the quality of the tools you're using. So, if you're using a chinese SD copy or a bad quality SD card, it may appear some unexcepted error on the middle of a delicated process, resulting into a irremediable damage to your console.

This is self-explanatory. If your emuNAND is bricked, cloning it into sysNAND will have the same result.

Same as above. If your NAND backup is broken/corrupted somehow, and you use it to reflash the sysNAND, your console will brick for sure.

If your emuNAND has a modified Secure_info (mainly to elude the ban of the console or archaic region change method) and you clone it to sysNAND, or if you try to inject a modified Secure_info to sysNAND, it will be insta-brick. Can be fixed via Hardmod, but if you ended up without backups, your console will be bricked for life.

If you're doing a NAND injection (or whatever thing you're writing on the NAND) and the app you're using shows an error or a failiure message, don't reboot. If you have common sense, you will notice that on reboot, the 3DS will try to boot the OS. But since the injection has failed/corrupted somehow, it obviously won't boot because the system is corrupted. If you have A9LH then is not a problem, unless you're using programs that don't protect the firmo/firm1 partitions like Decrypt9. On those cases you will not only archieve a brick, but you will also loose the A9LH.

Back on 2014, a lot of 3DS got bricked thanks to an Gateway firmware (primary the 2.0b2 one) while checking configuration on emuNAND. What it does is that on some parts in the system settings menu, the sysNAND was being readed an writted even if isn't supposed to (The NAND redirection wasn't working on those scenarios on purpose). And given that insta-write on the sysNAND, the system will not recognize the NAND on the next reboot, and so, the result is the famous *BSOD*.

ir56s3.jpg


So, if you have a 3DS flashcart and is outdated: UPDATE IT. Also, the same thing can be archieved by using the emuNAND for what should not be used to, like configuring the whole 3DS system, or using Normmatt's region free patch

Let's suppose that you have an untouched 3DS with an old firmware ver. (like 9.x or less). And given the fact that is old, you may think to use old well-known tutorials to get into CFW, right? Well, no. A lot of things has changed on little time and most of the process have been optimized. So if you're going to use old tools from old tutorials, you're risking yourself to archieve a brick.

This is self-explanatory. If you don't have any knowledge on basic solding for Hardmod, don't insist, you'll be liked to break the entire console if you don't know what you're doing. The same thing can be archieved if you fail to restore your sysNAND if you got some short circuit, or your PC shuts down, or you format the NAND memory, or you go crazy and rip the NAND memory chip off the motherboard. The only solution for this is to buy another 3DS.

If you somehow managed to send weird or bad patterns to the LED via i2c, you will brick the i2c flash commands and thus, bricking the MCU an being unable to boot the system. This brick isn't recoverable even with Hardmod, so the only solution for this is to buy another console.

This is a softbrick since the sysNAND still works. If your 2DS is on a version below 6.x (mostly 4.x given the MSET exploit) and format your 2DS sysNAND on system settings, on reboot wil ask you to turn on the 3D, but since 2DS doesn't have that feature, you'll be stuck there. It is possible to get out of that inferno somehow with Recovery Mode.

If you're thinking to erase certain titles because they either take too much space or the CIA program like FBI doesn't show a proper description and stuff, don't do it please. 3DS's OS is a system, as it's name implies. And a system is made up of modules, files... Erasing any of such things will likely brick the system, because anything has a reason to exist there in the first place. Don't toy with it unless you want to see weird errors by yourself (and if you have a backup).


*A9LH RELATED*

As explained on the Arm9LoaderHax tutorials, every OTP is unique per console. So, using OTP's of another console, even if both consoles are virtually the same, for example, O3DS black "USA" CTR-001, you will screw up everything. The reason this bricks is because a hash of the OTP is used as the encryption key for ARM9Loader, so using the wrong OTP results in the wrong key. It can be fixed using a hardmod, assuming you have a working sysNAND backup.

If you have A9LH already installed, you will notice that there's two files that are inyected on the NAND: Stage 1 and 2. If you try to update one without the other, your system will brick. And since the A9LH wasn't updated properly, the Payloads won't work. You can solve it via Hardmod if you have a NAND dump with the A9LH installed.

Since there's no New console that officially supports versions lower than 4.x, updating via System Setting after the 2.1 downgrade will brick your console for sure. Why this bricks is because you're running a Old3DS-exclusive version, and if you try to update or format the system, it will act exactly as an O3DS would do, not as an N3DS.

After a heart attack to see if the downgrade to 2.1 was succesfull or not, you may think to have a good rest to continue another day, right? Well, that's a bad idea. There's a lot of reports that explain that leaving the new3DS on Sleep Mode will brick the console. Is actually the same kind of rror as above, so do the A9LH installation without delay!

As adviced on the github site, using dgTool with arm9loaderhax already installed is a very dumb move. For unexperienced users, dgTool is a required tool to downgrade the 3DS's NATIVE_FIRM to be possible to downgrade the system to 9.2. What it does is perform a write on firm0, which is a partition of the NAND where NATIVE_FIRM is located. However, since arm9loaderhax perform a write on firm0/firm1, using dgTool will "disable" arm9loaderhax, and therefore, your system won't boot because firm0 has garbage on it. Be smart and don't use it when is not needed.

After you have succesfully installed Arm9LoaderHax, you can finally relax and be happy to know that you won't see the Yellow-screen freeze of MenuHax, or you won't fear a NAND brick anymore. But of course, don't relax that much. Keep in mind that the Arm9Loader will work if you have the neccesary files on the SD (implying that you're not using the mini-CFW fork), so if you're messing up with the SD reader slot of the console (like pushing the SD card with brute force), the Arm9 will not do anything if it can't read the SD. The solution for this is to hardmod, but you won't be able to go into CFW again unless you buy a new console or fix the SD slot


*SigHax/Boot9Strap RELATED*

Sometimes cupcakes out of the oven doesn't taste that great. Derreck released a BETA installer of the recent advanced hack (up to this date) called SigHax. Thing is that his installer is somewhat unstable and his steps where followed for some bricks and users made an advice on it, so he recommended Hardmod just in case. Using his BETA installer when there's a better alternative out there called SafeB9Installer is a dumb move, so always be informed.

And so with this list, am i losing something?
Also,write about that near every brick here can be fixed using NTRBoot,so if you're hopeless about firmbricks try to boot into the bootrom with flashed cart
 

lAkdaOpeKA

Well-Known Member
Member
Joined
Feb 6, 2015
Messages
1,386
Trophies
0
XP
1,482
Country
Italy
Here's another one: using a DS Bricker (taihen or r0mloader) will mess up the NVRAM and brick the DS mode (can be only fixed by formatting or restoring an NVRAM backup which luckily isn't console-unique)
 
D

Deleted User

Guest
I bricked my 3ds by so many differents ways! xD My favorite is the blue screen by modifing the NAND.bin image in sysnand virtual :)
You really did that? If you did, did you fix it with ntrboot or hardmod?

--------------------- MERGED ---------------------------

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.
 
Last edited by ,

Site & Scene News

Popular threads in this forum

General chit-chat
Help Users
    SylverReZ @ SylverReZ: Hello @realtimesave.