Hacking SWITCH NOOB PARADISE - Ask questions here

[bupeapoop]

Personally, other than initial clean NAND backup that I've made prior to hacking, only other backups I make are when I update my SD card contents, more specifically whenever a new (problematic? e.g. from 16.1.0 to 17.0.0) firmware is released. I dump my emuNAND as well as my SD card contents (minus the folder where the games are stored, I find it easier to reinstall them rather than backing them up all the time). And that's pretty much it. If you had a file based-emuNAND, I making a backup more often would be understandable as it's probably more prone to data corruption than partition-based emuNAND.

If you feel the need to make monthly backups, go ahead. To me, personally, that isn't really necessary if you have a decent SD card (I have a SanDisk Extreme 256GB on both Switches) that you've previously tested with h2testw for possible defects and unless you have a file-based emuNAND (which you don't). Again, this is all coming from my personal experience.

Thanks for explaining your backup process. In essence, you like to keep things as simple as possible. That works with me also. As I play around with my Switch, I'll no doubt add more apps/modules to my SD Card so I'll most likely take another backup sooner rather than later, but once I get to a point where I'm happy with everything, I'll leave it at that.

When taking a new backup, do you tend to delete your existing emuNAND dump and create a new one using NxNandManager and the guide you recommended HERE?

If you have a spare external HDD to keep your Switch game backups, I'd keep their NSP and XCI files there. I've only installed the games that I plan to play in a near time on my SD card so, currently, it's only about half full. if you feel like installing the games all over again is a hassle, do make a full backup of your SD card with the games installed as well. I'd rather keep things simple and make a backup without games installed to it, and keep the game files on a separate HDD(s).

Yeah this is what I had in mind. Luckily, I have two External HDDs that are mirrored with one another as a fail safe in the event that one fails. This is where I currently have all my game backups store. I'll take your advice and keep my NSP and XCI files there and install the games I intend on playing using DBI.

My original plan was to simply fill my 400GB SD Card with as many game backups as possible, but I prefer your method of only installing games that I plan on playing in the near future. Is there a reason you keep your SD Cards memory half full? It wouldn't run any slower if you were close to maxing out your SDs full storage capacity would it?

Sure, it's the emummc.ini file, located in emuMMC folder. Contents of mine are the following:

[emummc]
enabled=1
sector=0x2
path=emuMMC/ER00
id=0x0000
nintendo_path=emuMMC/ER00/Nintendo

sector and id parameters are set automatically when you restore the backup, I believe. I don't remember setting them up manually, but it shouldn't be hard to find the values with the NxNandManager. path and nintendo_path I had to adjust as it wasn't set properly for me when I restored my backup when I was switching from old to a new SD card.

First, make sure that these folders exist. On my original setup, the folder within emuMMC wasn't called ER00 but something else, and that's the case for you as well. Restoring via NxNandManager expected me to have a Emutendo folder, which should be a Nintendo folder for emuNAND. Mine was named the same, i.e. Nintendo, but it was located inside the folder that was renamed to ER00 after the restore.

Thank you for clarifying. This is all good information that I never knew. I've went ahead and saved this information in a notepad file alongside my SD Backup content in the event I ever have to restore the backup.

Once again @Blythe93 thanks for all your effort in helping me clarify a few things. The last time I attempted to Jailbreak my Switch, it took me a good week or so to get everything up and running using the Rentry guide. Once it was all working fine, instead of me just leaving things the way they were, I couldn't stop playing around with things that I never fully understood. ended up tweaking the wrong file and corrupted the entire SD Card only days after getting it all up and running. A member here then advised me to start from scratch. Hearing the news that I had to start all over again was so disheartening that I put my Switch away and never touched it again until now. This was easily 18+ months ago. This is why I'm taking great care in ensuring I have a working backup this time around in case anything screws up!

 

[Blythe93]

When taking a new backup, do you tend to delete your existing emuNAND dump and create a new one using NxNandManager and the guide you recommended HERE?

Indeed, I only keep one backup that I've tested and that is working properly for me. And yes, that's the guide I use.

Is there a reason you keep your SD Cards memory half full? It wouldn't run any slower if you were close to maxing out your SDs full storage capacity would it?

Not really. I've just thought that it might be pointless to fill it fully as I don't play that many games apart from a select few. As for the SD card slowing down when full, my first Switch is almost full and I haven't noticed any kind of slowdown compared to my second Switch. If there is one, I didn't notice it. Games run just fine from my personal experience and I'm mainly playing first party Nintendo games.

Once again @Blythe93 thanks for all your effort in helping me clarify a few things. The last time I attempted to Jailbreak my Switch, it took me a good week or so to get everything up and running using the Rentry guide. Once it was all working fine, instead of me just leaving things the way they were, I couldn't stop playing around with things that I never fully understood. ended up tweaking the wrong file and corrupted the entire SD Card only days after getting it all up and running. A member here then advised me to start from scratch. Hearing the news that I had to start all over again was so disheartening that I put my Switch away and never touched it again until now. This was easily 18+ months ago. This is why I'm taking great care in ensuring I have a working backup this time around in case anything screws up!

You're welcome. ^^ I remember reading everything I could find about Switch hacking, all the tutorials that were relevant during that time and all the different CFWs that were available. It took me some time to figure out how to properly dual boot SX OS and Atmosphere in order to give that setup a try and it was good experience to say the least. I've learned a thing or two. Still, Atmosphere is the only one actively maintained so I eventually switched to Atmosphere completely.

Good luck with your Switching hacking efforts, may it serve you well for many years to come. Have fun!

 

[jgs88]

I'm able to play switch-games. hooray!
Thanks again Blythe for the patience and guiding

Is there also a fool-proof guide to be able to play other games like: gba, nds, snes (and maybe even other consoles?? playstation perhaps??)

And maybe another noob-question here: but if i want to get a bigger microSD, can I just copy all the games from 1 microSD to another, or do I have to go through the steps in the guide again? (not that it's difficult now, but just wondering)

 

[Blythe93]

Is there also a fool-proof guide to be able to play other games like: gba, nds, snes (and maybe even other consoles?? playstation perhaps??)

I'm not sure about guide, but you have a few options to choose from:
1) Nintendo Switch Online - on a modded system, all you need to have is linked NNID, either real of fake (fake can be easily set with linkalho). Only then you'll be able to run their emulators for NES, SNES, GB, GBA, N64 and Sega Genesis.
2) Retroarch for Switch - I haven't tested it out yet, but it has plenty of cores/emulators for different systems. Performance vary depending on which system you're trying to emulate. They have an instructional video for Switch so you can check that out.

