# Official GBATemp.net Flash Cart Safety F.A.Q



## Foxi4 (Feb 24, 2014)

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!

[prebreak]Continue Reading[/prebreak]
*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!


----------



## Vengenceonu (Feb 24, 2014)

I thought we already established 2.0b1 was safe? Since when is it "potentially dangerous"?


----------



## Foxi4 (Feb 24, 2014)

Vengenceonu said:


> I thought we already established 2.0b1 was safe? Since when is it "potentially dangerous"?


The firmware has a tendency to freeze and may cause data loss - there have been numerous reports of losing save files irreversibly, as well as one report of an alleged 2.0B1 brick. It's an unstable Beta firmware, which is why it's not officially recommended or endorsed for everyday use. It's unlikely to cause a brick, but for the safety of our users, stable firmware is recommended instead.


----------



## Reploid (Feb 24, 2014)

MT card can be bricky too? I tgouht in wasn't a clone. Stupid GW, made everything go to hell just when things started to get intresting.


----------



## Foxi4 (Feb 24, 2014)

Reploid said:


> MT card can be bricky too? I tgouht in wasn't a clone. Stupid GW, made everything go to hell just when things started to get intresting.


MT-Card's firmware is based on GW Firmware v1.2, it's safe to use, which is why it's highlighted in green. There haven't been any reported cases of MT-Card bricks - you're safe and sound on MT Firmware v1.0.


----------



## codezer0 (Feb 24, 2014)

What should I do? I'm expecting a Gateway 3DS... as I desperately need both the emuNAND functionality, and specifically, the ability to support system transfer from my standard 3DS.


----------



## Foxi4 (Feb 24, 2014)

codezer0 said:


> What should I do? I'm expecting a Gateway 3DS... as I desperately need both the emuNAND functionality, and specifically, the ability to support system transfer from my standard 3DS.


emuNAND has been introduced in the GW Firmware 2.0B1 which is highly unlikely to cause a brick _(only one case with no evidence to support it)_, however it is finicky, moody, may freeze and corrupt save files. You can either use that, backup your saves often and _"risk it" _or wait for a new firmware from Gateway.


----------



## codezer0 (Feb 24, 2014)

Yes, though it is my understanding, that  _only_ 2.0b2 currently supports the underpinnings for successful System Transfers.


----------



## Foxi4 (Feb 24, 2014)

codezer0 said:


> Yes, though it is my understanding, that _only_ 2.0b2 currently supports the underpinnings for successful System Transfers.


Bummer. Well, in that case, I guess we'll all just have to wait for GW v2.0 stable. I'm sorry to hear about your problem, I wish I could assist you further.


----------



## anhminh (Feb 24, 2014)

I and many people out there still stick with 2.0b2 because it work normally and because we fear that when we downgrade the worst thing can happen.


----------



## Foxi4 (Feb 24, 2014)

anhminh said:


> I and many people out there still stick with 2.0b2 because it work normally and because we fear that when we downgrade the worst thing can happen.


You're really playing with fire here - there's a lot of documented 2.0B2 brick cases as of today, so please, do heed the warning.


----------



## Ryukouki (Feb 24, 2014)

I definitely agree with Foxi here, that's a risky move. Just because you're safe today, or tomorrow, how about two days from now? A week from now? When I look at it, the risks of losing my 3DS console far outweigh a few meager features that the beta firmware offers. 

As far as this guide, way to go Foxi.


----------



## tHciNc (Feb 24, 2014)

Its weird that all the users that DGAF and still use 2b2 have had no issues, i must have had 100 power downs since it came out 2 months ago, multiple black screens that needed power downs, heaps of looping gw mode to sysnand etc and never a fear of a issue, maybe im nieve, but then again, i havent ever used or needed diagnostics in 6+ months, and if my stupidity backfires, nothing that a few minutes soldering cant fix, also weird the team couldnt replicate the bricking themselves, hence them saying its only clones..


----------



## sergster1 (Feb 24, 2014)

tHciNc said:


