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.
*A9LH RELATED*
*SigHax/Boot9Strap RELATED*
And so with this list, am i losing something?
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*.
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
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?
Last edited by Autz,
