Hacking SWITCH NOOB PARADISE - Ask questions here

  • Thread starter Thread starter APartOfMe
  • Start date Start date
  • Views Views 6,005,036
  • Replies Replies 47,917
  • Likes Likes 66
Ok, so basically the steps would be:
1. Transfer the user from Oled to modded swtich
2. Create the emuNAND
3. Back-up save files in emuNAND (for example) using jksv
4. Edit the save files
4. Restore the edited save files then transfer save files from emuNAND to sysNAND using the mehtod of this video by Reclaimer Shawn:
5. Transfer user from stock to Oled Model again

Ignoring what Nintendo considers cheating, the steps should be alright?
For example, doing this process to edit a weapon in Zelda BotW (I suppose it isn't an online game) wouldn't be a problem, right?


Ignoring any ban questions (keeping yourself safe is of course your responsibility.)

I’ve not done it specifically with Goldleaf on the system and going Read/Write directly into the mounted USER: partition but this method does avoid soiling your clean Sysnand with CFW/Homebrew and will allow you to communicate with Ninty to xfer Cloud Saves and the like.

@ReclaimerShawn is a sharp guy and his method in the video makes good sense.

Be careful around the game directory names as they will diverge as you install different games on your Emunand that you don’t install on your a Sysnand and vice versa.
Post automatically merged:

if you want I have already used st link v2 and no it was impossible to connect it to the computer. and I sent it back I should have a new one this week.

Good deal. It’s too bad this happened to you. Using STLink to recover is pretty much last resort so sending it back was quickly becoming your only option anyway. I hope your new one behaves better for you!
 
Hello, again and again,

I'm performing the setup for atmosphere and I have a quite technical question (that is not necessary to start atmosphere but necessary for my own sanity).

I have from hekate (I guess it comes from hekate), the hekate_ipl.ini file which is exactly :
[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

Now, on rentry, it indicates for Erista enuNAND (https://rentry.org/EristaEmuNAND) :
[config]
autoboot=0
autoboot_list=0
bootwait=3
backlight=100
autohosoff=0
autonogc=1
updater2p=0
bootprotect=0

[Atmosphere CFW]
payload=bootloader/payloads/fusee.bin
icon=bootloader/res/icon_payload.bmp

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

Ok can someone explain why there is a need to modify this file ? I mean I would guess that for example the line [CFW - emuMMC] would give the exact same result as [Atmosphere CFW] but the contents of both is very different ? Nothing is linked to what is called fss0 in the second one, emummcforce disappears in the second one, the second one have a link to fusee.bin in the line payload that the first do not have etc etc etc..

Can someone explain line by line what those parameters do and why they are so different from the hekate original file and the one from rentry ?

edit : Just checked the [config] lines and even here there is a difference for example in updater2p

Thanks
 
Hello, again and again,

I'm performing the setup for atmosphere and I have a quite technical question (that is not necessary to start atmosphere but necessary for my own sanity).

I have from hekate (I guess it comes from hekate), the hekate_ipl.ini file which is exactly :
[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

Now, on rentry, it indicates for Erista enuNAND (https://rentry.org/EristaEmuNAND) :
[config]
autoboot=0
autoboot_list=0
bootwait=3
backlight=100
autohosoff=0
autonogc=1
updater2p=0
bootprotect=0

[Atmosphere CFW]
payload=bootloader/payloads/fusee.bin
icon=bootloader/res/icon_payload.bmp

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

Ok can someone explain why there is a need to modify this file ? I mean I would guess that for example the line [CFW - emuMMC] would give the exact same result as [Atmosphere CFW] but the contents of both is very different ? Nothing is linked to what is called fss0 in the second one, emummcforce disappears in the second one, the second one have a link to fusee.bin in the line payload that the first do not have etc etc etc..

Can someone explain line by line what those parameters do and why they are so different from the hekate original file and the one from rentry ?

Thanks
I've explained multiple time that rentry is actually a bad guide and I'm surprised people recommend it. The best Switch hacking guide in the scene is switch.homebrew.guide. Forcing users to change their hekate_ipl.ini speaks to an agenda instead of giving users the freedom to choose what they want. I highly recommend starting over and following the guide I posted instead.
 
  • Like
Reactions: BigOnYa
Should I remove everything I have copied on my SD card then ? I have not started anything not modifying anything yet

edit : I've checked the guide you proposed. There are not much information as far as I can tell about this hekate_ipl.ini file, it just says : "If you downloaded Hekate by itself then you needed to create a hekate_ipl.ini file in your bootloader folder. That is outside the scope of this guide. If you don’t know how to do that then use the SDSetup bundle". Which does not give me much more information that I already have.

It is even different :

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

[CFW (sysMMC)]
emummc_force_disable=1
fss0=atmosphere/package3
icon=bootloader/res/icon_payload.bmp

[CFW (emuMMC)]
emummcforce=1
fss0=atmosphere/package3
icon=bootloader/res/icon_payload.bmp

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

[Fusee]
icon=bootloader/res/icon_payload.bmp
payload=bootloader/payloads/fusee.bin

edit2 : Just found that there are a lot of information in the hekate github page... Have not seen it https://github.com/CTCaer/hekate. Nonetheless I still have difficulties to understand the modification from fss0 to payload and the removal of some elements/modification of others such as emummcforce.
 
Last edited by Temaps,
I've explained multiple time that rentry is actually a bad guide and I'm surprised people recommend it. The best Switch hacking guide in the scene is switch.homebrew.guide. Forcing users to change their hekate_ipl.ini speaks to an agenda instead of giving users the freedom to choose what they want. I highly recommend starting over and following the guide I posted instead.
I wouldn't call the rentry guide a bad one. Sure, it's not perfect, but it covers way more topics of interest to a beginner than the one you recommend, which is by no means a bad guide, but just incomplete. The rentry one is meant as a resource. You want to do this, read this section. Or you want to do that, read this other section. If it's consulted as such, it's very helpful. Recommending to new users to avoid the rentry guide just because you prefer the older switch.homebrew.guide is misguiding them at best. To each their own, but every guide can be useful when used correctly, and they complement each other.
 
I wouldn't call the rentry guide a bad one. Sure, it's not perfect, but it covers way more topics of interest to a beginner than the one you recommend, which is by no means a bad guide, but just incomplete. The rentry one is meant as a resource. You want to do this, read this section. Or you want to do that, read this other section. If it's consulted as such, it's very helpful. Recommending to new users to avoid the rentry guide just because you prefer the older switch.homebrew.guide is misguiding them at best. To each their own, but every guide can be useful when used correctly, and they complement each other.

Agreed. To each their own.
I don’t have an agenda or refer people to only use reentry.
I do prefer to work with the reentry guide for the reasons listed above.
That said, I help everyone regardless of the guide they are using with the question they are asking. I have no dog in this hunt.
 
Last edited by binkinator,
  • Like
Reactions: BigOnYa
Hello all, on my side I'm not challenging which guide should be used as I would obviously not be able to do so. I accept to use all of them (proposed recently in this thread) to get an overall idea of the thing. I'm just a bit lost about the parameters that are written in the hekate_ipl.ini file. Mainly :

can someone explain why there is a need to modify this file ? I mean I would guess that for example the line [CFW - emuMMC] would give the exact same result as [Atmosphere CFW] but the contents of both is very different ? Nothing is linked to what is called fss0 in the second one, emummcforce disappears in the second one, the second one have a link to fusee.bin in the line payload that the first do not have etc etc etc..
Anyone has a good explanation maybe ? Open to any clarification as I really do not understand why the initial one called [CFW - emuMMC] do not seem to be sufficient (as there are clearly modifications in both guides for the hekate_ipl.ini file)
 
  • Like
Reactions: binkinator
Hello all, I'm not challenging which guide to be used as I would obviously not be able to do so. I'm just a bit lost about the parameters that are written in the hekate_ipl.ini file. Mainly :


Anyone has a good explanation maybe ? Open to any clarification as I really do not understand why the initial one called [CFW - emuMMC] do not seem to be sufficient
It‘s a choice between booting original fusee.bin which is the Atmosphere way vs booting via fss0 which is the Hekate way.

Both will get you CFW.

I use the payload/fusee.bin way to start most of the time but also do fss0/package3 on my personal switch. The biggest reason for me is silly…using package3 gives you the opportunity to change one of the bootlogos during boot up! I keeps my Switches like NASCAR! LOL

The Hekate way reads all your configs in the hekate_ipl.ini giving you more flexibility while the fusee.bin way ignores the configs and just boots with some predetermined defaults which is simpler.

The docs in the readme in the link below go into exquisite detail about all the options so you can decide how you would like to boot. I often recommend starting off with fusee.bin to get started and then convert to fss0 once you know everything works. I like the bells and whistles! :-)

https://github.com/CTCaer/hekate
 
Last edited by binkinator,
  • Like
Reactions: Temaps
Oh ok, so

[Atmosphere CFW]
payload=bootloader/payloads/fusee.bin

and

[CFW - sysMMC]
fss0=atmosphere/package3

Would both boot atmosphere with the possibility to start homebrew from the hbmenu etc... ? (not talking about other parameters from the hekate_ipl.inif file). So basically, I can just let the .ini file that was pre-filled from the sigpatches or change to the one presented in the guides, they would both boot in atmosphere EmuNAND

edit : isn't fss0 the atmosphere way ? Because I see
fss0={FILE path} Takes an Atmosphere package3 binary (formerly fusee-secondary.bin) and extracts all needed parts from it. kips, exosphere, warmboot and mesophere if enabled.

edit 2 : I complete my edit 1 with another question, how the system can know I want to boot into emuNAND when there is no information regarding emuNAND in the hekate_ipl.ini (see below from rentry).

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

[Atmosphere CFW]
payload=bootloader/payloads/fusee.bin
icon=bootloader/res/icon_payload.bmp

[Stock SysNAND]
fss0=atmosphere/package3
stock=1
emummc_force_disable=1
icon=bootloader/res/icon_switch.bmp
 
Last edited by Temaps,
Oh ok, so

[Atmosphere CFW]
payload=bootloader/payloads/fusee.bin

and

[CFW - sysMMC]
fss0=atmosphere/package3

Would both boot atmosphere with the possibility to start homebrew from the hbmenu etc... ?

Corrent in that they both boot Amosphere HOWEVER, they would boot different *Nands.

The first one will default CFW on your Emunand if it's available.
The second one will boot CFW on your Sysnand.

(not talking about other parameters from the hekate_ipl.inif file). So basically, I can just let the .ini file that was pre-filled from the sigpatches or change to the one presented in the guides, they would both boot in atmosphere EmuNAND

edit : isn't fss0 the atmosphere way ? Because I see
fss0={FILE path} Takes an Atmosphere package3 binary (formerly fusee-secondary.bin) and extracts all needed parts from it. kips, exosphere, warmboot and mesophere if enabled.

Everything hack-wise is HOS w/ CFW at the end of the day.


If you talk to the Atmosphere team they will recommend you download fusee.bin from their GitHub releases page and inject it and job done.

If you talk to the Hekate folks they will prefer fss0 and opening up the bootloader options for some on-the-fly customization. They produce a bootloader after all. This is what a bootloader does. :-)

payload= or the "Payloads" button in Hekate will "chain-load" or load another payload without using Hekate's launch configs. Things such as "emummcforce=1" will be ignored. And atmosphere will use it's own configs.

fss0= will load a payload from Hekate with Hekate's configs telling what settings it should use. Configs like "kip1patch=nosigchk" in the launch config options will be used.

 
  • Like
Reactions: Temaps
The second one will boot CFW on your Sysnand.
Oh my bad I copied the wrong line, I meant
[CFW - emuMMC]
fss0=atmosphere/package3
kip1patch=nosigchk
emummcforce=1
atmosphere=1
icon=bootloader/res/icon_payload.bmp
Basically I understood they are kinda both the same.

I have completed my previous post with an edit 2, let me paste it again for clarification

edit 2 : I complete my edit 1 with another question, how the system can know I want to boot into emuNAND when there is no information regarding emuNAND in the hekate_ipl.ini (see below from rentry).
[config]
autoboot=0
autoboot_list=0
bootwait=3
backlight=100
autohosoff=0
autonogc=1
updater2p=0
bootprotect=0
[Atmosphere CFW]
payload=bootloader/payloads/fusee.bin
icon=bootloader/res/icon_payload.bmp

[Stock SysNAND]
fss0=atmosphere/package3
stock=1
emummc_force_disable=1
icon=bootloader/res/icon_switch.bmp
 
If you can‘t open boot0 on your emunand it is likely corrupt.

You should probably copy your data off to your PC and reformat the SDCard using Hekate. You will likely lose your installed games and have to reinstall them.

You can attempt to backup your game saves like so:


Here’s how to rehack your switch once you’ve backed everything up.
Thank you for the advice Binkinator. I tried to rehack after formatting the SDCard to FAT32 format to minimise future corruption.
Launched Hekate 6.01 and created a partition based emuNAND, but neither 1.4.0 nor 1.4.1 atmosphere will boot for me.
It briefly displays the atmosphere logo then its just a black screen.
Does it matter that the card was previously in exFat format?
 
Thank you for the advice Binkinator. I tried to rehack after formatting the SDCard to FAT32 format to minimise future corruption.
Launched Hekate 6.01 and created a partition based emuNAND, but neither 1.4.0 nor 1.4.1 atmosphere will boot for me.
It briefly displays the atmosphere logo then its just a black screen.
Does it matter that the card was previously in exFat format?
It definitely doesn’t matter how it was formatted before.

What does your /bootloader/hekate_ipl.ini file look like?

If you did the fusee.bin version did you make sure to download it from the Atmosphere release page and place it in /bootloader/payloads/fusee.bin?

https://github.com/Atmosphere-NX/Atmosphere/releases
Post automatically merged:

Oh my bad I copied the wrong line, I meant
[CFW - emuMMC]
fss0=atmosphere/package3
kip1patch=nosigchk
emummcforce=1
atmosphere=1
icon=bootloader/res/icon_payload.bmp
Basically I understood they are kinda both the same.

I have completed my previous post with an edit 2, let me paste it again for clarification


[config]
autoboot=0
autoboot_list=0
bootwait=3
backlight=100
autohosoff=0
autonogc=1
updater2p=0
bootprotect=0
[Atmosphere CFW]
payload=bootloader/payloads/fusee.bin
icon=bootloader/res/icon_payload.bmp

[Stock SysNAND]
fss0=atmosphere/package3
stock=1
emummc_force_disable=1
icon=bootloader/res/icon_switch.bmp
You got it! Those two will boot essentially the same, CFW on Emunand (provided emunand exists)

Hekate/fss0 spells it out. Fusee.bin ignores the configs listed and assumes its own defaults.
 
Last edited by binkinator,
Understood, thank you but how with this specific line
[Atmosphere CFW]
payload=bootloader/payloads/fusee.bin
icon=bootloader/res/icon_payload.bmp
the system (atmosphere/hekate) knows I want to boot in emuNAND ?
 
Understood, thank you but how with this specific line
[Atmosphere CFW]
payload=bootloader/payloads/fusee.bin
icon=bootloader/res/icon_payload.bmp
The system (atmosphere/hekate) knows I want to boot in emuNAND ?

Yes. Fusee.bin defaults to Emunand (if available.)

The icon flag is read by Hekate and displayed but after it chainloads fusee.bin all other options are ignored.
 
  • Like
Reactions: Temaps
Oh it is some kind of internal hidden parameter that defaults the boot to emuNAND !
I've learnt so much in the past days thanks a lot. I'll install atmosphere now, I guess I'll come into errors as lucky as I am... Let's hope for the best

Ahem one more question again, in the rentry guide it indicates bootprotect=0. I've checked hekate github and I do not like setting it to 0, is there any reason for that ?

0: Disable, 1: Protect bootloader folder from being corrupted by disallowing reading or editing in HOS.
 
Oh it is some kind of internal hidden parameter that defaults the boot to emuNAND !
I've learnt so much in the past days thanks a lot. I'll install atmosphere now, I guess I'll come into errors as lucky as I am... Let's hope for the best

Ahem one more question again, in the rentry guide it indicates bootprotect=0. I've checked hekate github and I do not like setting it to 0, is there any reason for that ?
If you are concerned about accidentally modifying things in your /bootloader/ directory or are concerned that a nefarious homebrew package might do so you will want to set this to 1. You will still be able to pop your SDCard out (or mount it via Hekate over UMS) to make changes on your PC since this setting means nothing to Windows.

For example:

Setting this to one will prevent your from using things like FTP to log into your Switch and changing your hekate_ipl.ini icons to point to different graphics because the entire /bootloader/ folder is protected. I find being able to make these changes remotely quite handy so mine is set to 0. The choice is yours though. Safely first! :-)
 
It definitely doesn’t matter how it was formatted before.

What does your /bootloader/hekate_ipl.ini file look like?

If you did the fusee.bin version did you make sure to download it from the Atmosphere release page and place it in /bootloader/payloads/fusee.bin?
The ipl file configuration:

[config]
autoboot=0
autoboot_list=0
bootwait=3
backlight=100
autohosoff=0
autonogc=1
updater2p=0
bootprotect=0
[Atmosphere CFW]
payload=bootloader/payloads/fusee.bin
icon=bootloader/res/icon_payload.bmp
[Warmboot Error Fix]
fss0=atmosphere/package3
stock=1
emummc_force_disable=1
icon=bootloader/res/icon_switch.bmp

Yes, I made sure to update fusee.bin according to each version attempted.
 

Site & Scene News

Popular threads in this forum