> Its weird that all the users that DGAF and still use 2b2 have had no issues, i must have had 100 power downs since it came out 2 months ago, multiple black screens that needed power downs, heaps of looping gw mode to sysnand etc and never a fear of a issue, maybe im nieve, but then again, i havent ever used or needed diagnostics in 6+ months, and if my stupidity backfires, nothing that a few minutes soldering cant fix, also weird the team couldnt replicate the bricking themselves, hence them saying its only clones..


 

Well when a reputable REVIEWER from GBATemp gets a brick on a legit console you should heed the warning and downgrade.


----------



## R4iFanboi (Feb 24, 2014)

Excellent guide/FAQs Foxi4

Your tone in writing is very nice and humble and that makes reading more enjoyable! Good job and keep up the good work.


----------



## leeksausage (Feb 24, 2014)

Is downgrading GW from 2.0B1 (or 2.0B2) as simple as replacing the Launcher.dat on the SD card of do you need to format or run the blue cart again?
Some advice on this process would be very welcome =)


----------



## Foxi4 (Feb 24, 2014)

R4iFanboi said:


> Excellent guide/FAQs Foxi4
> Your tone in writing is very nice and humble and that makes reading more enjoyable! Good job and keep up the good work.


Thanks! The safety of our users is a priority for us, but at the same time, we don't want to come across as boorish. 


leeksausage said:


> Is downgrading GW from 2.0B1 (or 2.0B2) as simple as replacing the Launcher.dat on the SD card of do you need to format or run the blue cart again?
> Some advice on this process would be very welcome =)


I do believe that the downgrade process works exactly the same as the upgrade process - follow the installation manual found in the Release and you should be golden.


----------



## The Real Jdbye (Feb 24, 2014)

profi200 has mentioned that there is no bricking code in Gateway 2.0b1, so this info is not entirely accurate.
I myself am using 2.0b1 along with most people who don't want to risk a brick, and have had no trouble.


----------



## Foxi4 (Feb 24, 2014)

The Real Jdbye said:


> profi200 has mentioned that there is no bricking code in Gateway 2.0b1, so this info is not entirely accurate.
> I myself am using 2.0b1 along with most people who don't want to risk a brick, and have had no trouble.


The F.A.Q specifically mentions that 2.0B1 and its clone derrivatives are discouraged not necessarily because of the possibility of bricking but because of its instability. It's not recommended due to all the reports of lost save files, freezing and other malfunctions of the firmware.


----------



## The Real Jdbye (Feb 24, 2014)

Foxi4 said:


> The F.A.Q specifically mentions that 2.0B1 and its clone derrivatives are discouraged not necessarily because of the possibility of bricking but because of its instability. It's not recommended due to all the reports of lost save files, freezing and other malfunctions of the firmware.


But it's posted in a topic called "Official GBAtemp.net 3DS Bricking F.A.Q" which is rather misleading. And is there any evidence that 1.2 doesn't have those problems?


----------



## Foxi4 (Feb 24, 2014)

The Real Jdbye said:


> But it's posted in a topic called "Official GBAtemp.net 3DS Bricking F.A.Q" which is rather misleading. And is there any evidence that 1.2 doesn't have those problems?


Hours of testing and no complaints about lost saves until 2.0B1 came along are convincing enough for me to make this assumption, but just for you, I've clarified it a little bit further:


> 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*
> ...


This F.A.Q isn't only about the bricks, it's also a set of general recommendation on what's considered officially safe and what isn't. I suppose that _"GBATemp.net's Flash Cart Safety F.A.Q"_ is a better title. I hope that settles it.


----------



## Runehasa (Feb 24, 2014)

Good guide much needed at this stage of the game


----------



## Satangel (Feb 24, 2014)

THIS is where GBAtemp shines, very nice work and so easy to work with. Well done to everyone involved!


----------



## alexenochs (Feb 24, 2014)

You should add in the FAQ somewhere that if someone absolutely must run 2.02b that they should avoid the diagnostics feature at all costs as its been tested by users here and seems to be a contributer and maybe even the cause of all bricks


----------



## Foxi4 (Feb 24, 2014)

alexenochs said:


> You should add in the FAQ somewhere that if someone absolutely must run 2.02b that they should avoid the diagnostics feature at all costs as its been tested by users here and seems to be a contributer and maybe even the cause of all bricks


It's... already in there - you must've missed it. 


> As of late, another problem popped up. 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.


