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

[Foxi4]

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
• 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, this brick is *irreversible*, which is why we urge you to spend a moment of your time familiarizing yourself with the F.A.Q.

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]

Good guide much needed at this stage of the game

 

[Satangel]

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

 

[alexenochs]

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]

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]

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]

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 :

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.

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]

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]

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]

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]

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

 

[Foxi4]

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.

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]

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]

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]

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]

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]

"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]

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]

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]

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.

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