In an effort to protect GBATemp.net users from bricking their 3DS(XL) systems, it was decided that a joint thread dedicated to any and all information regarding the issue will now be stuck to the front page until the matter is fully resolved. If you are interested in finding out more about how to prevent your system from bricking, how to recover it and which firmware is currently considered safe, you are kindly requested to follow the link below. The GBATemp.net Staff would like to sincerely thank all of the contributors whose articles, posts, guides and software were featured and remind all 3DS Mode flash cart users that: Gateway Firmware v2.0B1-2.0B2 R4i Gold 3DS Deluxe Firmware v3.0-3.3 3DS Link v3.0-3.3 Firmware Orange 3DS v3.0-3.3 Firmware …are considered *potentially dangerous* and may cause bricking (GW v2.0B2/Clone v3.2-3.3) or malfunction and save data loss (GW v2.0B1/Clone v3.0). Currently, if you do not have a NAND backup or an EmuNAND image, this brick is only reversible using a Raspberry Pi-based unbricker, which is why we urge you to spend a moment of your time familiarizing yourself with the F.A.Q. The GBATemp.net Staff wishes the userbase to be safe when operating flash carts and enjoy a smooth portal browsing experience, therefore we request users to refrain from creating threads aiding in speculation or concerning matters already discussed elsewhere - this includes threads about flash cart features, firmware release dates and other flash cart-related discussions. Please note that once official information hits, it will be promptly covered and put on the GBATemp.net portal. We understand that these are vital topics for some of you, but at the same time, we ask everyone to be patient for just a little bit longer. Please use the search feature found in the top right-hand corner of the forum from any page prior to posting. Should you be interested in any of those subjects, we suggest posting in the following discussion topics: For flash cart news, updates, and support, click here For queries comparing the features of 3DS flash chips, click here For everyday questions about flash chips, click here Thank you for your attention, we hope that your 3DS experience will be a safe one! Official GBATemp.net 3DS Bricking F.A.Q So What is this “Bricking” Business All About? Everything began with the initial report by a well-known scene developer crediar, who claimed that the Gateway Team included special “Bricking Code” in their 2.0B2 beta firmware, code which was subsequently copied in 3.2-3.3 clone firmware. Allegedly, this code compares checksums of the Launcher.dat file used with the checksums of the unaltered 2.0B2 firmware at random and upon detecting a mismatch it re-programs the eMMC controller to lock out NAND. This allegation was promptly confirmed by other scene developers, including mathieulh, profi200, yellows8, neimod and Normatt, however a different checksum check, one that refers to ARM9 code in memory, was claimed to be responsibile for bricking while the Launcher.dat checksum check merely prevented the exploit from executing - the latter was removed by Normatt in his firmware patch. The existence of this code is yet to be conclusively proven, however it does rise security concerns as systems of numerous users, including our reviewer Devin, have been bricked. Unfortunately, the bricking didn’t stop there. Apparently, the alleged “Bricking Code” had a second layer which activated once the timestamp on the Launcher.dat and/or other files on the SD card is later than February 4th 2014. This however does not seem to be a doomsday date, as we have the 24th of February today and we haven’t recorded another huge wave of bricked 3DS systems, perhaps due to the random factor in the equation. It would seem that using Gateway’s Diagnostic Tool greatly increases the risk of bricking the system. It is currently unknown whether this behavior is connected with the alleged "Bricking Code" or if it’s a separate glitch altogether. According to mathieulh, the reason why the Diagnostics Tool increases the bricking risk is because it uses Gateway-specific functionality, which in the rare event of failing triggers the alleged "Bricking Code". Whatever the reason behind the bricks may be, we strongly discourage the use of Gateway’s Diagnostics Tool for the time being on the basis the evidence collected by gamesquest1, which isn’t conclusive and does not explain why the bricks occur, but does rise safety concerns nonetheless. If you were affected by the brick wave, there's a possibility of unbricking the systems without a NAND backup with the use of a generated key. An anonymous source contacted the 3DSUnbricker developers and claimed that the bricks were caused by Gateway's failed attempt at AP. According to said source, the locking system uses a password generated using the console-specific eMMC CID encrypted using a Gateway masterkey. The source supplied the developers with the key necessary for unlocking the eMMC and they are currently hard at work coding a tool which will allow for unbricking all affected systems. This is so far the most damning of evidence for the existence of "Bricking Code" in Gateway's Firmware, as the possibility of this occuring accidentally is practically null. As of late, Gateway released a new line of firmware codenamed Omega, we have not observed any bricking cases since and a scene developer mathieulh claims that both v2.1 Omega and v2.2 Omega are free from the bricking code. gamesquest1 attempted to re-create the brick on Omega v2.1 and failed in doing so. Despite all this, other developers including Slashmolder and Bond697 disagree, saying that the bricking code was merely changed and is no longer as easily triggered as before. Alright, so Using 3DS Flash Carts isn’t Safe? The mechanism behind the bricks is not entirely understood at this point, but there is a number of ways in which you can protect your system from being affected as well as nullify the damage in the unlikely event of a brick. First and foremost, the GBATemp.net staff strongly encourages to revert to stable firmware, which are as follows: Gateway 3DS – Firmware v1.2 R4i Gold 3DS Deluxe – Firmware v2.0 3DS-Link – Firmware v2.0 Orange-3DS – Firmware v2.0 MT-Card – Firmware v1.0 Take note that we do not recommend using Gateway Firmware 2.0B1 and clone firmware 3.0 for everyday use – this is due to an unconfirmed, isolated case of bricking, but more so due to firmware stability concerns. It has been noted that beta firmware and its derivatives are responsible for loss of save file data, prone to freeze and highly unstable. For the safety of your system and data, we strongly urge our users to use earlier firmware. Unfortunately, due to a DMCA notice we've received, we are unable to host the recommended firmware or link to it on our website - we apologize for the inconvenience and hope that downloading them will not be an issue. Secondly, it is gravely important that you perform a NAND backup of your system and store it safely. A full NAND backup can be performed in two ways, either by fashioning a NAND dumping kit or by using the NAND Backup feature. My System is Bricked, What Now? First of all, don’t panic. It's not the end of the world and you will be assisted in recovering your system to the best of the Community's abilities. Start off from informing your flash cart manufacturer about the issue. Be as descriptive as possible - this will help firmware developers in narrowing down the issue and ironing it out in future releases, or at the very least, it will prompt them to act. Once you've done that, please, post your story in our collective 3DS Bricking Report thread - this allows us to assert the scale of the issue. With all said and done, you can progress to the important part - recovering your affected system. Thanks to GBATemp users krisztian1997, ryuga93, bkifft and inian we now have two confirmed methods of unbricking affected systems with the use of an Arduino or a Raspberry Pi. At current, the procedure requires a NAND backup or an EmuNAND image, but a method which does not require them is in development - the Raspberry Pi Unbricker is already capable on unlocking the eMMC. If you're one of the lucky Raspberry Pi users, you can follow this video guide by gamesquest1 to unbrick your system without the use of a backup NAND image. In other cases, the pre-requisites for the re-flashing operation are as follows: A NAND backup for your system. An EmuNAND image can also be used for recovery. Take note that backups from other systems are not usable! (Does not apply when using the new Raspbery Pi eMMC unlocking method) A soldered connection to the system’s NAND An Arduino/Raspberry Pi respectively 3DSUnbricker, which can be found on the respective GitHub repositories The pin-outs and instructions on how to connect to the NAND module for each system are available in the respective NAND Dumper threads: (3DS) NAND Dumping Tutorial and Pin-Out (3DS XL) NAND Dumping Tutorial and Pin-Out For instructions on how to reflash your NAND, please read the unbricking threadcarefuly. This modification is requires extreme precision – we do not recommend performing it if you’re a newbie. If you doubt your own abilities as far as soldering is concerned, we urge you to post in the respective threads before attempting to perform it. Perhaps some of the kind GBATemp.net users will assist you in unbricking your system safetly – don’t jump into it head first! That’s All There is to it, Folks! We hope that the information found in this F.A.Q will help you in keeping your 3DS(XL) systems safe and sound. This thread will be periodically updated with new information, so hop in whenever you’re in doubt – you know what they say, better safe than sorry! If you think that the article is incomplete, inaccurate or if you believe that you have vital information that could improve it, please post your comments below - we'll look through each and every one! Thank you for your attention!