Hacking SWITCH NOOB PARADISE - Ask questions here

[tomy54332]

When using automatic updates like daybreak/aio there is caution about sysmodules, I really want to install triplayer to play background music while gaming but I'm hesitant to use any sysmodules bc they make screw up an update (I use daybreak to update). Is it safe to install and still use daybreak, any advice on what I should do?

 

[urherenow]

any advice on what I should do?

This might seem like I'm being a jerk to you, but I'm dead serious. The BEST thing you can do is read the docs of all the things you use, and read the change log when updating them... and stop using AIO updaters. Figure out how to configure everything the way YOU need them to be configured. AIO updaters include basic configuration files that overwrite what you already have. Bad news all around.

Daybreak isn't an AIO updater, nor is it something you install. It's already included with the latest versions of Atmosphere. This is simply what you use to update the system firmware (emmc cfw or emummc).

 

[Draxzelex]

Apologise for the confusion, i meant to say ofw and cfw emunand. I actually have Pokémon Scarlet game card with save file on ofw, then i created cfw emunand and downloaded the dlc and played the save file from ofw. So if i transfer the save file back to ofw where i do not have the dlc, would it be a problem?

Sorry but I'm still not following. You are able to boot OFW on emuMMC? As far as I'm aware, that is not possible.

First of all, because of the shops and Tinfoil. THAT is why you want to use wi-fi on CFW.

Secondly, you don’t need to have an attitude about it like you came into my thread to do. I asked for an answer, not a snarky response.

I and many others have never resorted to using shops so I don't find that reason enough. Also I was merely offering help. Nobody is going to want to help someone who bites the hand that feeds it and given that no one else has responded to your thread, it seems I am right.

I rebooted my Switch and now the emuMMC is stuck on a black screen after the Atmosphere logo. Sysnand boots OK. I've tried reinstalling Atmosphere and Hekate. This happened before but it was due to themes in the contents folder. There's nothing in there now so not sure what's causing it this time. What other steps can I try?

When you say "reinstalling Atmoshere & Hekate", what exactly do you mean? Did you copy and paste the new folders on top of the preexisting ones or did you delete the old folders then place the new ones on the SD card?

 

[Mohd_]

Sorry but I'm still not following. You are able to boot OFW on emuMMC? As far as I'm aware, that is not possible.

Of course not. They are separate. Physical game card and save file played on OFW. Transferred save file to CFW (on emummc) and played with DLC downloaded online. Wants to transfer back to OFW to play online tera raids but OFW doesn’t have DLC (did not buy).

 

[rave420]

I think you're understanding the proper terminology is hampering your progress. For one thing, the Switch uses an eMMC to store all of its software so you could not have possibly set up an eMMC unless you're implying you physically installed a new eMMC into your console. I could be wrong here but if I make an assumption or two, what you're referring to is not eMMC but emuMMC. Also, unless your hekate_ipl.ini file is really messed up, Hekate should display more than just "sysMMC". Because booting sysMMC is vague. You can boot sysMMC via Stock like in the first option or through CFW. That difference can make or break how you update sysMMC. Stock and sysMMC aren't two different things; technically they cannot even be compared to each other. Stock is a mode like CFW while sysMMC is a state similar to emuMMC. So now that you have a better understanding of Switch terminology, I believe you should review the facts and rephrase your question.

Yeah you are right, I checked again and did indeed meant to type emuMMC instead of eMMC.

Here is the question again, this time using the proper terms as well as the proper options present in Hekate_ipl.ini:

So, I got a first-production run RCM compatible switch which I have long since modded with Atmosphere. My original FW on the device is 9.0.0. It might be 9.0.1, but the point is, it's old. I've set up emuMCC which runs the latest Firmware, currently on 16.1.0. I followed the rentry guide word for word back in May, with great success.

Now, here's where I'm confused. I would very much like to get my OFW to the latest version as well, to play games I legitimately own online on stock or sysMMC. Hekate gives me the option of booting Stock, sysMMC (CFW), emuMMC (CFW), and Fusee (as well as Lockpick_RCM.bin). Both stock and sysMMC (CFW) are on 9.0.1. How do I update the firmware? Boot into stock and update through the system dialog? Or do I boot into sysMMC (CFW) and use Daybreak? I read that my OFW is so old that updating might render the game card reader slot inaccessible, and I would very much avoid this, and other issues in the process.

So, do I boot sysMMC (CFW) and update from 9.0.1 straight to 16.1.0 using Daybreak, or are there other considerations? I do have NAND backups, but I'm worried about permanently burning some fuse which might prevent proper operation of CFW, or my backup should I need to restore it.

 

[Billsley]

Also, it use to be that the led would flash red as a sign of success and and green was failure, that's not the case anymore. If I remember correctly it now just flashes green

