Hacking SWITCH NOOB PARADISE - Ask questions here

Draxzelex

Well-Known Member
Member
Joined
Aug 6, 2017
Messages
19,011
Trophies
2
Age
29
Location
New York City
XP
13,379
Country
United States
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.
Well since you don't use fusee, you can only use either setup Hekate yourself or use a pre-configured pack that can launch into Atmosphere. For now, we will go with the absolute minimum setup required to launch Atmosphere through Hekate and use DeepSea minimal
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.
Not to worry as we won't be needing or booting SX OS anymore. Instead, you're going to remove the boot.dat on your SD card and download SX Gear to put in its place. Then you're going to take Hekate, rename it to payload.bin, and put it on the root of the SD card. If done correctly, you will be launching Hekate instead of SX OS when you insert the dongle.
 

FliP0x

Well-Known Member
Member
Joined
Aug 6, 2016
Messages
163
Trophies
0
Age
30
XP
320
Country
Croatia
Not to worry as we won't be needing or booting SX OS anymore. Instead, you're going to remove the boot.dat on your SD card and download SX Gear to put in its place. Then you're going to take Hekate, rename it to payload.bin, and put it on the root of the SD card. If done correctly, you will be launching Hekate instead of SX OS when you insert the dongle.
Thanks, I skipped that part assuming I already have SXOS and the dongle so I wouldn't need to install anything SX related.

I can now boot into Atmosphere and noticed the issue why I reverted back to SXOS in the past. Most of the games were mounted and those I cannot start, that is expected, but the installed NSPs are all corrupted. Assuming I will have to uninstall those and re-install on Atmosphere.

What would be the best way to get up-to-date now? I am currently still on 11.0.0 due to SXOS.

Do we still use Daybreak to install firmware without burning fuses?
 

Draxzelex

Well-Known Member
Member
Joined
Aug 6, 2017
Messages
19,011
Trophies
2
Age
29
Location
New York City
XP
13,379
Country
United States
Thanks, I skipped that part assuming I already have SXOS and the dongle so I wouldn't need to install anything SX related.

I can now boot into Atmosphere and noticed the issue why I reverted back to SXOS in the past. Most of the games were mounted and those I cannot start, that is expected, but the installed NSPs are all corrupted. Assuming I will have to uninstall those and re-install on Atmosphere.

What would be the best way to get up-to-date now? I am currently still on 11.0.0 due to SXOS.

Do we still use Daybreak to install firmware without burning fuses?
I vaguely remember this being an issue for anything installed with SX Installer. It applied to some patch to anything it installed that only SX OS uses rendering all of that content only playable in Atmosphere. If you did indeed install everything with SX Installer, you may need to reinstall everything. At any rate, yes you can use Daybreak to update the firmware without burning fuses. Usage is self-explanatory; the only tricky part is sourcing the firmware you wish to install. For that, there is Google.
 

Rostodon

Member
Newcomer
Joined
Feb 7, 2022
Messages
24
Trophies
0
Location
Toronto
XP
95
Country
Canada
Well since you don't use fusee, you can only use either setup Hekate yourself or use a pre-configured pack that can launch into Atmosphere. For now, we will go with the absolute minimum setup required to launch Atmosphere through Hekate and use DeepSea minimal
I deleted the atmosphere, bootloader and config folders from my SD card and added the DeepSea minimal pack. Launched emuMMC from Hekate and it's stuck on a black screen after the Atmosphere logo.
 

rave420

Well-Known Member
Member
Joined
Dec 21, 2010
Messages
277
Trophies
1
XP
212
Country
Canada
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.

Thank you for the thorough reply, I appreciate you taking your time and explaining this to me. A few points to note. I am not too concerned going back to a lower firmware version once I update, I am happy as can be to do the tethered coldboot with the jig every time. It's not really a hassle for me.

And yes, you're right, my understanding of the game card reader slot is wrong. I read up on it again, and indeed, certain firmware versions "update" the card reader slot, and going back to lower firmwares afterwards will lead to it being non-functional on those lower firmware versions. I'm not too bothered by it, provided that I can cleanly update and don't have to make use of my NAND backup at some point (which was made on the 9.1.0 FW version).
This is why I would still like to avoid burning any fuses if possible, but again I'm not really sure why I feel that way. Perhaps it's something about the hardware being permanently altered through a software update which rubs me the wrong way.