It's definitely not the cause of all bricks though, it merely increases the risk. 2.0B2/3.2-3.3 should not be used anyways.


----------



## Cyan (Feb 24, 2014)

Nice guide, thanks for writing it and posting on the portal to help and cover as many of users as possible.

Just two things I don't agree with, but it's only technical informations which end users may not care :


> 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 set NAND capacity to 0 bytes and then locks out completely.


1. it's not the Launcher.dat which is checked, but arm in memory. (There's a Launcher.dat checksum, but it's there to prevent running the exploit at all, not part of the bricking process. This is what has been patched by Normmatt to launch his modified version)
2. there's only a lock, the size isn't affected or changed to 0.

Of course, it's only information I gathered reading posts on the forum. some info may be right or wrong.


----------



## Foxi4 (Feb 24, 2014)

Cyan said:


> Nice guide, thanks for writing it and posting on the portal to help and cover as many of users as possible.
> 
> Just two things I don't agree with, but it's only technical informations which end users may not care :
> 
> ...


Ad.1 - I'm merely going by what crediar stated in his post, later posts by profi200, yellows8 and mathieulh neimod clarify that. At this stage it's all assumptions anyways, but I'll add some additional information about the checksum being over ARM9.

Ad.2 - this is actually something I've read elsewhere. If the NAND was merely _"locked"_, wouldn't it be akin to locking an SD card/USB stick flash memory, aka, can be read but can't be written to?


----------



## kyogre123 (Feb 24, 2014)

For people who want to do a System Transfer (or just use 2.0b2 for any purpose) and don't trust that the bricking issue is only related to the Diagnostic Test, you can do the following:

1. Use GW 2.0b1 to do a NAND backup. Store it in a safe place.
2. Create the emuNAND using GW2.0b1.
3. Load anything in DS mode to nullify the DS Profile hack.
4. Change the date of the System to 23 December 2013.
5. Replace the launcher.dat file of GW2.0b1 for GW2.0b2
6. Download and install Moo0 TimeStamp. This program can be used to change the timestamp of all the files in the SD card of your 3DS to somewhere around 23 December 2013. The timestamp of launcher.dat doesn't need to be modified.
7. Reapply the GW Installer and enjoy GW2.0b2.
8. Everytime you exit emuNAND, make sure to turn off your 3DS and check the timestamp of the files of the SD card to see if there are changes; if some files appear to have a timestamp of 2014, repeat step 6.

And that's all. Just take in account that I can't prove that this method is bricking proof, so you must be aware that there's still a risk that the brick could happen.


----------



## Cyan (Feb 24, 2014)

I'm not sure, I'll have to read the unbricking thread again. But I think doing only the lock gets the same result.
Like I said, it's only technical, the end result is the same : size is reported as 0bit.


Maybe you could add to the guide that users who bricked but don't have a NAND backup, but are using EmuNAND can use EmuNAND_tool to restore the 3DS.


kyogre123:
Only timestamp of files starting with the letter "l" are checked against the 4th feb 2014.
The date check of the file is not what did the brick. People started bricking in January.

You can do a "Prepare EmuNAND" to fully delete the SD card, and it will create a new/clean Launcher.dat file *without* any timestamp.
I think you can then copy any file with the same name to the card, it will not have a time stamp either. (need to be verified, but I think you can replace the file without updating the timestamp)


----------



## kyogre123 (Feb 24, 2014)

Cyan said:


> kyogre123:
> Only timestamp of files starting with the letter "l" are checked against the 4th feb 2014.
> 
> You can do a "Prepare EmuNAND" to fully delete the SD card, and it will create a new/clean Launcher.dat file *without* any timestamp.


 
I'm not going by what the "trusted hackers" have said, but by what the reports have shown so far.

This is how we discovered that *possibly* the only thing causing the bricks is the Diagnostic Test and gamesquest1 confirmed that, while having every file in the SD with timestamps lower than 2014, not even the Diagnostic Tool was able to brick his system.


----------



## Cyan (Feb 24, 2014)

Ah, I didn't see this tests yet, I have to catch what I didn't read while being at work.


----------



## Foxi4 (Feb 24, 2014)

Cyan said:


> I'm not sure, I'll have to read the unbricking thread again. But I think doing only the lock gets the same result.
> 
> Like I said, it's only technical, the end result is the same : size is reported as 0bit.
> 
> Maybe you could add to the guide that users who bricked but don't have a NAND backup, but are using EmuNAND can use EmuNAND_tool to restore the 3DS.


I'll implement both edits now, thanks. 


kyogre123 said:


> This is how we discovered that *possibly* the only thing causing the bricks is the Diagnostic Test and gamesquest1 confirmed that, while having every file in the SD with timestamps lower than 2014, not even the Diagnostic Tool was able to brick his system.


This is _false_, as explained by mathieulh. The reason why the Diagnostics Test causes more bricks is because it uses Gateway-specific features prominently - bricks _may still occur without ever using it!_


----------



## kyogre123 (Feb 24, 2014)

Foxi4 said:


> This is _false_, as explained by mathieulh. The reason why the Diagnostics Test causes more bricks is because it uses Gateway-specific features prominently - bricks _may still occur without ever using it!_


 
It's not false, reread what I said...


----------



## Foxi4 (Feb 24, 2014)

kyogre123 said:


> It's not false, reread what I said...


You said that it's _possibility_ the only thing that causes bricks - it's not. The frequency of bricks is connected with something else entirely. I'm only underlining that because we don't want people to use 2.0B2 under the false assumption that they're safe as long as they're not using the Diagnostics Tool.


----------



## kyogre123 (Feb 24, 2014)

Foxi4 said:


> You said that it's _possibility_ the only thing that causes bricks - it's not. The frequency of bricks is connected with something else entirely. I'm only underlining that because we don't want people to use 2.0B2 under the false assumption that they're safe as long as they're not using the Diagnostics Tool.


 
That's why I put the disclaimer in my other post, but we can't really say "it's false"; also, the word "possibly" even implies that there's a chance that a brick can occur (just because we will never be certain of anything). Mathieulh was the first (and only if I recall correctly) that said that the chance the GW's laucher could cause a bricks were extremely low, you should consider that.


----------



## Foxi4 (Feb 24, 2014)

kyogre123 said:


> That's why I put the disclaimer in my other post, but we can't really say "it's false"; also, the word "possibly" even implies that there's a chance that a brick can occur (just because we will never be certain of anything). Mathieulh was the first (and only if I recall correctly) that said that the chance the GW's laucher could cause a bricks were extremely low, you should consider that.


_"Low"_ is still a risk. That's like saying that walking around a minefield is relatively safe because _"what are the chances" _- it's not safe, even if one in a million 3DS'es bricks.


----------



## kyogre123 (Feb 24, 2014)

Foxi4 said:


> _"Low"_ is still a risk. That's like saying that walking around a minefield is relatively safe because _"what are the chances" _- it's not safe, even if one in a million 3DS'es bricks.


 
That's as safe as updating the 3DS... so you would say "don't update your 3DS because there's a small possibility it could get bricked? I don't think so and that's my point.


----------



## Foxi4 (Feb 24, 2014)

kyogre123 said:


> That's as safe as updating the 3DS... so you would say "don't update your 3DS because there's a small possibility it could get bricked? I don't think so and that's my point.


Yeah, no. We don't seem to have an understanding here - the thing with _randomness_ is that it's _random_ - you could get zero bricks in 100 tests, but it's equally likely that you'll get 100 bricks - it's like a coin toss, and we're not going to recommend using a firmware that can brick your system at random chance.


----------



## Qtis (Feb 24, 2014)

kyogre123 said:


> That's as safe as updating the 3DS... so you would say "don't update your 3DS because there's a small possibility it could get bricked? I don't think so and that's my point.


 
I'd imagine Nintendo would replace your bricked console if their update was causing it.

In the case of the Gateway&Co, you're on your own. At most you can restore your console to the pre-brick state, but not everyone has that chance, let alone the required hardware. Also ordering all required parts for the *hardware mod* to get a restored console takes a while and quite a few $$.


----------



## kyogre123 (Feb 24, 2014)

Foxi4 said:


> Yeah, no. We don't seem to have an understanding here - the thing with _randomness_ is that it's _random_ - you could get zero bricks in 100 tests, but it's equally likely that you'll get 100 bricks - it's like a coin toss, and we're not going to recommend using a firmware that can brick your system due to random chance.


 
I think you have twisted the original idea...

At first I just posted a steps to make an even more safe environment for those who want to use GW2.0b2, as I have been doing that and also gamesquest1 test (surprisingly for me) confirmed this idea. In this same "guide" I clarified that there may be a chance that a brick can occur, so any person who would be willing to try that would be aware of the possibility of the risk.

Then, Cyan didn't know why I said that so I explained that this is according to the reports of bricks and the tests made by gamequest1. The I still don't understand the reason of your first reply but here we are. And just in case, I remark, I already posted a disclaimer saying that there's still a possibility simply because we can't be certain, so anyone willing to give it a try should be aware of it.



Qtis said:


> I'd imagine Nintendo would replace your bricked console if their update was causing it.
> 
> In the case of the Gateway&Co, you're on your own. At most you can restore your console to the pre-brick state, but not everyone has that chance, let alone the required hardware. Also ordering all required parts for the *hardware mod* to get a restored console takes a while and quite a few $$.


 
That's a good point of view, but that was not the original idea so I would thank you all if you could stop derailing it...


----------



## Foxi4 (Feb 24, 2014)

kyogre123 said:


> _*Snip!*_


Fair enough, we understood what you meant. All we're saying is that using 2.0B2 is _discouraged_, no matter what safety measures the user will undertake. At the end of the day, it's the end user's choice - we're merely discouraging unsafe firmware.


----------



## Yepi69 (Feb 24, 2014)

Or just don't buy a flashcart at all for the time being, we know the risks, no sense into buying something that can potentially wreck your system beyond warranty with something so new that it wasn't perfected yet.


----------



## kyogre123 (Feb 24, 2014)

We could also simply don't buy any gaming console so there will be nothing to brick


----------



## mechagouki (Feb 25, 2014)

The FAQ twice mentions a device called an ARUDINO that can be used for unbricking. I can't seem to find this device for sale anywhere on the internet. Would it be possible to modify an ARDUINO to serve the same purpose?


----------



## Foxi4 (Feb 25, 2014)

mechagouki said:


> The FAQ twice mentions a device called an ARUDINO that can be used for unbricking. I can't seem to find this device for sale anywhere on the internet. Would it be possible to modify an ARDUINO to serve the same purpose?


This is actually a mistake on my part - I always misspell Arduino for some reason. Well-spotted, the name was now corrected in the F.A.Q.


----------



## Shinitai (Feb 25, 2014)

Hey man, thanks for writing this. Just one thing:


Foxi4 said:


> however the checksums check responsibile for bricking was said to refer to ARM9 code in memory 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.


I'm having trouble understanding this.
What I'm getting is that there are two checksum checks. One of them checks the Launcher.dat checksum, and prevents the exploit from executing (and thus the system from entering "Gateway mode") if it fails. The other one checks something else (ARM9 code in memory?) and bricks the system if it fails.
Is that right?


----------



## Cyan (Feb 25, 2014)

that's right.
The memory check is an additional check in place "in case Clone teams disable the checksum check to alter the Launcher.dat", added in 2.0b2.
it was meant to brick clone user's console, because Gateway team don't like Clone team stealing their work (Clone team only replace the "Gateway" string to "R4i", patch the file's checkum function, and release it as their own, making money on Gateway's work).

Like they did previously, on 2.0b2 release the Clone team patched the Name's string and the file's checksum, without analyzing the other/newer functions, and released it with the bricking check code activated.
The Gateway team waited quietly for the brick wave which should have been caused by the clones, to tell users that "clones team should not be trusted", but it backfired at them because it was discovered that they purposely included the bricking code and it affected even legit Gateway users.


----------



## Arras (Feb 25, 2014)

mechagouki said:


> The FAQ twice mentions a device called an ARUDINO that can be used for unbricking. I can't seem to find this device for sale anywhere on the internet. Would it be possible to modify an ARDUINO to serve the same purpose?


Scratching the name and writing ARUDINO on it probably works


----------



## Foxi4 (Feb 26, 2014)

Shinitai said:


> Hey man, thanks for writing this. Just one thing:
> 
> I'm having trouble understanding this.
> What I'm getting is that there are two checksum checks. One of them checks the Launcher.dat checksum, and prevents the exploit from executing (and thus the system from entering "Gateway mode") if it fails. The other one checks something else (ARM9 code in memory?) and bricks the system if it fails.
> Is that right?


That's correct, see above. I've clarified the sentence so that it's clear that there are in fact two implemented checks. I also added gamesquest1's new unbricking video tutorial.


----------



## irondoom (Feb 26, 2014)

I tried to downgrade to 1.2 but for some reasons it did not see my save games (both ocarina zelda and bravely default). I verified that save games were still on the 3DS SD card (and backed up on my PC). They were on the card, but the ROM wanted to make new save files for both games.

I put the gateway version back to 2.0B2 and it sees the save games again. I am not too worried about brick because I have made NAND backups, and did soldering for awhile, and have arduino already from other projects. So its not too big a thing if i hit a brick, but I would still prefer to avoid it.

So I want to use 1.2, but only if I can downgrade from 2.0b2 without losing my saves. I don't see why it would be a problem, but when I downgraded it would not see the saves on the SD card. Just wondering can anyone confirm they did a downgrade and did not lose their saves to these games? Most especially concerned about Bravely Default and Shin Megami IV as I have most amount of hours in those two.


----------



## Foxi4 (Feb 26, 2014)

irondoom Unfortunately, 1.2 is not compatible with the 2.0 save format. You may be able to downgrade to the safer 2.0B1 without losing progress, however make sure that you backup all your saves as the firmware is unstable and may corrupt them. That would be the recommended course of action in my opinion, sorry to hear about the inconvenience.


----------



## Shinitai (Feb 26, 2014)

Cyan said:


> that's right.
> The memory check is an additional check in place "in case Clone teams disable the checksum check to alter the Launcher.dat", added in 2.0b2.
> it was meant to brick clone user's console, because Gateway team don't like Clone team stealing their work (Clone team only replace the "Gateway" string to "R4i", patch the file's checkum function, and release it as their own, making money on Gateway's work).
> 
> ...


So 2.0b1 already had the Launcher.dat checksum verification and the bricking function, and an additional one was included in 2.0b2? And I'm guessing the second one is buggy, and that's why all legit bricks happened to people using 2.0b2 (except for the one person who reported a brick on 2.0b1)?
If that's the case, do earlier versions like 1.2 have any verification/bricking function at all?


Also, on another note, what the hell with the savegame incompatibilities? Jesus. Why would there ever be more than one savegame format? Breaks my heart.


----------



## Foxi4 (Feb 26, 2014)

Shinitai said:


> So 2.0b1 already had the Launcher.dat checksum verification and the bricking function, and an additional one was included in 2.0b2? And I'm guessing the second one is buggy, and that's why all legit bricks happened to people using 2.0b2 (except for the one person who reported a brick on 2.0b1)?
> If that's the case, do earlier versions like 1.2 have any verification/bricking function at all?
> 
> 
> Also, on another note, what the hell with the savegame incompatibilities? Jesus. Why would there ever be more than one savegame format? Breaks my heart.


2.0B1 and 1.2 are confirmed to be free of the bricking code, the reason why 1.2 is endorsed is its stability. The reasons for a new save file format is a matter of compatibility with newer games, I'd wager.


----------



## Shinitai (Feb 26, 2014)

Right, my bad. 2.0b1 had the verification but instead of bricking the console, the exploit just fails to run if the verification fails. Then a second verification was added in 2.0b2 along with the bricking code. Is that right?

The savegame format thing doesn't make sense to me. As far as I know, the format is actually decided by the game developer and can be whatever the hell they want, so it's usually different for each game. I don't see how Gateway could have a say on it.


----------



## Foxi4 (Feb 26, 2014)

Shinitai said:


> Right, my bad. 2.0b1 had the verification but instead of bricking the console, the exploit just fails to run if the verification fails. Then a second verification was added in 2.0b2 along with the bricking code. Is that right?
> 
> The savegame format thing doesn't make sense to me. As far as I know, the format is actually decided by the game developer and can be whatever the hell they want, so it's usually different for each game. I don't see how Gateway could have a say on it.