There may be some other options available for some other systems, but I guess that those above will keep you busy for a while.

but if i want to get a bigger microSD, can I just copy all the games from 1 microSD to another, or do I have to go through the steps in the guide again? (not that it's difficult now, but just wondering)

If you have a file-based emuNAND, sure.
If you have a partition-based emuNAND, it's a bit more complicated. Here's the complete guide. I'd personally suggest NxNandManager method as it worked perfectly for me.

 

[jgs88]

I'm encountering another problem. It looks like I can't get big games copied to the microSD. Tried it with "usb file transfer" and by putting the microSD in the pc. I think it has something to do with files larger than 4GB?

Tried it with DBI > "Install title from DBIbackend", but it appears it doesn't 'find' the PC. Are there any other options to make it work?
Thanks in advance

 

[impeeza]

I'm encountering another problem. It looks like I can't get big games copied to the microSD. Tried it with "usb file transfer" and by putting the microSD in the pc. I think it has something to do with files larger than 4GB?

Tried it with DBI > "Install title from DBIbackend", but it appears it doesn't 'find' the PC. Are there any other options to make it work?
Thanks in advance

Why do you need to transfer files bigger than 4GB to your SD Card?

 

[Blythe93]

I think it has something to do with files larger than 4GB?

Indeed.

Tried it with DBI > "Install title from DBIbackend", but it appears it doesn't 'find' the PC. Are there any other options to make it work?

Check this reply of mine about how to make DBI backend work.

 

[impeeza]

Tried it with DBI > "Install title from DBIbackend", but it appears it doesn't 'find' the PC. Are there any other options to make it work?
Thanks in advance

It's infinetely better to use MTP responser of DBI, is more stable and quick.

 

[Blythe93]

Any suggestions on how to fix this?

Sigpatches that you've downloaded should come with sys-patch module, meaning that you shouldn't have issues running game backups. Double check that everything's in correct folder. Which guide did you follow?

 

[autumns]

if i update my sysnand to 18.0 can i leave my emunand on 17.0.1? is there any reason to or not to update it? i know some stuff like sysDVR and some overclocking i think are still broken in 18.0, will my emunand still have 17.0.1 compatibility with those or would it be 18.0 compatibility?

 

[impeeza]

if i update my sysnand to 18.0 can i leave my emunand on 17.0.1? is there any reason to or not to update it? i know some stuff like sysDVR and some overclocking i think are still broken in 18.0, will my emunand still have 17.0.1 compatibility with those or would it be 18.0 compatibility?

no problem at all.

 

[autumns]

if i haven’t burnt any extra fuses (19 burnt rn), and i downgrade from 18.0.0 back to 17.0.1 using daybreak on my cfw sysnand, is there a precedent for a ban risk with going online with a downgraded switch?

 

[Yoshi_yogurt]

I'm a bit confused by the hekate_ipl.ini file. I have seen some people have the different "Atmosphere fss0 CFW", "Atmosphere fss0 OFW" launch option in Hekate, while I got "CFW -sysMMC", "CFW -emuMMC", and "stock - sysMMC".
I have tried to read about the difference but im not sure what is the difference is. Is one better than the other?

My Hekate file is:

[config]
autoboot=0
autoboot_list=0
bootwait=0
autohosoff=0
autonogc=1
updater2p=1
backlight=100


[CFW - sysMMC]
fss0=atmosphere/package3 
kip1patch=nosigchk
atmosphere=1 emummc_force_disable=1 
icon=bootloader/res icon_payload.bmp

[CFW - emuMMC]
fss0=atmosphere/package3 
kip1patch=nosigchk 
emummcforce=1
atmosphere=1
icon=bootloader/res/icon_payload.bmp

[Stock - sysMMC]
fss0=atmosphere/package3 
emummc_force_disable=1
stock=1
icon=bootloader/res/icon_switch.bmp

 

[Draxzelex]

if i haven’t burnt any extra fuses (19 burnt rn), and i downgrade from 18.0.0 back to 17.0.1 using daybreak on my cfw sysnand, is there a precedent for a ban risk with going online with a downgraded switch?

If you updated online to firmware 18.0 then yes because Nintendo will expect your console to be on firmware 18.0 so downgrading will cause a mismatch and flag you for a ban.

I'm a bit confused by the hekate_ipl.ini file. I have seen some people have the different "Atmosphere fss0 CFW", "Atmosphere fss0 OFW" launch option in Hekate, while I got "CFW -sysMMC", "CFW -emuMMC", and "stock - sysMMC".
I have tried to read about the difference but im not sure what is the difference is. Is one better than the other?

My Hekate file is:

[config]
autoboot=0
autoboot_list=0
bootwait=0
autohosoff=0
autonogc=1
updater2p=1
backlight=100


[CFW - sysMMC]
fss0=atmosphere/package3
kip1patch=nosigchk
atmosphere=1 emummc_force_disable=1
icon=bootloader/res icon_payload.bmp

[CFW - emuMMC]
fss0=atmosphere/package3
kip1patch=nosigchk
emummcforce=1
atmosphere=1
icon=bootloader/res/icon_payload.bmp

[Stock - sysMMC]
fss0=atmosphere/package3
emummc_force_disable=1
stock=1
icon=bootloader/res/icon_switch.bmp

The "differences" you are talking about are just what people title the boot entries. As you can see, your boot entries are named "CFW - sysMMC", "CFW - emuMMC", and "Stock - sysMMC". However those are just interchangeable names that don't actually affect the boot process. The names you see are just other titles people come up for their hekate_ipl.ini files; the difference in names doesn't mean there's a different way of booting CFW. Regardless, the aforementioned names you spoke of involve "fss0" which all of your boot entries use if you notice that the first line of each has "fss0=package3" which really means there is no difference in your hekate_ipl.ini and the others you mentioned.

Hi!
After some initial troubles I am almost done with the process of getting everything working on AMS 18.0
After repeatedly being unable to play the games I installed with Awoo (not even sure if that piece of software is still relevant or not) I decided to try DBI.
The usual fun error message was "checking whether this software can be played".
When trying to install DBI it gave me an actual error that it could not find ES Sigpatches and as such could not find (generate?) a ticket.

I have tried a couple of sources (mostly through the forums here) to install said Sigpatches but the games still refuse to run.

Anything specific I could be overlooking?

Thanx in advance!

Did you use the patches from this thread?

 

[prof72]

I download the game "Tribes of Midgard Switch"
it started but forever loading
as i check the google it says it needs to be online

is it possible top play this offline?
maybe there is a needed file top open and play this since i am on JB

 

[axcxiii]

ok so I am completely new to modding my switch and I need help I have a serial number that starts with xkw5 and firmware version 18.0.0 animal crossing edition if that matters

 

[impeeza]

I'm a bit confused by the hekate_ipl.ini file. I have seen some people have the different "Atmosphere fss0 CFW", "Atmosphere fss0 OFW" launch option in Hekate, while I got "CFW -sysMMC", "CFW -emuMMC", and "stock - sysMMC".
I have tried to read about the difference but im not sure what is the difference is. Is one better than the other?

My Hekate file is:

[config]
autoboot=0
autoboot_list=0
bootwait=0
autohosoff=0
autonogc=1
updater2p=1
backlight=100


[CFW - sysMMC]
fss0=atmosphere/package3
kip1patch=nosigchk
atmosphere=1 emummc_force_disable=1
icon=bootloader/res icon_payload.bmp

[CFW - emuMMC]
fss0=atmosphere/package3
kip1patch=nosigchk
emummcforce=1
atmosphere=1
icon=bootloader/res/icon_payload.bmp

[Stock - sysMMC]
fss0=atmosphere/package3
emummc_force_disable=1
stock=1
icon=bootloader/res/icon_switch.bmp

https://github.com/CTCaer/hekate?tab=readme-ov-file#bootloader-configuration

Each hekate_ipl.ini entrance can be configured to load a payload, or load the PACKAGE3 file

FSS0 read the indicated PACKAGE3, then extract the needed code and create a modified bootloader.

If you use the PAYLOAD sentence the binary file is used as unmodified bootloader.

For the differences between OFW and CFW are:
On "Stock - SysNAND" only a minimal changes are fine and you system will load HOS which is the original Operative System of the console. This mode can only work on your physical EMMC chip also know as SysNAND.

CFW loads Atmosphère which is a set of modifications of the HOS allowing you to use homebrew. This mode can be loaded for your physical EMMC chip or for a emulated one, you can emulate you original NAND on a RAW partition of your SDCard or as a set of files (RAW or File based)
Then:

"CFW -sysMMC": loads Atmosphère on you original NAND
"CFW -emuMMC": loads Atmosphère on your emulated NAND
"stock - sysMMC" loads original OS if your console

 

[Ex000]

Hi im having problems with some games on tinfoil it keeps saying corrupted data detected for my smash bros. I have the latest sigpatches (i think) and my ams version is 1.7.0

Someone please help me out

Edit: forgot to also say it said when I downloaded the game failed to load nca?

Post automatically merged: Apr 7, 2024

 

[cityslicker]

If I install a mod chip, do I need a way to push a payload to the switch when I boot the device? Or does the switch automatically boot into hekate?

 

[Blythe93]

ok so I am completely new to modding my switch and I need help I have a serial number that starts with xkw5 and firmware version 18.0.0 animal crossing edition if that matters

As far as I can tell, that model's patched i.e. you'll need a modchip in order to hack it.

If I install a mod chip, do I need a way to push a payload to the switch when I boot the device? Or does the switch automatically boot into hekate?

As far as I know, it automatically boots into Hekate provided you have all the necessary files on your SD card. Otherwise you'll just get the "No SD card" screen.