Hi, thanks for the reply. I think the confusion was the whole hwfly and picofly firmwares (I didn't know they were different). I found the Correct file in the Picofly latest firmware and copied the .uf2 file over to the rp1-rp2 directory and the led flashed as you described. Its annoying that i would have successfully modded the V2 switch is was attempting only to think there was a problem and reverse the whole procedure. oh well. lesson learned. thanks for your help.

 

[tomy54332]

This might seem like I'm being a jerk to you, but I'm dead serious. The BEST thing you can do is read the docs of all the things you use, and read the change log when updating them... and stop using AIO updaters. Figure out how to configure everything the way YOU need them to be configured. AIO updaters include basic configuration files that overwrite what you already have. Bad news all around.

Daybreak isn't an AIO updater, nor is it something you install. It's already included with the latest versions of Atmosphere. This is simply what you use to update the system firmware (emmc cfw or emummc).

Sorry not daybreak lmao deepsea**

and yeah nah I totally understand, I bought my switch already modded so I didn't have to learn anything off the bat. I spent hours looking at docs, reddit, here etc trying to figure out how to safely update everything but it was a bit overwhelming and deepsea minimal install worked perfectly for me so I'll probably use it again tbh

And that's the reason I'm nervous about installing triplayer bc I've essentially done nothing to my cfw outside of installing games so I know the basic configuration that deep-sea installs will be fine but I'm worried if I add a sysmodule and install triplayer it will mess up the deepsea update next time.

 

[Billsley]

Need some advice, I also have a V1 switch that is exploitable, what is the easiest method of installing CFW? Also is there a way of not having to send a payload every boot? so you dont have to use a pc. does it matter what firmare the switch is (as it was updated to the newest 16. something) and if it does would that mean its needs a modchip?

 

[Draxzelex]

Of course not. They are separate. Physical game card and save file played on OFW. Transferred save file to CFW (on emummc) and played with DLC downloaded online. Wants to transfer back to OFW to play online tera raids but OFW doesn’t have DLC (did not buy).

Right but you cannot boot OFW on emuMMC. So if you aren't booting OFW on emuMMC, then what are you booting OFW on?

Yeah you are right, I checked again and did indeed meant to type emuMMC instead of eMMC.

Here is the question again, this time using the proper terms as well as the proper options present in Hekate_ipl.ini:

So, I got a first-production run RCM compatible switch which I have long since modded with Atmosphere. My original FW on the device is 9.0.0. It might be 9.0.1, but the point is, it's old. I've set up emuMCC which runs the latest Firmware, currently on 16.1.0. I followed the rentry guide word for word back in May, with great success.

Now, here's where I'm confused. I would very much like to get my OFW to the latest version as well, to play games I legitimately own online on stock or sysMMC. Hekate gives me the option of booting Stock, sysMMC (CFW), emuMMC (CFW), and Fusee (as well as Lockpick_RCM.bin). Both stock and sysMMC (CFW) are on 9.0.1. How do I update the firmware? Boot into stock and update through the system dialog? Or do I boot into sysMMC (CFW) and use Daybreak? I read that my OFW is so old that updating might render the game card reader slot inaccessible, and I would very much avoid this, and other issues in the process.

So, do I boot sysMMC (CFW) and update from 9.0.1 straight to 16.1.0 using Daybreak, or are there other considerations? I do have NAND backups, but I'm worried about permanently burning some fuse which might prevent proper operation of CFW, or my backup should I need to restore it.

Now the question is a lot more clear and easier to answer but before we proceed, there is something that must be cleared up. Updating the firmware doesn't render the game card reader slot inaccessible, at least on higher firmware versions. Updating the firmware does render the game card reader slot inaccessible on lower firmware versions and this could be relevant if a better exploit, such as untethered coldboot, is released someday in the future. To prevent this, the game card reader slot can be made inaccessible on higher firmware versions to preserve its function on lower firmware versions. This all depends on you as there is no right or wrong answer. You must decide if being able to access cartridges on a lower firmware version for a future theoretical exploit is more or less important than being able to play cartridges on modern firmware versions.

Regardless of which you prefer, you must also take into consideration whether or not you want to burn your anti-downgrade fuses. These are preserved for the same reason as the game card reader slot but fuses are easier to maintain. If you want to save your fuses, then it is a no brainer to use Daybreak to update the firmware since it does without triggering them. But if you don't care about downgrading or future hacks, then you can boot Stock and burn them without a second thought. I should mention that there is no advantage to burning fuses since Nintendo does not banned for mismatched fuse counts. However using Daybreak to update the firmware may trigger a ban. So is there a way to update the firmware without burning fuses that won't trigger a ban?

The answer is yes. There are two methods but I'm going to mainly advocate for one. The reason Daybreak preserves the fuses is because while in CFW, it prevents AutoRCM from being erased during system updates. If you update the firmware in Stock even if you have AutoRCM enabled, AutoRCM will be uninstalled before the procedure is done. So if you were to download the system update onto the console in advance while booted in Stock for example then go offline and reboot the console back into CFW, if you install the system update and have AutoRCM enabled, the firmware will be updated without burning fuses. This method is what I personally use and I haven't been banned yet.

The other method is far riskier and not generally advised. Since the method I previously mentioned involves CFW, there is still technically a slight chance of a ban. If you want to completely avoid any usage of CFW and homebrew but update the firmware without burning fuses, you can manually trigger RCM when the system update finishes installing. What this boils down to is having your jig inserted while the Switch is installing a system update and holding the volume (+) button so when it finishes, it will instead boot into RCM. The reason this method is not preferred is because you only have one chance to preserve your fuses. If your jig is not 100% efficient, you will not boot into RCM and your fuses will be irreversibly burnt.

There you have it. Those are all of known methods of updating the firmware without burning fuses. Whether you use any of those methods or none at all is totally up to you. Some people elect to burn the fuses since a new exploit hasn't been discovered since the scene's inception but no one knows what the future may hold.

Need some advice, I also have a V1 switch that is exploitable, what is the easiest method of installing CFW? Also is there a way of not having to send a payload every boot? so you dont have to use a pc. does it matter what firmare the switch is (as it was updated to the newest 16. something) and if it does would that mean its needs a modchip?

You don't "install" CFW; the way that the current exploit works renders it impossible to install any CFW. It is more accurate to say you setup CFW. And the exploit works by sending a payload every boot. If you don't want to send a payload, either do not turn off the console by leaving it in sleep mode or find a new exploit. If you don't want to use a PC to send a payload, you can have a trinket installed internally to send payloads automatically or buy a dongle that you can plug on the go to send payloads more conveniently. Lastly, firmware doesn't determine if your console is exploitable or not since you already pointed out your is already exploitable. The hardware determines if it needs a modchip or not. Unpatched Erista units don't need a modchip while every other device does which includes patched Erista consoles, Mariko, and the Switch Lite.

Anyway, here is a guide on how the Nintendo Switch. I always recommend this guide as it not only was the first Switch hacking guide to be released but it has also been regularly updated as the scene progressed.

Post automatically merged: Sep 24, 2023

I don't use my Switch as much and now it is mainly used as a Home Console for Local Multiplayer and Party Games.
For reference; I own 2 Switches. One is "modified" and the other is kept legit for online games such as Pokemon etc.

For years I've used SXOS because I enjoyed the XCI loading feature and being able to store my library on an external SSD that is connected to the dock and simply switch games on demand.
I've loaded Atmosphere several times to check it out, but always downgraded back to be able to use XCI (mainly, because I was too lazy to make the switch and since patching XCIs to work on lower firmwares does not work as reliable anymore).

I've researched and informed myself a couple of months ago, but have not yet made the upgrade and transfer to Atmosphere.

I already have Atsmophere and everything required to load it on my SD card. I don't have any EmuNAND or anything else. Since this modified Switch will never be used online, I have no fear of getting it banned.

The way I remember it, making the switch is as simple as removing SXOS from the SD Card and just load into Atmosphere instead.

My main question now is, how do I go from there? Do I need to uninstall everything I ever installed with SXOS? Can I simply install/overwrite the games again on Atmosphere using the title installers (I don't recall the names right now, was Goldleaf one of the installers?).

I would prefer to keep my save files, not sure if uninstalling the games will wipe the save data too.

You don't need to uninstall everything that you installed with SX OS. CFW isn't saved or installed to the console so the same applies to all of the games you installed. They were installed to the console itself. And if for whatever reason you decide to uninstall the games, it won't impact the save data. But the save data is stored on the console so that is also not tied to CFW.

 

[FliP0x]

You don't need to uninstall everything that you installed with SX OS. CFW isn't saved or installed to the console so the same applies to all of the games you installed. They were installed to the console itself. And if for whatever reason you decide to uninstall the games, it won't impact the save data. But the save data is stored on the console so that is also not tied to CFW.

So it should be as simple as loading into Atsmophere and launching the already installed games? Because I believe I tried that already some time ago and the games would not launch.

EDIT:
My bad, I previously only mounted the games using SXOS and probably did not install them. That's why they would not launch on Atmosphere. Could I in this case simply install the same XCIs using a title installer on Atmosphere?

 

[Rostodon]

When you say "reinstalling Atmoshere & Hekate", what exactly do you mean? Did you copy and paste the new folders on top of the preexisting ones or did you delete the old folders then place the new ones on the SD card?

First I pasted the new folders over the preexisting ones. That didn't work so I deleted the atmosphere folder and placed the new one on the SD card.

 

[Dust2dust]

My bad, I previously only mounted the games using SXOS and probably did not install them. That's why they would not launch on Atmosphere. Could I in this case simply install the same XCIs using a title installer on Atmosphere?

Yes, installing xci files works the same way as installing nsp or nsz files. DBI support all these file types. Don't forget to also update your sigpatches.

 

[Draxzelex]

So it should be as simple as loading into Atsmophere and launching the already installed games? Because I believe I tried that already some time ago and the games would not launch.

EDIT:
My bad, I previously only mounted the games using SXOS and probably did not install them. That's why they would not launch on Atmosphere. Could I in this case simply install the same XCIs using a title installer on Atmosphere?

You might be missing some patches. See, Atmosphere's developers are strictly anti-piracy so additional files are needed to play games that you don't own. You can download those patches from this thread. Also, you can just install .XCI files like you would an .NSP file. If you don't have a preferred title installer, I highly recommend TinWoo Installer. Its what I personally use and I never have any issues while using it.

First I pasted the new folders over the preexisting ones. That didn't work so I deleted the atmosphere folder and placed the new one on the SD card.

Well at least you tried deleting the folders. What was the last thing you did before your emuMMC stopped working?

 

[cirelachlan]

Hi, thanks for the reply. I think the confusion was the whole hwfly and picofly firmwares (I didn't know they were different). I found the Correct file in the Picofly latest firmware and copied the .uf2 file over to the rp1-rp2 directory and the led flashed as you described. Its annoying that i would have successfully modded the V2 switch is was attempting only to think there was a problem and reverse the whole procedure. oh well. lesson learned. thanks for your help.

No problem. Yeah, the information out there is all over the place. Especially for those modchips. Most information pertains to the rp2040 board and not the modchip it's based on so get use to asking questions when you need to and reading lots of forum posts. I think the longer those things are in circulation, the more updated start to finish tutorials will be for them.

 

[Rostodon]

Well at least you tried deleting the folders. What was the last thing you did before your emuMMC stopped working?

I added two files (for OAuth) into the switch/tinfoil folder. Deleting them didn't help though.

Edit: I managed to get it back up and running by deleting the atmosphere, config and bootloader folders, then copied over new versions from the HATS pack. However, when I reboot it goes to black again and I have to repeat the same process of deleting and adding new.

Edit 2: I was able to narrow it down even further to just deleting and replacing the config folder. Is there anything in there that would be causing the issue?

 

[Draxzelex]

I added two files (for OAuth) into the switch/tinfoil folder. Deleting them didn't help though.

Edit: I managed to get it back up and running by deleting the atmosphere, config and bootloader folders, then copied over new versions from the HATS pack. However, when I reboot it goes to black again and I have to repeat the same process of deleting and adding new.

Edit 2: I was able to narrow it down even further to just deleting and replacing the config folder. Is there anything in there that would be causing the issue?

I don't use the HATS pack so I'm not familiar with what it contains. Let's start by narrowing down how you launch Atmosphere. Do you use Hekate or fusee?

 

[FliP0x]

You might be missing some patches. See, Atmosphere's developers are strictly anti-piracy so additional files are needed to play games that you don't own. You can download those patches from this thread. Also, you can just install .XCI files like you would an .NSP file. If you don't have a preferred title installer, I highly recommend TinWoo Installer. Its what I personally use and I never have any issues while using it.

I followed the "Migrate SXOS to Atmosphere" guide. Got the sigpatches, latest Atsmophere release, hekate and fusee.bin and the custom .ini files that you are suggested to make.

I kept SXOS on the SD card because I need the SXOS Launcher to get into Hekate.

However, when I put the RCM jig in, insert the SXOS dongle and press VolUp and Power, I get a SXOS splash screen and instead of getting into the SXOS launcher, it straight up boots into SXOS. No idea why it does it and it didnt do this before.

 

[Hayato213]

I followed the "Migrate SXOS to Atmosphere" guide. Got the sigpatches, latest Atsmophere release, hekate and fusee.bin and the custom .ini files that you are suggested to make.

I kept SXOS on the SD card because I need the SXOS Launcher to get into Hekate.

However, when I put the RCM jig in, insert the SXOS dongle and press VolUp and Power, I get a SXOS splash screen and instead of getting into the SXOS launcher, it straight up boots into SXOS. No idea why it does it and it didnt do this before.

My guess is you have autoboot set to sx os.

 

[FliP0x]

My guess is you have autoboot set to sx os.

I didnt enable that option in SXOS.

If you mean the hekate_ipl.ini, autoboot is set to 0, which I assume is off.

 

[Rostodon]

I don't use the HATS pack so I'm not familiar with what it contains. Let's start by narrowing down how you launch Atmosphere. Do you use Hekate or fusee?

It's just the latest versions of Hekate, Atmosphere, Tinfoil and Sigpatches. I have a modded OLED so it boots into Hekate and I load CFW from the Launch menu.