Hacking SWITCH NOOB PARADISE - Ask questions here

[XenArtezie]

The problem is NEUTOS. Remove it and grab a fresh copy of Kosmos.

Already did (just deleted everything but the emuMMC folder) and copied the new files from the new kosmos pack to the sd, but when pushing the hekate payload, and launching emunand, the same error appears (just after the Nintendo Switch logo).

So is my emunand folder corrupted after all?

 

[Starforce2005]

The two rules to follow is that you do not go online with both sysMMC and emuMMC and that you never go online after using CFW & homebrew. The downside is that you will need space on your SD card to accommodate emuMMC. In order to prevent fuses from being burnt, you should enable AutoRCM.

But does booting into OFW and play normally could coexist with playing emunand offline? Atleast i've seen alot of people doing it without problem.
With AutoRCM, i've heard that updating firmware in OFW will reset AutoRCM regardless

 

[Itsuki235]

But does booting into OFW and play normally could coexist with playing emunand offline? Atleast i've seen alot of people doing it without problem.
With AutoRCM, i've heard that updating firmware in OFW will reset AutoRCM regardless

1) Yes, they co-exist just fine.
2) The AutoRCM thing is backwards. It is convenient to disable AutoRCM in order to boot OFW. Then it can do whatever it does online, update games/firmware/play online/reboot w/e, and none of that matters or requires a jig to boot while in that mode. Then later on, turn autoRCM back on and launch in emuMMC CFW mode, so switching back and forth is easy by toggling that setting.

 

[Cyan]

You need RCM to boot into CFW.
AutoRCM is just a way to force-wait at boot without using a jig until you send a payload instead of booting OFW, by creating an error in boot0 and forcing the console to go into recovery.

The thing is if you are in RCM, you can't use the official nintendo boot payload anymore, so you need hekate to still launch "stock" OFW, which is not fully clean but with few cfw patches (the less patch possible) but it's still cfw.

Fuses are burned at official payload step (boot -> payload -> HOS)
If you use hekate payload, no fuses are burned, but HOS is not 100% clean (but no reported ban)
If you use the official nintendo boot payload, it will burn fuses to match HorizonOS version.
if you use the official boot payload, it means you already are not using RCM (but hekate), so your console is not modified into losing AutoRCM if you don't update online.
Booting OFW does not replace RCM, but updating it does as it replace boot0/boot1 where the "error" is located to force the console into AutoRCM.

It's not a big problem to burn fuses if your console is vulnerable and not patched, as you will always have RCM access to boot into CFW using a dongle, even with unmatching number of burned fuse.
You might want to keep fuse unburned on patched units, to stay for example on low OFW to boot into RCM using software method (instead of jig) to use CFW on emuMMC (clean cfw for online, or unclean cfw offline for homebrew)


