Hacking Clarification of emuMMC safety?

[marine5422]

I wants know about clarification of switch based emuNAND(emuMMC) safety.
Unlike the 3DS era, even a small modification switch with online access could be result a ban If I read correctly.
I'm not sure about emuMMC also could be a ban result even if I don't use homebrew and NSP.

I have a old switch that is pure state (non-mod) with FW4.1.0.
And I just plan to make a emuMMC for online with pure state. (No homebrew or NSP).
It is still safe with emuMMC for a online, even if you don't play pirate games? (even no burn fuse?)
(I had a another switch too, and it's for NSP/homebrew. That's why I just left that 4.1.0 switch non-mod state.)

Someone suggested that, just update the sysNAND for online and other for emuNAND is good for me. (Like NSP or other things)
But I just want's my sysNAND for 4.1FW state for a possible later exploit.
(Maybe coldboot... I guess? Maybe not, but anyway I don't want lose lower FW's benefit)
And If you update the sysNAND, I never back to clean OFW state due to fuse burn.
(Actually you can downgrade with choidujour for manual fw install and make autoRCM for emuMMC boot possible,
but as you can see it's not clean-state. it's rcm modified. I don't wanna this)

So my question that: Is it okay with using a sysnand left this state (FW 4.1.0 with 5 burn fuse) and made a clean emuMMC, and updated to FW 8.1.0 (without burn fuse) for online?
Or even a clean non-mod emmMMC could be dangerous that could result a ban someday, so that I have to use for sysnand update to 8.1.0 for safety online access like someone suggested?

 

[Boydy86]

is emulated NAND not the one your meant to keep a million miles away from an internet connection?

 

[metaljay]

If you are super worried about banning, then I would update sysNand to latest firmware and keep it clean and online; and emuMMC for offline and dirty things.

The pros of this: LEAST likely way of being banned as they are literally separate partitions
Cons: you’ll be tied into using RCM and a dongle forever. (No chance of a warm boot)

No one knows if a emuMMC that is clean and online will EVER be detected by Nintendo, it could be one day, and by that point your to late.

 

[Lacius]

I have a old switch that is pure state (non-mod) with FW4.1.0.
And I just plan to make a emuMMC for online with pure state. (No homebrew or NSP).
It is still safe with emuMMC for a online, even if you don't play pirate games? (even no burn fuse?)
(I had a another switch too, and it's for NSP/homebrew. That's why I just left that 4.1.0 switch non-mod state.)

Someone suggested that, just update the sysNAND for online and other for emuNAND is good for me. (Like NSP or other things)
But I just want's my sysNAND for 4.1FW state for a possible later exploit.
(Maybe coldboot... I guess? Maybe not, but anyway I don't want lose lower FW's benefit)
And If you update the sysNAND, I never back to clean OFW state due to fuse burn.
(Actually you can downgrade with choidujour for manual fw install and make autoRCM for emuMMC boot possible,
but as you can see it's not clean-state. it's rcm modified. I don't wanna this)

So my question that: Is it okay with using a sysnand left this state (FW 4.1.0 with 5 burn fuse) and made a clean emuMMC, and updated to FW 8.1.0 (without burn fuse) for online?
Or even a clean non-mod emmMMC could be dangerous that could result a ban someday, so that I have to use for sysnand update to 8.1.0 for safety online access like someone suggested?

Assuming your Switch is unpatched, the easiest option would be to have a clean sysNAND on 8.1.0 for online play and a dirty emuNAND kept offline for all hackery. If you want to keep your sysNAND on 4.1.0, then you would need a second emuNAND that's clean for online play.

There is already a warmboot browser exploit out for 4.1.0, and it's highly unlikely that 4.1.0 will get an untethered coldboot exploit. If you prefer the RCM exploit over the warmboot browser exploit, then there's no real reason to stay on 4.1.0. Alternatively, you could also install AutoRCM to keep your fuses low. This would allow you to update your clean sysNAND to 8.1.0 for online play while preserving the ability to downgrade later.

 

[metaljay]

Assuming your Switch is unpatched, the easiest option would be to have a clean sysNAND on 8.1.0 for online play and a dirty emuNAND kept offline for all hackery. If you want to keep your sysNAND on 4.1.0, then you would need a second emuNAND that's clean for online play.

There is already a warmboot browser exploit out for 4.1.0, and it's highly unlikely that 4.1.0 will get an untethered coldboot exploit. If you prefer the RCM exploit over the warmboot browser exploit, then there's no real reason to stay on 4.1.0. Alternatively, you could also install AutoRCM to keep your fuses low. This would allow you to update your clean sysNAND to 8.1.0 for online play while preserving the ability to downgrade later.

Is it possible to update sys nand via system settings (so it’s clean and no use of home brew), then when it asks to reboot, you go into RCM instead and enable autoRCM from NyX, so bootloader never registers the fuse count? Only issue is again, we have no way to check that Nintendo cannot detect autoRCM

 

[Lacius]

Is it possible to update sys nand via system settings (so it’s clean and no use of home brew), then when it asks to reboot, you go into RCM instead and enable autoRCM from NyX, so bootloader never registers the fuse count?

That's possible with a jig, but it's hard to do and risky. Instead, if your goal is to update your clean sysNAND without burning fuses, I would do the following:

1. Install AutoRCM if you haven't already done so. You can do this with Hekate.
2. Delete all traces of Atmosphere from your SD card.
3. Put a clean download of the latest version of Atmosphere onto your SD card.
4. Boot your clean sysNAND into Atmosphere using fusee-primary (this is unlikely to get you banned).
5. Update your system through the system settings.

Doing this will keep your fuse count low, AutoRCM will be installed, and your sysNAND is still likely to be clean. You should also stop using Atmosphere with your clean sysNAND and instead boot to OFW using Hekate when you want to launch your clean sysNAND.

It is also worth mentioning that BCT verification happens outside Horizon, so AutoRCM is currently not detectable.

 

[Garou]

Is it possible to update sys nand via system settings (so it’s clean and no use of home brew), then when it asks to reboot, you go into RCM instead and enable autoRCM from NyX, so bootloader never registers the fuse count?

of course. in fact, that's one of the old way to update without burning fuses
https://gbatemp.net/threads/an-easy...ch-firmware-without-burning-any-fuses.511847/

 

[Lacius]

of course. in fact, that's one of the old way to update without burning fuses
https://gbatemp.net/threads/an-easy...ch-firmware-without-burning-any-fuses.511847/

The point is to be able to update to 8.1.0 without burning efuses while also keeping the NAND clean (in order to prevent a ban). The method I outlined is one of the least dirty methods.

 

[metaljay]

That's possible with a jig, but it's hard to do and risky. Instead, if your goal is to update your clean sysNAND without burning fuses, I would do the following:

1. Install AutoRCM if you haven't already done so. You can do this with Hekate.
2. Delete all traces of Atmosphere from your SD card.
3. Put a clean download of the latest version of Atmosphere onto your SD card.
4. Boot your clean sysNAND into Atmosphere using fusee-primary (this is unlikely to get you banned).
5. Update your system through the system settings.

Doing this will keep your fuse count low, AutoRCM will be installed, and your sysNAND is still likely to be clean. You should also stop using Atmosphere with your clean sysNAND and instead boot to OFW using Hekate when you want to launch your clean sysNAND.

It is also worth mentioning that BCT verification happens outside Horizon, so AutoRCM is currently not detectable.

Why point 4?
Wouldn’t updating through system settings turn off autoRCM?

Also, I haven’t read about BCT being verified outside of OS, whilst I see this as low risk, I still think my first post above seems the ideal for anyone paranoid about banning.

 

[Lacius]

Why point 4?
Wouldn’t updating through system settings turn off autoRCM?

Also, I haven’t read about BCT being verified outside of OS, whilst I see this as low risk, I still think my first post above seems the ideal for anyone paranoid about banning.

Updating through the system settings while Atmosphere is running blocks the removal of AutoRCM.

 

[JokerJoester]

Updating through the system settings while Atmosphere is running blocks the removal of AutoRCM.

Is the latest firmware version safe to update to through Atmosphere? I was avoiding doing so because I wasn't sure

 

[Lacius]

Is the latest firmware version safe to update to through Atmosphere? I was avoiding doing so because I wasn't sure

You want to avoid using Atmosphere or any other CFW on your clean NAND.

That being said, running it one time to update normally, without doing anything homebrew related, should be relatively safe.

Atmosphere supports 8.1.0 and below. 8.1.0 is the latest system version as of this post. When new Switch updates come out, Atmosphere will very likely need to be updated before it's compatible with the new Switch update.

 

[marine5422]

Assuming your Switch is unpatched, the easiest option would be to have a clean sysNAND on 8.1.0 for online play and a dirty emuNAND kept offline for all hackery. If you want to keep your sysNAND on 4.1.0, then you would need a second emuNAND that's clean for online play.
xploit, then there's no real reason to stay on 4.1.0. Alternatively, you could also install AutoRCM to keep your fuses low. This would allow you to update your clean sysNAND to 8.1.0 for online play while preserving the ability to downgrade later.

Thanks for protip. Warmboot exploit could be enough for me. Dongle isn't good for me. So I'll left FW lower.

And one more check: Could be non-burnt fuse or RCM modified with latest firmware could be detected by Ninty aside from ban?

-> Sysnand for 4.1 an Emunand (8.1) for with same fuse count(5, non-burnt) unlike ordinary states(10).
(So disguised the fuse FW stated with Atmosphere. I just wonder if that [fuse count == FW ver] match info could be detectable by Ninty)

Maybe developer would be know that 'what info' sent to server during the online access. And I just wonder if that fuse count with version related things are included in that 'what info'.
That's the most priority concern that before I use the emuMMC.

 

[Lacius]

And one more check: Could be non-burnt fuse or RCM modified with latest firmware could be detected by Ninty aside from ban?

Nobody has ever been banned for a low fuse count before, and it's not something that is currently detectable outside of the boot process or sleep functions. The same goes for AutoRCM.

 

[marine5422]

Nobody has ever been banned for a low fuse count before, and it's not something that is currently detectable outside of the boot process or sleep functions. The same goes for AutoRCM.

Now it's very clear for me. Thanks.

 

[OrGoN3]

You want to avoid using Atmosphere or any other CFW on your clean NAND.

That being said, running it one time to update normally, without doing anything homebrew related, should be relatively safe.

Atmosphere supports 8.1.0 and below. 8.1.0 is the latest system version as of this post. When new Switch updates come out, Atmosphere will very likely need to be updated before it's compatible with the new Switch update.

Would booting through hekate with stock options still protect AutoRCM during a system update from HOS?

Edit: And why would it matter if AutoRCM is kept or not? Just keep a jig for updating purposes and re-enable RCM after the update. Right?

 

[Lacius]

Would booting through hekate with stock options still protect AutoRCM during a system update from HOS?

No, I don't think so. Somebody correct me if something has changed.

Alternatively, you can briefly boot into Atmosphere and update, and AutoRCM will be preserved. Booting in Atmosphere for only this purpose is unlikely to get you banned.

 

[OrGoN3]

No, I don't think so. Somebody correct me if something has changed.

Alternatively, you can briefly boot into Atmosphere and update, and AutoRCM will be preserved. Booting in Atmosphere for only this purpose is unlikely to get you banned.

Ah. I was under the impression that booting through Hekate preserves efuses no matter what you do.

 

[Lacius]

Ah. I was under the impression that booting through Hekate preserves efuses no matter what you do.

Hekate will never burn efuses no matter what, correct. I'm talking about AutoRCM being preserved. Last I checked, Hekate doesn't have write protection for the BCT public key and keyblob regions, so if you update after booting OFW in Hekate, AutoRCM will be overwritten, and the system will boot stock OFW after rebooting.

 

[OrGoN3]

Hekate will never burn efuses no matter what, correct. I'm talking about AutoRCM being preserved. Last I checked, Hekate doesn't have write protection for the BCT public key and keyblob regions, so if you update after booting OFW in Hekate, AutoRCM will be overwritten, and the system will boot stock OFW after rebooting.

Ah. Dumb me. Thanks for clarifying!!