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

  • Thread starter Thread starter ShadowOne333
  • Start date Start date
  • Views Views 5,359,439
  • Replies Replies 7,392
  • Likes Likes 266
Hey, does anyone know if the Sig patches are included in the Deepsea pack?
As far as I can see, there are no sigpatches in either of their builds on their GitHub release page (at least not going by the folders and filenames they don't). I can't see sys-patch module either.
 
  • Like
Reactions: impeeza
Do people really care about a slightly quicker boot time that much? I get that it's only use was for piracy, but then that's probably 99% of AMS users.
He is really out of touch with reality or doesn't want to acknowledge the majority of users are pirates not to get attention from the nintenjas. But i agree. The boot time increase is negligible. The Switch has very fast SD access.
 
Do not use precreated sigpatches, no always works for everyone, disassemble system modules by yourself and patch your setup.
Yes, use sys-patch! :)

He is really out of touch with reality or doesn't want to acknowledge the majority of users are pirates not to get attention from the nintenjas. But i agree. The boot time increase is negligible. The Switch has very fast SD access.
He is not out of touch, he just doesn´t support piracy in any way.
And thats a good thing, he avoids being targeted by Nintendo lawyers this way.
 
I'm also interested, is emuNAND needed to boot via package3?

Do you mean booting sysnand instead of the emunand? It should work fine, just use emummc_force_disable=1 instead.

That's how my entries in the ipl file current looks like, i'll do some testing this weekend but from what i've been searching since i last posted this should work fine:

Code:
{-------- Stock -------}
[Stock]
fss0=atmosphere/package3
stock=1
emummc_force_disable=1


{-- Custom Firmwares --}
[CFW - FSS0 SYS]
fss0=atmosphere/package3
kip1patch=nosigchk
emummc_force_disable=1

[CFW - FSS0 EMU]
fss0=atmosphere/package3
kip1patch=nosigchk
emummcforce=1
 
  • Like
Reactions: SkullHex2
Do you mean booting sysnand instead of the emunand? It should work fine, just use emummc_force_disable=1 instead.

That's how my entries in the ipl file current looks like, i'll do some testing this weekend but from what i've been searching since i last posted this should work fine:

Code:
{-------- Stock -------}
[Stock]
fss0=atmosphere/package3
stock=1
emummc_force_disable=1


{-- Custom Firmwares --}
[CFW - FSS0 SYS]
fss0=atmosphere/package3
kip1patch=nosigchk
emummc_force_disable=1

[CFW - FSS0 EMU]
fss0=atmosphere/package3
kip1patch=nosigchk
emummcforce=1
Yeah that's right.
I don't know much about emuNAND and last time I saw a Hekate config it used fusee.bin to boot into sysNAND and package3 to boot into emuNAND. This is why I thought emuNAND and package3 could be related somehow.
Thanks for the config :3
 
Yeah that's right.
I don't know much about emuNAND and last time I saw a Hekate config it used fusee.bin to boot into sysNAND and package3 to boot into emuNAND. This is why I thought emuNAND and package3 could be related somehow.
Thanks for the config :3

If you were using fusee.bin if there was a emunand, the default config of payload=bootloader/payloads/fusee.bin would always boot Emunand. Using fss0 give you the options to boot SysMMC, EmuMMC, or Stock. In term of Fusee and Hekate they are both bootloader, you can use Hekate to chainload Fusee,bin.
 
  • Like
Reactions: SkullHex2
Do you mean booting sysnand instead of the emunand? It should work fine, just use emummc_force_disable=1 instead.

That's how my entries in the ipl file current looks like, i'll do some testing this weekend but from what i've been searching since i last posted this should work fine:

Code:
{-------- Stock -------}
[Stock]
fss0=atmosphere/package3
stock=1
emummc_force_disable=1


{-- Custom Firmwares --}
[CFW - FSS0 SYS]
fss0=atmosphere/package3
kip1patch=nosigchk
emummc_force_disable=1

[CFW - FSS0 EMU]
fss0=atmosphere/package3
kip1patch=nosigchk
emummcforce=1
Should I add something else to kip1patch? The Hekate README also mentions nogc to use together with stock=1, but I'm not sure if it could be useful on CFW too (although I believe it is intended to be used mainly on CFW). tbh I don't even know how many fuses are burnt on my unit, so it could actually be useless. But let's pretend no of fuses are burnt (or whatever the minimal amount is), should the entry look like this? kip1patch=nosigchk,nogc
 
I haven't booted via package3 in years, would this still be a good entry?
I'm not entirely familiar with the terms you guys are using here, what does it mean "booting via package3" if I may ask, in simple terms? I've noticed that @justinkb posted that if you need kip patches for "reasons" starting from the next Atmosphere release something will no longer work? How to fix or go around that?