So, your choices are :
1. clean updated OFW for online
NO autoRCM
burned fuses matching OFW
boot normally into OFW for online
use jig to go into RCM to boot emuMMC, keep it offline and do what you want here (homebrew or piracy it's your choice)


2. clean outdated OFW for vulnerability to boot into RCM using software method
no autoRCM
burned fuses matching OFW
can't use online with OFW, it's used only to go into cfw
RCM can then let you choose one or two different emuMMC partition, one for online (clean), one for unclean, homebrew, etc.

3. a mix of both maybe?
autoRCM,
with or without burned fuses, it's not a problem when using hekate. Same for gamecard fuses, it's not a problem as long as you don't try to play games on lower firmware version.
Updated OFW on emmc (attention when updating you have to prepare jig to go into RCM at first reboot or it'll burn fuses)
from RCM, choose to boot Stock or emu, use one for online, one for homebrew. not necessarily the mmc being online, just don't mix them.

Advantage of using emu as online is probably that you don't have to care to lose AutoRCM when updating online?
it'll update the boot0 on emu, and the real boot0 will retain it's "bug" and the console will not lose autoRCM.


For burned fuses, it has been an habit from users to fear fuses burning but without reason.
Not burning fuses is only meant to be able to "go back to old OFW" (no online play!) for whatever reason.

The most expected reason being to keep low burned fuses just in case one day someone find a vulnerability on an old firmware which requires "that much low fuse you kept (not even sure your fuses are low enough)" so that people could downgrade on a vulnerable outdated OFW as gateway to hack the console into CFW instead of using Jig/dongle/modchip/flashcard.
But nobody is developing outdated exploit based on old vulnerability, right? most active hackers are trying to fix compatibility with latest released firmware version, and everybody uses RCM or SXOS to get kernel access.
Would you ever downgrade?


Just keep a full eMMC backup of each of your "updated" firmware version matching last burned fuses, in case you want to restore it. that's all.
for example, I made a backup of 4.1, I keep my fuses at 4.1 so I can restore it.
if I update officially to 10 and ever burn fuses, I'l be sure to make a new 10 backup !
if you don't make a new backup you won't be able to "officially boot" without RCM. but it's still not so much of a problem as you can use hekate to boot stock.

 

[Itsuki235]

Thank you very much for taking the time to answer all my questions.
I'll re-read carefully to understand everything.

I might be able to expand on some of the ideas or provide a different perspective, so if you don't mind I'll be responding as well.

1. Do Atmosphere v12 with OFW/HOS 10.0.1. There is no reason to be on older versions or use older anything. If you are going to put the time in to update, then might as well update to the latest version. Everything works on the latest CFW and OFW. It is correct that loader_patches or a loader.kip is only needed on OFW 10. Atmosphere 12 on OFW 9.2.0 does not need the loader.kip or the loader_patches.

2. OFW 8-> OFW 9 changed how the joycons were handled for homebrew so a lot of homebrew that used joycons needed to be recompiled. That process is over now. Homebrew that did not use the joycons (ChoixNX) never needed updating.

3. You already know what you are doing, but I would recommend is 1) restoring the OFW 4.2 sysnand backup 2) updating to 10.0.1 using official servers 3) creating a fresh 100% vanilla 10.0.1 sysnand backup 4) creating a 10.0.1 emuMMC. Then you do not need to update in stages or involve ChoixNX at all. It is possible to downgrade emuMMC later using ChoixNX if you ever feel like being on a lower OFW (why?).

4. Ignore everything related to bis permissions/flags/Cal0 whatever. Atmosphere v12 removed all of those protections for emuMMC, sysMMC still has those protections, but there is no reason to be updating sysMMC unoffically using ChoixNX anyway, so figuring out what flags need to go where shouldn't ever matter but if you are curious take a look at SD:/exosphere.ini from NeutOS.

5. Update to OFW 10.0.1 and then use "Lockpick_RCM.bin" to dump the latest keys to SD:/switch/prod.keys. An updated prod.keys is needed for some things on the PC that say to specify a keys.dat or w/e.

6. When booting from Hekate with the entry as "payload=fusee-primary.bin", no additional files are required. It is correct that the indirect way that Hekate boots Atmosphere was not needed for anything in more recent OFW versions (>~4.2.0). There were some minor benefits like not displaying the "Atmosphere" logo, shotening boot time, and an old (now fixed) bug that made the "payload=" syntax not being compatible with autoboot.

7. First, always make sure the fs patches are where they need to be. Then the 2 methods are to either use "loader.kip" or the "kip_patches/loader_patches" method. That second method is required for Tinfoil. Everything except tinfoil will work with the first method because tinfoil bans the use of that loader.kip (and all other kips).

8. Yes, that is how it works and that change looks perfect. However, be sure to delete the CFW (SYSNAND) option completely. The stock option is not needed either if you are willing to disable AutoRCM when booting into OFW. As long as the patches are available, fusee-primary.bin will load them automatically without any extra config settings.

9.1. There is liable to result in a ban. Probably will not, but you never really know. The only safe way to do this is to take the console offline, create a second temporary synand backup, boot CFW Sysnand, save the game data, then restore from that sysnand backup, and then delete the second temporary sysnand backup. Then repeat the process every time you want to back up your save data.

9.2 Nothing to add to Drax's reply.