Both checksum checks were added in 2.0B2, 2.0B1 is clean but terribly unstable. Gateway does have a say because the save files are not handled exactly the same as on retail cartridges - they're handled by Gateway's firmware. Substantial changes to the loading mechanism necessitate a change of formats sometimes.


----------



## J. Sinclair (Feb 26, 2014)

Foxi4 said:


> Both checksum checks were added in 2.0B2, 2.0B1 is clean but terribly unstable. Gateway does have a say because the save files are not handled exactly the same as on retail cartridges - they're handled by Gateway's firmware. Substantial changes to the loading mechanism necessitate a change of formats sometimes.


 
Right, but I thought that it was not brick code but rather a bug or a problem with the code where if you ran GW Diagnostics and then booted into Gateway mode it would brick the console.
I'm may be wrong in thinking this, but is that a possibility? That it's just a bug, gone rouge?

Also have a quick question about the youtube app and GW.
My system froze when I tried to view a video. It would not let me do anything, so I held the power button down until it died. Then when powering on again, after I selected "Boot GW Mode" it froze on a black screen again. Tried doing it once more but in Classic mode and then it came back. After that it worked to boot in GW mode.
Anyone know what and why this happened?


----------



## Shinitai (Feb 26, 2014)

Foxi4 said:


> Both checksum checks were added in 2.0B2, 2.0B1 is clean but terribly unstable. Gateway does have a say because the save files are not handled exactly the same as on retail cartridges - they're handled by Gateway's firmware. Substantial changes to the loading mechanism necessitate a change of formats sometimes.


That's what I thought, but Cyan's post seems to imply that 2.0b1 had a check and a second one was added for 2.0b2.


----------



## Foxi4 (Feb 26, 2014)

J. Sinclair said:


> Right, but I thought that it was not brick code but rather a bug or a problem with the code where if you ran GW Diagnostics and then booted into Gateway mode it would brick the console.
> I'm may be wrong in thinking this, but is that a possibility? That it's just a bug, gone rouge?
> 
> Also have a quick question about the youtube app and GW.
> ...


With the recent developments in mind, I find it unlikely that the bricks resulting from the use of the Diagnostics Tool aren't connected with the brick code. mathieulh's theory about how the bricks are more frequent due to intense use of Gateway-specific functionality by the tool is far more likely. If these bricks were unrelated to the bricking code, they wouldn't be magically fixable by using the same unlocking key generated using the GW master key.

Your 3DS likely closed because the Youtube app is simply buggy. The GW launcher could freeze to a black screen due to a simple glitch or due to some remnants of information in memory which prevented it from passing the ARM checksum test phase - I don't think it's a reason for concern.



Shinitai said:


> That's what I thought, but Cyan's post seems to imply that 2.0b1 had a check and a second one was added for 2.0b2.


I'll let Cyan clarify that, as I'm not sure myself. The first check isn't malicious so it had little bearing to system safety, so I didn't really dig into that subject too deeply.  Going by what crediar stated in his original warning, the firmware checksum check was implemented in 2.02B.


----------



## Costello (Feb 27, 2014)

I am unstickying this thread from the homepage (been days now) to leave room for other news 
Foxi4


----------



## Foxi4 (Feb 27, 2014)

Costello said:


> I am unstickying this thread from the homepage (been days now) to leave room for other news
> Foxi4


Fair enough - with the Gateway master key out and about, I think everyone's made up their mind about the situation anyways and with unbrickers around, the situation can be considered more or less resolved.


----------



## codezer0 (Feb 27, 2014)

Foxi4 said:


> Fair enough - with the Gateway master key out and about, I think everyone's made up their mind about the situation anyways and with unbrickers around, the situation can be considered more or less resolved.


Wait, what?!


----------



## Cyan (Feb 27, 2014)

The masterkey is out?
I didn't read the news for the last two days. If we can now unlock instead of reseting and reflashing a backup, that's a great news.


----------



## Foxi4 (Feb 28, 2014)

codezer0 said:


> Wait, what?!





Cyan said:


> The masterkey is out?
> I didn't read the news for the last two days. If we can now unlock instead of reseting and reflashing a backup, that's a great news.


