Hacking Sigpatches for Atmosphere (Hekate, fss0, fusee & package3)

[miniminx]

Why not? If you know what to test toy can test. I just tested sigpatches and they are working. No big changes. I do not use auto patcher, because prefer to do sig patches the old way.

Yes, my appologies - I am a noob when if comes to the switch. I will just wait until hekate and AtmosphereNX are are released on the github pages and then use patches that are in this thread as impeeza does a good job keeping them up to date.

 

[Sabregod]

Do you still need sys-patch if you're already using a modified fusee.bin with latest sigpatches but everything is working fine?

 

[duckbill007]

Of course not. You need either syspatch or set of sigpatches.

 

[Sabregod]

Of course not. You need either syspatch or set of sigpatches.

Ok thanks. I've been out of the switch scene for a couple of years and decided to finally update Atmosphere/Hekate/CFW. I initially looked for Youtube tutorials but it turns out there are lot of things are not mentioned such us the use of sys-patch, or using patched fusee.bin.

After I updated, I spent a while troubleshooting why I'm unable to install XCI games or NSP apps. The installations either result in corrupted data, or a new icon appears, but it’s blank with a spinning loading wheel inside. It turns out I shouldn't use the original fusee that comes with default Atmosphere, and need to use a modified fusee.bin.

 

[miniminx]

Ok thanks. I've been out of the switch scene for a couple of years and decided to finally update Atmosphere/Hekate/CFW. I initially looked for Youtube tutorials but it turns out there are lot of things are not mentioned such us the use of sys-patch, or using patched fusee.bin.

After I updated, I spent a while troubleshooting why I'm unable to install XCI games or NSP apps. The installations either result in corrupted data, or a new icon appears, but it’s blank with a spinning loading wheel inside. It turns out I shouldn't use the original fusee that comes with default Atmosphere, and need to use a modified fusee.bin.

You can use hekate with the updated patches.ini instead of a modded fussee.bin, or so I am led to believe from reading some posts in this thread. Also you can use modded fussee.bin instead to use IPS patches. OR you can use the latest Sys-patch (when that gets updated for the newest firmware). Someone like impeeza can clarify this though as I am not that good with the switch.

 

[kidkat210]

You can use hekate with the updated patches.ini instead of a modded fussee.bin, or so I am led to believe from reading some posts in this thread. Also you can use modded fussee.bin instead to use IPS patches. OR you can use the latest Sys-patch (when that gets updated for the newest firmware). Someone like impeeza can clarify this though as I am not that good with the switch.

What ya said is pretty spot on, here a post I made laying it out

its your boot method. since ams 1.7, ips patches no longer work with fuse.bin (Link scroll down to "fusee no longer supports applying IPS patches to KIPs."). thanks to that change not all the patches for sig patches get loaded. so you got some options to fix this.
1) use a modified version of fuse,bin that re enables ips patches.
2) use a fairly new sys-module called sys-patch (link to op for info) (since the dev of it got a C&D for the project, it got dropped but some members of the community keep it alive - Download Link
3) use hekate's fss0 method of booting atmosphere

 

[duckbill007]

IPS patches are made with mrdude's ips patch generator... So I mean that patches generated with that app are generated by searching that pattern. And it seems that's not found in the firmware files (the pattern)...

I just compared IPS patch generator sources and sys-patch sources. They are using different patterns. So, they produce patches that changes different places of code (I do not say that one or another wrong, code can be pached in different ways).

So, if you use both sigpatches and sys-patch, then sys-patch can inform you wrong: it can give you red line because module already patched, but in different way, so sys-patch can not neither find own pattern nor detect that it prepatched.

 

[theuuaad]

What ya said is pretty spot on, here a post I made laying it out

I think using modified version of fuse is better than using fss0. If you choose to restart instead of shutting down on devices with RCM functionality, fss0 will not be used. However, on devices with RCM patched, this issue will not occur. I don't know if it's a problem with my settings or if everyone else has it

 

[josete2k]

I think using modified version of fuse is better than using fss0. If you choose to restart instead of shutting down on devices with RCM functionality, fss0 will not be used. However, on devices with RCM patched, this issue will not occur. I don't know if it's a problem with my settings or if everyone else has it

Just replace the reboot_payload.bin file with hekate's payload.

Done.

 

[Badablek]