10. If you launch using fusee-primary.bin, then atmosphere will automatically load any kips found in SD:/atmosphere/kips/*
Technically the fss0= method could load kips from any path, but guides say to place in that location because that is the default location for them to load from when using fusee-primary.bin.

11. Create "SD:/atmosphere/config/override_config.ini" with the following file with the following contents:

Spoiler: override_config.ini

[hbl_config]
override_key=R
override_any_app=true
override_any_app_key=R

Unix line endings (LF) and ANSI/UTF-8 or UTF-8 w/o BOM
It is also possible to mess with the button config using Kosmos Toolbox, but it requires rebooting and is both confusing and annoying to set up that way.

12. If you combined the pieces like older guides said to (why) then that means you have large 32GB file to restore. That will require exFat, but please switch back to Fat32 after it has been restored and create a new nand backup once on newer OFW.

 

[Cyan]

Thank you for your own insight and completed answers

thanks for the 3) idea.
I never installed games so I don't have to "reinstall" or lose anything from mmc or emu, so it's a good idea to just go clean first. the few games I bought officially but played on cfw I made savegame backups so I can restore them on emuMMC later.

my only concern to not just update current firmware officially (instead of restoring clean dump) were the use of homebrew and few errors message I got. they might have dirtied the data to use online with.

and you are probably right it'll be easier to just do things from "clean latest version" as if it was the first time hacking it, than trying to mix and update an already hacked version.

4) I see, I'll update officially my sysNAND, so no need of that flag.
it's indeed easier than updating with choixNX offline before doing the emu dump, then restoring old backup.


8)
Yes, I think I'll go with the no autoRCM method and burned fuses to use OFW, and jig to CFW.
I used autoRCM until now for ease of use to not keep the jig with me.
it's not too much of a problem to keep it, or not reboot the console often I guess (unless it crashes in homebrew which happens a lot).
so having a very short boot option in hekate is fine, no more need for stock.
though, I think I'd keep cfw sysNAND (for savegame backup, it shouldb't ban me right?)

Ah, it's 9.1)
Like you said, we don't know and can't be sure. it could one day be a ban reason.
better not mess with it then.

Maybe another solution to edit the sysNAND without dirtying it is to use NAND explorers payloads or on computers? that way, the firmware never boots into CFW, but we can still have file access.
Rajkosto's hacDiskMount on PC, or TegraExplorer on console.

10) I see, it could work but nobody tried

11) thanks for the info.


I don't intend to use tinfoil, but I think I still prefer ips patches with fusée-primary.
I guess time and usage will dictate the method I'll use, both are fine so it's just preferences.

Thanks a lot to both Drax and you for answering my questions
some were maybe more technical than what other users are usually asking.


Edit :
When using emuNAND, should I set a different "nintendo" folder?
nintendo_path = xxxx

edit: I found the answer !
the path is automatically set to "nintendo_<emuNAND ID>" by hekate


Is sharing the same folder a ban risk?
I guess it would be a problem if I return to sysNAND while this folder contains games with missing ticket/certs.
But sharing the same folder will allow me to play bought games on emuNAND without having duplicate officially bought games on SD (nintendo and emutendo), but not share the savegame (too bad)
I guess my SD is big enough to have 2-3 duplicated games.

 

[Starforce2005]

1) Yes, they co-exist just fine.
2) The AutoRCM thing is backwards. It is convenient to disable AutoRCM in order to boot OFW. Then it can do whatever it does online, update games/firmware/play online/reboot w/e, and none of that matters or requires a jig to boot while in that mode. Then later on, turn autoRCM back on and launch in emuMMC CFW mode, so switching back and forth is easy by toggling that setting.

Hi Itsuki, About Number 2, will doing that burn fuses?

 

[Itsuki235]

Hi Itsuki, About Number 2, will doing that burn fuses?

Yes.

Edit:

Maybe another solution to edit the sysNAND without dirtying it is to use NAND explorers payloads or on computers? that way, the firmware never boots into CFW, but we can still have file access.
Rajkosto's hacDiskMount on PC, or TegraExplorer on console.

Purely theoretical, I have never tried it, but yes, it should work like that.

Is sharing the same folder a ban risk?

Actually, I don't know. Never tried that config since I only use cartridges on sysNAND. Maybe Drax can answer this.

One more thing that I would add, and a spot where I differ with Drax, is to install Incognito onto the emuMMC side.

Technically, Atmosphere v12 also introduced a very similar feature where some ProdInfo would point to garbage. Atmosphere's method is untested (it has just been released) but it can be enabled by setting "blank_prodinfo_emummc=1" in "SD:/exosphere.ini", see neutOS for a template.

Edit2:
The reason I have never tried it is because I always start with 100% fresh sysnand.

Edit :
When using emuNAND, should I set a different "nintendo" folder?
nintendo_path = xxxx

edit: I found the answer !
the path is automatically set to "nintendo_<emuNAND ID>" by hekate

For an emuMMC based on the second partition on an SD card, is automatically set to "emuMMC/RAW1/Nintendo" so there is never any conflict between what is installed on sysNAND and emuMMC. But that only applies to contents installed AFTER emuMMC is created while on emuMMC. For stuff installed prior to that, I am not sure if creating emuMMC duplicates the contents or if they have to be manually copied or what.

 

[Starforce2005]

You need RCM to boot into CFW.
AutoRCM is just a way to force-wait at boot without using a jig until you send a payload instead of booting OFW, by creating an error in boot0 and forcing the console to go into recovery.

The thing is if you are in RCM, you can't use the official nintendo boot payload anymore, so you need hekate to still launch "stock" OFW, which is not fully clean but with few cfw patches (the less patch possible) but it's still cfw.

Fuses are burned at official payload step (boot -> payload -> HOS)
If you use hekate payload, no fuses are burned, but HOS is not 100% clean (but no reported ban)
If you use the official nintendo boot payload, it will burn fuses to match HorizonOS version.
if you use the official boot payload, it means you already are not using RCM (but hekate), so your console is not modified into losing AutoRCM if you don't update online.
Booting OFW does not replace RCM, but updating it does as it replace boot0/boot1 where the "error" is located to force the console into AutoRCM.

It's not a big problem to burn fuses if your console is vulnerable and not patched, as you will always have RCM access to boot into CFW using a dongle, even with unmatching number of burned fuse.
You might want to keep fuse unburned on patched units, to stay for example on low OFW to boot into RCM using software method (instead of jig) to use CFW on emuMMC (clean cfw for online, or unclean cfw offline for homebrew)


So, your choices are :
1. clean updated OFW for online
NO autoRCM
burned fuses matching OFW
boot normally into OFW for online
use jig to go into RCM to boot emuMMC, keep it offline and do what you want here (homebrew or piracy it's your choice)


2. clean outdated OFW for vulnerability to boot into RCM using software method
no autoRCM
burned fuses matching OFW
can't use online with OFW, it's used only to go into cfw
RCM can then let you choose one or two different emuMMC partition, one for online (clean), one for unclean, homebrew, etc.

3. a mix of both maybe?
autoRCM,
with or without burned fuses, it's not a problem when using hekate. Same for gamecard fuses, it's not a problem as long as you don't try to play games on lower firmware version.
Updated OFW on emmc (attention when updating you have to prepare jig to go into RCM at first reboot or it'll burn fuses)
from RCM, choose to boot Stock or emu, use one for online, one for homebrew. not necessarily the mmc being online, just don't mix them.

Advantage of using emu as online is probably that you don't have to care to lose AutoRCM when updating online?
it'll update the boot0 on emu, and the real boot0 will retain it's "bug" and the console will not lose autoRCM.


For burned fuses, it has been an habit from users to fear fuses burning but without reason.
Not burning fuses is only meant to be able to "go back to old OFW" (no online play!) for whatever reason.

The most expected reason being to keep low burned fuses just in case one day someone find a vulnerability on an old firmware which requires "that much low fuse you kept (not even sure your fuses are low enough)" so that people could downgrade on a vulnerable outdated OFW as gateway to hack the console into CFW instead of using Jig/dongle/modchip/flashcard.
But nobody is developing outdated exploit based on old vulnerability, right? most active hackers are trying to fix compatibility with latest released firmware version, and everybody uses RCM or SXOS to get kernel access.
Would you ever downgrade?


Just keep a full eMMC backup of each of your "updated" firmware version matching last burned fuses, in case you want to restore it. that's all.
for example, I made a backup of 4.1, I keep my fuses at 4.1 so I can restore it.
if I update officially to 10 and ever burn fuses, I'l be sure to make a new 10 backup !
if you don't make a new backup you won't be able to "officially boot" without RCM. but it's still not so much of a problem as you can use hekate to boot stock.

Hi Cyan i'm using SX PRO, i have no knowledge of other payload like hekate, will SX PRO payload in its dongle work the same way?
The reason i care for fuse is because my original backup of my sysnand, its always good to have the option to fix brick in the future, but if the fuse is burnt my backup will not work anymore.

So what you basically meant is that there is no way to update OFW without burning fuse? Thank you very much

--------------------- MERGED ---------------------------

Yes.

Is there anyway to update OFW without burning fuse?

 

[Cyan]

the only way to update OFW from network without burning fuse is to be sure to always (re)boot to RCM and not use official payload booter to launch Horizon. Attention when updating the firmware on sysNAND as it automatically reboots the console right away without AutoRCM!
You can use ChoixDuJourNX to update offline and automatically set AutoRCM.

I'm not very knowledgeable when it comes to SXOS, but I'd say they also bypass fuse burning to launch HOS.

so as long as you use AutoRCM, or always use the JIG to boot into OFW, then you are fine.
if one day you launch OFW without the jig, the fuses are burned.

I would think SXOS also allow you to boot unmatching fuse firmware version, so if you accidentally burned fuses, and you want to downgrade it should allow you to boot your firmware anyway.
But that's only assumption, someone will have to confirm as I don't know SXOS that well !

 

[Itsuki235]

Is it anyway to update OFW without burning fuse?

If you have autoRCM enabled, then no fuses should have ever been burnt. Updating OFW is possible using Tinfoil/SX Installer or ChoiDujourNX. The process usually involves ChoiDujourNX downloaded from
https://switchtools.sshnuke.net/ however that involves obtaining the OFW files. I am not sure if I am allowed to link to them, so I better not, but they are obtainable from darthsternie.
Place the extracted *.nca files from "Firmware 10.0.1" in SD:/firmware/*. Then you can follow this guide: https://switch.homebrew.guide/usingcfw/manualupgrade

 

[Starforce2005]

the only way to update OFW without burning fuse is to be sure to always (re)boot to RCM and not use official payload booter to launch Horizon. Attention when updating the firmware on sysNAND as it automatically reboots the console right away without AutoRCM!

I'm not very knowledgeable when it comes to SXOS, but I'd say they also bypass fuse burning to launch HOS.

so as long as you use AutoRCM, or always use the JIG to boot into OFW, then you are fine.
if one day you launch OFW without the jig, the fuses are burned.

I would think SXOS also allow you to boot unmatching fuse firmware version, so if you accidentally burned fuses, and you want to downgrade it should allow you to boot your firmware anyway.
But that's only assumption, someone will have to confirm as I don't know SXOS that well !

Hi, Cyan.
Is my understanding correct - I should have JIG always plugged (Since official update will reset AutoRCM, i forgot where i read it) in whenever i turn on my switch, and launch OFW through SX OS menu?
Thank you very much

 

[Cyan]

if you don't have AutoRCM, yes.
If your console is ipatched, NEVER set autoRCM or you'll brick ! in that case you always need the jig when (re)booting, or it'll burn fuses.
if it's a vulnerable non patched console, I suggest you set autoRCM to be safe. you won't need to use the jig+vol pressed when booting, BUT it will boot to black screen and if you are not careful it'll empty the battery without you noticing. just plug the "usb dongle" with the payload to boot the console into non black screen.
Attention 2 : if you shutdown, and then put the console in charge, it'll boot to autoRCM (blackscreen) too!
So, if one day you think your console is bricked, and don't boot, do not worry ! it's probably just out of charge ! just plug it to the charger for few minutes before trying to use the usb dongle to send the payload.

Maybe you should check your fuse count (hekate payload, or using one of the existing homebrew) to check and know if you can still restore your backup without problem. It's always safer to check just before restoring.

if you want to go into hekate, don't use the sxos USB dongle, but one of the other methods to send payloads (computer, or phones)

 

[Starforce2005]

If you have autoRCM enabled, then no fuses should have ever been burnt. Updating OFW is possible using Tinfoil/SX Installer or ChoiDujourNX. The process usually involves ChoiDujourNX downloaded from
https://switchtools.sshnuke.net/ however that involves obtaining the OFW files. I am not sure if I am allowed to link to them, so I better not, but they are obtainable from darthsternie.
Place the extracted *.nca files from "Firmware 10.0.1" in SD:/firmware/*. Then you can follow this guide: https://switch.homebrew.guide/usingcfw/manualupgrade

Hi Itsuki235, the reason i don't use apps like ChoiDujourNX is because, in order to use them, i have to boot into CFW, but my OFW is clean i don't want to "taint" it, i only ever boot into CFW with emunand so far(and made sure 90DNS is set), so if i were to update OFW to play normally i would prefer to use offcial update. (Or is my understanding wrong?)

 

[Cyan]

your understanding is right
so be ready to use the jig and press vol button to go into RCM right after updating from the network, as it will reboot and it probably will have removed AutoRCM by installing a new Boot0.
if your console allow AutoRCM, set it back.
if you ever burn fuses and want to restore older backup, I guess you'll have to use "boot OFW" from SXOS, and it'll not be "100% clean" anymore.

I suggest you to make a new clean NAND dump each time you update your firmware so you can recover from the same firmware if ever needed, not an old one.
that way you don't really have to care about fuses or autoRCM anymore.

 

[Starforce2005]

your understanding is right
so be ready to use the jig and press vol button to go into RCM right after updating from the network, as it will reboot and it probably will have removed AutoRCM by installing a new Boot0.
if your console allow AutoRCM, set it back.
if you ever burn fuses and want to restore older backup, I guess you'll have to use "boot OFW" from SXOS, and it'll not be "100% clean" anymore.

I suggest you to make a new clean NAND dump each time you update your firmware so you can recover from the same firmware if ever needed, not an old one.
that way you don't really have to care about fuses or autoRCM anymore.

Thank you very much Cyan!

 

[Qrawler2]

Hey guys, a quick question :

I have a sysnand and a emunand.. I updated sysnand to latest version yesterday 0.10.1. Emunand ist still on 0.9.1. Can I safely boot up into emunand and back to sysnand? Or will there be a problem because of the fuses?

I don't want to update emunand as everything I need it for is working atm..

Additional info:
No autorcm
Using jig to get into hekate and emunand
Reboot without jig to get into ofw.

 

[Itsuki235]

I have a sysnand and a emunand.. I updated sysnand to latest version yesterday 0.10.1. Emunand ist still on 0.9.1. Can I safely boot up into emunand and back to sysnand? Or will there be a problem because of the fuses?

You can boot into emuMMC/emuNAND normally. The fuses do not affect anything.

The primary purpose of fuses is to prevent downgrading firmware, which is bypassed completely by entering recovery mode. So, doing recovery mode->CFW will always work, irrespective of burnt fuses.

 

[Qrawler2]

Y

You can boot into emuMMC/emuNAND normally. The fuses do not affect anything.

The primary purpose of fuses is to prevent downgrading firmware, which is bypassed completely by entering recovery mode. So, doing recovery mode->CFW will always work, irrespective of burnt fuses.

Well thank you itsuki, I read somewhere that it might haplen that additionally fuses will be burnt if I go back to an older cfw and the back to a higher ofw.. This is nonsense then I guess?

 

[jacobtc]

I have been out of the loop for a while now. My Switch is running 8.0 Atmosphere on Sysnand, however, I did make a backup of the 2.3 firmware before I started. How would I go about restoring the 2.3 to Sysnand, and creating a Emunand with the newest Atmosphere, keeping the saves from my previous 8.0 Sysnand CFW?

No fuses have been burned, I've used AutoRCM.

EDIT: Oh, and before I forget, I purchased the Switch second hand, but the previous user never deleted his profile, so I now have his user show up, every time I launch a game, is it possible to get rid of this in the process as well?