Pretty much. Long story short, the key's out and unlocking is possible using the Raspberry Pi kit _(the Arduino kit will follow suit, the code is currently being tested)._ It's not just a simple unlock though - in addition to locking the NAND, the bricking code also disabled writing capabilities. This is why a workaround has been implemented - the unbricker unlocks the NAND, dumps its contents, cleans it with a force erase which re-enables writing capabilities and flashes it with the image it just dumped.


----------



## PROTOBOY (Mar 4, 2014)

Thanks


----------



## Foxi4 (May 11, 2014)

Thread has been slightly updated with information regarding Gateway Omega 2.1 and 2.2 which are currently the recommended Gateway firmwares and are said to be free of the bricking code according to mathieulh. It still requires a facelift, but it will do for now.


----------



## Vengenceonu (May 11, 2014)

Foxi4 said:


> Thread has been slightly updated with information regarding Gateway Omega 2.1 and 2.2 which are currently the recommended Gateway firmwares and are said to be free of the bricking code according to mathieulh. It still requires a facelift, but it will do for now.


 
You forgot to edit the MT-card info. It still says only v.1.0 is the only safe version for it.


----------



## Foxi4 (May 11, 2014)

Vengenceonu said:


> You forgot to edit the MT-card info. It still says only v.1.0 is the only safe version for it.


I'm not a 100% sure if v1.2 is copy-pasted from Gateway or not so I haven't, I didn't miss it, it was intentional. There haven't been any reported bricks on v1.2, but I don't see anyone actively checking the firmware for brick code either.


----------



## Vengenceonu (May 11, 2014)

Foxi4 said:


> I'm not a 100% sure if v1.2 is copy-pasted from Gateway or not so I haven't, I didn't miss it, it was intentional. There haven't been any reported bricks on v1.2, but I don't see anyone actively checking the firmware for brick code either.


 
Fair enough. I think it's their own work though. While omega's was able to support both zelda VC games and HarmoKnight straight out of the gate, theirs didnt until they got a hardware update to go with the software one. Not 100% conclusive proof but way better then R4i gold deluxe promising Gateway features by christmas (maybe they meant christmas of 2014)


----------



## Foxi4 (May 11, 2014)

Vengenceonu said:


> Fair enough. I think it's their own work though. While omega's was able to support both zelda VC games and HarmoKnight straight out of the gate, theirs didnt until they got a hardware update to go with the software one. Not 100% conclusive proof but way better then R4i gold deluxe promising Gateway features by christmas (maybe they meant christmas of 2014)


MT-Card does innovate on their own, but from what I recall, they coincidentally included functionality similar to Gateway's release and the time window between the two was extremely small. I'd love to say that it's 100% safe, but I'd rather if someone relevant to the scene would confirm those suspicions.

*EDIT:* Due to some additional information surfacing, Omega recommendation has been retracted until further notice.


----------



## vagueheart (May 30, 2014)

Hey I would like to say thank you so much for this thread.
It has helped me better understand the situation and all 

I haven't got a gateway yet, was trying to grasp what is going on now.
Hopefully omega is safe!


----------



## Foxi4 (May 30, 2014)

From what was gathered so far the bricking code is still there but it was polished to the point that you cannot trigger it by accident.


----------



## vagueheart (May 30, 2014)

Foxi4 said:


> From what was gathered so far the bricking code is still there but it was polished to the point that you cannot trigger it by accident.


 
Yep I just saw the thread : http://gbatemp.net/threads/more-tha...d-bricks-should-i-get-a-gateway.365665/page-4
On the last few post, Mathieulh said sth about finding the brick function and stuff like that.

I'm not a coding/technology student lol. I study accounting and all these stuff are so confusing XD
(Would have loved to be a hacker if I knew how cool I could be if I learnt that as a child, muahaha~)

Hopefully there will be more updates from these awesome guys regarding the brick function 
Having more information would be good.

If it has been polished to that extent that would be great!
But until someone has trigger it (hopefully not by accident), then we would never know how safe it is right?


----------



## Foxi4 (May 30, 2014)

That's why it's not "officially recommended" yet, but in my opinion enough time has passed without a single brick to validate an update.


----------