I think using modified version of fuse is better than using fss0. If you choose to restart instead of shutting down on devices with RCM functionality, fss0 will not be used. However, on devices with RCM patched, this issue will not occur. I don't know if it's a problem with my settings or if everyone else has it

definitively a problem with your setup. I'm using fss0 on all my switch since the beginning without a problem, even when rebooting.
using modified payload (at least from unthrusted sources) is way more hazardous than (correctly) configuring Hekate !

and no need to replace anything like suggested. Just use hekate "special" feature in [config] section of hekate_ipl.ini :

updater2p=1

0: Disable, 1: Force updates (if needed) the reboot2payload binary to be hekate.

source (hekate github)

 

[theuuaad]

definitively a problem with your setup. I'm using fss0 on all my switch since the beginning without a problem, even when rebooting.
using modified payload (at least from unthrusted sources) is way more hazardous than (correctly) configuring Hekate !

and no need to replace anything like suggested. Just use hekate "special" feature in [config] section of hekate_ipl.ini :

updater2p=1

0: Disable, 1: Force updates (if needed) the reboot2payload binary to be hekate.

Thank you, the issue has been resolved!!

Also, I would like to know if the configuration in \atmosphere\config\ takes effect when using fss0 to boot a system with cal0blank=1? I seem to have noticed that I need to configure another exosphere.ini file in the root directory separately? Are system_Settings.ini and stratopole.ini affected

Will these configurations take effect if cal0blank=1 is not used?

 

[josete2k]

definitively a problem with your setup. I'm using fss0 on all my switch since the beginning without a problem, even when rebooting.
using modified payload (at least from unthrusted sources) is way more hazardous than (correctly) configuring Hekate !

and no need to replace anything like suggested. Just use hekate "special" feature in [config] section of hekate_ipl.ini :

updater2p=1

0: Disable, 1: Force updates (if needed) the reboot2payload binary to be hekate.

source (hekate github)

I choose replace payload because that updater2p option doesn't work if you launch fusee via hekate...

 

[Badablek]

Thank you, the issue has been resolved!!

Also, I would like to know if the configuration in \atmosphere\config\ takes effect when using fss0 to boot a system with cal0blank=1? I seem to have noticed that I need to configure another exosphere.ini file in the root directory separately? Are system_Settings.ini and stratopole.ini affected

