Hacking Question How to avoid switch bricks?

[Kanakops]

Hi, I've been wondering for a long time if I should do a thread or ask everything directly on the noob paradise one but I think it's better for everyone if I ask it on the thread who could been found with title search. All the days, I see a thread about bricking issues, I think it sucks but it's also a scary situation, if a lot can fortunately fix the brick, a lot cannot.

I have a couple of question about bricks, I know there is this thread who explain how to unbrick your switch but I see none about how to prevent this situation to happen except the basics like "Always having a backup nand, always use emunand, always run trusted source homebrew". Anyway here the questions :

1) It is possible to brick my whole console (sysnand included) after a bad manipulation on the emunand?
Exemples

• Bad update of the emunand (choixdujournx/Daybreak)
• Bad .nsp (malware/fake game/brickers)
• Bad manipulation with a payload

2) It is possible to unbrick any type of brick if we have a nand backup? (Erista non patched model)
2.1) It is possible to unbrick any type of brick if we have a nand backup? (Mariko/patched model with sx chips)
3) Should we avoid AutoRCM ? It is causing people issues?
4) Why some people can't even detect their consoles with tegrarcm after a brick, how they can have this situation?

Thanks for reading and answering, I think it would help people like me to understand the whole concept a little bit more.

 

[Adran_Marit]

Hi, I've been wondering for a long time if I should do a thread or ask everything directly on the noob paradise one but I think it's better for everyone if I ask it on the thread who could been found with title search. All the days, I see a thread about bricking issues, I think it sucks but it's also a scary situation, if a lot can fortunately fix the brick, a lot cannot.

I have a couple of question about bricks, I know there is this thread who explain how to unbrick your switch but I see none about how to prevent this situation to happen except the basics like "Always having a backup nand, always use emunand, always run trusted source homebrew". Anyway here the questions :

1) It is possible to brick my whole console (sysnand included) after a bad manipulation on the emunand?
Exemples

• Bad update of the emunand (choixdujournx/Daybreak)
• Bad .nsp (malware/fake game/brickers)
• Bad manipulation with a payload

2) It is possible to unbrick any type of brick if we have a nand backup? (Erista non patched model)
2.1) It is possible to unbrick any type of brick if we have a nand backup? (Mariko/patched model with sx chips)
3) Should we avoid AutoRCM ? It is causing people issues?
4) Why some people can't even detect their consoles with tegrarcm after a brick, how they can have this situation?

Thanks for reading and answering, I think it would help people like me to understand the whole concept a little bit more.

Alot of the guide for getting started include a backup section, where you make a nand backup under hekate See this guide as an example. Even when I started hacking my switch the guides incuded a hey you should do this.

1.1) Bad .NSP/.NRO Yes, this is what was used in Pikabrick, which the original brick code, was from a this is why you should always run homebrew from a trusted source post. In the case of PikaBrick it corrupted the users prodinfo which is needed to boot HorizonOS - and could only be restored if you had a backup until recently (guide you linked) -

1.2) Bad update via ChoidujourNX/Daybreak - I've only seen cases of ChoidujourNX updates breaking when the user has updated a Mariko chipped console, to my knowledge this is the only way a brick can occur with choidujourNX. Daybreak is fine. - This type of brick is recoverable.

1.3) While none of of the current payloads can brick directly, someone I know did a proof of concept where they could cause a brick with a payload.

2) On an unpatched Erista (gen 1) switch it is extremely difficult to brick, but not impossible (see 1.3) All software bricks to date are recoverable to my knowledge (prodinfo or other emmc corruption/bricks)
2.1) again software bricks can be recovered with a backup, hardware bricks are alot harder to fix

3) AutoRCM should NOT enabled on any ipatched or mariko switch, the reason for this is we are unable to send payloads to recover it on newer console.
If you have an Unpatched Erista it is fine, and the only issue is it takes a bit to charge if it goes flat and is in RCM mode

4) If my switch isn't showing in RCM I normally hard reboot the console(15-20 second power button hold)/pc and that gets it to show again.

If something still isn't clear I will try my best to help you understand, I also suggest you take a read at this, there is also This page which is a list of payloads including malicious code
thnx by the way for linking my guide

 

[Kanakops]

Alot of the guide for getting started include a backup section, where you make a nand backup under hekate See this guide as an example. Even when I started hacking my switch the guides incuded a hey you should do this.

1.1) Bad .NSP/.NRO Yes, this is what was used in Pikabrick, which the original brick code, was from a this is why you should always run homebrew from a trusted source post. In the case of PikaBrick it corrupted the users prodinfo which is needed to boot HorizonOS - and could only be restored if you had a backup until recently (guide you linked) -