As for AutoRCM, I don't use it presently. I use the jig and tethered payload launcher maybe four times a year, the switch stays on unless I accidentally run the battery flat. Looking at the AutoRCM option in Hekate is causing me some concern. AutoRCM reads: "It can restore all versions of AutoRCM whenever requested. This corrupts the BCT and you can't boot without a custom bootloader." I have only superficial understanding of what this implies. Is the payload I inject when the console is in RCM considered the "bootloader", or what is the meaning of it? I'm hesitant turning it on without a proper understanding of what I'm getting myself into. I know what AutoRCM is supposed to accomplish, but with the warning and my lack of clear understanding has caused me to not consider it. Once I turn on AutoRCM, the console won't boot normally and instead default to RCM without needing a jig.

So now, if I understand you correctly, here is what you're advocating for (given that I want to preserve my fuses for vague reasons):
0. I make sure I am on the latest version of Atmosphere
1. I boot into my stock firmware
2. I download the system update through the system updater, but don't install it yet
3. I boot into Hekate, and enable AutoRCM
4. I boot into "(CFW) sysMMC", and install the previously downloaded update package through the system updater
5. After the update finishes installing, the console will reboot into RCM mode
6. From here, I can inject hekate, and boot all of my different configurations (CFW (sysMMC), CFW (emuMMC), Stock, Fusee)
7. Once everything works, I can disable AutoRCM again
8. Enjoy the latest FW on stock