all config files go to atmosphere\config EXCEPT exosphere.ini which must be put at the root of the microSD card
(I don't know why this particular file must be there, but I think sciresM had a good reason to do it so)


"This is the configuration file used by exosphère. This file is located in the root of your SD card and a default template can be found inside the /atmosphere/config_templates/ folder."


source (atmosphere github)


@josete2k if you chainload fusee from hekate, shouldn't reboot2payload be able to reboot from atmosphere to atmosphere ? (just for my own curiosity, I never tried because I hate chainloading )

 

[theuuaad]

all config files go to atmosphere\config EXCEPT exosphere.ini which must be put at the root of the microSD card
(I don't know why this particular file must be there, but I think sciresM had a good reason to do it so)


"This is the configuration file used by exosphère. This file is located in the root of your SD card and a default template can be found inside the /atmosphere/config_templates/ folder."


@josete2k if you chainload fusee from hekate, shouldn't reboot2payload be able to reboot from atmosphere to atmosphere ? (just for my own curiosity, I never tried because I hate chainloading )

Is there any particular requirement for using fuse and package3? For package3, I only know that an additional kip1patch=nosigchk and patches.ini are needed, while using fuse directly does not require them, which seems to have become more complicated. After the fuse change did not support loading patches, I felt that many configurations needed to be changed

 

[Badablek]

Is there any particular requirement for using fuse and package3? For package3, I only know that an additional kip1patch=nosigchk and patches.ini are needed, while using fuse directly does not require them, which seems to have become more complicated. After the fuse change did not support loading patches, I felt that many configurations needed to be changed

not true anymore (directly loading sigpatches from fusee), since atmosphere 1.7.0 (with vanilla fusee of course). But using fss0 or fusee (chainloading) is only a matter of choice, there is no reason to use one or an other, except from your own feeling on the subject. For my part, my own choice is to use the least binaries possible to avoid any conflict or bug (mathematically, having two binaries can lead to more bugs or bad interactions between it). Chainloading fusee from Hekate, IMHO, is a bad behavior, as you use two binaries (hekate → fusee) to achieve boot...when using fss0, you use only one (hekate). I'm not saying fss0 is better or the only "good" way, but as Hekate can open package3 without fusee, why not using it ?!


now, a lot of people uses sys-patch instead of sigpatches...and as a sysmodule, it's automatically loaded when Atmosphere starts. So it's even easier than anything else (works with fss0 and chainloading fusee). Even with sigpatches, you make your hekate config once for all

fss0 relies only on official vanilla tools
fusee (for those you want to use only sigpatches) relies now on hazardous modified payload fusee.bin

easy choice (for me ).


ps : as a fss0 user, the only changes I made since the beginning of the hack (since day one) are : changing some naming convention when Atmosphere has reached version 1.0.0 and removing the line to load sigpatches when I decided, myself, to move on with sys-patch. No, not many configurations have needed to be changed (2 changes in6 years, not that bad !)


but again, this is my point of view, which can be shared or not by others

 

[ztc8850]

When I use the signpatched for firmware 19 it says "could not start the software Pleas try again from HOME menu?

 

[Blythe93]

When I use the signpatched for firmware 19 it says "could not start the software Pleas try again from HOME menu?

As far as I know, sigpatches right now are incomplete and there's no official release of the Atmosphere with the 19.0.0 support. If you're on emuNAND, revert back to 18.1.0 and wait for the Atmosphere and sigpatches/sys-patch to get updated (maybe Hekate as well?). I guess that there aren't many games out there that require 19.0.0 in order to work.

 

[miniminx]

As far as I know, sigpatches right now are incomplete and there's no official release of the Atmosphere with the 19.0.0 support. If you're on emuNAND, revert back to 18.1.0 and wait for the Atmosphere and sigpatches/sys-patch to get updated (maybe Hekate as well?). I guess that there aren't many games out there that require 19.0.0 in order to work.

Yep one of the FS patches needs fixed. ES patches work so you can launch installed NSP games, FS patches partially work in that I can run XCI games (tested on looney tunes wwos), NRO forwarders are not working for now. You'll just need to wait for a while until they get fixed. Stay on 18.1.0 firmware for now.

TBH I am not sure why XCI works but NRO forwarders don't because as far as I know they need the same patches? Maybe someone that knows alot about patches will know.

 

[Mars04]

Yep one of the FS patches needs fixed. ES patches work so you can launch installed NSP games, FS patches partially work in that I can run XCI games (tested on looney tunes wwos), NRO forwarders are not working for now. You'll just need to wait for a while until they get fixed. Stay on 18.1.0 firmware for now.

TBH I am not sure why XCI works but NRO forwarders don't because as far as I know they need the same patches? Maybe someone that knows alot about patches will know.

Hi, how did you get your sigpatches being applied with FW 19.0.0? I updated to AMS 1.8.0 and FW 19.0.0, but none of my installed NSP games work on emmunand...

Since there isn't a new Hekate yet, Hekate didn't boot to emmunand and gave a "not supported HOS" error. So I booted to my emmunand via fusee payload.

But that doesn't apply sigpatches. Is there already a new modified fusee out for FW19? or a newer Syspatch then 1.5.2?

 

[SamuelLG]

Hello. I need some help

I have an old version of switch (I bought it in 2018) and payed some guy to have a mod chip on it a few years ago (when SXOS was still a thing). Since SXOS died, I changed to Atmosphere/Hekate and the console works very well, from time to time I manage to make firmware updates on emunand and also updates on atmosphere / hekate / sigpatches. I load Atmosphere using the fss0=atmosphere/package3 method with sigpatches.

But for the last update, in order to play the newest zelda and mario party, I upgraded my emunand to 18.1.0 (sysnand is on 16.0.3), my atmosphere to 1.7.1, hekate to 6.2.1, sigpatches for 18.1.0 V2 and so on, but Hekate doesnt work properly anymore. When I turn on the switch, it loads the Hekate but it shows a bugged screen with no touchscreen, the buttons in the interface is misplaced and some "noisy" patches are all over the screen like when VGA on computers are dying.

I tried everything in my shallow knowledge, but the only thing that worked was going back to Hekate 6.1.1 (with atmosphere 1.7.0 and firmware 18.0.0). No issues with this previous version.

Whats going on?!