1.2) Bad update via ChoidujourNX/Daybreak - I've only seen cases of ChoidujourNX updates breaking when the user has updated a Mariko chipped console, to my knowledge this is the only way a brick can occur with choidujourNX. Daybreak is fine. - This type of brick is recoverable.

1.3) While none of of the current payloads can brick directly, someone I know did a proof of concept where they could cause a brick with a payload.

2) On an unpatched Erista (gen 1) switch it is extremely difficult to brick, but not impossible (see 1.3) All software bricks to date are recoverable to my knowledge (prodinfo or other emmc corruption/bricks)
2.1) again software bricks can be recovered with a backup, hardware bricks are alot harder to fix

3) AutoRCM should NOT enabled on any ipatched or mariko switch, the reason for this is we are unable to send payloads to recover it on newer console.
If you have an Unpatched Erista it is fine, and the only issue is it takes a bit to charge if it goes flat and is in RCM mode

4) If my switch isn't showing in RCM I normally hard reboot the console(15-20 second power button hold)/pc and that gets it to show again.

If something still isn't clear I will try my best to help you understand, I also suggest you take a read at this, there is also This page which is a list of payloads including malicious code
thnx by the way for linking my guide

Thanks a lot for the time and the informations you gave me, this is more clear for me now

 

[Adran_Marit]

Thanks a lot for the time and the informations you gave me, this is more clear for me now

No worries and if you need more information just ask

 

[Draxzelex]

Another very simple thing to note that noobs often overlook is that just because the screen is black doesn't mean its a brick. The term brick should always be used as a last resort because true (software-based) bricks can only be recovered with an eMMC backup

 

[D3N2]

No worries and if you need more information just ask

Hi @Adran_Marit - hoping you can help? I'm kinda desparate at this stage...

I've recently followed the rentry.org/EristaEmuNAND guide and setup exactly as specified and have been using the Switch happily with no real issues, using Tinfoil, etc.

Prior to hacking I had parental controls enabled with a timer which I wanted to remove, so I went into settings and attempted to remove, but turns out it requires connection to Nintendo servers to complete the process so I cancelled out of the settings and resumed normal use. I then noticed however that when entering the settings and scrolling down the list I'd get an Atmosphere crash screen (didn't note down the error) so assumed this would be because I attempted to disable parental controls and it bugged out when attempting to access Nintendo servers. My thinking was therefore to power off the Switch and enter OFW, then disable parental controls, but upon turning off the Switch and attempting to power on again I'm not getting anything on-screen, it's just black. I figured it might just be because it's in RCM or similar, but TegraRCMGUI isn't detecting it either when attempting Vol+&Power. Anyone have any ideas it'd be greatly appreciated!

EDIT: Also worth noting when viewing Device Manager the APX driver does not appear active when the Switch is connected (it does show under hidden devices however)

EDIT 2: I'm now worried I may have created a default.INI file in Atmosphere / Hosts folder instead of the default.TXT file as it states in the guide. I can't recall if I created it as default.INI or TXT - does Atmosphere automatically generate the INI file once you've added the host info to the default.TXT file? Or have I just stupidly created a INI file which is incorrect and it's possible Nintendo have remotely bricked my device somehow?

 

[Draxzelex]

Hi @Adran_Marit - hoping you can help? I'm kinda desparate at this stage...

I've recently followed the rentry.org/EristaEmuNAND guide and setup exactly as specified and have been using the Switch happily with no real issues, using Tinfoil, etc.

Prior to hacking I had parental controls enabled with a timer which I wanted to remove, so I went into settings and attempted to remove, but turns out it requires connection to Nintendo servers to complete the process so I cancelled out of the settings and resumed normal use. I then noticed however that when entering the settings and scrolling down the list I'd get an Atmosphere crash screen (didn't note down the error) so assumed this would be because I attempted to disable parental controls and it bugged out when attempting to access Nintendo servers. My thinking was therefore to power off the Switch and enter OFW, then disable parental controls, but upon turning off the Switch and attempting to power on again I'm not getting anything on-screen, it's just black. I figured it might just be because it's in RCM or similar, but TegraRCMGUI isn't detecting it either when attempting Vol+&Power. Anyone have any ideas it'd be greatly appreciated!

EDIT: Also worth noting when viewing Device Manager the APX driver does not appear active when the Switch is connected (it does show under hidden devices however)

EDIT 2: I'm now worried I may have created a default.INI file in Atmosphere / Hosts folder instead of the default.TXT file as it states in the guide. I can't recall if I created it as default.INI or TXT - does Atmosphere automatically generate the INI file once you've added the host info to the default.TXT file? Or have I just stupidly created a INI file which is incorrect and it's possible Nintendo have remotely bricked my device somehow?

Nintendo has never remotely bricked anyone.