Hacking RELEASE Sigpatches for Atmosphere (fusee-primary only!)

[TheCasualties]

Im in 10.0.4 with emummc and i have problems with the burnout game.... always installs fine, but when i go to check corrupt data... There´s some corrupt data... i try diferents sd´s, installers, sigpatches... i make a nsp from the dump of my cartdrige, i make xci and convert to nsp... and always the same result... Any idea?

Did you try the archive bit fixer in hekate? Thats the only other option I can think of for you. It sometimes helps with 'corrupt data' error.

From hekate main menu, select tools, then the 'Arch bit - RCM - Touch..' line in the bottom right. Select fix archive bit.

 

[Ibcap]

Im in 10.0.4 with emummc and i have problems with the burnout game.... always installs fine, but when i go to check corrupt data... There´s some corrupt data... i try diferents sd´s, installers, sigpatches... i make a nsp from the dump of my cartdrige, i make xci and convert to nsp... and always the same result... Any idea?

How are you booting atmosphere? Are you using fusee primary?

 

[Mister_X]

I try a many many diferent ways... primary, secondary, with hekate, without hekate, formatting console, diferent cfw´s..... and always the same result.

 

[Ibcap]

I try a many many diferent ways... primary, secondary, with hekate, without hekate, formatting console, diferent cfw´s..... and always the same result.

Sounds like the issue is your game file then. Other cfw (reinx and sxos) contain working sigpatches in the download so they should work with no modifications required. That leaves the only consistent factor as your game.

 

[Mister_X]

Sounds like the issue is your game file then. Other cfw (reinx and sxos) contain working sigpatches in the download so they should work with no modifications required. That leaves the only consistent factor as your game.

Thanks for the info, but i try everithing, i try to convert the xci, i try with others customs firmwares, a new microsd, formatting the switch and starting from 0....

And when i go to check corrupt data... Zas! There´s some corrupted data (just at 99-100%)

 

[pofehof]

Its not misleading from the point of view from someone who wants to avoid launching sysMMC by accident and to incur a ban. It also doesn't make sense to check what you booted after the fact when only one tool will check what you boot beforehand.

Since when does loading simply Atmosphere without launching homebrew result in a ban? From what I have heard, just doing that shouldn't warrant one (according to Reswitched).

if you have AutoRCM enabled which there is no reason to use nowadays

I agree (which makes your point moot?). If you want to use both sysMMC and emuMMC, then there is no point in having AutoRCM. Also, in that use-case, you should simply be launching sysMMC normally, and emuMMC through a payload, because you shouldn't be installing any NSPs on your sysMMC (sigpatches are for installing NSPs).

And regardless of sleep mode, the slower boot time is still a con.

A non-game breaking one, similar to your point about not being able to switch between sysMMC and emuMMC, especially thanks to sleep mode being a thing.

In the end, fusee is inferior and useless compared to Hekate. If you want to use it, that is your perogative but it holds no value.

So, why are you in the fusee-primary topic if you believe this?

 

[Draxzelex]

Since when does loading simply Atmosphere without launching homebrew result in a ban? From what I have heard, just doing that shouldn't warrant one (according to Reswitched).

While it may or may not, it pays to err on the side of caution.

I agree (which makes your point moot?). If you want to use both sysMMC and emuMMC, then there is no point in having AutoRCM. Also, in that use-case, you should simply be launching sysMMC normally, and emuMMC through a payload, because you shouldn't be installing any NSPs on your sysMMC (sigpatches are for installing NSPs).

What I meant to say was there is no reason not to use AutoRCM. CFW allows systems to shut down properly so it should not be rebooting back into RCM and AutoRCM also saves wear & tear on your Joy-Con rail.

A non-game breaking one, similar to your point about not being able to switch between sysMMC and emuMMC, especially thanks to sleep mode being a thing.

Its still an advantage nonetheless that doesn't make fusee any more appealing. This just means that Hekate can do everything fusee can but better.

So, why are you in the fusee-primary topic if you believe this?

Because people are spreading fear and misinformation over the superior boot process.

 

[pofehof]

While it may or may not, it pays to err on the side of caution.