Sorry if it's something trivial for you guys to understand but I'm relatively new to the Switch hacking scene and I'm hardly familiar with all the terms being used in discussions. ^^" I'd like to know more about this upcoming issue before I update my Switch when the time comes.
 
I'm not entirely familiar with the terms you guys are using here, what does it mean "booting via package3" if I may ask, in simple terms? I've noticed that @justinkb posted that if you need kip patches for "reasons" starting from the next Atmosphere release something will no longer work? How to fix or go around that?

Sorry if it's something trivial for you guys to understand but I'm relatively new to the Switch hacking scene and I'm hardly familiar with all the terms being used in discussions. ^^" I'd like to know more about this upcoming issue before I update my Switch when the time comes.
oky, few start concepts:

Bootloader, normally any electronic device have a small piece of code which is run at startup, that code, verify some devices and load the mininum code to load the next step of software. On Switch there is a bootloader, which is replaced by fuse.bin or for Hekate when you mod your console.

The first stage of bootloader, then loads a second stage called package3, which is responsible to setup all hardware and then load the nintendo firmware.

if you use Fusee.bin as payload the Atmosphère bootloader is used and then the package3 file is loaded and run which load the patched nintendo fimware with Atmosphère.

Also you can use Hekate payloads which load Hekate bootloader, then hekate can:
  • chainload fusee.bin and the process is as described before.
  • Use the Hekate's process and then Hekate read the package3 file, extract some code from it, and use own code to create a new stage of load, that new stage continue the process and loads HOS with atmosphère.
That behavior is controlled by the HEKATE_IPL.INI, by example:

Chainload Atmosphère's fusee.bin
Code:
{--- Atmosphère payload ---}
[Atmosphère (Payload)]
id=Atmosphere
payload=bootloader/payloads/fusee.bin
{--- Stock END ---}


Use the Hekate's bootlader process
Code:
{--- EMUNAND START---}
[CFW (EMUMMC)]
id=EMUNAND
emummcforce=1
fss0=atmosphere/package3
atmosphere=1
kip1patch=nosigchk
{--- EMUNAND END ---}

by default Atmosphère's bootloader read SDCM:/emuMMC/emummc.ini and if is present the EmuNAND is loaded.

On hekate the "emummcforce" directive tells what to do.

you also can force atmosphere to do not use a EmuNAND but I can not remember how :P
Post automatically merged:

Found how to chainload fusee.bin and disable Emunand from Hekate_ipl.ini:


Code:
{------ Atmosphere ------}
{Pick this option to launch CFW.}
[Atmosphere]
payload=atmosphere/fusee.bin
emummc_force_disable=1
{ }
 
Last edited by impeeza,
oky, few start concepts:

Bootloader, normally any electronic device have a small piece of code which is run at startup, that code, verify some devices and load the mininum code to load the next step of software. On Switch there is a bootloader, which is replaced by fuse.bin or for Hekate when you mod your console.

The first stage of bootloader, then loads a second stage called package3, which is responsible to setup all hardware and then load the nintendo firmware.

if you use Fusee.bin as payload the Atmosphère bootloader is used and then the package3 file is loaded and run which load the patched nintendo fimware with Atmosphère.

Also you can use Hekate payloads which load Hekate bootloader, then hekate can:
  • chainload fusee.bin and the process is as described before.
  • Use the Hekate's process and then Hekate read the package3 file, extract some code from it, and use own code to create a new stage of load, that new stage continue the process and loads HOS with atmosphère.
That behavior is controlled by the HEKATE_IPL.INI, by example:

Chainload Atmosphère's fusee.bin
Code:
{--- Atmosphère payload ---}
[Atmosphère (Payload)]
id=Atmosphere
payload=bootloader/payloads/fusee.bin
{--- Stock END ---}


Use the Hekate's bootlader process
Code:
{--- EMUNAND START---}
[CFW (EMUMMC)]
id=EMUNAND
emummcforce=1
fss0=atmosphere/package3
atmosphere=1
kip1patch=nosigchk
{--- EMUNAND END ---}

by default Atmosphère's bootloader read SDCM:/emuMMC/emummc.ini and if is present the EmuNAND is loaded.

On hekate the "emummcforce" directive tells what to do.

you also can force atmosphere to do not use a EmuNAND but I can not remember how :P
Post automatically merged:

Found how to chainload fusee.bin and disable Emunand from Hekate_ipl.ini:


Code:
{------ Atmosphere ------}
{Pick this option to launch CFW.}
[Atmosphere]
payload=atmosphere/fusee.bin
emummc_force_disable=1
{ }
Thank you very much for such a detailed explanation!
Does it replace sigpatches or is it used along side them?
It can be used alongside sigpatches. Should you forget to update your sigpatches, sys-patch should do the work for you. Unless it also needs an update, that is.
 
  • Like
  • Love
Reactions: zxr750j and impeeza

Site & Scene News

Popular threads in this forum