My apologies if this is pretty obvious and self-explanatory. I really do need to mentally step through this one thing at a time. My worst fear is the switch becoming a brick and being unusable because of something I did with the software. I can handle a console ban (hell, I've been permanently offline for years now anyways), I can even live with a non-functional game card reader slot. Ideally I would like none of these things to happen though, and I get to use the switch on stock to play the games I own online.

Thank you very much for your time, reading guides is all fine and well, but there is no substitute for talking to someone who has done these things before. I also couldn't really find a clear answer in the guide regarding this either. Much appreciated, take care.
 

Draxzelex

Well-Known Member
Member
Joined
Aug 6, 2017
Messages
19,011
Trophies
2
Age
29
Location
New York City
XP
13,379
Country
United States
I deleted the atmosphere, bootloader and config folders from my SD card and added the DeepSea minimal pack. Launched emuMMC from Hekate and it's stuck on a black screen after the Atmosphere logo.
I think you still need the emummc.ini file found in the old /bootloader folder.
Thank you for the thorough reply, I appreciate you taking your time and explaining this to me. A few points to note. I am not too concerned going back to a lower firmware version once I update, I am happy as can be to do the tethered coldboot with the jig every time. It's not really a hassle for me.

And yes, you're right, my understanding of the game card reader slot is wrong. I read up on it again, and indeed, certain firmware versions "update" the card reader slot, and going back to lower firmwares afterwards will lead to it being non-functional on those lower firmware versions. I'm not too bothered by it, provided that I can cleanly update and don't have to make use of my NAND backup at some point (which was made on the 9.1.0 FW version).
This is why I would still like to avoid burning any fuses if possible, but again I'm not really sure why I feel that way. Perhaps it's something about the hardware being permanently altered through a software update which rubs me the wrong way.

As for AutoRCM, I don't use it presently. I use the jig and tethered payload launcher maybe four times a year, the switch stays on unless I accidentally run the battery flat. Looking at the AutoRCM option in Hekate is causing me some concern. AutoRCM reads: "It can restore all versions of AutoRCM whenever requested. This corrupts the BCT and you can't boot without a custom bootloader." I have only superficial understanding of what this implies. Is the payload I inject when the console is in RCM considered the "bootloader", or what is the meaning of it? I'm hesitant turning it on without a proper understanding of what I'm getting myself into. I know what AutoRCM is supposed to accomplish, but with the warning and my lack of clear understanding has caused me to not consider it. Once I turn on AutoRCM, the console won't boot normally and instead default to RCM without needing a jig.

So now, if I understand you correctly, here is what you're advocating for (given that I want to preserve my fuses for vague reasons):
0. I make sure I am on the latest version of Atmosphere
1. I boot into my stock firmware
2. I download the system update through the system updater, but don't install it yet
3. I boot into Hekate, and enable AutoRCM
4. I boot into "(CFW) sysMMC", and install the previously downloaded update package through the system updater
5. After the update finishes installing, the console will reboot into RCM mode
6. From here, I can inject hekate, and boot all of my different configurations (CFW (sysMMC), CFW (emuMMC), Stock, Fusee)
7. Once everything works, I can disable AutoRCM again
8. Enjoy the latest FW on stock

My apologies if this is pretty obvious and self-explanatory. I really do need to mentally step through this one thing at a time. My worst fear is the switch becoming a brick and being unusable because of something I did with the software. I can handle a console ban (hell, I've been permanently offline for years now anyways), I can even live with a non-functional game card reader slot. Ideally I would like none of these things to happen though, and I get to use the switch on stock to play the games I own online.

Thank you very much for your time, reading guides is all fine and well, but there is no substitute for talking to someone who has done these things before. I also couldn't really find a clear answer in the guide regarding this either. Much appreciated, take care.
AutoRCM corrupts BOOT0 which is used to launch the console normally. If its corrupt, the console does not launch and becomes "bricked". The reason I use quotation marks here is while that it is technically bricked, we can take advantage of this brick with the exploit. See since the console cannot launch normally, it instead boots into RCM. A similar effect is achieved when you remove the eMMC; in either case, this is more of a functional brick than a true brick. And thus, this eliminates the need for a jig to enter RCM.

AutoRCM is also required to prevent fuses from being burnt. Fuses are burnt when the console's stock bootloader detects a lower fuse count than the expected firmware. Say for example you just updated your console from firmware 1.0 to 3.0. When the firmware is done installing, the fuse count will still be at 1. That is when the console reboots. Once it reboots, the stock bootloader runs again and checks the firmware and the fuse count. It sees that the firmware is 3.0 but the fuse count is lower than expected so it burns fuses until it reaches the expected number for firmware 3.0. AutoRCM, or more specifically RCM, is triggered before the stock bootloader runs so we can avoid fuses from being burnt. This is also why some payloads act as substitute bootloaders; because we interrupted the normal launch sequence of the Switch, we need to inject our own. Not all payloads are bootloaders though. The easiest way to differentiate which ones are bootloaders and which ones aren't is by which payloads boot CFW/OFW; ones that load CFW/OFW double as bootloaders while the ones that don't aren't.

As for your steps, there are some adjustments that need to be made. For one, I recommend deleting the Wi-Fi settings once you download the system update just to avoid being online with CFW. The more important advice is that you do not disable AutoRCM as explained in the above paragraph. In short, AutoRCM keeps the fuses from being burnt so it must remain enabled for as long as you want to preserve your fuses. But now you might be asking, "Well how do I normally use my console without using CFW and burning fuses"? I admit I neglected to mention the usefulness of Stock Mode. As explained earlier, the stock bootloader burns fuses but the ones we inject via payloads won't. Hekate is an example of one. Hekate will not burn the fuses. Stock Mode is basically using Hekate to launch the console normally, as if you were using the stock bootloader, but without CFW. So in step 7, you will not be disabling AutoRCM but instead booting through Hekate, preferably Stock if you want to go online, if you wish to preserve your fuses.
 

FliP0x

Well-Known Member
Member
Joined
Aug 6, 2016
Messages
163
Trophies
0
Age
30
XP
320
Country
Croatia
New to using Atmosphere after I switched from SXOS.

I have the latest Atmosphere 1.5.5 running on latest OFW 16.1.0.

First, I installed Mario Kart 8 Ultimate, the update and the DLC using DBI, in that order (base game first, then update, then dlc). Installed successfully, even though it gave me an error for sigpatches (?), but I also installed the latest sigpatches (everything came in an all-in-one package that included atmosphere, hekate, sigpatches etc).
It installed regardless, but I can't launch the game. Just to be sure, I standalone downloaded the latest sigpatches for Atmosphere 1.5.5 and copied them where they should be, but no luck.

It gave me an error 2155-8007. Google told me this is because Nintendo servers are blocked, as they should be, and I found a suggestion to use Linkalho to unlink and relink my account. Did exactly that, except now I am stuck on Error 2124-0220 - A Nintendo Account is required.

Tried the Fake Nintendo Account option in Tinfoil, but it is not resolving the issue and Google is not suggesting anything else I can try.

What did I do wrong?
 

Hayato213

Newcomer
Member
Joined
Dec 26, 2015
Messages
19,952
Trophies
1
XP
20,987
Country
United States
New to using Atmosphere after I switched from SXOS.

I have the latest Atmosphere 1.5.5 running on latest OFW 16.1.0.

First, I installed Mario Kart 8 Ultimate, the update and the DLC using DBI, in that order (base game first, then update, then dlc). Installed successfully, even though it gave me an error for sigpatches (?), but I also installed the latest sigpatches (everything came in an all-in-one package that included atmosphere, hekate, sigpatches etc).
It installed regardless, but I can't launch the game. Just to be sure, I standalone downloaded the latest sigpatches for Atmosphere 1.5.5 and copied them where they should be, but no luck.

It gave me an error 2155-8007. Google told me this is because Nintendo servers are blocked, as they should be, and I found a suggestion to use Linkalho to unlink and relink my account. Did exactly that, except now I am stuck on Error 2124-0220 - A Nintendo Account is required.

Tried the Fake Nintendo Account option in Tinfoil, but it is not resolving the issue and Google is not suggesting anything else I can try.

What did I do wrong?

Why you using linkalho?
 

FliP0x

Well-Known Member
Member
Joined
Aug 6, 2016
Messages
163
Trophies
0
Age
30
XP
320
Country
Croatia
A ban is unlikely because I have been playing games just fine on SXOS prior to switching to Atmosphere. Nintendo servers were blocked on SXOS as well as Atmosphere, but on SXOS I never had the title verification pop up. That's probably the difference between XCI and NSP.

2155-8007 should in general mean that you were unable to connect to Nintendo servers, which can be due to a ban, or in this case they were blocked in the hosts file.

However, this is no longer relevant because I am stuck on error "Error 2124-0220 - A Nintendo Account is required" now.
 

Hayato213

Newcomer
Member
Joined
Dec 26, 2015
Messages
19,952
Trophies
1
XP
20,987
Country
United States
A ban is unlikely because I have been playing games just fine on SXOS prior to switching to Atmosphere. Nintendo servers were blocked on SXOS as well as Atmosphere, but on SXOS I never had the title verification pop up. That's probably the difference between XCI and NSP.

2155-8007 should in general mean that you were unable to connect to Nintendo servers, which can be due to a ban, or in this case they were blocked in the hosts file.

However, this is no longer relevant because I am stuck on error "Error 2124-0220 - A Nintendo Account is required" now.

I don't mean you really got banned, it just mean the system treat it like the system is banned if you blank out the serial #.
 

FliP0x

Well-Known Member
Member
Joined
Aug 6, 2016
Messages
163
Trophies
0
Age
30
XP
320
Country
Croatia
I did some messing around with linking, unlinking, creating new users and now I am back to error 2155-8007 - cant connect to Nintendo servers.

EDIT: I read that flight mode resolves this issue, but turning flight mode on and attemping to launch a game simply asks you to turn flight mode back off

EDIT2: Looks like I got it resolved, seems to have been related to the sig error I got during install. Installed another game and it ran just fine, to I deleted and installed mario kart which this time installed without errors and now launches normally
 
Last edited by FliP0x,

Hayato213

Newcomer
Member
Joined
Dec 26, 2015
Messages
19,952
Trophies
1
XP
20,987
Country
United States
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?

Sound like Emunand is broken, if it was theme it will throw the blue atmosphere error screen, did you upgrade the firmware before the emunand went black screen?
 

Rostodon

Member
Newcomer
Joined
Feb 7, 2022
Messages
24
Trophies
0
Location
Toronto
XP
95
Country
Canada
Sound like Emunand is broken, if it was theme it will throw the blue atmosphere error screen, did you upgrade the firmware before the emunand went black screen?
I didn't upgrade the firmware. I can get it to boot when i replace the atmosphere, bootloader and config folders. But on reboot it goes to black screen again.
 

Site & Scene News

Popular threads in this forum

General chit-chat
Help Users
  • No one is chatting at the moment.
    Psionic Roshambo @ Psionic Roshambo: I did use a bot for Diablo III though but no ban there lol