You can say that, but as long as you don't have installed NSPs on your sysMMC, or launch homebrew while connected to the Internet, there should be nothing to worry about.

What I meant to say was there is no reason not to use AutoRCM.

The reason to not use it, is if you want to boot into a clean sysMMC. If you are only booting into one of these, then AutoRCM is fine.

This just means that Hekate can do everything fusee can but better.

It's just a slightly different bootloader with a faster loading time. Once again, once the console is running, both fusee-primary and fss0 are the same.

Because people are spreading fear and misinformation over the superior boot process.

You're the only one who spread misinformation from what I have seen. You listed a bunch of hekate features that have nothing to do with fss0/fusee-secondary booting atmosphere (Hekate's payload doesn't boot directly into atmosphere). which ibcap called you out on.

Also, saying "fusee will not hesitate to kick you into sysMMC" is also pretty misleading since, by default, it'll always boot you into emuMMC as long as the partition is there (and was created through hekate, which adds the emummc.ini file).

 

[Draxzelex]

You can say that, but as long as you don't have installed NSPs on your sysMMC, or launch homebrew while connected to the Internet, there should be nothing to worry about.

There have bans without .NSP files or launching homebrew without being connected to the Internet.

The reason to not use it, is if you want to boot into a clean sysMMC. If you are only booting into one of these, then AutoRCM is fine.

You cannot boot into Hekate's Stock mode or sysMMC without burning fuses with Fusee and AutoRCM enabled. And Hekate's stock mode is similar enough to OFW that no one has been banned for it.

It's just a slightly different bootloader with a faster loading time. Once again, once the console is running, both fusee-primary and fss0 are the same.

You are only looking at it from the point of view while the console is running. Using fusee offers you no advantage compared to fss0.

You're the only one who spread misinformation from what I have seen. You listed a bunch of hekate features that have nothing to do with fss0/fusee-secondary booting atmosphere (Hekate's payload doesn't boot directly into atmosphere). which ibcap called you out on.

What are you talking about? I correctly listed the feature parity that Ibcap agreed with me on (e.g nogc). Also Hekate's payload not directly booting into Atmosphere is irrelevant since if you were going to recommend fss0, you would not tell someone to download it from Hekate's GitHub but a place that pre-bundles it such as SDSetup.

 

[phonz]

I try a many many diferent ways... primary, secondary, with hekate, without hekate, formatting console, diferent cfw´s..... and always the same result.

are the SD cards formatted as exFAT? have you tried installing to Console memory instead? *shrug* throwing spaghetti out there.

 

[kasboy]

any new sigpatched for error on 010000000000000D?
I think it's Edizon?

 

[pofehof]

There have bans without .NSP files or launching homebrew without being connected to the Internet.

Is there actual proof of this happening, or people saying that it happened, but it turned out that they did other things going on such as .nsp forwarders, tampering with save data for online games, etc.? Because, on ReSwitched, they have mentioned that atmosphere, homebrew, cheating in offline games, emuMMC, and couple other things have not resulted in a ban yet.

You cannot boot into Hekate's Stock mode or sysMMC without burning fuses with Fusee and AutoRCM enabled. And Hekate's stock mode is similar enough to OFW that no one has been banned for it.

Why would you ever want to boot hekate's stock mode or sysMMC in this use case? You are not supposed to install NSPs on it (if you want to avoid a ban), so you would just boot the console without RCM.

You are only looking at it from the point of view while the console is running. Using fusee offers you no advantage compared to fss0.

And in that point of view, fss0 doesn't offer you an advantage compared to fusee. In the end, the boot time is not a gamechanger since most people will simply put their console to sleep, not doing a speedrun to boot CFW.

Also Hekate's payload not directly booting into Atmosphere is irrelevant since if you were going to recommend fss0, you would not tell someone to download it from Hekate's GitHub but a place that pre-bundles it such as SDSetup.

It is relevant because no matter what, people who download atmosphere will also have fusee-primary.bin (since it's available in there), and people will notice that they could put that in the payloads folder for hekate, which is something most people would likely opt to do.

What are you talking about?

Talking about this post where you mention hekate tools and features are part of fss0. ibcap's reply to you is the same thing what I am saying ("The conversation is fss0 vs fusee primary."), though it seems that the initial question is misleading, since it says hekate vs. fusee instead of saying fss0 vs. fusee-primary.

In the end, I don't see how the other user was being misleading (other than one mentioning Homebrew being better on primary). As I keep on saying, when you were asked to elaborate on why you think fss0 is better, you mentioned hekate features that had nothing to do with it. That's where I'll leave this at.

 

[Mister_X]

are the SD cards formatted as exFAT? have you tried installing to Console memory instead? *shrug* throwing spaghetti out there.

Yes, i buy evena new sd card and formatting the console, and same result.

 

[Draxzelex]

Is there actual proof of this happening, or people saying that it happened, but it turned out that they did other things going on such as .nsp forwarders, tampering with save data for online games, etc.? Because, on ReSwitched, they have mentioned that atmosphere, homebrew, cheating in offline games, emuMMC, and couple other things have not resulted in a ban yet.

I run a banning thread which is pinned here by the way. You may want to check it out. ReSwitched don't have statistics to back up their claims.

Why would you ever want to boot hekate's stock mode or sysMMC in this use case? You are not supposed to install NSPs on it (if you want to avoid a ban), so you would just boot the console without RCM.

To avoid burning fuses but play the console online since a mismatched fuse count has no resulted in any bans as of yet.

And in that point of view, fss0 doesn't offer you an advantage compared to fusee. In the end, the boot time is not a gamechanger since most people will simply put their console to sleep, not doing a speedrun to boot CFW.

Never claimed it was a gamechanger. If you had 2 different routes to pick to reach your destination, would you pick the slower or faster one?

It is relevant because no matter what, people who download atmosphere will also have fusee-primary.bin (since it's available in there), and people will notice that they could put that in the payloads folder for hekate, which is something most people would likely opt to do.

Nope because people can download Hekate with fss0 pre-bundled such as from SDSetup. Downloading Atmosphere from the GitHub or anywhere else that doesn't bundle the patches is inferior and gives the user more trouble hence why its irrelevant because most people should be downloading Atmosphere with the patches pre-bundled.

Talking about this post where you mention hekate tools and features are part of fss0. ibcap's reply to you is the same thing what I am saying ("The conversation is fss0 vs fusee primary."), though it seems that the initial question is misleading, since it says hekate vs. fusee instead of saying fss0 vs. fusee-primary.

In the end, I don't see how the other user was being misleading (other than one mentioning Homebrew being better on primary). As I keep on saying, when you were asked to elaborate on why you think fss0 is better, you mentioned hekate features that had nothing to do with it. That's where I'll leave this at.

I already addressed what he said but you didn't check which he also agreed with (although I disagree with whose fault it is).

 

[pofehof]

I run a banning thread which is pinned here by the way. You may want to check it out. ReSwitched don't have statistics to back up their claims.

Would you say a majority of people were banned for simply using Homebrew, or a very small minority? Also, that is a thread that asks users to simply fill out a questionnaire with no proof of what they had installed (or lack thereof) on their Switch. Because of this, as I said, it's not farfetched to believe that the people who were supposedly banned for simply using Homebrew likely did other things that they do not want to admit to (such as cheating online, editing saves for games that can go online, etc.).

To avoid burning fuses but play the console online since a mismatched fuse count has no resulted in any bans as of yet.

But why would you worry about burnt fuses? SysMMC will always be on the latest firmware, whereas emuMMC could be on any old firmware because atmosphere would ignore the burnt fuse check? You seem to try to worry about something that isn't there.

Never claimed it was a gamechanger. If you had 2 different routes to pick to reach your destination, would you pick the slower or faster one?

By that logic, seeing that atmosphere patches are usually, if not, always updated first, you'd go for that. Nonetheless, unlike a different console, you are not constantly booting a Switch from an off position simply since you can always put it in sleep mode.

Also, I am curious as to where that user got their times, mainly the 17 seconds for fss0. I did my own test, and using fss0-fusee-secondary to sysMMC boot (the screen where you press a button three times) sysMMC took 32 seconds whereas fusee-primary to emuMMC (partition based) boot took 37 seconds, which is truly nothing to write home about (maybe due to the 400GB microSD card I'm using). Also, a 20 second difference isn't a big deal for a majority of people.

Nope because people can download Hekate with fss0 pre-bundled such as from SDSetup. Downloading Atmosphere from the GitHub or anywhere else that doesn't bundle the patches is inferior and gives the user more trouble hence why its irrelevant because most people should be downloading Atmosphere with the patches pre-bundled.

This is a third party setup which isn't promoted by hekate AFAIK. By that logic, anyone can make a download that has the latest update with a chainload for fusee-primary.

As for the second point, maybe for people who are not tech savvy, but for those who know what they are doing, fusee-primary is just as good.

I already addressed what he said but you didn't check which he also agreed with (although I disagree with whose fault it is).

I was never talking about the nogc issue, I was talking about you listing the hekate tools and features "AutoRCM, eMMC dumping, the battery desync fix, the archive bit, and so much more" as fss0 only which is the confusion I mentioned before (you went from talking about boot times to hekate features). You talking about those features would make sense if you were comparing hekate vs. fusee-primary payloads, but this was never what the discussion was about from what I have seen. The post you linked to doesn't have you addressing this confusion at all, you just double down on suggesting that fss0 has faster boot-time than fusee-primary.

 

[Draxzelex]

Would you say a majority of people were banned for simply using Homebrew, or a very small minority? Also, that is a thread that asks users to simply fill out a questionnaire with no proof of what they had installed (or lack thereof) on their Switch. Because of this, as I said, it's not farfetched to believe that the people who were supposedly banned for simply using Homebrew likely did other things that they do not want to admit to (such as cheating online, editing saves for games that can go online, etc.).

It doesn't matter how many people were banned as I never stated that majority of people were only banned for homebrew. You were the one insisting that people do not get banned for homebrew. I don't have to prove its the majority; just that its a risk factor like the rest of CFW. As for whether or not people are lying, Occam's razor dictates that it is easier to assume people are telling the truth than lying as you have to prove that people are lying. Lastly, ReSwitched are as fallible as the rest of us. There have even been times where they were proven wrong such as TX's modchip or using sept for booting firmware versions 7.0 or higher. And as I previously stated, they still lack any proof or statistics to backup their claims. If anything, they are reporting what other people have stated but their probing is unlikely to be as thorough or objective as mine since I don't see any ban report forms from them.

But why would you worry about burnt fuses? SysMMC will always be on the latest firmware, whereas emuMMC could be on any old firmware because atmosphere would ignore the burnt fuse check? You seem to try to worry about something that isn't there.

There is always the possibility that an untethered coldboot solution will be made available someday on lower firmware versions. Plus there is no advantage in burning fuses. Lastly, AutoRCM is a hack that is far more useful to have than to not and is one of the key requirements for preventing fuses from being burnt.

By that logic, seeing that atmosphere patches are usually, if not, always updated first, you'd go for that. Nonetheless, unlike a different console, you are not constantly booting a Switch from an off position simply since you can always put it in sleep mode.

That is a different line of logic as there is no benefit in obtaining the latest patches. The only scenario I can think of is when a new firmware is released requiring an update to ES and/or FS patches. However in those cases, there is still no benefit in updating as there is no content that would require that firmware in the time it would take fss0 patches to be updated. It may even be detrimental as not all homebrew or other tools may be equipped to work on the newest firmware or CFW.

This is a third party setup which isn't promoted by hekate AFAIK. By that logic, anyone can make a download that has the latest update with a chainload for fusee-primary.

Exactly my point. This is why I stated it was irrelevant since you can pack either fss0 or fusee with the patches. Just because Hekate doesn't directly boot into Atmosphere or Fusee lacks the patches for backups are equally irrelevant because both are missing key files that packs would solve.

I was never talking about the nogc issue, I was talking about you listing the hekate tools and features "AutoRCM, eMMC dumping, the battery desync fix, the archive bit, and so much more" as fss0 only which is the confusion I mentioned before (you went from talking about boot times to hekate features). You talking about those features would make sense if you were comparing hekate vs. fusee-primary payloads, but this was never what the discussion was about from what I have seen. The post you linked to doesn't have you addressing this confusion at all, you just double down on suggesting that fss0 has faster boot-time than fusee-primary.

I really hate to use this type of language but this is just stupid. This is the equivalent of quoting someone from a post they made a year ago if they said that there were no hacks for Mariko. You were only referring to part of a conversation rather than addressing the conversation in its whole. Obviously if you take it out of context it may sound stupid or uniformed but that is because the conversation didn't end there. This quite frankly, coupled with the earlier" issue" that most people disagreed was a non-issue, convinces me your here to argue for the sake of arguing rather than prove anything. Because you still have not listed any advantages to using Fusee while I have listed multiple for fss0. I have one and only one advantage in mind.

 

[Danethos86]

i know off topic but running
switch 9.2 ofw ams 0.13.0
do i keep 9.2 ofw or update ofw to 10.3 such with ChoiDujourNX thing?

 

[Tokiwa]

i know off topic but running
switch 9.2 ofw ams 0.13.0
do i keep 9.2 ofw or update ofw to 10.3 such with ChoiDujourNX thing?

Your choice, i know some people are still using 9.2 because none of the games they are currently playing requires 10.x.x

You can stay on that version until a game asks to update your firmware if you wish.

 

[suloku]

In case this is useful to somebody, these are the contents for booting in hekate_ipl.ini I use for hetake on my current setup to boot
- Sysnand latest firmare untouched (hetake's stock mode, uses fusee_secondary) --> online play
- Sysnand CFW atmosphere with no sigpatches via hetake (uses fusee_secondary) --> homebrew usage, mainly checkpoint for savedata. No sigpatches since there's no use for them here.
- EmuMMC atmosphere with latest firmware and latest patches. Uses fusee_primary via hekate. Additionally on this emuMMC I used incognito RCM to remove the prodinfo, I guess one could use the now configurable setting in atmosphere, I think this would clear prodinfo in both sysnand CFW and emuMMC CFW since it is a shared setting, if anyone has confirmation could please tell me?)--> this one I use for everything else.

[Stock (SYSNAND)]
emummc_force_disable=1
fss0=atmosphere/fusee-secondary.bin
stock=1
icon=bootloader/res/icon_switch.bmp
{}

[CFW (SYSNAND)]
emummc_force_disable=1
fss0=atmosphere/fusee-secondary.bin
atmosphere=1
logopath=bootloader/bootlogo.bmp
icon=bootloader/res/icon_payload.bmp
{}

[CFW (EMUMMC)]
emummc_force_enable=1
payload=bootloader/payloads/fusee-primary.bin
atmosphere=1
logopath=bootloader/bootlogo.bmp
icon=bootloader/res/icon_payload.bmp
{}

You may move any of these to a separate .ini file and place it on bootloader/ini/ folder and the boot option will appear in "other" in hekate. I actually have sysnand CFW boot option there.

This is what works best for my setup, allows me to use this sigpatches and run emuMMC trough atmosphere, while keeping hekate and the benefits of launching CFW on my sysnand for some homebrew. I think many people use this setup, hope it helps.

 

[pofehof]

This quite frankly, coupled with the earlier" issue" that most people disagreed was a non-issue, convinces me your here to argue for the sake of arguing rather than prove anything. Because you still have not listed any advantages to using Fusee while I have listed multiple for fss0. I have one and only one advantage in mind.

To be fair, you haven't responded to the part where I mentioned that fss0 to sysMMC = 32 second boot and fusee-primary to emuMMC = 37 second boot. The fact that you are suggesting a bootloader for booting a whole 5 seconds faster (let alone 20 seconds) is a huge advantage for something a standard user might notice a few times a month is very ridiculous.

Also, no, I'm not arguing for the sake of arguing. Just showing your hypocrisy since you said that people were being misleading about fss0. With you being misleading on trying to promote hekate features as features solely for fss0, you try to say things such as:

"For example, you cannot tell if you booted emuMMC or not with Fusee unless you use different themes"

Which is laughable since, assuming that people installed games on the emuMMC, they will be able to tell the difference in the list of games that appear, and

"even then, fusee will not hesitate to kick you into sysMMC."

Which is even more misleading, because as long as emummc.ini's value doesn't change (and maybe the raw partition doesn't get corrupted), this will never happen